►
From YouTube: DevSecOps is the Way (S1E4): Application Analysis - The importance of a Software Bill of Materials
Description
In this monthly series, learn how Red Hat weaves together DevOps and Security to master the force called DevSecOps. This show brings you Red Hat products and our security ecosystem partners to aid in your journey. June is Application Analysis month! In this episode, Paul Novarese, Senior Solutions Engineer at Anchore, walks through how important a Software Bill of Materials (SBOM) can be. The simple SBOM provides a foundation for gaining visibility of embedded secrets, malware and image risks as well as vulnerabilities -- which explains why the US and other governments are issuing guidance around SBOMs. By including generating SBOMs into your DevSecOps practices, you won’t need a Jedi to thwart cyber attackers..
Bring your lightsaber and be prepared to train hard... may the DevSecOps be with you!
A
A
A
A
A
A
B
B
So
if
you're
not
familiar
with
s-bomb,
this
will
be
a
great
session,
especially
because
recently
it
was
what
may
12th
a
an
executive
order
was
signed
for
the
security
cyber
security
and
there's
a
section
in
there
section
four
around
software
supply
chain
and
there's
a
lot
around
s-bomb,
so
we're
gonna
dig
into
that
topic
and
before
I
have
paul
introduce
himself.
I
just
wanted
to
mention
about
this
series
that
you're
watching.
B
Every
month
you
can
see,
we've
done,
we
do
two
openshift
tv
shows
this
one
is
devsecops
is
the
way
where
we
bring
in
a
thought
leader
like
paul
and
talk
about
that
that
category,
our
other
openshift
tv
show
is
with
the
openshift
commons
briefing
and
if
you
know
mike
wait,
he
he
runs
those
as
well.
That's
usually
a
partners
of
ours
that
has
specific
capabilities
in
that
in
that
category
as
well,
then
we
try
to
publish
three
podcasts.
B
We
also
do
a
blog
on
that
category,
as
well
plus
a
couple
other
data
and
we're
going
to
be
releasing
a
page
that
sort
of
summarizes
what
we've
done
over
the
last
couple
months.
So
you
can
reference
that
as
well,
but
any
questions
or
any
thoughts
or
concerns,
please
feel
free
to
reach
out
to
us.
You
can
see
the
the
web,
the
web
link
there
and
the
email
address
as
well.
B
C
C
Yeah
yeah
enjoyed
my
time
there.
Yeah
still
still,
you
know
in
touch
with
quite
a
few
of
the
guys
from
the
team
there,
most
of
whom
are
still
at
red
hat.
You
know,
but
they've
spread
out
all
over
the
place
too.
It's
it's.
You
know
me
amazing,
where
you
see
people
go
from
red
hat
right,
it's
a
really
good
springboard
for
just
about
anybody's
career.
I
think.
C
For
the
first
time
you
know
some
of
the
security
implications
are
not
always
super
obvious
right,
both
the
positives
and
the
negatives
right
things
you
need
to
look
out
for
and
just
helping
them
get
a
you
know,
get
their
arms
around
how
they
need
to
approach
it
right.
What
to
be
aware
of
what
to
look
out
for
lessons
learned.
All
of
that
stuff.
B
Yeah
there's
a
lot
of
new
security
techniques
and
technologies,
so
many
different
vendors
out
there
that
seem
to
be
overlapping.
I'm
sure,
I'm
sure
you
see
that
as
well.
It's
it's
kind
of
tough!
Even
if
you
look
at
kubernetes
and
see
all
the
certified
partners
and
things
like
that,
there's
just
really
difficult
to
get
your
hands
around.
Who
does
what
yeah.
C
Yeah
and
there's
a
lot
of
overlap,
especially
in
you
know,
there's
a
lot
of
places
that
have
become
commoditized
right.
I
mean
vulnerability.
Scanning
right,
for
example,
is,
is
kind
of
table
stakes
at
this
point
right
that
everybody
is
doing
it,
but
then
there's
a
lot
of
stuff
around
the
deeper
inspection
of
the
containers,
the
images,
the
runtime
inspection.
C
You
know
so
there's
a
lot
of
of
places
where
the
boundaries
are
getting
pushed
out
a
little
further
right,
the
vulnerability
scanning.
At
this
point,
I
wouldn't
say
it's
a
solved
problem,
because
there
are
some
wrinkles
and
stuff
there,
but
definitely
the
the
velocity
of
the
frontier
right
is
is
in
other
places.
At
this
point,.
B
C
Yeah,
so
it's
a
it's
company's
been
around
since
around
2015.
You
know
once
docker
kind
of
started
taking
off
around
that
period.
It
was
pretty
obvious
that
containers
presented
some
unique,
both
challenges
and
opportunities
for
for
security.
Right,
I
mean
there's
a
lot
of
things
that
scanning
containers
is
not
the
same
as
scanning
applications
on
a
bare
metal
system,
but
the
the
way
containers
are
packaged
in
these
images.
Right
presents
a
real
big
opportunity
as
well
right.
C
You
know
how
you,
how
you
actually
build
the
image
layer
by
layer
things
like
that
that
have
a
lot
of
impact
on
security.
Right
I
mean.
Even
if
you
have
zero
vulnerabilities,
you
could
have
a
very
insecure
container
if
you
misconfigure
it
right
just
depending
on
what
ports
you
expose
or
what
packages
you
include,
or
you
know
how
you
put
it
together,
essentially
right.
So
there's
a
lot
more
to
scanning
those
images
than
just
the
vulnerabilities.
A
C
B
C
So
angkor,
I
guess,
was
to
give
you
that
connotation
of
of
stability
and
security
right
that
you
know
you're
well
anchored
and
very
stable,
and
I
think
the
actual
the
extra
e
on
the
end
there
is
is,
you
know,
from
a
practical
point
of
view,
it's
a
little
easier
for
search.
You
know,
seo
purposes,
you
know
you
got
to
have
a
little
unique
wrinkle,
so
I
don't
think
there's
there's
too
much
to
it
right
but
yeah.
It
was
definitely
a
nautical
theme.
C
B
C
So
there
there's
a
lot
of
discussion
around
it
and
it
I
don't
know
if
there's
really
a
a
standard,
you
know
platonic
definition
of
an
s
bomb.
Yet
right,
there's
a
there's
a
few
competing
formats
out.
There
there's
definitely
some
discussion
about
what
should
be
in
an
s
bomb,
but
I
mean
essentially
what
it
is.
Is
it's
like
the
nutrition
label
on
the
can
of
soup
right?
What's
in
the
what's
in
the
can
you
know
what
should
I
expect,
and
you
know,
from
product
to
product
there's
going
to
be
variations.
C
Some
some
of
those
nutrition
labels
have
more
information
than
others
right
I
mean,
but
there
is
a
baseline
of
you
know.
What's
the
bare
minimum
that
needs
to
be
on
this
label,
for
it
to
be
a
software
bill
of
materials,
and
I
think
we're
actually
going
to
see
a
little
bit
of
that
really
get
codified
here
in
the
next
few
weeks,
even
right
so
dave,
as
you
mentioned,
there
was
an
executive
order
recently
about
you,
know
cyber
security
with
all
of
the
supply
chain
attacks,
we've
seen
solarwinds
code,
cove,
etc.
C
So
we're
really
expecting
to
see
some
direction
from
the
federal
government
here
in
the
next
few
weeks
around.
What
is
that
bare
minimum
that
needs
to
be
in
an
s
bomb?
Maybe
some
guidance
around
formats
as
well,
because,
like
I
said,
there's
a
few
competing
formats,
so
it's
it's
definitely
influx
right,
yeah,
exciting
times.
B
Yeah
in
that
executive
order
right,
I
they
do
try
to
define
s-bomb,
but
it's
it's
very
generic
and
and
you're
right,
there's
no
mention
of
formats.
I
do.
I
think
I
remember
hearing
that
they
are
looking
at.
You
know
formalizing
on
three
different
formats
like
you
know,
spdx
or
something
like
that,
but
but
yeah.
I
it's
gonna
be
interesting
that
I'm
I'm
as
well
looking
for
the
government
to
provide
us
some
information
on
that.
C
Yeah
and
I
think,
like
a
lot
of
things
in
the
government
right,
I
mean
there's
an
executive
order
that
just
kind
of
provides
the
strategic
direction
and
then
it's
up
to
the
bureaucrats,
to
kind
of
really
hammer
out
the
details
right
and
and
like
I
said,
I
think,
we'll
see
the
first.
The
first
draft
of
that
I
mean
there's,
definitely
like
an
open
call
for
comments
right
now
and
I
think,
sometime
in
july,
we're
supposed
to
see
that
first
glimpse
of
a
proposal
on
a
real
standard.
B
C
Yeah
yeah
and
up
to
recently
it
was
really
more
of
a
means
to
an
end
right,
whereas
you
know
now,
it's
like
this
is
a
a
front
of
mind
thing
right.
We
have
to
have
this
s
bomb
right,
whereas
before
the
customers
that
I
was
dealing
with,
didn't
really
care
what
we
were
doing,
we
were
using
an
s
bomb
because
it
made
our
job
of
providing
them
with.
An
assurance
of
this
container
is
compliant
right,
made
that
job
easier
right.
C
But
now
it's
like
I
need
to
have
this
s-bomb,
because
I
want
to
be
able
to
do
business
with
you
know,
party,
x
or
party
y,
and
I
can't
do
it
unless
I
can
deliver
an
s-bomb
with
my
software
yeah
right.
So
it's
kind
of
now
an
end
into
itself,
along
with
all
of
the
you
know,
tactical
advantages
we
get
for
for
analyzing,
the
software
right
so
generating
it.
C
I
mean
it's
one
of
those
things
where,
like
you
said,
there's
a
couple
of
different
computing
standards
right
now:
there's
spdx,
there's
cyclone
dx,
there's
a
couple
of
others
and
in
the
container
space
specifically
right.
There's
there's
not
a
lot
of
tools
that
are
aimed
at
especially
open
source
tools
aimed
at
generating
an
s
bomb
for
a
container
image,
specifically
right.
C
B
C
Well,
yeah,
that's
a
good
question.
I
mean
a
lot
of
tools
out
there.
Just
don't
know
how
to
deal
with
container
images
is
really
the
simple
answer
to
that
right
that
there's
it's
just
a
foreign
concept
to
them.
They
just
haven't
caught
up
and
so
they're
really
not
built
for
that.
The
good
thing
about
container
images
from
our
point
of
view
is
because
they
are
in
a
sense.
You
know
people
don't
think
of
images
as
being
immutable,
but
they
are.
C
But
if
we
look
at
those
things
like
image
digest,
that
gives
us
a
very
easy
and
accessible
fingerprint
that
we
don't
even
have
to
generate
right,
I
mean
you
can
generate
fingerprints,
one
way
or
the
other.
A
hash
for
a
tar
file
or
whatever
right,
but
all
of
that
work
is
already
done
and
we
don't
even
have
to
mess
with
that,
and
so
we're
just
that
much
further
ahead
in
speeding
up
the
analysis
process.
C
So
you
know
once
that's
the
the
real
key
to
what
we
do
is
once
we've
seen
an
image
one
time
we
can
evaluate
the
image
over
and
over
again
without
even
seeing
the
image
again
right.
So
if
the
vulnerability
definitions
change,
if
the
policy
rules
that
we
want
to
evaluate
the
image
against
have
changed,
we
can
issue
that
evaluation
really
quickly
without
rescanning
the
image
right,
because
we
know
for
image
digest
xyz
right.
This
is
what's
in
it
and
that's
you
know
a
fact
right
that
will
never
change.
C
C
Exactly
vulnerabilities,
are,
you
know,
we're
consuming
vulnerability
definitions.
You
know
constantly
right
in
real
time,
they're
just
flowing
into
our
system
and,
like
I
said,
policy
rules
can
change.
I
mean
those
are
not
going
to
be
on
a
changing
on.
You
know,
hour
to
hour,
usually
right,
but
you
might
add
additional
policy
rules
like
maybe
you
need
to
comply
with
the
pci
dss
standard,
let's
say
or
whatever
it
is:
nist
800,
53
or
nist
800
180
right.
Those
are
pretty
common
industry
standards.
C
But
let's
say
you
decide:
oh
we're
going
to
go
into
business
in
europe
and
now,
all
of
a
sudden,
we
also
need
to
comply
with
iso
27001
right.
So
it's
not
a
matter
of
the
policies
themselves,
changing
necessarily
as
as
much
as
your
business
needs
are
changing,
so
that
additional
policy
rules
need
to
be
looked
at
right
and
again,
we
can
issue
that
you
know
evaluation
of
the
image
without
having
to
do
that.
C
Intensive
work
of
opening
up
the
image
and
figuring
out
everything.
That's
in
it
right.
We've
already
done
that,
so
the
new
new
policy
can
be
applied
and
evaluated
essentially
instantly
right,
I
mean
that's.
That's
the
goal
is
to
be
able
to
do
it
continuously
right
on
a
reg.
You
know,
as
early
as
possible,
scan
the
image
right.
That's
the
the
shift
left
mentality
that
that
devsecops
really
is.
C
Is
you
know
we're
beating
that
drum
right,
so
we
do
that
scan
as
soon
as
the
image
is
built,
some
of
our
open
source
tools
even
help
you
get
a
little
bit
of
feedback
before
the
image
is
built
right.
While
you
just
are
kind
of
you
know
noodling
around
on
your
laptop,
but
once
that
image
has
been
scanned
right,
then
we
can
say,
as
you
move
it
from
you
know,
dev
to
qa
and
qa
to
staging
as
you
push
it
into
production
or
even
as
the
containers
are
executing
in
production.
C
You
know
that
information
that
we
know
about
is
changing.
As
you
mentioned,
the
vulnerabilities
or
you
know
if
we
need
to
change
gears
on
the
policies
and
we
can
just
continually
evaluate
those
and
alert
you
when
something
has
changed,
and
so
this
image
was
compliant
and
now
all
of
a
sudden,
it's
not
right,
and
then
you
can.
C
B
Yeah
one
of
the
debates
I've
heard
in
the
past
around
images
and
build
materials
are
around
layers
and
some
some
folks
say
well
yeah.
I
want
to
know
what
the
first
layer
had,
because
it
was
resolved
in
the
second
layer.
Third
layer:
do
you
see
use
cases
out
there
where
it's
valuable,
to
understand
the
build
materials
for
each
layer
or
is
just
the
last
layer
good
enough.
C
It
depends
right,
I
think,
there's
there's
definitely
a
lot
of
debate
around
that
right
because,
from
a
security
point
of
view,
if
you
have
let's
say
compromise
code
in
a
lower
layer,
even
if
it's
not
present
in
the
final
layer
right,
an
attacker
could
in
theory
get
a
hold
of
it,
and
you
know
it
could
compromise
something
right
so
yeah.
I
think
you
need
to
look
at
both
right
now,
there's
always
the
option
of
like
squashing,
an
image
before
you
publish
it.
That
has
it's
it's
pluses
and
minuses
as
well.
C
Right
I
mean
it
really
hampers
our
ability
to
do
things
like,
for
example,
for
an
image
from
a
public
repository
like,
let's
just
say,
we're
pulling
the
jenkins
image
from
docker
hub
having
that
layer
history.
There
actually
helps
us
a
lot
because
we're
able
to
infer
like
I
don't
have
the
docker
file
for
jenkins,
blue
ocean
or
whatever
right,
but
I
can
infer
it
from
the
layer
history
right
so
squashing
it
in
that
case
actually
makes
my
evaluation
a
lot
less
effective.
C
It's
just
information
that
gets
lost.
On
the
other
hand,
right
I
mean,
as
a
squashed
image
is
going
to
be
faster
to
scan.
That's
less.
You
know
to
go
through
there
and
and
in
fact
we
see
a
a
big
performance
hit,
especially
in
images
where
there's
deletions
from
one
layer
to
the
next
right.
If
you're
just
building
each
layer,
it's
not,
I
mean,
there's
definitely
a
hit
right.
C
C
I
think
the
the
medium
there
is
being
for
for
images
you're
building
yourself
being
very
aware
of
things
like
multi-stage,
builds
right
that
can
cut
down
on
a
lot
of
problems,
and
it
makes
your
images
smaller
in
general
and
smaller
images
tend
to
be
more
secure
right,
I
mean
there's
less
attack
surface
so
looking
at
those
image,
construction
best
practices
are
never
a
bad
thing
right,
but
they're.
Those
best
practices
were
already
there
before
we
started
looking
at
these
things,
and
they
still
tend
to
hold
up
pretty
well
right.
So.
B
C
Yeah,
so
what
we
typically
see
in
an
enterprise
is,
we
will
integrate
in
with
like
a
ci
cd
pipeline.
As
soon
as
the
image
is
built
there,
we
would
do
a
scan
of
it
upload
the
s
bomb
to
our
back
end
and
then
issue
evaluations.
The
evaluations
happen
in
our
policy
engine
and
our
back
end,
and
essentially,
what
we
would
suggest
to
our
our
users
is
once
that
s-bomb
is
collected
and
archived
is
to
evaluate
it
all
the
time.
Every
time
you
move
the
image
right.
C
So
if
I
pull
an
image,
I
can
get
an
evaluation
pretty
quickly
right.
I
just
hit
our
api
and
say:
please
give
me
an
evaluation
of
imagex
and
I
don't
need
to
worry
about.
You
know,
think
keeping
track
of
where
it's
been
before.
I
just
tell
it
what
image
I'm
about
to
look
at,
and
it
just
gives
me
the
evaluation
back
and
that,
like
I
said
since
we've
already
scanned
the
image,
that's
the
intensive
part.
C
The
evaluation
is
actually
extremely
lightweight
so
separating
out
that
you
know
scanning
of
the
image
analyzing
the
image
and
making
the
s-bomb
from
the
actual
evaluation
of
the
image
to
say
what
are
the
vulnerabilities
right
now
right
that
we
know
about
what
the
definitions
we
have.
What
is
the
policy
evaluation?
C
You
know,
given
the
whatever
rules
are
in
effect
today
right
that
process,
you
know,
separating
those
two
steps
enables
us
to
do
that.
Continuous
evaluation
right
and
that's
really
the
key.
So
I
can
get
that
evaluation
as
I
push
into
production
right
so
right
before
those
containers
are
actually
created.
We
have
a
kubernetes
admission
controller
and
you
know
it
can
operate
in
a
lot
of
different
modes,
but
the
most
common
is
a
it
does
two:
it
checks
for
two
things:
one
have
we
seen
this
image
before
right,
so
that
is
a
big.
C
You
know
gate
there
to
say:
did
this
image
go
through
the
proper
process
right?
Has
it
gone
through
our
pipeline
or
whatever
our
process
is,
if
it
hasn't,
it
wouldn't
have
gotten
scanned.
That
would
be
a
huge
red
flag
right,
somebody's
trying
to
deploy
something.
We've
never
seen
before
whether
it
it
passes
or
not
that's
a
big
red
flag
and
then,
of
course,
does
the
evaluation
you
know
have
a
passing
grade.
Essentially,
so
you
can
get
that
last
second
check
right
as
opposed
to
there's
other.
C
You
know,
there's
the
opposite,
maybe
not
the
opposite,
but
the
competing.
Well,
I
don't
want
to
say
competing
either
right
because,
like
something
like
acs
in
openshift
does
a
lot
of
looking
at
code
as
it
executes
right.
That's
definitely
an
important
part
of
security
right,
but
you
know
our
philosophy
is
for
what
we
do.
You
know
we
aim
to
be
best
in
breed
and
making
sure
that
the
stuff
is.
C
You
know
all
systems
go
before
you
start
executing
it
right
once
it's
executing
we
will,
you
know
let
something
like
acs
take
over
and
because
that's
what
they
do
best
right,
but
both
of
those
are
important
pieces
right.
I
don't
want
it
to
sound
like
in
fact,
I've
been
having
quite
a
few
conversations
with
some
other
people
at
red
hat,
and
you
know
the
two
pieces
really
complement
each
other
really.
C
C
A
C
B
C
Yeah,
so
I
mean
there's:
definitely
it
is
a
big
piece
of
our
evaluation.
I
mean,
because
that
is
like
a
lot
of
people.
That's
all
they
think
about
when
they
think
about
security
is
well.
If
I
don't
have
any
cves,
then
I
must
be
good,
but
it's
definitely
not
where
we
stop
right,
it's
just
the
beginning.
C
For
us,
the
policy
evaluation
is
really
the
key,
and
that
can
be
you
know,
like
we
said
earlier
things
like
you
know,
maybe
I
don't
want
to
use
the
you
know
if,
depending
on
what
I'm
going
to
do
with
the
software,
I'm
building
right
is
it
for
an
internal
project?
Is
it
for
something
on
my
website,
or
is
it
software
that
I'm
going
to
actually
be
shipping
to
customers
right?
I
might
have
three
different
policies
on
what
open
source
licenses
I
can
use
in
those
three
cases.
C
So
we
can
look
at
the
components
there
and
say
you
know,
are
those
components
in
in
line
with
our
policies
or
it
could
be
something
you
know
to
the
current.
You
know
mania
around
supply
chain
attacks.
Where
are
the
the
components
that
I'm
sourcing?
Where
are
they
coming
from
right
so
like
when
I
do
a
pip
install
numpy
or
whatever
am
I
getting?
You
know
what
I
expect
or
am
I
being
you
know,
redirected
with
a
package.
C
You
know
what
do
they
call
that
a
dependency
confusion
check
or
whatever
that's
a
big
point
of
concern
right?
Am
I
being
redirected
to
a
different
repo
right
that
has
compromised
components
in
it?
Right
or
maybe
I
want
to
use
nginx
in
my
project
and
I
fat
finger
in
type
engine,
z
right
and
I
get
some
kind
of
compromise.
C
C
Things
like
even
things
like
what
ports
you're
exposing
right.
If
I
in
my
docker
file,
I
can
you
know,
expose
port,
you
know
22
right
or
what
packages
are
installed
in
there.
You
know
I
mean-
maybe
maybe
sudo
doesn't
have
any
vulnerabilities
right
now,
but
I
don't
want
pseudo
installed
in
my
container
images
right.
It's
it's!
It's
amazing
how
many
people
have
it
in
there
right
but
and
it'll
pass
a
cv
scan
right,
but
there's
still
no
reason
to
have
it
in
there
right.
So
you
can
audit
those
kind
of
things.
C
C
A
C
C
In
fact,
my
son,
you
know
it's
in
this
lego
league
right
where
they,
you
know
you
program,
the
mindstorms
robot,
and
they
have
like
this
obstacle
course
set
up,
of
course,
at
their
last
competition,
someone
on
his
team,
like
literally
decided
to
start
from
scratch
and
rewrite
the
program,
and
of
course
the
thing
like
did
not
work
at
all.
I'm
like
right,
but
you
know
like.
C
Yeah
anyway,
I
might
come
back
to
a
couple
of
slides
just
to
illustrate
some
points,
but
so
here
what
I've
got
is
I've
just
got
a
few
little
sample
containers
running
in
open
shift
here,
basically
nginx
and
then
a
couple
of
rail
containers
that
just
are
you
know,
they're
just
running
a
beacon,
but
basically
I
just
needed
something
running
in
here.
We
can
take
a
look
at
what
they
actually
have
in
them.
C
C
You
know
this
is
the
enterprise
ui,
the
open
source
version
of
this
called
anchor
engine
doesn't
quite
have
doesn't
have
a
web
ui.
You
have
to
do
everything
to
the
command
line
or
through
through
the
api,
but
the
api
is
is
basically
the
same
so
anyway
I'll
just
open
up
a
couple
of
these
images
and
we'll
look
at
what's
actually
in
them.
So
this
is.
C
This
is
a
policy
compliance
here,
I'm
actually
going
to
come
back
to
this
and
go
to
the
software
bill
of
materials
right,
so
these
tabs
here
of
the
image,
metadata
contents
etc.
This
is
that
software
bill
of
materials
that
we're
talking
about
right,
just
every
fact
about
the
image.
What
is
it
based
on?
You
know
how
big
is
it,
etc?
C
Obviously
it
wouldn't
all
fit
on
a
web
ui,
but
we
also
catalog
every
file
in
the
image
right
along
with
you
know
mode.
You
know
permissions
checksums,
all
this
stuff
language
artifacts.
Well,
in
this
case,
I
don't
think
there's
a
whole
lot
of
stuff,
and
this
is
kind
of
a
simple
image.
I
don't
have
anything
installed
in
it
and
then
the
change
log
so
like,
if
I
you
know,
have
multiple
versions
of
an
image
I
can
do
diffs
across
time
right.
C
I
can
compare
those
two
s
bombs
and
say
what
has
changed
from
one
to
the
other
right
so
for
forensics.
You
know
this
is
a
big
plus
and
then
the
build
summary.
This
would
be
things
like
the
manifest
the
docker
history
right.
So
this
is
the
layer
history.
This
is
how
I
infer
a
docker
file
for
images
that
I
don't
have
a
docker
file
for,
and
you
can
see
like
what's
being
done
at
each
at
each
layer
here
like
what's
being
installed.
C
So
when
then,
when
we
get
to
the
evaluation,
it's
things
like
okay,
what
are
the
vulnerabilities
in
this
image?
And
again
this?
Is
you
know
an
up
to
the
second
view
right.
This
is
not
what
the
image
looked
like
when
I
scanned
it.
This
is
what
I
know
about.
You
know
using
the
the
current
vulnerability
definitions
and
then,
of
course,
the
policy
compliance
right.
How
do
I
turn
this
into
a
pass
or
a
fail
right?
So
you
can
see
here.
I've
got
a
couple
of
things
wrong
with
this
image:
the
root
user.
C
You
know
I
didn't
define
a
user
for
the
image
to
run
as
things
like.
This
aren't
quite
as
important
in
kubernetes
right,
you
can,
you
can,
you
know,
put
these
in
your
deployments,
but
still
again
belt
and
suspenders
right
things
like.
Are
there
secrets
in
the
image
right?
So
I
like
left
an
aws
access
key
and
an
ssh
private
key
in
here
right
and
we're
just
searching
for
these.
Looking
at
these
are
essentially
just
arbitrary,
regular
expressions.
C
You
can
kind
of
see
the
the
regex
here
that
I'm
searching
for,
but
as
I
ski
in
the
image,
I
look
for
these
and
we
can
add
whatever
we
want.
There's
an
aws
access
key
as
well
right.
So
these
are
things
that
the
developers
should
be
using.
You
know
vault
or
cube
secrets
for,
but
you
know
a
lot
of
times
while
they're
prototyping
these
will
end
up
in
a
file
somewhere
and
they
forget
to
remove
it
before
they
build
the
image
right.
C
So
that's
kind
of
what
your
you
know,
your
basic
software
bill,
materials
plus
the
evaluation
looks
like,
and
this
again
is
generated
on
the
fly
when
I
pull
up
the
web
page
like
if
I
go
back
here
and
say,
show
me
like
this
image.
It
will
re-evaluate
it's
evaluating
it
right
there
right
so
boom
that
it
just
reevaluated
it
all
right.
So.
B
A
question
for
you,
because,
typically
when
people
think
about
software
build
materials,
they
might
only
be
thinking
about
the
dependencies
that
you
pull
in,
but
I
think
you
made
a
good
point
here
and
then
a
little
bit
earlier
that
it's
not
only
that
right.
It's
some
of
the
files
that
are
right
that
are
installed
in
an
image
like
sudo
or
whatever.
You
need
to
understand
those
as
well
right.
C
Right
right
I
mean
there
could
be
a
lot
of
stuff
in
here
right,
just
general
files
that
are
laying
around
that
are
not
coming
in
from
a
package
manager
of
some
sort
right.
It
could
be.
You
know
we're
we're
going
to
look
at
things
like
node
or
ruby,
gyms
or
or
you
know
python
packages,
but
I
can
just
put
arbitrary
files
in
an
image
right
and
all
of
that
would
slip
through
that
scan.
C
I'm
just
going
to
run
this
crypto
miner,
I'm
not
going
to
spend
a
lot
of
time,
customizing
it
or
anything,
but
the
plus
is
the
fingerprints
of
those
things.
Are
they
just
stick
out
like
a
sore
thumb
and
we
can
find
those
things
I
might
have
one
in
this
image
actually,
but
in
any
case
I'll
show
you
how
we
can
find
those
right
policy
rules
right.
We
talked
about
these.
What
do
they
actually
look
like,
though?
Let
me
just
open
up,
so
you
can
see
like
out
of
the
box.
C
We
ship,
like
a
cis
docker
benchmark
policy.
We
have
some
nist
policy.
Bundles
we've
got
one
that
we
just
recently
developed
for
fedramp,
etc.
I've
been
working
on
one
for
like
devops
in
general
that
I've
been
using
things
like
you
know.
We
talked
about
licenses,
it's
really
easy
to
check
those
vulnerability
checks.
I
mean
again
it's
kind
of
table
stakes
in
a
way,
but
we
can
do
different
things
with
them
and
look
at
things
like
you
know.
C
If
the
kind
of
this
multi-stage
set
of
criteria
around
it
like
in
this
case,
I
only
flag
a
vulnerability
if
it
is
greater
than
or
equal
to
high
severity,
and
it
has
a
fix
available
right
and
you
can
get
even
more
specific
than
that.
You
can
look
at
things
like
the
cdss
scores
or
how
long
it's
been
since
the
advisory
was
published,
etc.
Right,
there's
a
bunch
of
knobs,
so
you
can
get
as
sophisticated
as
you
want
around
those
kind
of
things,
but
again
vulnerabilities.
C
You
know
it's
like
the
least
interesting
part
of
it
right,
so
image,
typo
squatting
that
we
mentioned,
I
mean
I
can
do
things
like
make
sure
I'm
not
pulling
my
base
images
from
docker
hub
and
instead
say
you
can
only
use
this
internal
harbor,
repo
right
or
build.
You
know,
rules
around
package,
typo,
squatting,
right
same
kind
of
thing
happens
with
python
right.
So
in
this
case,
like
I
just
make
sure
if
you're
using
python,
you
have
to
install
the
pipsec
package,
it's
got
its
own
set
of
hardening
around.
C
C
You
know
code
from
like
arbitrary
github
repos
right
if
they're
doing
that,
rather
than
using
the
code
in
my
internal
repo,
you
know
some
if
they're
running
get
clone
in
here
right,
something's-
probably
not
right,
so
you
know
just
checking
for
those
kind
of
things
and
that
again
it's
you
can't
find
that
stuff
with
it's
beyond
a
cbd
scan
right
right.
So
you
see
the
secret
scans.
We
talked
about
crypto
miners,
you
know,
like
I
said
they
have
pretty
pretty
stable
fingerprints,
they're
really
easy
to
catch.
C
C
So
we
can
just
say
you
know,
for
images
in
repo
x
apply
this
set
of
policies
for
images
in
repo
y
apply
this
set
of
policies,
so
you
can,
you
know,
get
it
all
done
in
one
in
one
big
bundle,
and
all
of
this
is
json
right.
Essentially
this
entire.
What
we
call
a
policy
bundle
is
just
a
big
json
file,
so
it's
very
easy
to
flow
it
out
of
our
api,
make
changes
to
it,
update
it
and
then
flow
it
back
into
the
api.
So
you
know
it's
a
real.
C
It's
real,
get
ops
friendly,
essentially
and
then
we're
kind
of
venturing
into
you
know,
like
I
said
we're,
not
a
runtime
monitoring
tool
like
you
know,
acs
or
falco,
or
something
like
that,
but
we
do
keep
track
of
where
the
images
are
actually
executing
that
we,
the
images
that
we've
scanned
like
in
this
case.
You
know
I've
got
in
this
name
space.
C
I've
got
these
images
running
right
and
I
can
do
things
like
show
me
all
the
vulnerabilities
in
my
production
environment
right
and
I
could
you
know,
filter
around
a
particular
cve
if
there
was
a
zero
day
or
something
like
that
right.
So
there
is,
you
know
this
kind
of
view
into
where
the
things
we've
scanned,
where
they,
where
they
actually
are
out
in
the
you
know
in
the
real
world
right.
So
we
don't
just
cut
it
off
once
the
image
is
in
production.
C
B
A
B
I
was
just
going
to
mention
you
know
back
to
my
earlier
question
around
there's
more
to
an
s
bomb
than
than
just
the
dependencies.
I
believe
I
actually
read
it
again.
The
definition
given
in
the
executive
order
seems
like
they're
only
thinking
about
dependencies,
so
we
might
need
to
educate
our
president
on
what
else.
C
You're
right
right,
I
think
the
the
the
first
version
of
this
this
you
know
will
be-
I,
I
think,
we're
we're
ahead
of
the
game
in
that
regard.
Right
we're
definitely
looking
at
a
lot
more
and
all
of
the
stuff
I've
seen
mentioned
as
things
that
will
probably
be
in
that
first
standard
we
are
already
collecting
you
know
a
lot
of
it
is
around
the
dependencies,
the
licenses
and
so
on,
but
yeah
we
want
to.
We
want
to
basically
have
complete
knowledge
of
the
image
right
everything
about
it.
C
We
want
to
catalog
even
down
to
things
like.
Let
me
go
flip
over
to
this.
This
is
my
other
back
end
here,
even
down
to
things
like
when
we
look
at
the
image
we
want
to
know
where
it's
coming
from
right.
What
are
the
base
images
right?
So
if
I
look
at
this
rel
image,
I
need
to
resize
my
my
fonts
a
little
bit.
C
You
know
in
this
case
looking
at
those
layers-
and
this
goes
back
to
the
conversation
we
were
having
earlier
about-
you
know
looking
at
layers
versus
a
squashed
image.
If
you
have
a
layered
image,
we
can
detect
the
base
image
based
on
those
layers
right.
So
in
this
case,
this
image
is
based
on
ubi8
right,
and
I
know
that,
because
I've
seen
uv
i8-
and
I
know
what
those
layers
look
like
and
this
image
has
those
same
layers
at
the
beginning
of
it
right.
C
C
I
can
differentiate
between
a
vulnerability
that
was
introduced
by
the
base
image
or
a
vulnerability
that
the
developer
put
in,
with
whatever
he
was
doing,
and
likewise
for
policy
violations
right,
so
that
helps
us
with
the
remediation
workflow
and
say
who
do
I
assign
this
to
right?
If
it's
a
base
image
that
we
maintain
internally,
I
can
send
you
know
open
a
github
issue
or
send
a
jira
ticket
to
that
team.
If
it's
something
the
developer
did
I
can.
I
know
how
to
assign
that
that
bug
essentially
right.
C
So
it's
a
that's
a
big
advantage
too
right,
and
we
can
only
do
that
if
the
images
are
not
squashed,
because
once
you
squash
them,
then
it's
just
one
layer
for
the
entire
image
and
there's
no
real.
You
can
do
things
like
see
sort
of
like
this,
like
you
know,
oh
it's
rel
8.4,
which
we
look
at
by
things
like
the
slash
scos
release
file,
but
you
can't
quite
be
definitive
of
what
the
the
ancestor
image
is
in
that
case,
so
you
do
lose
a
lot
of
of
information.
I.
A
B
A
C
C
Some
other
ones
are
not
so
good,
but
in
those
cases
where
the
the
feed
is
deficient
right,
all
the
information
we
have
is
the
the
nvd
feed,
usually
right,
there's
a
couple
other
feeds
as
well,
or
we're
relying
on
a
third
party
to
update
that
information,
and
in
that
case,
you're
you're.
Basically,
you
know
we
can
only
be
as
good
as
the
information
we
consume
and
if
the
publisher
of
the
distribution
is
not
maintaining
that
feed
you're
going
to
get
a
lot
of
false
positives,
yeah
absolutely
so
we
can
generate
the
s.
C
The
evaluation
is
going
to
be
less
than
perfect,
and
if
that,
if
the
good
thing
is,
if
that
you
know
os
publisher
does
get
their
act
together
right
then,
all
of
a
sudden,
the
existing
scans-
you
have
are
more
valuable
right
as
soon
as
we
consume
a
better
quality
feed.
The
evaluations
get
better
automatically.
We
don't
have
to
rescue
in
all
the
images,
because
we
did
the
scheme
we
know
what's
in
there.
We
just
don't
know
the
quality
of
those
components
until
the
feed
is.
Is
you
know
up
to
snuff
yeah,
but
yeah?
B
C
We
have
plug-ins
for
things
like
jenkins
or
forget,
lab
or
things
but
yeah.
Essentially,
it's
just
they're
just
massaging
the
api
right
I
mean
everything
is
done
to
the
api
and
you
know
for
like
get
lab.
You
know
what
that
looks
like
is.
The
developer
would
get
something
in
their
security
dashboard
right.
So,
like
you
know,
I
set
up
a
pipeline
for
them.
You
know.
C
Basically
it's
just
like
build
the
image
and
then
you
know
hit
the
anchor
api
right
here
and
just
scan
this
image,
and
then
it
just
shows
up
in
there.
You
know
if
you
have
a
plug-in
right,
it
just
shows
up
in
their
security
dashboard
like
okay,
here's
your
you
know
what
you're
not
turning
this
off,
so
you
can
see
in
here.
Okay,
there's
a
few
images,
I
can
go
to
the
vulnerability
report
and
they
can
see
what's
in
there.
C
C
Basically,
we
try
to
work
with
any
ci
cd
tooling
out
there
and
push
all
of
that
stuff
that
we
evaluated
both
the
vulnerabilities
and
the
evaluation
they're
just
json
and
they
flow
out
the
api
and
then
the
plug-in
can
do
something
with
them
and
present.
You
know
the
vulnerabilities
or
the
policy
violations
to
the
developer
right
here.
They
don't
have
to
go
to
our
web
ui
to
see
this
stuff
right
this.
This
is
the
exact
same
information
they
would
see
if
they
did
go
into
the
web
ui
right,
so
they
can
just
fix
it.
C
You
know
rebuild
the
image
and
move
on
and
you
know
I
mean
that's
really.
The
idea
right
is
to
get
this
information
to
the
developers
as
early
as
possible,
because
it's
easier
for
them
to
fix.
When
they're
you
know
they
haven't
moved
on
to
another
project.
They
haven't
lost
the
contacts
they
just
know.
What's
going
on
right,
they're
in
that
mode,.
B
C
B
C
Know
that
seems
you
know
pretty
like
a
pretty
big
difference,
but
you
know
in
production
once
something's
in
production,
they're
saying
it
could
be
a
hundred
times
more
expensive
to
fix
the
defect
like.
I
think
that
was
something
like
eighty
dollars
to
fix
a
defect
in
dev
versus
like
seventy
four
hundred
dollars
to
fix
it
in
production.
A
C
C
A
C
C
B
C
C
The
sift
generates
these
s
bombs
right
and
you
can
point
it
at
an
image,
but
you
can
also
point
it
at
a
project
right
on
your
laptop,
so
you
can
kind
of
start
doing
some
of
these
policy
checks
before
you
even
commit
code
into
the
repo
right
and
then
gripe
does
takes
that
s
bomb
and
generates
the
list
of
vulnerabilities,
and
it
can
also
work
on.
It
doesn't
have
to
be
a
an
image
right,
so
you
can
get
that
first
pass
of
feedback
before
you
push.
C
You
don't
have
to
wait
for
the
image
to
build
and
then
the
scanner
to
run-
and
these
are
they're
written
in,
go
they're
really
fast,
I
mean
so.
You
can
get
that
feedback
very
quickly
and
just
fix
a
bunch
of
stuff
before
you've
committed
any
code
at
all
right
and
then
you
know
your
first.
Your
first
push,
you
know,
hopefully,
will
be
the
only
one.
You'll
never
have
any
any
bugs
in
committed
code
ever
again.
C
A
C
Might
upset
the
the
economy
on
on
those
things
right,
but
obviously
it
won't
fix
every
problem,
but
you
can
get
a
lot
of
stuff
fixed
really
quickly
that
way
yeah.
So
we
would
absolutely
recommend
that
people
do
these
scans
as
they're
coding
as
their
prototyping
as
their.
You
know,
doodling
on
their
laptop
before
they
they
push
into
a
repo
and
have
the
auto
build
kick
in.
C
C
Yeah
like
64
of
people-
and
these
are
like
major
enterprises
right-
that
have
had
some
kind
of
impact
from
a
supply
chain
attack
right
now,
I'm
not
saying
anchor
will
solve
every
single
one
of
these,
but
you
know
our
mission
is
to
basically
reduce
this
number
right
and
get
it
as
small
as
possible.
Right,
and
you
know,
I
think
a
lot
of
organizations
really
have
heard
that
right,
they're
they're
paying
attention
right,
so
the
supply
chain
attacks
are
really
a
big
they're
front
of
mind
with
a
lot
of
these
enterprises
right.
C
So
we
definitely
want
to
help
people
protect
themselves
right
and
and
reduce
the
frequency
of
these
problems
and-
and
you
know
like
I
said-
we're-
never
going
to
eliminate
every
problem
out
there,
but
we
want
to
reduce
the
frequency
of
them.
You
know
how
often
they
occur
and
the
severity
of
them
when
they
do
occur
right,
that's
the
main
thing
you
know.
If
we
can
do
those
two
things,
I
think
you
know
we'll
make
the
world
a
better
place.
C
B
C
I
definitely
enjoyed
it.
It's
always
good
to
talk
to
somebody
else
and
and
kind
of
bounce
ideas
around
and
get
y'all's
perspective
on
this
too
right,
because
I
sometimes
I
feel
like
I'm,
you
know
in
a
echo
chamber
here
right,
but
you
guys
see
a
little
bit
larger
slice
of
the
industry
than
I
do
right.
So
it's
good
to
see
what
else
is
going
on
there.
B
A
B
All
right
yeah,
so
again,
this
is
our
devsecops
is
the
way
monthly
show
this
month
was
app
analysis
and
a
couple
more
days
to
go
in
a
month,
but
next
month
we'll
be
talking
all
about
data
data
controls,
data,
encryption
and
we'll
have
again.
Another
devsecops
is
the
way
we'll
have
a
second
openshift
tv
show,
as
well
as
a
couple
podcasts.
So
definitely
look
forward
to
that
as
well,
but
with
that
I
think
I'm
I'm
good.
Today.
I
want
to
thank
paul
again
for
joining
from
from
acor.