Global security at maximum velocity: Multi-Region and hybrid DevSecOps @ AWS re:Invent 2022

– So, today we are going to be talking
about global security at maximum velocity.
Yes, that’s a lot of fuzzy words all put together.
But first, let me introduce who I am.
So I’m William Manning or Bill Manning,
whatever you wanna go by.
I’m the solution architect
and also solution engineering manager for JFrog.
If you’re not familiar with who JFrog is,
we’re the (indistinct) little company
that you’ve never heard of.
So our main product that you already probably realized
is called Artifactory.
Over 7,000 organizations globally use us,
almost 100% of the Fortune 100,
the top 10 auto manufacturers,
top 10 banks in the world.
We manage the software that companies use and produce.
Everything from the transitive dependencies
that make up your software
to the software you produce,
we have over 30 package types we support out of the box.
One of the reasons why we talk
about also global
is the fact that you can actually take our product,
install it in multiple regions globally around the world.
We have customers that are using everything
from the single instances,
running inside of their AWS VPC,
all the way up to 38 instances for global security.
The thing is,
is that today, what we are going to be talking about,
in addition to this,
is the fact that we are governance board members
of the cloud native foundation.
We are also a CNA,
So we are also a certified, well, CVE number authority.
And on top of that,
the bigger reason why I’m here is this.
Software supply chain security.
We hear about this all the time.
Everybody knows this word
and the series of phrases
because of things like SolarWinds, right?
SolarWinds affected 18,000 customers around the globe.
It actually was like $100 billion remediation.
And just to let you know,
what caused the problem was a transitive dependency.
A dependency that was used to build the software
that SolarWinds put out there.
And in this case,
it happened to be a fifth level transitive dependency.
So it was not even directly asked for.
It came along for the ride.
It’s called an indirect transitive dependency.
So the thing is,
is that when you talk about software supply chain,
what JFrog does is,
you have your code at the top.
The thing is,
is that actually 85% to 90% of the software you produce,
whether that’s low level C code,
all the way up to things
like Docker containers and orchestration
are actually someone else’s.
These are people you don’t know.
The thing is,
is that when you talk about software supply chain,
one of the key problems that we run into today is,
is that developers are artisans.
Let’s just put it out there.
They are artists.
Code is their craft.
This is what they do.
And to do the job that they do,
they depend on these dependencies.
And the problem is,
is that how do you know how safe and secure
those components are?
And the thing is,
is that I love this quote.
This quote is one of my favorite things
I’ve ever seen.
Every time you pip install, go get, mvn fetch,
this also includes helm updates,
this also includes Docker pulls.
It’s basically the equivalent of taking a thumb drive
you found on the street
and plugging it into your production server.
That doesn’t sound safe at all, right?
Or you’re actually uploading things into AWS,
you’re pulling Docker images,
and I’m gonna show you an example
of a terrifying one in a few minutes.
But the thing is,
is that how do you have that level of protection
to ensure that your company does not become a headline.
So 99% of the codebase that,
you know, that 85 consumes,
75% of that contains at least one major vulnerability.
Think about that.
You have no idea where this is coming from
and you’re introducing things
that could potentially threaten
your company reputation, financially.
Lots of different aspects behind it.
And the thing is,
is that 49% of the code base that we analyze
has at least one highly-risk item.
Think about this.
I mean this is things like exposing your ports,
or you know, creating a,
like, I’ll show you an example in a bit.
There’s a service in the Docker container I downloaded
that starts a service
and sends a request to somewhere in Asia.
It establishes a connection
and starts sending the data from my container somewhere.
No idea where it goes.
And the thing is,
is that, the other thing too is the longevity of these.
These actual software transitive dependencies
your developers use,
90% of them are old, outdated, never updated,
or they’ve just been completely abandoned.
The thing is,
this is the number that you should all be terrified about.
A 650% in supply chain attacks.
The software that your developers use to do their job
are highly compromised.
So what we do in terms of security at JFrog
is we have end-to-end DevSecOps,
everything from shift left all the way to shift right.
And we also work completely through your SDLC.
So we also manage the software development life cycle
of every piece of code you do,
even combined entities like Docker images
where you create applications and you host them.
We also help accelerate releases when you do this.
And fortify what you do by preparing actual security
using our Xray product,
all the way from developer to deployment,
or code to cloud.
I do a lot of work with the US military,
and we say from compile to combat.
Also too, we scale with your organization.
So we provide global coverage
for your organization to do the job that they do
while ensuring safety and security at the same time
we also streamline your ability to do compliance.
Everybody out there these days
talks about Software Bill of Materials.
(indistinct) in our end.
The reason why that came about was in May, 2021,
the Biden administration,
in reaction to the SolarWinds incident that happened,
put together a series of guidelines.
And one of the guidelines that was part of this
was the whole idea
of having a Software Bill of Materials.
The ingredients.
Funny story, by the way, Software Bill of Materials
was actually first proposed
by the Food and Drug Administration.
Because medical devices have software.
And the software devices,
you need to have accountability.
‘Cause if you put a pacemaker in
with nefarious materials,
and you suddenly kill somebody,
you’re gonna wanna know.
So in addition to that,
we actually look at all the various aspects
in which you actually build your software.
Like I said, whether you’re a lease manager,
whether you’re a security admin,
whether you’re a developer, doesn’t matter.
We supply tools to make the jobs easier
for the organizations at large.
So the thing is,
we could scan any sort of content.
And we have just recently, by the way,
introduced infrastructure as code analysis.
So if you’re using something like Terraform,
are you potentially deploying your infrastructure
in a bad way?
We scan Docker containers.
Now, not just the application layer,
but the OS, the runtime,
all the pieces that make that up.
We also integrate across the board,
we are truly universal
in the aspect in which we deploy and build our staff.
So you can use any CI,
you can use any CD.
You can actually integrate it the way you want to.
We make it fully malleable and deployable.
You get complete visibility from day one
when you start utilizing us,
what makes up your software?
How is it made,
What’s the life cycle of that software?
Why am I doing it?
And we also provide protection
around things like malicious code detection.
We also provide things like Zero-Day analysis.
And in addition to that,
any product out there that the security can tell you
when and what’s happening,
we tell you where and how long
and how it’s affecting you.
And you get to control your own destiny
by controlling your security posture,
and the fact that you can also be hybrid.
So if you,
we have a lot of companies
hearing this digital transformation,
the latest buzzword of moving
from your own DC up into AWS.
I actually did a talk last week with AWS
and how you can use our platform
to migrate your development organization from your own DC
up to the cloud itself
using our techniques like replication.
Now, on top of that,
when we start doing this,
we’ve actually now broached into the next segment of this.
So the thing is,
is it’s not only the pieces that you use,
but also the things that are introduced.
So we’re also now doing infrastructure as code analysis.
We actually can show secret detection.
We have malicious code detection,
also things like application level exposures
and also services exposures.
I’m gonna show you an example of a Docker container
that I actually downloaded off the internet
and ran our scans against it.
And when I show you what’s inside,
it’s pretty terrifying,
because all I did was type in Docker Python host,
and it came back with a link to a Docker hub image
to run my Python code.
So really fast,
let me explain to you the platform
and why it’s important.
And we’re gonna go from here,
so we’re gonna go from developer to deployment.
Our primary component,
basically the cornerstone of what we do as a technology
is our Artifactory component.
Now, Artifactory is the universal binary repository manager,
as I said before,
over 30 package types.
So we actually maintain and manage
the third-party transit dependencies
you used to build your software
and the software you produce.
We use that in conjunction with our Xray product.
Xray is our security compliance,
license, you know, vulnerability.
And also, a new other concept called operational risk.
What is the health of the open source project
supplying you with the software
that you’re actually using,
the libraries you’re using to build it?
So the far right over here we have
is we have like shift right,
which is we have distribution and connect.
Distribution is a way for you to produce software
like web services where you have Helm charts and Terraform
and Docker images that constitutes a web service.
You have your AWS set up
with multiple regions around the globe,
you can use our Artifactory Edge nodes
to deploy the software
to those regions more succinctly.
Add in a layer of security there
to ensure that the things
that you’re putting into production are safe and secure,
even up to the last minute before it is deployed.
Below that, we have Connect.
Connect is our IoT process.
IoT in terms of an MDM,
so it’s a device manager.
It’s also a device updater,
it’s a remote diagnostic tool.
And on top of that,
you can also pull things like logs,
and also send events and get correlated information.
We actually have some of the largest names
in this space utilizing this right now,
in a couple of military organizations also.
And at the bottom of this,
we have JFrog Pipelines.
It’s our CI/CD, NCI orchestration tool.
It’s actually completely built using Kubernetes.
You can design the runtime
to execute on what you want.
Whether it’s Debian-based, CentOS-based, or Windows-based.
It’s all based in YAML, for better or for worse.
You can actually extend it,
you can also templatize it to make it more easier
to actually implement.
And then at the same time too,
we don’t do plugins, we do integration.
So it’s full native API integration,
it’s a third-party resources.
Now, when it comes to security,
we talked about things of where does it matter most?
Well, some of the things you should know is,
is that we have things like ID plugins.
So this way, you can,
your developers can actually go ahead
and attack the security flaws and issues
where it matters most.
Where the ROI is greatest in any organization,
which is at the developer.
As I stated, all developers are artisans.
So at the same time,
we proxy any third-party request
for the libraries they use through Artifactory
out to the outside world,
we bring them in,
and then we distribute them to the developers.
So if you have 1,000 developers in your organization,
and developer zero brings down a library
and all its transitive friends.
That means all 999 other developers
will be able to use the same thing.
We can also, with Xray,
pre-evaluate those binaries before they get used.
So in other words,
the libraries that your developers depend on,
we can evaluate them to see if there’s any security flaws,
any security issues preemptively
before they even use it.
You can also integrate this into any CI environment,
whether you’re using Jenkins,
whether you’re using Buildkite, you’re using Azure DevOps,
whatever you’re using as an organization.
‘Cause we realized,
all DevOps organizations these days
use a cornucopia of different materials.
And the thing is,
is that we take this whole idea
and we go all the way to the end,
and also give the ability
to produce the Software Bill of Materials
that I stated before.
Here’s an example of an MPM
that I’m actually working on.
I’m actually working on this project.
We’ve actually broken down the hierarchy
of third-party transitive dependencies
that I need from my project.
I can also show you that I found all these CVEs
with this particular library called Lodash
that I’m utilizing right now.
I can also, as a developer,
know that I’m introducing something potentially malicious
into the code I create.
And the thing is,
is that we also provide a remediation analysis of that.
So I can actually, as a developer,
remediate it where I need to be
by actually upload,
you know, by actually utilizing the ones that I need.
Oh, so I downloaded this container off the net,
and one of the things is I found all these actual threats
and vulnerabilities inside.
These are all violations of everything I found
inside this default container.
But I only have a few minutes left,
I’m gonna show you some interesting things.
So first of all,
here is a series of vulnerabilities that I found
inside of of this.
Now, most tools can tell you directly,
by the way, that you have these,
I guess I shouldn’t step there,
you have these problems.
Now, early detection is something that’s key,
but the other problem is,
is you still have to research
whether or not you’re actually utilizing,
maybe the nefarious component.
If it’s a library with 100 functions,
and one is bad,
do you throw it out?
We just introduced a new feature,
and this idea is simple.
It’s called applicability.
Is the CVE that is actually in question here,
is it applicable to the way you’re using it?
So if you look here,
you can actually see,
that this CVE is applicable.
And I can go in,
and it tells me exactly where I need to go to fix it.
The remediation time is cut down
to minutes as opposed to hours
or potentially longer.
But I could also tell you
that even if say, a library is terrible,
like in this case,
this is actually,
if you’re familiar, by the way,
with CVEs and CVSS scoring, this is a 9.8.
Which basically says it’s gonna burn your company
to the ground if you use it.
The problem is,
is that its one function.
And in says, if I go in and I use this function,
I’ll be in violation,
but I’m not.
So we’re letting you know
that you can keep using this library
with a less threat unless you’re doing it.
Now, our product is continuously scanning
as opposed to,
because we own the binaries.
And that means that when you look at this information,
you have quick remediation.
This is the one that cracks me up the most though.
Secrets, right?
We all know about secrets.
Well, check this out.
I downloaded this,
and it’s a clean image.
But when we did our scan,
it let me know that there was some play,
basically APIs keys found.
And if you look, by the way,
they’re actually AWS.
Now, this came from somewhere.
But watch this,
where did I find these API keys, right?
Actually, it’s under slash, root, dot ash,
underscore, history.
So these were actually retained as a history function
as opposed to something that was just publicly out there.
Nobody went into,
and cleaned out the root user access in this case.
Other things that we do too is,
is that even things I told you about the service
that was exposed,
well, here it is right here.
So this service actually was running in this container,
and when I started it,
I did a wire sniff
and found out that I actually was establishing
a TLS connection to somewhere out in the world,
and all the data from my container
was being piped up through it.
So the thing is,
is that understanding the pieces that go into it
is really essential,
even down to the fact
that if you are using,
say like anything like Docker container images
that you might have.
And you know, any other Docker registry even,
you know, looks like this, right?
My ability to show you the layers of a container.
But I can also show you,
if you use Artifactory in our platform,
here’s the application layer of my Docker image.
If I ask you in the normal Docker container
what’s running, it’s hard to tell.
And also too,
being able to understand where you’re using it
and how it’s being used.
Because I can also tell you,
this is the build that produced it
and here’s every container that’s used it.
So it’s not just about detection,
it’s not just about what’s inside,
but understanding the data to go ahead
and actually remediate
and do the things that you need to do.
So we provide tools for end-to-end,
and there’s a reason why we’re the trusted source
when it comes to this.
So I know I’ve got a couple of minutes over,
and I’m gonna try to push the buttons again.
I push buttons.
There we go.
And all I wanted to say is,
come by, we’re actually located on the other side.
I think it’s 40, 4800 something.
It’s one of the addresses over there.
We have a complete demo of all these components end-to-end.
And just wanna say thank you for your time,
and come by if you have any questions.
I’ll be around.