Automated Vulnerability Detection throughout your Pipeline - Brian Vermeer from Synk
Cloud CommuteMay 10, 2024
1
x
11
00:24:5022.74 MB

Automated Vulnerability Detection throughout your Pipeline - Brian Vermeer from Synk

Brian Vermeer from Snyk, a cybersecurity company providing tooling to detect common code issues and vulnerabilities throughout your development and deployment pipeline, talks about the necessity of multi checks, the commonly found threads, and how important it is to rebuild images for every deployment, even if the code hasn’t changed.

If you have questions to Brian, you can reach him here:

If you are interested in Decodable, you can find them here:

Additional show notes:

The Cloud Commute Podcast is presented by simplyblock (https://www.simplyblock.io)


01:00:00
The thing is in the Java world,

01:00:01
it's either not so big or very

01:00:04
big. There's no in between, or at

01:00:05
least it doesn't get the

01:00:07
amount of attention, but yeah,

01:00:08
Log4Shell was a big

01:00:10
one because first of all, props to

01:00:14
the folks that maintain that,

01:00:15
because I think there were only

01:00:16
three active maintainers at that

01:00:17
point when the thing came out and

01:00:19
it's a small library that is

01:00:22
used and consumed by a lot of

01:00:24
bigger frameworks. So everybody

01:00:26
was looking at

01:00:27
you're doing a bad job.

01:00:28
It was just three guys that

01:00:30
voluntarily maintain it.

01:00:37
You're listening to simplyblock's Cloud Commute Podcast,

01:00:40
your weekly 20 minute

01:00:41
podcast about cloud technologies,

01:00:43
Kubernetes, security,

01:00:44
sustainability, and more.

01:00:47
Welcome back everyone. Welcome

01:00:48
back to the next episode of simplyblock's

01:00:50
Cloud Commute podcast.

01:00:52
Today I have yet another amazing

01:00:54
guest with me, Brian from Snyk.

01:01:01
That's always the question, right?

01:01:02
How do you pronounce that name? Is

01:01:04
it Snek, Snik, Synk? It's not

01:01:06
Synk. It's actually it's Snyk.

01:01:10
Some people say Snyk, but I don't

01:01:12
like that. And the founder wants

01:01:14
that it's Snyk. And it's actually

01:01:16
an abbreviation.

01:01:18
All right, well,

01:01:19
we'll get into that in a second.

01:01:21
So now you know, I mean.

01:01:22
Yeah, we'll get back to that in a

01:01:24
second. All right. So you're

01:01:26
working for Snyk. But maybe we can

01:01:30
talk a little bit about you first,

01:01:32
like who you are, where you

01:01:33
come from. I mean, we know each other for a

01:01:35
couple of years, but...

01:01:37
That's always

01:01:37
hard to talk about yourself,

01:01:38
right? I'm Brian Vermeer. I live

01:01:41
in the Netherlands, just an hour

01:01:42
and a half south of Amsterdam.

01:01:44
I work for Snyk as a developer

01:01:46
advocate. I've been a long term

01:01:49
Java developer, mostly back end

01:01:51
developer for all sorts of jobs

01:01:53
within the Netherlands. Java

01:01:55
champion, very active in the

01:01:57
community, specifically the Dutch

01:01:58
community. So the Netherlands Java

01:01:59
user group and adjacent Java

01:02:02
user groups do some stuff in the

01:02:04
virtual Java user group that we

01:02:05
just relaunched.

01:02:07
That I've tried to

01:02:10
be active and I'm just a happy

01:02:11
programmer.

01:02:13
You're just a happy

01:02:14
programmer. Does that even exist?

01:02:17
Apparently, I am the living

01:02:19
example.

01:02:20
All right, fair enough.

01:02:21
So let's get back to Snyk and the

01:02:24
cool abbreviation. What is Snyk?

01:02:27
What does it mean? What do you

01:02:29
guys do?

01:02:30
Well, what we do,

01:02:31
first of all, we create security

01:02:33
tooling for developers. So our

01:02:35
mission is to make security

01:02:38
an integrated thing within your

01:02:41
development lifecycle. Like in

01:02:43
most companies, it's an

01:02:44
afterthought. Like one security

01:02:46
team trying to do a lot of things

01:02:47
and we have something in the

01:02:48
pipeline and that's horrible

01:02:50
because I don't want to deal with

01:02:52
that. If all tests are green, it's

01:02:53
fine. But what if we perceive it

01:02:57
in such a way as, "Hey, catch it

01:03:00
early from your local machine."

01:03:02
Just like you do with unit tests.

01:03:05
Maybe that's already a hard job

01:03:06
creating unit tests, but hey,

01:03:07
let's say we're all good at that.

01:03:11
Why not perceive it in that way?

01:03:12
If we can catch things early,

01:03:14
we probably do not have to do a

01:03:16
lot of rework if

01:03:17
something comes up.

01:03:21
So that's why we create tooling

01:03:22
for all stages of your software

01:03:24
development lifecycle.

01:03:25
And what I said, Snyk is an

01:03:27
abbreviation. So now you know.

01:03:30
So what does it mean? Or do you forget?

01:03:31
So Now You Know.

01:03:34
Oh.

01:03:36
Literally. So now you know.

01:03:39
Oh, that took a second.

01:03:40
Yep. That takes a while for some

01:03:43
people. Now, the thought behind

01:03:45
that is we started as a

01:03:47
software composite analysis tool

01:03:48
and people just bring in

01:03:52
libraries. They have

01:03:53
no clue what they're

01:03:53
bringing in and what kind of

01:03:55
implications come with that. So we

01:03:59
can do tests on that. We can

01:04:01
report of that. We can make

01:04:02
reports of that. And you can make

01:04:04
the decisions. So now at least you

01:04:06
know what you're getting into.

01:04:07
Right. And I think with

01:04:09
implications and stuff, you mean

01:04:13
transistive dependencies.

01:04:15
Yeah.

01:04:15
Stuff like that.

01:04:16
Yeah. Yeah.

01:04:17
And I guess that just got worse

01:04:19
with Docker and images and all

01:04:22
that kind of stuff.

01:04:24
I won't say it gets worse. I think

01:04:26
we shifted the problem. I mean,

01:04:29
we used to do this on bare metal

01:04:33
machines as well that these

01:04:35
machines also had an operating

01:04:37
system. Right. So I'm not saying

01:04:39
it's getting worse, but developers

01:04:43
get into more responsibility

01:04:45
because let's say we're doing

01:04:48
DevOps, whatever that may mean. I

01:04:49
mean, ask 10 DevOps engineers.

01:04:52
That's nowadays a job. What DevOps

01:04:55
is, you probably get a lot of

01:04:56
questions about tooling

01:04:57
and that, but apparently what we

01:04:59
did is tearing down the wall

01:05:00
between old fashioned developer

01:05:02
creation and getting things to

01:05:05
production. So the ops folks, so

01:05:07
we're now responsible as a team

01:05:09
to do all of that. And now your

01:05:12
container or your environment,

01:05:14
your cluster, your code is

01:05:17
all together in your Git

01:05:20
repository. So it's all code now.

01:05:22
And the team

01:05:23
creating it is responsible

01:05:26
for it. So yes, it shifted the

01:05:28
problem from being in separate

01:05:29
teams now to all in one team

01:05:33
that we need to create and

01:05:34
maintain stuff. So I don't, I

01:05:36
don't think we're

01:05:36
getting into worse

01:05:37
problems. I think we're, we're

01:05:39
shifting the problems and it's

01:05:40
getting easier to get into

01:05:41
problems. That's, that's what I,

01:05:42
yeah. Yeah. Okay. We're, we're

01:05:43
broadened the scope of,

01:05:45
of where you could potentially run

01:05:47
into issues. So, so

01:05:48
the way it works is that

01:05:50
Snyk, I need to remember to say

01:05:52
Snyk and not Snyk

01:05:53
because now it makes sense.

01:05:56
I am, I'm not, I'm not very, I'm

01:05:58
not, I'm okay with however you

01:06:00
call it. As long as you don't

01:06:01
say sync, I'm fine. That's, then

01:06:03
you're actually messing up letters.

01:06:05
Yeah, sync,

01:06:05
sync is different. It's, it's not,

01:06:08
it's not awkward and it's not

01:06:09
Worcester. Anyway. So,

01:06:13
so that means the, the tooling is

01:06:16
actually looking into, I

01:06:18
think the dependencies,

01:06:20
built environment, whatever ends

01:06:24
up in your Docker

01:06:24
container or your

01:06:27
container image. Let's say that

01:06:29
way, nobody's using Docker anymore.

01:06:32
And all those other

01:06:36
things. So basically everything

01:06:38
along the

01:06:39
pipeline or the built

01:06:41
pipeline, right? Yeah. You can say

01:06:44
that actually we start at the

01:06:45
custom code that you're actually

01:06:46
writing. So we're doing static

01:06:47
analysis on that as well. Might

01:06:50
combine that with

01:06:52
stuff that we know

01:06:53
from your, let's say all your

01:06:54
dependencies that come in your

01:06:56
dependencies,

01:06:57
transitive dependencies,

01:06:59
like, "hey, you bring in a spring

01:07:00
boot starter that has a ton of

01:07:02
implications on how many libraries

01:07:04
come in." Are these affected? Yes

01:07:06
or no, et cetera, et cetera. That

01:07:09
we go one layer deeper or

01:07:11
around that, say your,

01:07:12
your container images and let's

01:07:14
say it's Docker because it's

01:07:16
still the most commonly

01:07:18
used, but whatever, like any image

01:07:20
is built on a

01:07:22
base image and probably

01:07:24
you streamlined some

01:07:26
binaries in

01:07:27
there. So what's there,

01:07:28
that's another shell around the

01:07:30
whole application. And then

01:07:32
you get into, in the end,

01:07:34
for instance, your

01:07:36
configuration for your

01:07:38
infrastructure is

01:07:38
go to the bullet.

01:07:40
That can go wrong by not having a

01:07:42
security context or like some

01:07:47
policies that are not

01:07:48
bad or something like that. Some

01:07:50
pods that you gave more privileges

01:07:54
than you should have because,

01:07:56
Hey, it works on my machine,

01:07:57
right? Let's ship it. These kinds

01:07:59
of things. So on

01:08:00
all these four fronts,

01:08:01
we try to provide

01:08:04
pooling and test capabilities in

01:08:07
such a way that you can choose how

01:08:08
you want to utilize these test

01:08:10
capabilities, either in a CI

01:08:12
pipeline or our local machine

01:08:13
or in between or part of your

01:08:15
build, whatever fits your needs.

01:08:19
And instead of,

01:08:20
Hey, this needs to be

01:08:22
part of your build pipeline,

01:08:23
because that's how the tool works.

01:08:25
And I was a developer myself for

01:08:27
back end for backend jobs a long

01:08:29
time. And I was the person that

01:08:31
was like, if we need to satisfy

01:08:33
that tool, I will find a way

01:08:35
around it.

01:08:37
Yeah, I hear you.

01:08:38
Which defeats the purpose because,

01:08:40
because at that point you're only

01:08:41
like checking boxes. So I think if

01:08:45
these tools fit your way of

01:08:48
working and implement your way of

01:08:52
working, then you actually have an

01:08:55
enabler instead of a wall

01:08:57
that you bump into every time.

01:08:59
Yeah. That makes a lot of sense.

01:09:03
So that means when you,

01:09:04
say you start at a code

01:09:06
level, I think simple, like

01:09:08
the still most common thing,

01:09:11
like SQL injection issues, all

01:09:14
that kind of stuff, that

01:09:15
is probably

01:09:16
handled as well, right?

01:09:17
Yeah. SQL injections, path of

01:09:19
virtual injections, cross-site

01:09:20
scripting, all

01:09:21
these kinds of things

01:09:23
will get notified

01:09:25
and we will, if

01:09:27
possible, we will give you

01:09:29
remediation advice on that. And

01:09:31
then we go levels deeper. So

01:09:33
it's actually like,

01:09:34
you can almost say it's like four

01:09:35
different types of scanner that

01:09:37
you can use in whatever way you

01:09:39
want. Some people are like, no,

01:09:41
I'm just only using the dependency

01:09:43
analysis stuff. That's also fine.

01:09:44
Like it's just four different

01:09:46
capabilities for basically four

01:09:49
levels in your, in

01:09:52
your application,

01:09:52
because it's no longer just your

01:09:54
binary that you put in. It's more

01:09:55
than that, as we just discussed.

01:09:58
So, when we look at

01:09:59
like the recent and not so

01:10:02
recent past, I mean,

01:10:04
we're both coming from the Java

01:10:05
world. You said you're

01:10:07
also, you were a Java programmer

01:10:09
for a long time. I am. I

01:10:13
think the, I mean, the Java world

01:10:15
isn't necessarily known for like

01:10:17
the massive CVEs. except Log4Shell

01:10:23
Yeah, that was a big,

01:10:25
Right? Yeah.

01:10:27
The thing, I think,

01:10:28
the thing is in the Java world,

01:10:29
it's either not so big or very

01:10:32
big. There's no in between, or at

01:10:33
least it doesn't get the

01:10:35
amount of attention, but yeah,

01:10:36
Log4Shell was a big

01:10:38
one because first of all, props to

01:10:42
the folks that maintain that,

01:10:43
because I think there were only

01:10:44
three active maintainers at that

01:10:45
point when the thing came out and

01:10:47
it's a small library that is

01:10:50
used and consumed by a lot of

01:10:52
bigger frameworks. So everybody

01:10:54
was looking at

01:10:55
you're doing a bad job.

01:10:56
It was just three guys that

01:10:58
voluntarily maintain it.

01:11:00
So for

01:11:01
the people that do

01:11:02
not know what

01:11:02
Log4Shell was. So Log4J is

01:11:06
one of the most common logging

01:11:08
frameworks in Java. And there

01:11:11
was a way to inject remote

01:11:14
code and execute it with basically

01:11:18
whatever permission your

01:11:19
process had. And as you said, a

01:11:23
lot of people love to run their

01:11:24
containers with

01:11:25
root privileges. So

01:11:28
there is

01:11:30
your problem right there. But

01:11:31
yeah, so Log4Shell was,

01:11:34
I think, at least from what

01:11:37
I can remember, probably like the

01:11:39
biggest CVE in the Java world,

01:11:41
ever since I joined.

01:11:44
Maybe that

01:11:44
one, but we had in 2017, we had

01:11:47
the Apache struts one that

01:11:48
blew, blew, blew away, blew away

01:11:51
our friendly

01:11:53
neighborhood Equifax. But yeah.

01:11:55
I'm not talking about struts

01:11:57
because that was like so long

01:11:59
deprecated by that

01:12:00
point of time. It was,

01:12:02
it was, it was ... They deserved it.

01:12:05
No, but seriously, yeah. True,

01:12:07
true. The struts one was

01:12:08
also pretty big, but since we are

01:12:12
just recording it, this on April

01:12:15
3rd, there was just like a very,

01:12:18
very interesting thing that was

01:12:19
like two days ago, three days ago,

01:12:21
like April 1st. I think it was

01:12:23
actually April 1st, because I

01:12:24
initially thought it's an April's

01:12:26
Fool joke, but it

01:12:27
was unfortunately not

01:12:30
I think it was the last

01:12:31
day of March though. So it was not.

01:12:33
Maybe I just saw it

01:12:34
like April 1st. To be

01:12:36
honest, initially I thought, okay,

01:12:38
that's a really bad

01:12:39
April's Fool. So what we're

01:12:42
talking about is the XZ issue.

01:12:45
Maybe you

01:12:46
want to say a few words

01:12:47
about that or what?

01:12:49
Well, let's keep it

01:12:50
simple. The XZ issue is basically

01:12:54
an issue in one of the tools that

01:12:56
come with some Linux

01:12:59
distributions. And

01:13:01
long story short,

01:13:03
I'm not sure if they already

01:13:04
created exploits on that. I

01:13:06
didn't, I didn't

01:13:07
actually try it because

01:13:08
we've got a folks that doing the

01:13:09
research. But apparently there,

01:13:12
because of that tool, you could

01:13:15
do nasty stuff as arbitrary code

01:13:16
executions or, or things with

01:13:19
going into secure connections.

01:13:23
At least it comes with your

01:13:26
operating system. So that means if

01:13:29
you have a Docker

01:13:30
image or whatever

01:13:31
image and you're based on a

01:13:33
certain well-known Linux

01:13:35
distribution, you

01:13:36
might be infected,

01:13:38
regardless of whatever your

01:13:39
application does. And it's a big

01:13:42
one. If you want to go into deep,

01:13:43
there are tons of blogs of people

01:13:45
that can explain to you what

01:13:47
the actual problem was.

01:13:48
But I think for the general

01:13:49
developers, like, don't shut your

01:13:53
eyes and like, it's not

01:13:54
on my machine. It might be in

01:13:56
your container because you're

01:13:57
using an outdated, now outdated

01:14:00
image. I think there's

01:14:03
two things. First of all, I think

01:14:04
it was found before it actually

01:14:06
made it into any distribution,

01:14:07
which is good. So if you're, if

01:14:10
you're not using any of the like

01:14:11
self-built distributions, you're

01:14:12
probably good. But what I found

01:14:15
more interesting about it, that

01:14:18
this backdoor was introduced from

01:14:21
a person that was working

01:14:26
on the tool for

01:14:29
quite a while, like over a year or

01:14:31
so, basically getting the trust of

01:14:33
the actual maintainers

01:14:34
and just sneaking stuff in

01:14:39
eventually. And that is... That is

01:14:42
why I think tools like

01:14:44
Snyk or let's, let's be blunt,

01:14:47
some of the competitors are so

01:14:48
important, right? Because

01:14:51
it's, it's really hard to just

01:14:53
follow all of the new CVEs and

01:14:56
sometimes they're

01:14:56
not blowing up this

01:14:57
big. So you probably don't even

01:14:59
hear about them, but for that

01:15:00
reason, it's

01:15:01
really important to have

01:15:02
those tools.

01:15:03
I totally

01:15:05
agree. I mean, as a development

01:15:07
team, it is a side effect for you,

01:15:11
like you're building stuff and you

01:15:13
don't focus on checking manually,

01:15:14
whatever is coming in and if

01:15:16
it's vulnerable or not, but you

01:15:18
should be aware of these kinds of

01:15:19
things. And so if they come in,

01:15:21
you can make appropriate choices.

01:15:23
I'm not saying you have to fix it.

01:15:25
That's up to you, like,

01:15:26
and your threat level and whatever

01:15:27
is going on in your company, but

01:15:30
you need to be able to make

01:15:31
these decisions based on

01:15:34
accurate knowledge and have the

01:15:37
appropriate knowledge

01:15:37
that you can actually can make

01:15:39
such a decision. And yeah, you

01:15:42
don't want to manually hunt these

01:15:44
things down. You want to be

01:15:46
actively pinged when something

01:15:47
happens to your

01:15:48
application that might

01:15:49
have implications for it, for your

01:15:50
security risk.

01:15:52
Right. And from

01:15:54
your own feeling, like,

01:15:56
in the past, we mostly deployed

01:15:58
like on-prem installations or in

01:16:00
like private clouds,

01:16:01
but with the shift to public

01:16:02
cloud, do we increase the like

01:16:06
risk factor? Do we

01:16:07
increase the

01:16:08
attack surface?

01:16:10
Ehm. Uh. That's a...

01:16:12
Yes. I think the

01:16:14
short story,

01:16:16
the short thing is, yes,

01:16:17
there are more things that we have

01:16:19
under our control as a development

01:16:20
team. We do not always

01:16:22
have the necessary specialties

01:16:25
within the team. So we're doing

01:16:27
the best we can, but that means

01:16:28
we've got multiple attack phases.

01:16:31
Like your connection

01:16:33
with your

01:16:34
application is one thing,

01:16:35
but this one is if I can get into

01:16:37
your container for some reason, I

01:16:40
can use this, even though

01:16:42
at some, some things in containers

01:16:43
or some things in operating

01:16:44
systems might not

01:16:45
be directly usable,

01:16:47
but part of a chain that causes a

01:16:50
problem. So I can get in in one,

01:16:52
like if there's one hole,

01:16:53
I could get in and use, use

01:16:55
certain objects or certain

01:16:57
binaries in my chain

01:16:58
of attacks and make

01:17:00
it a domino effect, basically. So

01:17:01
you're, you're giving people more

01:17:04
and more ammunition. So, and as

01:17:07
we automate certain things, we do

01:17:09
not always have the necessary

01:17:11
knowledge about

01:17:13
certain things that

01:17:15
might become bigger and bigger.

01:17:17
Plus the fast pace we're

01:17:20
currently moving. Like,

01:17:22
like tell me like 10 years ago,

01:17:24
how were you deploying?

01:17:28
I don't know. I don't remember. I

01:17:30
don't remember yesterday.

01:17:31
Yeah. But I mean,

01:17:33
probably not three times a day,

01:17:34
like 10 years ago, we're probably

01:17:36
like deploying once a month,

01:17:38
you have time to test or something

01:17:39
like that. So it's a combination

01:17:41
of doing all within one team,

01:17:44
which yes, we should do, but also

01:17:46
the fast pace that we need to

01:17:47
release nowadays is something

01:17:50
like, okay, we're just doing it.

01:17:52
The whole continuous development

01:17:54
and continuous deployment

01:17:55
is part of this. If you're

01:17:57
actually doing that, of course.

01:17:59
Yeah, that's,

01:17:59
that's true. I think,

01:18:01
I think it would have been like

01:18:02
about every two weeks or so. But

01:18:05
yeah, you normally had like one

01:18:06
week development, one week bug

01:18:08
fixing and testing, and then you

01:18:10
deployed it. Now it's like, you do

01:18:13
something, you think it's ready,

01:18:15
it runs through the pipeline. And

01:18:17
in the best case, it gets

01:18:18
deployed immediately. And if

01:18:19
something breaks, you gonna fix

01:18:21
it. Or are you in the worst case,

01:18:22
you roll back if it's really bad.

01:18:24
But on the other end,

01:18:26
say you're an application

01:18:27
developer, and you need to do that

01:18:28
stuff in a container. And do you

01:18:30
ship it? Are you touching

01:18:33
your container if you or rebuild

01:18:35
your container if your application

01:18:37
didn't change?

01:18:39
Yes.

01:18:40
Probably, probably, probably a lot

01:18:43
of folks won't, because hey, did

01:18:45
some, some things didn't change,

01:18:47
but it can be that the image your

01:18:49
base your stuff upon or your base

01:18:51
image or however you may manage

01:18:52
that can be company wide, or you

01:18:54
just will something out of Docker

01:18:56
hub or whatever. That's

01:18:58
another layer that might have

01:18:59
changed and might have been fixed

01:19:00
or might have been vulnerabilities

01:19:02
found in it. So it's not anymore

01:19:04
like, "hey, I didn't touch that

01:19:06
application. So I don't have

01:19:07
to do a rebuild." Yes, you should

01:19:10
because other layers in that whole

01:19:11
application changed.

01:19:13
Right, right. And I think you

01:19:14
brought up an important other

01:19:16
factor. It might be that

01:19:18
meanwhile, like, during the last

01:19:20
were in between the last

01:19:22
deployment, and now

01:19:23
a CVE has been found

01:19:25
or something else, right? So you

01:19:27
want to make sure you're

01:19:29
going to test it again.

01:19:30
And then you have other

01:19:32
programming languages, I'm not

01:19:33
naming things here. But

01:19:37
you might get a different version

01:19:39
of the dependency, which is

01:19:41
slightly newer. You're

01:19:43
doing a new install, right? And,

01:19:44
and all of that are there's so

01:19:46
many different things,

01:19:48
applications, these days, even

01:19:49
micro service are so complex,

01:19:51
because they normally need like,

01:19:52
so many different dependencies.

01:19:55
And it is hard to

01:19:56
keep keep an eye on that.

01:19:59
And that kind of brings me to the

01:20:02
next question, like, how does

01:20:04
snake play into like SBOM or

01:20:06
the software bill of materials?

01:20:11
Getting into the hype train of

01:20:12
SBOMs. Now, it's not it's not just

01:20:14
the hype train. I mean, it's a

01:20:15
serious thing. For folks

01:20:17
that don't know,

01:20:18
you can compare the

01:20:20
SBOM as your ingredients nutrition

01:20:23
list for whatever you try to

01:20:25
consume to stuff in your face.

01:20:28
Basically, what's in there, you

01:20:29
have no clue, the nutrition facts

01:20:31
on the package should

01:20:34
say what's in it, right? So that's

01:20:36
how you should perceive an SBOM.

01:20:37
If you create an artifact,

01:20:41
then you should create a suitable

01:20:43
SBOM with it that basically

01:20:45
says, "okay, I'm using these

01:20:47
dependencies and these transistive

01:20:48
dependencies, and maybe even these

01:20:50
Docker containers or whatever,

01:20:51
I'm using these things to create

01:20:55
my artifact." And a consumer of

01:20:57
that artifact is

01:20:59
then able to search

01:21:00
around that like say a CVE comes

01:21:02
up, a new Log4Shell comes up,

01:21:04
let's make it big.

01:21:06
Am I infected? That's the first

01:21:08
question, a consumer or

01:21:10
somebody that uses your artifact

01:21:11
says. And with an SBOM, you

01:21:15
have a standardized, well, there

01:21:17
are three standards,

01:21:18
but never nevertheless, like

01:21:19
multiple standard, but there's a

01:21:20
standardized way

01:21:21
of having that and

01:21:24
make it at least machine

01:21:26
searchable to see if you are

01:21:28
vulnerable or not.

01:21:29
So how we play into

01:21:30
that? Yes, you can use our sneak

01:21:32
tooling to create SBOMs for your

01:21:35
applications or for your

01:21:37
containers, that's

01:21:38
possible. We have the capabilities

01:21:40
to read SBOMs in to see if these

01:21:42
SBOMs contain packages or

01:21:45
artifacts or stuff that have

01:21:48
known vulnerabilities. So you can

01:21:51
again, take the appropriate

01:21:52
measures. I think it's, yes, SBOM

01:21:55
is great from the

01:21:57
consumer side. So

01:21:59
it's very clear what that stuff

01:22:02
that I got from the

01:22:03
internet or got from a supplier,

01:22:06
because we're talking about supply

01:22:07
chain all the time, from a supplier

01:22:09
within stuff that I build

01:22:11
upon or that I'm using that I can

01:22:12
see if it contains problems or it

01:22:15
contains potential

01:22:16
problems when something new comes

01:22:17
up. And yes, we're at we have

01:22:20
capabilities of creating these

01:22:21
SBOMs and scanning these SBOMs.

01:22:23
All right. We're basically

01:22:25
out of time. We're not basically

01:22:26
we are of time. But there's one

01:22:28
more question I still want to ask.

01:22:31
And how do you or where do you

01:22:33
personally see like the biggest

01:22:34
trend could be related to Snyk to

01:22:37
security in general?

01:22:38
The biggest trend is

01:22:40
that is the hype thing of AI

01:22:41
nowadays. And and that is

01:22:44
definitely a thing. What people

01:22:47
think is that AI is a suitable

01:22:49
replacement for a security

01:22:50
engineer. Yeah, I exaggerate now,

01:22:54
but that's not we have

01:22:57
demos where we let a code

01:23:02
assistant tool, a well known code

01:23:04
assistant tool, spit out vulnerable

01:23:06
code, for instance. So I think

01:23:09
the trend is two things,

01:23:13
the whole supply chain, software

01:23:14
supply chain, whatever you

01:23:15
get into, you should look at one

01:23:17
thing. But the other tool is that

01:23:19
if people are using AI,

01:23:21
don't trust it blindly. And I

01:23:23
think it's that's for everything

01:23:24
for both stuff in

01:23:25
your supply chain,

01:23:25
as in generated code by a code

01:23:28
assistant. You should know what

01:23:30
you're doing. Like it's a great

01:23:32
tool. But don't trust it blindly,

01:23:34
because it can also hallucinate

01:23:36
and bring in stuff that you

01:23:37
didn't expect if you are not aware

01:23:39
of what you're doing. So yeah.

01:23:41
I think that is a perfect

01:23:43
closing. It can hallucinate things.

01:23:47
Oh, definitely, definitely. It's a

01:23:49
lot of fun to play with it.

01:23:51
It's also a great tool. But you

01:23:53
should know it doesn't first of

01:23:54
all, it doesn't replace

01:23:55
developers that think.

01:23:56
Like thinking is still something an AI

01:23:58
doesn't do.

01:24:02
All right. Thank you very much.

01:24:05
Time is over. 20 minutes is always

01:24:08
super, super short, but it's

01:24:09
supposed to be that way.

01:24:13
So Brian, thank you very much for

01:24:14
being here. I hope that was not

01:24:17
only interesting to me. I actually

01:24:18
learned quite a few new things

01:24:20
about Snyk because I haven't

01:24:22
looked into it for a couple of

01:24:24
years now. So yeah, thank you very

01:24:27
much. And for the audience,

01:24:31
I hope you're listening in next

01:24:32
week. New guest, new show episode,

01:24:35
and we're going to see you again.

01:24:38
The cloud commute podcast is sponsored by

01:24:40
simplyblock your own elastic

01:24:42
block storage engine for the cloud.

01:24:44
Get higher IOPS and low predictable

01:24:45
latency while bringing down your

01:24:47
total cost of ownership.

01:24:48
www.simplyblock.io