(bright upbeat music)
>> Okay, welcome back to Docker main stage.
It's theCUBE coverage of DockerCon 2022.
I'm John Furrier, host of theCUBE.
We're here with a special segment with Snyk.
We've been partnering with Docker,
going back to the early days,
cloud native container vulnerability scanning
within Docker desktop in 2020.
We got Mic McCully, Field Strategist at Snyk.
Mic, thanks for coming on the cube.
>> Thanks for having me, glad to be here.
Excited to have this conversation.
>> Yeah, love the background.
I'm a big football fan myself,
and love that little mention there.
Love the Snyk logo too.
Good plug there.
But I want to get into that, the security
you guys were of the first conversations
when shift left was hot
when it just started to come and it's never going away
but now there's been a huge focus
and an increase of concerns around vulnerabilities
within the supply chain of security software.
So in open source software.
So what are you guys doing now?
Cause this is a new focus in the industry.
Everyone's talking about it
your company's making changes and mitigate that risk.
What do you guys have?
>> Yeah, it's a great question.
And shift left is definitely a big focus of ours, right?
It's what sort of our core foundation is what we based
our whole approach
to software supply chain definitely has made its way
to the top of the spectrum as far as conversations,
and I think it plays very well into our focus.
You know, one of the things that I believe
a lot of organizations are focused on
is trying to get a hold of understanding
a lot of the implicit trust
and risk associated with everything that goes
into building any sort of modern application.
And that's all of the components that are being used,
everything from the open source,
to the containers that are consumed, to the process
into all of the ecosystem and tooling
that's consumed a lot of the trust layers in there.
It's extremely important to understand what that is.
What's the risk, right?
And from a Snyk perspective,
taking that intelligence and trust
and giving it back to the developers
when they're making those decisions,
is our focus like that, that whole concept
of taking all of that security expertise
and pushing it back to the individuals,
making those decisions,
I think is probably one
of the more powerful ways
that you can start to implement
some more security controls,
and get some trust and understand your risk process
throughout that software supply chain.
>> Okay. So you said trust three times,
I'm going to come back to that
because shifting left is all about empowering developers
but what good at shifting left
If you got to stop and then go back and research
something that wasn't in your pipeline
or something else happened?
So open source obviously is growing like a weed,
it's continuing to exponentially grow
and more people are doing it,
commercialization as well,
but the word trust is not zero trust.
You're hearing people use the word zero trust security
that's different, right?
They're talking about developers looking for trusted code.
So it's interesting, you got hackers
and zero trust, and you got developers and trust
and you got software in between.
This is kind of the core issue here, isn't it?
>> It is because of that using, I mean,
there's huge advantages
with all of these new approaches, right?
Leveraging the open source and the containers,
and the software packages
and these ecosystems to automate
a lot of those software processes,
but doing so means that
you've got this implicit trust that's there,
and so taking and trying to identify
and share those details with the developers
when they're making those decisions
but it doesn't stop there, right?
Like that's one of the other important aspects
of this is what organizations
have to do is to not only provide that
and help those individuals
when they're making those decisions
but then constantly understand
if that posture changes at any given time, right?
and knowing where it's happening, what is it, how do I prove
and have some of the providence details
of the origination of the information,
how can I trust to make sure
that the security was accounted for
for all the components
that I'm actually leveraging and using,
and then making sure that
you have that visibility
through that the entire life cycle.
That's probably one of the other important areas.
So it's not only sort of giving that information
in details and trying to take advantage of all of that
that early detection response and decision making process.
But it's also maintaining that understanding
of what that is, and that trust plays into that, right?
There's so much implicit trust associated with it.
And the more that you can understand it, comprehend it
take control of it, the better your organization
from a security posture's going to be.
>> Yeah. I mean, you've got builders and attackers.
I mean, it's clearly the spectrum
and the builders want the a hundred percent trust.
And I think this is going to be such an important
game changing topic that has to be addressed.
It's the only way with the scale
you're seeing and the growth of software,
and by the way, open source become much more
than just open source it's community.
It's social people kind of hang out
and build code together and then ventures are being started.
So this is a nice progression.
Makes a lot of sense.
I have to ask you though,
what are some of the of the data say on the attacks?
Is it increasing?
at what rate?
What's the complexity look like?
What's it look like as it evolves?
Because, you know,
even though it's zero geo trust on one side
and trust on the other,
the attackers also adjust too.
>> Yeah.
>> So what's-
>> it's a very good question.
I think that's what we're seeing is
and this is just a natural evolution,
I think there's been, you know
an historic focus on a lot of the security associated
with running applications and locking them down.
And I was reading blog just by Docker the other day
about how it's like this hardened sort of outside layer
but there's this soft squishy inside,
that soft squishy inside is all
of those building components that are inside of there.
And because of that hardened layer,
it makes those attack vectors, right?
When you're trying to penetrate those.
And so what we've seen is this natural evolution is say,
well, let's go find the weak link,
let's go understand,
if there's a way to actually bypass these security controls.
And sometimes the ways to do that is to simply go upstream
into the process in which the application's being built.
If I can go upstream and actually change
some of those components
and implement my attack inside of the application,
it automatically gets embedded
instead of trying to attack it directly.
And so we're seeing that
and it's what's making a lot of the news
and why some of the conversations
around software supply chain are becoming very prominent.
It's this ecosystem.
And unfortunately, you know,
in a lot of organizations that I think
some of that development area
hasn't had that security focus
as a lot of the traditional areas associated
with applications and exposure of your organization
because of that,
it's left a little bit more exposed, right?
That trust that we talked about in addition
to the processes has to have a little bit more
of that security ingrained inside
of those processes to make sure
that it's not being left open.
It's not an open door, an open window
that's giving sort of an easy route into the application.
>> Yeah, totally.
I totally see that in the next.
In the last couple minutes we have left,
I want to get into what you guys are doing
with your customers
and what our company's doing to mitigate the risks
in the software supply chain.
Obviously open source is not going away.
It's only going to be part of it.
what's going on with the customers?
>> Yeah, it's a great question.
And a big focus of ours
is to help organizations understand
all of those areas as much as possible, right?
And to provide them that guidance.
And part of this is not only the solution
and how we deploy it and how we can deliver it,
but it's some of the security intelligence
associated with it,
instead of putting the burden on our customers
of trying to stay on top of all of that risk, right?
Where is all of these different moving parts
and something changes from being completely fine one day
to, you know, a high vulnerability and risk posture.
How do you react to that?
And so providing as much of that insight
guidance and prioritization and the details
to those organizations in an actionable format
that's probably one of the more core elements to this.
It's not just the,
"Hey here's a whole list of all your problems",
It's what do you do?
Like how do you take all of that information,
those details, those risks,
how do you prioritize them?
what's the steps that you take
from an action perspective
in order to address those, right?
If I've got a container with some problems,
what is sort of the recommended approach
to solving that?
What should I upgrade to?
What is the guide associated with those?
And so a lot of it is focused
on providing not only the insight
and the ability to react and understand
that risk at any given time
but also more focused on what do you got to do, right?
How do you actually take steps to alleviate
or mediate that risk as much as possible?
>> That's a good point.
What's so I have to ask you,
what's the difference
between getting it right and getting it wrong
or in other words,
why do some supply chain vulnerabilities remain unfixed
and deprioritized?
Why isn't it going faster?
>> Yeah. And some of that,
there's reasons across the board, right?
Some of it crossed from the perspective that
there might not be fixes.
And so in some of those cases
just being aware of what that risk is,
so you can put in
other mitigating controls in order to accommodate those.
In other cases,
it's prioritizing where your risk is most important, right?
And part of this also stems from the fact that,
if you fall into sort of that reactionary bucket,
then you have to be
in sort of that prioritization reactive mode.
The more that you can push this back
to that early process,
the less that that has to occur,
because you have the ability
to actually make the best decision possible
with the information you have during that early process.
So, some of it's just, you know,
predicated on the fact that
there's not always solutions to all the problems.
And then a part of this too,
is where in the phase
are you actually starting to attack and handle it?
>> All right, thanks for coming on,
I really appreciate it.
Business is good at Snyk.
Thanks for sharing your insights here
on the on The Main Stage. Okay.
This is theCUBE back to the DockerCon main stage.
We'll be back more.
See you soon.
(upbeat music)