►
From YouTube: SBOMs, VEX, and Kubernetes
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
SBOMs, VEX, and Kubernetes - Kiran Kamity, Deepfactor; Jonathan Meadows, Citi; Dr. Allan Friedman, Cybersecurity and Infrastructure Security Agency; Andrew Martin, Control Plane; Rose Judge, VMware
Software supply chain security is rapidly becoming critical to overall security. Softwarew Bill of Materials (SBOMs) formats are standardizing around CycloneDX, SPDX, etc. VEX (vulnerability exploitability exchange) is emerging as a standardized companion to SBOMs to help determine whether a vulnerability is exploitable. For Kubernetes app developers, how do we address the supply chain problem? This panel discusses the practical and operational aspects of gathering, using, and handling SBOMs for containers: both running on Kubernetes and the underlying images that comprise Kubernetes itself. We will cover use cases from open source projects, through vendors and cloud providers, to the use of SBOMs in highly regulated environments including financial services and critical national infrastructure. Panelists include experts and practitioners with deep expertise in SBOMs, VEX, supply chain security, and cloud native application security.
A
There
have
been
a
couple
of
interesting
setbacks,
I
would
say
for
this
panel
because
we
had
four
people
that
were
supposed
to
do
the
panel.
One
of
them
couldn't
make
it
so,
but
he
was
kind
enough
to
record
a
video
and
send
it
over
to
one
of
the
questions
and
the
other
person
felt
sick
just
last
night.
So
but
she
was
kind
enough
to
get
up
this
morning
and
make
some
videos,
so
it's
not
like
so
they're
not
going
to
be
in
person,
but
we've
gotten
the
talking
track
from
them
that
will
play.
A
So.
Let's
see
how
this
goes,
because
we
were
planning
for
a
conversational
kind
of
panel.
Now
I'm
gonna
have
to
go
back
and
forth
between
me
setting
some
background
asking
the
question
and
then
playing
that
video.
So
imagine
it's
a
conversation.
That's
happening
on
the
screen,
so
this
panel
is
about
all
of
the
things
that
you've
been
hearing
in
this
conference.
The
primary
topic
of
this
conference
has
been
around
supply
chain.
Security
and
s-bombs,
especially
for
cloud
native
applications,
is
something
that
is
emerging
as
an
extremely
important
and
Urgent
thing
to
do.
A
So
we
our
goal
in
doing
this
panel,
was
to
bring
some
people
that
have
that
are
experts
in
the
operational
aspects
of
application,
security,
developer
security
supply
chain
security
Etc.
To
make
sure
that
we
talk
about
the
Practical
aspects
of
how
do
you
go
about
achieving
this
mandate?
How
do
you
go
about
creating
s-bomb
because,
of
course,
there's
a
lot
of
talk
about
future
and
things
that
you
can
do
to
make
the
the
perfect
supply
chain
security
solution
over
the
next
year,
two
years
Etc?
A
But
what
do
you
do
now
from
an
operational
perspective,
so
we're
going
to
touch
upon
some
of
those
things
first?
Well,
we're
also
going
to
touch
upon.
What
can
you
do
after
you've
created
your
original
s-bombs
and
so
on
and
so
forth?
So
let
me
introduce
the
panelists
I'm
going
to
start
with
the
people
that
are
not
in
person
present
here
today,
Rose
judge.
She
is
a
senior
open
source
engineer
at
VMware
she's,
one
of
the
maintainers
of
the
turn
project.
A
A
Awesome
and
my
name
is
Kiran
committee
I'm,
the
founder
and
CEO
of
deep
Factor.
We
have
a
booth
here
so
check
us
out
if
you're
interested
deep
factor
is
a
modern
developer
security
solution
for
Docker,
kubernetes
type
applications
that
will
help
you
address
some
of
your
supply
engine
security
supply
chain,
security
problems,
among
other
things.
So
let's
get
started.
A
The
first
question
that
we
wanted
to
talk
about.
We
want.
We
actually
wanted
to
break
this
into
very
practical
aspects
of
esbar.
What
are
what
is
an
s-bomb?
What
is
a
Vex
file?
What
is
a
cyclone
DX
and
spdx
file?
What
do
you
do
with
it?
Why
is
it
important
number
two
we
wanted
to
talk
about?
How
do
people
go
about?
Creating
it
number
three,
as
you
go
through
from
left
to
right
in
your
pipeline,
talk
about.
Where
do
you
store
it?
A
Why
is
it
important
to
store
it
in
such
a
way
that
you
can
actually
search
through
it
and
make
sense
out
of
it,
and
then
we're
going
to
talk
about
how
do
people
consume
it?
And,
lastly,
we're
going
to
talk
about.
Is
this
the
beginning
of
your
supply
chain?
Security,
or
is
this
the
end
all
of
your
supply
chain
security?
Obviously
you
guys
know
the
answer,
but
we'll
double
click
on
the
details.
So,
let's
get
started
with
this
question:
what
is
an
s-bomb
and
why
should
people
care
about
it?
A
A
C
Work
for
the
cyber
security
infrastructure,
Security
Agency
in
the
US
government,
I'm
responsible
for
helping
to
lead
the
global
economy.
I'm
sorry
I
can't
be
there
today,
but
I
think
we
can
kick
off
the
conversation.
There's
some
basics
of
what
is
an
s-bomb.
Why
is
an
s-bomb?
Can
we
do
this
today
and
what's
some
of
the
broader
security
context,
so
I'm,
assuming
most
of
you
are
understanding
no
weapon?
Ask
mom
is
but
essentially
it's
a
dependency
treatment
right,
I
use
this
software.
The
software
uses
this
software
and
so
on.
C
Transparency
in
the
software
supply
chain
is
going
to
be
a
key
part
of
really
moving
forward
and
making
progress
on
how
we
think
about
software
and
in
fact,
it's
a
bit
shocking
that
perhaps
the
vast
majority
of
software
today
isn't
built
with
greater
transparency,
so
s-bomb
get
help.
Developers
can
help
people
selecting
software
and
it
can
help
users
to
make
sure
they
have
a
capability
to
react.
C
There
are
real
risks
out
there
as
we
think
about
software
supply
chain.
A
lot
of
them
are
vulnerable
vulnerabilities
right.
Many
of
us
spent
a
lot
of
time,
hunched
over
laptops
in
guest
rooms.
In
the
end
of
2021,
trying
to
understand
where
our
risk
was
for
the
log
for
J
crisis,
that's
not
a
one-up
I
would
not
bet
heavily
on
saying
well,
there
will
never
be
another
log
for
Jay,
but
there's
also
a
broader
question
around
risks
right.
C
It's
also
going
to
be
coming
from
your
friends.
The
governments
around
the
world,
the
2021
executive
order
said
ultimately
everything
the
US
government
buys
is
going
to
happen.
Captain
s
bomb,
the
FDA,
which
regulates
medical
devices
and
said
hey,
you're,
not
going
to
be
able
to
put
a
new
medical
device
on
the
market
without
telling
the
regulator
what
the
dependencies
are
for
a
full
s
bomb.
And,
of
course,
our
friends
across
the
Atlantic
in
the
EU
have
proposed
these
cyber
resiliency
act,
which
says
that
everything's
sold
in
the
European
Union
must
have
an
espec.
C
There
are
plenty
of
tools
out
there
today,
both
proprietary
and
open
source-
and
there
are
two
great
s-bomb
data
formats,
spdx
and
Cyclone
VX
they're,
both
open
source
projects,
they
continue
to
evolve
and
one
of
the
things
we're
working
on
is
to
make
sure
that
they're
fully
interoperable
at
the
end
of
the
day.
It's
just
data.
C
So
what
about
the
broader
security
landscape
right?
The
vision
isn't
just
to
create
this
brand
new
thing.
It's
to
build
this
into
our
software
security
architecture
and
how
we
think
about
risk
for
our
organizations
so
we're
busy
to
deciding
you
know
what
are
the
requirements
to
make
sure
this
happens
and
then
linking
this
data
to
other
things
that
we
care
about,
such
as
right,
making
sure
we
can
map
it
to
vulnerability,
databases,
making
we're
sure
we
can
map
it
to
other
sources
of
intelligence.
C
That
at
scale
will
help
us
prioritize
and
make
sure
we're
really
focusing
on
the
vulnerabilities
that
matter
and
increasingly
we're
interested
in
the
security
of
an
s-bomb.
So
some
of
it
is
pretty
basic.
You
should
sign
your
s-clock.
How
should
you
sign
your
s-bomb?
Well,
if
you
have
the
ability
to
sign
your
software
use
that
key
and
if
you
don't
have
the
ability
to
use
it
to
sign
your
software.
Well,
then
we've
got
bigger
problems,
so
let's
focus
on
sort
of
overall
modernization
and
the
last
step
is
going
to
be.
C
How
do
we
verify
that
the
data
is
true?
How
do
we
actually
show
that
there
is
a
path
that
comes
from
my
build
process
so
that
it's
not
just
trust
me,
but
it's
actually,
we
can
have
some
artifacts
that
have
a
full
chain
of
trust
and
we're
very
excited
to
see
that
continue
to
evolve.
I
think
that's
now
in
early
days,
but
like
all
security
processes,
we
need
to
start
with
a
crawl,
then
walk
then
run
hope.
We
have
a
very
productive
day
and
I'm
looking
forward
to
having
conversation.
A
Awesome
so
to
summarize,
there
are
two
two
formats
for
esbom
that
you
know
again
boiling
that
this
down
to
what
can
you
practically
do
between
now
and
June
if
you
are
mandated
to
comply
with
Biden's
executive
order,
two
formats
spdx
Cyclone
DX
pick
one,
and
even
if
you
don't
worry
about
don't
know
which
one
to
pick
I
would
say
pick
either
one
it's.
It's
not
a
bad
choice
to
pick
either
one.
There
are
tools
available
to
create
both.
There
are
also
tools
available
or
being
built
to
make
sure
that
you
can.
A
You
know
interoperate
between
the
two
and
convert
from
one
to
another.
The
second
thing
that
you
need
to
do
is
understand
whether
you
need
to
generate
a
Pex
file.
I
would
say
if
you're
hard-pressed
for
time.
Think
of
it
like
a
phase
two
project
like
do
your
s-bombs
first
and
then
add
Vex
later
on,
because
Vex,
basically
I,
you
know,
helps
you
identify
where
you
know
which
of
the
vulnerabilities
that
you
have
is
exploitable
ETC,
and
you
may
need
to
do
some
additional
work
to
get
that
data
in
place.
A
So
that's
step
number
two
and
then
of
course,
things
like
salsa,
Etc
and
other
things
that
will
help
you
establish
provenance
signatures.
Those
are
all
things
that
I
think
you
can
face
down.
The
road
either
could
be
phase
two
phase
three
and
Beyond.
So
if
you
were
to
ask
me,
I
would
say:
create
your
s-bomb
first,
that's
step.
One
step
two
would
be
think
about
signing
step.
Three
would
be
add
Vex
to
it.
As
a
as
an
addition
would
you
agree:
Ella
yeah.
B
Yeah
I
do
Andy
sorry,
the
the
the
mystery
of
Vex
is
is
the
cve
that
is
in
the
dependency
either
one
two
three
levels:
transitively
down
the
call
graph
actually
reachable.
So,
for
example,
worst
case
scenario
is
a
remote
code
execution.
Can
somebody
do
a
maybe
a
Shell
Shocked,
looking
dump
in
a
specific
bad
string
into
my
web-facing
server
into
my
into
my
socket
and
end
up.
Triggering
Miss
was
what
I'm
looking
for
an
out
of
context
execution,
so
untrusted
code
being
executed
and
then
potentially
firing
a
reverse
shell.
B
That's
the
worst
case
scenario
for
any
web
application
gives
an
attacker
a
foothold
that
they
can
then
begin
to
enumerate.
What's
within
that,
let's
say
a
container
at
this
point,
so
Vex
aims
to
say:
okay,
we
have
got
shell
shock
five
layers
deep
to
pick
any
example,
but
actually
we
are
going
to
remove
Bash
from
this
container
image,
so
there
is
no
mechanism
for
that
that
particular
function
signature
in
bash
to
be
executed.
B
So
we
know
that
even
if
this
is
exploited,
even
if
that
malicious
payload
is
written
into
our
web
server,
there's
no
way
this
can
be
triggered
the
another
way
you
can
do.
This
is
static
analysis
of
the
call
reachability
graph,
so
you
can
think
about
that
kind
of
like
decomposing,
an
application
into
an
abstract,
syntax
tree
and
then
walking
it
and
if
the
piece
of
code,
for
example,
you
might
have
a
vulnerable
library
with
three
function
signatures,
and
you
know
that
one
of
those
functioning
signatures
just
doesn't
get
called
in
the
code
at
all.
B
So
you
can
either
walk
that
AST
with
the
breachability
analysis
tool
code,
ql,
sem
grep,
sneak
they'll
all
have
these
capabilities
are
all
able
to
analyze
and
understand
whether
that
code's
reachable,
you
can
also
with
some
languages,
do
something
that's
a
bit
like
tree
shaking
so
just
removing
the
code.
If
it's
an
interpreted
language
where
the
source
is
fed
to
an
interpreter
at
runtime,
we
can
just
remove
the
source
code,
but
the
complexity
of
doing
this
is
really
quite
a
heavy
burden
on
a
user.
B
So,
as
you
say,
The
Ordering
of
these
things
publishing
effects
for
a
piece
of
software
that
you're
that
you're
publishing
has
to
come
with
a
deep
level
of
engendered
trust,
because
if
the
Vex
is
wrong
and
people
then
run
vulnerable
code
and
production,
there's
a
question
potentially
of
liability
when
deeply
uncharted
waters.
At
this
point,
so
Vex
is
not
something
that
we've
seen
particularly
widely
adopted
as
yet,
there
has
recently
Affiliated
version
of
the
specification
called
openvex
which
I'm
yet
to
dig
into.
It
will
be
interesting
to
see
I
believe
they're.
They
are
compatible.
B
B
If
we
have
the
capability
to
sign
our
software,
then
it
makes
sense
for
anything
that
we
want
to
give
that
same
level
of
trust
to
because,
of
course,
the
signature
just
says,
the
person
in
control
of
this
cryptographic
key
at
this
point
in
time
liked
this
thing
enough
to
put
their
name
on
it.
It's
not
really
anything
else.
It
doesn't
mean
that
the
artifacts
sanctity
is
secure.
It
doesn't
mean
that
it's
composition
is
necessarily
secure.
It
just
means
the
person
making
a
point
in
time.
B
Judgment
call
wanted
to
put
a
stamp
on
it,
so
the
ability
to
then
do
that
signature
signing
process
for
additional
metadata
that
you
publish
about
your
software
awesome
yeah,
definitely
worth
doing.
But
really
the
question
is:
is
the
thing
that
you're
signing?
Do
you
have
a
guarantee
that
you're
actually
giving
with
that?
B
We
have
to
be
correct,
so
we
have
to
be
running
not
only
perhaps
the
manual
review
or
the
manual
exploitability
check
to
make
sure
that
we're
not
triggering
that
remote
code
execution,
but
also
some
automation
around
it.
A
test
harness
this
is
where
the
automated
tooling
comes
in
the
reachability
analysis,
because
the
Temptation
will
be
to
essentially
allow
that
document
to
atrophy.
It's
done
once.
Yes,
we're
happy
software
moves
quickly.
It
evolves.
B
This
is
what
we
want,
so
if
we
then
make
a
second
release
without
revalidating
the
sanctity
or
the
safety
of
that
Vex
document,
we
risk
undermining
the
trust
that
is
absolutely
necessary
for
ultimately,
the
internet
I'd
say,
but
for
for
the
exchange
of
cryptographic,
information
and
and
trust
and
signing
so
yes,
small
soapbox
on
Vex
I'm
super
excited
for
it,
but
it
has
to
be
done
with
a
whole
bunch
of
caveats.
Yeah.
A
Yeah,
the
next
question,
I
think
that's
a
good
question
for
you
Andy,
a
quick
question
that
comes
up
whose
job
is
it?
Is
it
engineering
team's
job
to
generate
these
things
at
build
time?
Is
it
the
devops
team?
Is
it
the
security
team?
So
how
would
you
you
know
these
questions
come
up
in
organizations
all
the
time?
So
how
would
you
answer
that
question.
B
B
That
that
is
a
common
practice
in
organizations,
because
we
use
that
information
to
go
to
our
cve
feeds
that
are
published
by,
in
that
case,
the
node
security
project
and
then
embellished
by
software
security,
vendors
to
say.
Well,
actually
that
version
is
vulnerable
and
it's
got
a
CV
rating
of
X
and
you
can
then
make
a
decision
whether
or
not
to
ship
that
to
production
generating
an
s-bomb
is
really
a
very
similar
experience.
B
B
B
Rather
than
necessarily
answering
it
a
build
time,
we
have
the
most
information
to
build
a
complete
s-bomb,
but
if
I
give
you
an
s-bomb,
you
should
probably
revalidate
it
against
the
contents
file
system,
because
plenty
of
s-bombs
are
wrong.
It's
perhaps
even
the
question
for
the
package
producer.
Do
you
consider
that
actually
part
of
the
the
software
that
your
software
you've
produced
consumes
and
then,
finally,
we've
got
so
build
packaging
ingestion?
B
The
difference
there
build
is
obviously
in
the
build
system.
Packaging
is
when
it's
being
pushed
onto
the
npm
registry,
for
example,
but
what
about
ingestion?
Well,
if
we're
a
regulated
organization,
we
probably
pull
code
in
third
party
code
into
our
organization
across
some
form
of
perimeter.
Zero
trust
is
a
wonderful
and
necessary
part
of
modern
security,
but
it
doesn't
mean
that
we
don't
still
establish
a
perimeter.
We
don't
run
all
of
our
kubernetes
nodes
publicly,
because
defense
and
depth
means
that
we
don't
throw
the
baby
out
with
the
bath
water.
B
So
when
we're
ingesting
third-party
code
into
our
organizations,
we
still
care
about
its
composition.
We
should
still
at
the
at
the
top
level
of
risk
and
compliance.
We
should
still
analyze
those
packages
which
still
run
static
analysis
on
the
code
itself.
We
can
still
run
those
code,
reachability
questions
against
those
packages
and,
ultimately,
at
some
point
in
the
future,
we
probably
want
to
do
contributor
analysis
as
well.
B
The
open
ssf
tried
to
do
this
and
kind
of
had
to
back
out
because
there's
problems
of
collusion,
you
can't
actually
unmask
all
the
Linux
kernel
contributors
because
they
may
be
under
authoritarian
regimes.
We
don't
want
people
being
pressured
to
put
back
doors
into
the
software
that
we
know
and
love.
So
there
are.
There
are
questions
of
trust
throughout
this
whole
process
and
ultimately,
what
s-bombs
do
is
give
us
a
better
visibility
into
where
we
might
have
a
vulnerability,
but
they
do
not
solve
the
software
supply
chain
security
issue.
A
A
The
recommendation
here
is
sbos
need
to
be
created
at
build
time
and
therefore
the
devops
person
does
need
to
be
involved,
but
I
think
the
strategy
of
what
is
bumps
need
to
be
created
needs
to
come
from
the
Security
Experts,
so
Security,
Experts,
appsec,
prod
SEC
Etc
teams
are
the
ones
that
basically
determine
what
do
you
need
to
do
for
the
s-bombs
tell
work
with
the
engineering
teams
and
the
devops
teams
to
go
ahead
and
Implement
that,
as
part
of
the
CI
pipeline
to
to
create
it
right?
Yes,.
A
The
next
question
is:
okay:
we've
generated
s-bombs,
we've
decided
what
formats
are
created
in
and
we've
generated
as
bombs
during
the
build
step.
Where
do
you
store
them?
Is
there
even
a
standard
at
this
time
and
after
you
store
them?
How
do
you
share
them?
So,
let's
talk
about
that
and
we
asked
this
question
to
Rose-
and
this
is
her
answer
in
the
recorded
video.
D
D
When
we
think
about
where
s-bombs
should
be
stored,
I
think
the
considerations
around
the
storage
itself
is
really
not
much
different
than
any
other
type
of
cloud
native
artifact.
The
same
considerations
are
still
at
play:
life
cycle
management,
caching,
versioning,
Access
Control,
when
we
think
about
where
we
should
store
s-bombs
those
qualities
around
you
know
where
you're
actually
going
to
put
it
are
less
specific
to
s-bombs
themselves.
D
But
what
is
unique
to
s-bombs
when
we
think
about
storage
is
their
association
with
an
artifact
that
they
are
describing
and
really
making
sure
that
there
is
some
type
of
meaningful
relationship
between
the
s-bomb
and
the
artifact
right.
Ideally,
If
you're
receiving
a
piece
of
software
from
a
vendor.
You
would
have
access
to
the
relevant
parts
of
the
s-bomb
that
describe
that
software
in
the
same
place
or
very
near
to
where
you
are
pulling
the
software
from
as
of
right.
Now
how
s-bombs
should
be
stored
is
less
clear.
D
There
are
lots
of
discussions
taking
place
that
are
trying
to
answer
this
very
question
of
how
so,
while
there's
no
good
answer,
I
do
think
that
there's
a
couple
things
to
consider.
As
you
know,
we
work
to
try
to
answer
this
and
the
first
is
access
control
and
the
parties
involved
in
Sharing.
If
there's
no
reason
to
restrict
access
to
an
s-bomb,
then
sharing
is
a
lot
easier
right.
D
D
We
need
to
consider
the
mechanisms
for
sharing
so
likely
having
some
type
of
network
with
the
ability
to
push
and
pull
documents
or
parts
of
documents,
life
cycle,
management
of
s-bomb,
metadata
and
protocol
around
when
certain
metadata
might
expire
or
no
longer
be
shareable,
and
this
is
just
kind
of
the
tip
of
the
iceberg
when
we
think
about
the
best
way
to
distribute
s-bombs,
which
I
think
illustrates
why
there's
no
canonical
way
to
do
this
yet
right.
There's
a
lot
to
consider.
D
So
again,
there
is
no
clear
and
canonical
answer
for
this,
but
a
few
considerations
beyond
what
I've,
already
kind
of
mentioned,
for
how
and
where
an
s-bomb
should
be
distributed,
needs
to
first
and
foremost,
consider
what
is
the
software
and
who
is
the
consumer.
Obviously,
if
you're
downloading
an
app
from
the
App
Store
you're
not
expecting
an
s-bomb
to
come
with
it
right,
but
if
you're
receiving
source
code
from
a
vendor
to
build
into
your
product,
you
probably
have
more
interest
in
the
contents
of
that
code.
A
The
most
important
thing
like
rose
mentioned
is
not
just
where
you
store
it,
but
also
how
you
give
access
to
it
and
who's
supposed
to
access
what
is
bombs
so
thinking
around
that
part,
and
you
know
making
sure
that
you
have
the
right.
You
work
with
your
ITP
people
to
put
the
right
checks
and
balances
from
an
authorization
perspective
on
your
OCTA
or
your
SSO
provider,
to
restrict
access
to
certain
users
to
certain
types
of
response.
That's
the
the
the
challenge.
A
The
operational
challenge,
so
thinking
through
that
is,
is
the
the
painstaking
work
part.
The
next
question
would
be:
should
organization,
should
organizations
be
asking
their
vendors
for
sbon?
Let's
say
you
do
have
vendors
providing
your
software.
You
know
if
they're,
if
these
vendors
are
selling
into
federal
government,
of
course,
they're
mandated
by
the
Biden
executive
order
to
provide
their
response,
but
should,
if
you
guys,
are
not
a
federal
agency,
are
you
still
going
to
benefit
by
asking
for
s-bombs?
D
Like
most
answers
of
the
opinion
that,
yes,
you
should
be
asking
your
vendors
and
Cloud
providers
for
s-bombs
if
the
software
you're
consuming
from
them
could
be
exploited,
which
is
most
software
not
all,
but
most,
if
nothing
else
as
a
way
to
establish
trust
with
those
vendors.
So
if
you
receive
an
s-bomb
from
a
vendor
that
you're
consuming,
you
can
kind
of
do
a
sanity
check.
D
You
can
verify
that
the
binary
they
give
you
matches
the
F-bomb
that
they
give
you,
and
this
kind
of
will
give
you
an
idea
if
the
vendor
you're
working
with
has
an
idea
about
what's
in
their
code,
and
if
you
know
the
s-bomb
only
has
two
components
and
it's
a
huge
binary
with
lots
of
dependencies,
then
maybe
that's
a
red
flag.
Maybe
you
have
to
kind
of
reevaluate
if
you
should
be
using
that
vendor.
D
The
F-bomb
from
the
vendor
might
also
provide
additional
information
that
you
wouldn't
be
able
to
glean
from
just
the
binary.
So
maybe
there's
build
time
information
in
there
that's
relevant
to
the
way
you
use
your
software
and
three,
the
s-bomb
from
the
vendor
can
help.
You
understand
your
exposure
and
risk
when
cves
come
out
affecting
components
that
you
might
be
consuming
and
I.
Think
the
caveat
to
all
of
this
is
that,
if
you're
asking
for
s-bombs
from
your
vendors,
then
you
need
to
have
a
way
to
make
sense
of
that
s-bomb.
D
A
Okay,
so
this
is
an
interesting
question:
let's
say
you
are
the
vendor,
you
provide,
you
create
an
espa.
You
know
your
s-bomb
has
some
serious
vulnerabilities
in
it.
Are
you
still
going
to
go
share
that
respond
with
customers
or
do
you?
Are
you
going
to
shy
away
and
not
share
it
until
that
vulnerability
is
fixed
like
what's
what's
the
ethical
thing
to
do
here,
and
also
what's
the
Practical
thing
to
do
here.
A
Awesome
I'm
going
to
ask
you
a
question:
Andy
now
that
we've
created
the
s-bombs,
how
are
how
do
people
consume
s-bombs,
because
you
know
there's
no
point
just
creating
a
bunch
of
s-bombs
and
just
letting
it
sit
there?
What
are
the
things
you
know
proactively
operationally
and
reactively
that
one
could
do
from
a
consumption
and
making
sense
of
the
s-bomb
perspective
in
the
interest
of
time?
You
know
I'll
give
you
two
minutes.
Thank.
B
You
yeah
there's
some
interesting
interesting
points
there,
one
on
the
actual
generation
of
s-bombs
by
Cloud
providers
and
whether
they're
disclosed
or
not.
Ultimately,
the
metrics
we
can
gather
from
these
are
mean
times
remediation
of
the
providers
of
our
software.
If
somebody
has
a
cve
and
then
they
ship
a
patch
the
next
day,
well
before,
like
a
24-hour
remediation
window,
that
is
a
risk
window
for
our
production
software.
But
that's
that's
quite
reasonable.
You
know
in
large
organizations
it
might
take
two
or
three
days
just
to
get
that
process
moving
sometimes.
B
B
Then
we
might
do
something
like
actually
scan
the
package
manifest
with
with
a
container
vulnerability
tool,
because
still
those
package
URLs
are
are
the
same
information
that
we
use
for
CV
scanning,
But,
ultimately
really
to
close
this
Loop
and
to
do
so
in
good
faith
as
Rose
says
about
the
sort
of
dishonest
lens
of
not
disclosing
a
vulnerability
or
an
S
bond,
with
vulnerability
in
vendors
should
be
pushing
out
updates
and
saying
to
us.
We've
determined
that
this
one,
but
this
zero
day
has
been
announced.
B
It
is
in
this
package
and
we're
actively
working
on
it.
The
Vex
document
might
then
be
updated
for
that,
so
the
s
bomb
still
exists,
but
the
new
Vex
would
say
well,
there's
actually
an
exploitable
vulnerability
in
here
recommendation
is
we're
working
on
it,
which
is
one
of
the
subfields
of
the
vex,
and
then
they
push
the
next
export
s-bomb
with
the
the
next
package
version
at
the
point
for
mediation.
So
it
is
a
complex
dance
at
the
moment
and
there
is
no
there's
no
solution
for
it.
B
A
A
good
resource
for
you
guys
to
look
at
you
know,
as
you
think,
about
how
do
I
make
sense
of
these
s-bombs
is
the
guac
document
from
Google
guac
project.
Basically
I
like
the
way
it
breaks
it
down
into
three
parts,
proactively
thinking
about
consuming
s-bombs,
operationally
thinking
about
admission
control
Etc,
so
so
the
proactive
part
would
be.
A
Does
my
s-bomb
have
any
vulnerabilities
like?
If
so,
is
anything
critical?
Do
I
need
to
tell
my
developers
to
go
fix,
something
essentially
the
sca
aspect.
Software
composition,
analysis
aspect
of
it
both
from
an
OS
packages
installed
in
your
container
images
perspective,
as
well
as
the
dependencies
that
have
vulnerabilities
Etc.
A
That's
the
proactive
part,
then
there's
the
operational
part,
which
is
I'm
going
to
start
my
container
and
my
kubernetes
is
going
to
start
my
container
and
at
that
time,
from
an
admission
control
perspective,
do
I
even
launch
certain
containers
that
have
a
certain
set
of
vulnerabilities
or
a
certain
set
of
you
know.
Signature,
mismatches
and
things
like
that.
So
admission
control
is
the
second
operational
part
and
the
third
part
is
reactive.
A
There
there's
a
new
CV
that
just
came
out
where
all
in
my
kubernetes
clusters
is
a
vulnerable
component
running
that
has
that
CD
I
should
be
able
to
go
and
search
for
it
and
then
look
at
it
for
my
s-bomb
from
a
reactive
perspective.
So
all
of
these
three
aspects
are
very
important,
so
don't
just
think
about
creating
s-bombs
and
storing
them
somewhere.
Actually
think
about
this.
You
know
from
a
strategic
perspective.
How
do
I
make
sense
of
it
from
a
consumption.
You
know
point
of
view.
A
We
are
out
of
time.
Isn't
it
yeah?
Okay?
So
because
we
had
to
do
this,
recording
and
and
as
opposed
to
the
conversation
I
think
we
overshot
on
time
a
little
bit.
But
if
you
do
have
any
questions
by
all
means,
please
reach
out
to
Annie
and
I.
Will
we're
going
to
be
here
for
a
few
more
minutes
to
have
a
chat
with
and
answer
any
other
questions
or
just
geek
out
with
you
guys?
So
thank
you.