►
From YouTube: The State of SBOMs - Moderated by Dan Lorenc, Allan Friedman, Nisha Kumar & Frederick Kautz
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
The State of SBOMs - Moderated by Dan Lorenc, Chainguard; Allan Friedman, US Government; Nisha Kumar, VMware & Frederick Kautz, LF Public Health
A
B
I'm
just
going
to
say
we
were
going
to
jump
on
all
at
once
and
then
try
to
squish
squeeze
the
doorway.
Alan
friedman,
I'm
sometimes
referred
to
as
the
guy
who
doesn't
shut
up
about
s-bomb
failed
academic
who
got
talked
into
joining
government
about
six
years
ago
and
helped
coordinate
the
international
cross-sector
effort
at
ntia.
That
sort
of
created
a
shared
vision
of
s-bomb,
recently
moved
over
to
cisa
to
help
scale
and
operationalize
that,
while
still
making
sure
that
s
bond
remains
a
community-led
effort.
C
C
D
Hello,
I'm
frederick,
so
I
focus
on
quite
a
few
areas
in
the
in
the
open
source
community.
I
have
prior
experience
working
on
storage
and
networking
and
containers.
I
spent
a
significant
portion
of
my
time,
focusing
on
where
container,
networking
and
telecommunications
met.
I
still
work
with
those
particular
groups
on
an
ongoing
basis
as
well
to
help
define,
what's
called
the
cloud
native
network
function.
I
also
work
in
the
zero
trust
space
quite
extensively
in
around
these
time
periods.
A
Awesome,
you
said
both
of
the
magic
buzzer
words,
zero
trust
and
of
everything
in
the
last
executive
order.
All
right
well
I'll,
introduce
myself
quickly
as
well.
I
am
moderating
the
event
this
is
going
to
be
shown
at
so
if
you're
watching
this
live.
You've
probably
already
heard
this
if
you're
watching
this
later,
my
name
is
dan
lawrence.
I'm
an
engineer,
and
I
work
on
a
lot
of
container
cloud
software
supply
chain
security
related
things,
which
is
how
I
got
roped
into
coordinating
this
conference
and
s
bombs
in
particular.
A
B
B
I
think
it's
it's
a
natural
approach.
The
list
of
ingredients
is
imperfect,
but
they're
sort
of
a
very
real
question
which
is
hey?
Would
you
buy
or
use
or
consume
something
where
they
couldn't
produce
this
right?
If
someone
said
now
that
twinkie,
it's
got
stuff
in
it
and
we
know
that
has
stuff
in
it,
but
we
sort
of
hope
that
someone
somewhere
is
actually
keeping
a
careful
dragon
and
that's
really
a
big
part
of
it,
and
the
other
analogy
I
like
is
this
is
perhaps
a
little
bit
ambitious
to
think
about.
B
D
C
So
an
analogy
that
I've
been
using
a
lot
with
regards
to
container
images
is
a
sandwich
and
the
way
that
I
would
talk
about
you
know
it.
What
s-bomb
brings
to
the
table
is
the
difference
between
a
subway
sandwich
and
you
know
no
no
shade
on
subway,
but
would
you
rather
what?
What
do
you
think
is
the
difference
in
quality
between
the
subway
sandwich
and
a
sandwich
that
was
created
by
a
farm
to
table
restaurant?
C
The
farm
to
trade
table
restaurant
probably
has
the
higher
quality
sandwich
because
they
actually
know
where
all
the
ingredients
come
from
and
they
have
working
relationships
with
the
communities
that
make
those
ingredients.
So
that's
because
you
know
container
images,
look
like
sandwiches,
that's
usually
the
the
analogy
I
use.
A
D
Yeah,
so
I
I
don't
really
have
any
good
analogies
in
this
space,
but
I
I
do
try
to
bring
things
down
to
like
what
are
the
core
principles
that
people
want
to
want
to
have
part
of
it
is
when
we
talk
about
well,
where
did
it
come
from?
What's
the
quality
of
it
and
it
all
comes,
I
think
it
all
comes
down
to
to
things
like
trust
like
should
I
trust
this
thing.
D
How
long
should
I
trust
it
for
and
for
what
period
of
time
are
there
any
conditions
where
I
should
stop
trusting
it,
and
the
way
that
we
have
things
today
we're
trying
to
improve
on
on
that
level
of
trust,
to
say
so
that
we
can
reason
about
it
and
not
just
human
reason,
reasoning
about
it,
but
to
be
able
to
automate
that
that
reasoning
to
automate
much
of
that
trust
trust
process.
So.
C
D
A
Makes
sense
so
one
of
the
first
topics
I
wanted
to
talk
through
here
is:
why
now
right,
it's
2021
supply
chain
attacks
are
all
over
the
news:
we've
had
food
ingredient
labels
forever.
We've
had
a
software
for
a
long
long
time.
Why
now,
why
is
now
the
right
time
to
do
this?
Why
is
why
are
all
these
attacks
happening
this
year?
C
Oh,
I
was
gonna
say
like
you
know,
I
think
there
have
been
folks
that
have
been
focused
on
trying
to
maintain
software
hygiene
for
a
very
long
time.
It
just
so
happens
that
people
really
didn't
see
a
need
for
it,
because
at
the
time,
supply
chain
attacks
were
not
really
happening,
but
the
now
that
we
have
some
that
are
very
high
profile
and
everybody
knows
about
it,
and
I
heard
it
on
the
marketplace
morning
report
many
times
now.
B
And
I
think
you
know
there
are
a
couple
of
reasons.
One
is
in
a
rare
note
of
optimism:
we've
gotten
slightly
better
at
software
security
and
so
that
a
determined
adversary
that
actually
wants
to
make
some
progress
actually
can't
go
and
attack
the
front
gate.
They've
got
to
sort
of
sneak
in
and
and
find
a
way
to
go
upstream,
and
that
of
course,
expands
the
attack
surface.
B
The
other
thing
to
acknowledge
is,
of
course,
people
have
been
talking
about
s-bomb
for
a
long
time,
and
you
know
they're
they're
champions
out
in
the
world.
Folks,
like
you,
know,
josh
corman,
I'm
the
cavalry
that
have
been
talking
about
this
and
in
fact
there
was
even
an
attempt
to
put
this
in
legislation
back
in
2014.
B
B
People
weren't
always
great
about
tracking
their
open
source
obligations
and
licensing,
and
in
fact
that's
the
origin
of
one
of
the
two
big
f-bomb
standards
is
to
track
the
licensing,
but
I
think
there's
sort
of
this
confluence
events
of
people
saying
okay,
we
know
we're
gonna
have
to
do
something,
and
this
is
something
so,
let's
move
forward
and
then
the
high
profile
supply
chain
tax
have
given
both
industry
push.
And,
of
course,
your
friends
in
the
us
government
have
said
you
know
hey:
what
can
we
do
to
really
drive
behavior
and
investment
changes.
D
Yeah
and-
and
I
think
a
lot
of
it
comes
down
to
economics
as
well
like
if
you're
a
determined
attacker,
you
want
to
get
an
effect
whether
that
effect
is
to
increase
your
bank
account
or
to
exfiltrate
some
information
as
part
of
a
vast
resistant
threat.
Then
you
have
limited
resources.
Even
if
you
have
a
lot
of
resources,
it's
still
limited,
so
you
have
to
look
at.
D
Where
can
I
apply
these
resources
and
to
allen's
point,
we've
gotten
much
more
savvy
at
certain
defending
against
certain
types
of
attacks,
because
we
see
them
very
often,
and
the
supply
chain
is
one
of
those
areas
where,
if
you
want
to
attack
a
hardened
target,
you
don't
attack
it
directly.
You
try
to
find
the
the
supplier
attack
the
supplier
and
then
indirectly
gain
access
to
the
to
the
bigger
target.
D
There's
also
a
couple
other
advantages
as
well
like
we
focus
heavily
on
well.
How
do
we
defend
against
the
the
companies
our
suppliers
from
being
broken
into,
but
also
take
into
consideration
that
it's
not
just
it's
not
just
whether
they're
broken
into
you
could
have
something
where
the
supplier
is
never
breached.
But
you
still
don't
you
don't
have
visibility
into?
Oh
I'm
running
a
version
of
some
xml
parser
that
is,
that
is
at
risk.
It
was
statically
compiled
in
my
image.
Scanner
won't
pick
it
up.
D
B
B
You
have
one
or
you
don't
and
of
course,
there's
many
shades
of
nuance
beyond
that,
but
one
of
the
things
this
can
get
us
is
it.
It
allows
us
to
say
here's
some
progress
that
you
can
tangibly
make
that
you
can
ask
for
your
supplier.
That
doesn't
say:
oh,
you
need
to
go
through
a
seven
year
process
audit
to
show
that
you
have
that
you've
been
reading
from
the
devsecops
bible
and
you've
implemented
your
soul.
It's
an
s-bomb
is
a
nice
discreet
thing
that
is
in
economics
terms.
It's
an
efficient
signal.
B
C
So
this
is
this,
I
think,
is
like
some
place
where
developers
say
wait
a
minute.
I
do
have
an
s
form
it's
right
there
in
the
package.json
and
then
there
has
to
be
like
some
education
involved
in
there.
So
it's
yeah
part
of
our
part
of
our
growth
over
here
is
to
actually
understand
like
why.
The
things
that
we
have
right
now
do
not
meet
the
requirements
that
we
want.
A
Cool
yeah,
so
this
is
kubecon
cloud
native
con.
Everybody
here
is
focused
on
containers,
kubernetes
things
and
kubernetes,
so
we're
recording
this
in
september
kubernetes
a
few
months
ago,
just
shipped
their
latest
release
with
s-bombs
for
the
very
first
time,
there's
a
bunch
of
work
that
went
into
making
a
new
small
creator
for
the
kubernetes
infrastructure.
A
B
B
Of
the
cloud
I'm
going
to
give
some
of
the
sort
of
the
the
contrast
about
what
we
need
to
sort
of
think
about
and
then
I'll,
let
the
people
who
actually
build
things
chime
in
on
what
we're
doing,
and
I
think
it's
important
to
acknowledge
that
a
lot
of
the
impetus
behind
software
transparency
started
at
the
other
end
of
the
software
world
it
was
around
shipped
software
was
around
embedded
devices.
It
was
around
legacy
tech.
It
was
around
safety
critical
world
where
it's
actually
really
important
to
know
hey
since
it.
B
You
know
my
rare
industrial
control
system
may
not
have
a
vulnerability
in
itself.
That's
easily
scanned,
for
I
have
to
care
about
what's
under
the
hood
now.
Another
big
part
of
it
is
this:
it's
assumed
that
the
asset
owner
or
the
hospital
or
whoever's
that's
using
the
software
on
prem
is
empowered
to
take
some
action
right
that,
once
I
know
what
the
s
bomb
is,
I
can,
if
that
patch
isn't
available,
I
can
tune
my
ids.
I
can
segment
my
network.
B
I
can
work
with
my
thread
until
there's
a
lot
of
security
options
there
from
the
customer
side,
and
so
we
talk
a
lot
about
a
lot
of
the
benefits
from
the
user
side
in
a
cloud
or
sas
world.
Some
of
the
underlying
mechanics
are
a
little
different,
and
this
is
something
that
I
think
the
community
still
needs
to
explore
is
to
sort
of
actually
nail
down.
B
What
are
the
broader
ecosystem-wide
use
cases
across
the
supply
chain,
but
I
also
think
that
there's
a
huge
advantage
in
the
cloud
native
world
in
that
there's,
the
the
tools
of
devops,
allow
us
to
sort
of
say
we're
we're
already
a
little
more
aware
of
the
importance
of
knowing.
What's
in
our
you
know,
ongoing
build
process,
and
so
I
think
that's
enabled
much
faster
adoption
and
people
sort
of
getting
the
value,
and
hopefully
you
all
out
there
do
too.
C
One
thing
I
do
notice
is
that
in
the
cloud
native
world
software
reuse
is
really
high
much
higher
than
what
folks
have
anticipated
for
software.
Usually
it
used
to
be
like
a
small
piece
of
you
know,
code
that
was
shared
by
a
usb
stick
and
now
it
is
like
everyone
has
their
like
own,
open
source
project
hosted
on
github
and
it's
free.
Everyone
can
use
it.
And,
oh
that's,
that's
wonderful,
because
that
means
that
there's
a
diversity
of
innovation
that
comes
with
having
open
source
projects
and
open
code
like
this.
D
I
think
part
of
the
challenge
that
we're
running
into
as
well.
It's
like
when
we
were
doing
really
early
versions
of
docker
2013
2014.
The
applications
were
generally
simple.
We
we
explicitly
ruled
out
things
like.
Are
people
going
to
run
things
that
look
like
hadoop
or
erlang
otp,
which
have
very
specific
networking
properties?
D
The
idea
was,
let's
go
and
try
to
run
something
that
focuses
on
small
micro
services
that
that
you
would
run
within
some
platform
as
a
service
similar
to
heroku
or
or
similar
part
of
the,
because
of
that
very
narrow
focus
early
on
which
I
don't
think
was
the
wrong
thing.
It
helped
us
succeed,
but
the
threat
model
was
not
as
extensive
as
we
should
have
made
it
like
we're.
Looking
at,
how
do
we
prevent
container
breakouts?
How
do
we
pre?
D
How
do
we
protect
the
network
and
how
do
we
protect
the
the
docker
socket
so
that
people
can't
send
random
commands
to
docker,
so
the
thread
model
did
not
include
things
like
well.
What,
if
my
image
was
modified
underneath?
Would
we
notice-
and
it
turns
out
that
was
an
incredibly
important
question
and
I
know
for
sure
that
we
didn't
ask
those
questions
because,
like
docker,
docker,
save
and
docker
load
is
like,
I.
C
D
Those,
and
so
I
was
heavily
involved
in
the
creation
of
some
of
these
things.
It
was
the
first
format
that
that
was
on.
That
was
on
disk
for
an
image
outside
of
the
docker
push
to
a
to
a
repo
somewhere
and
there's
and
there's
mistakes
that
we,
if
we
had
expanded
our
threat
model
at
the
time,
these
type
of
mistakes,
many
of
them
not
saying
that
they
wouldn't
be
here
but
like
there's,
there's
a
whole
thing
around
image.
Signing
and
like
where
do
the
hashes
come
from
like
the
the
docker
image?
D
Hashes
historically
were
just
randomly
generated,
they
didn't
mean
anything
other
than
it's
just
a
random
number,
and
so
there's
a
lot
of
mistakes
that
were
made
in
the
past
that
are
that
were
paying
for
today.
Because
of
that
hyper
focused
and,
like
I
was
saying
it's,
it
was
a
trade-off
like
people
they
were.
D
Some
of
these
software
would
not
be
surprised
if
they
were
more
expensive
in
terms
of
in
terms
of
resources
than
building
a
cruise
ship
like
how
much
how
much
goes
into
building
kubernetes
itself.
It's
the
second
largest
developer
community
in
the
world
in
the
open
source
space.
So
you
just
look
at
the
total
number
of
resources
where
we're
at
we're
at
a
point
where
we
have
to
fix
things
now,
because
if
we
don't
fix
them,
the
software
is
just
going
to
get
more
complex.
A
B
A
Yeah
so
let's
say
somebody
does
want
to
start
producing
s-bombs
they're
cloud-native.
They
won't
start
producing
s-bombs
for
their
applications.
Have
you
seen
people
kind
of
make
this
transition
and
start
with
the
journey?
Are
there
some
tips?
You
have
things
people
should
avoid,
should
watch
out
for
what
are
the
right
ways
to
do
it.
C
C
What
folks
usually
get
upset
about
is
that
the
s
bomb
is
typically
very
big,
and
this
is
not
surprising,
because
that's
how
many
components
you
have
in
your
deployment
so
naturally
it'll
be
really
big.
The
other
thing
to
note
that
it's
also
big
because
of
the
amount
of
metadata
that
is
present
in
the
s
form.
You
need
all
of
that
metadata
when
you
want
to
analyze
your
supply
chain
and
that's
why
it's
there.
C
So,
even
though
it
can
look
very
scary
in
the
beginning,
all
it
is
is
just
a
giant
list.
We
still
do
not
have
tools
that
would
take
in
the
giant
list
and
filter
it
out
to
get
you.
You
know
the
whether
you
have
these
list
of
denied
things
in
the
s-com
or
whether
it
is
it
is
an
expired
s-pump.
All
of
those
analytic
tools
don't
exist
right
now,
mostly
because
the
way
folks
have
historically
looked
at
this
is
point
a
static
analyzer.
B
I
I
agree
with
nisha.
I
think
the
basics
of
pulling
this
together
today
are.
Are
there
there's?
I
love
cyclone
dx
as
well
as
spdx.
I
love
them
both
equally
and
there
are
both
of
the
communities
have
done
a
good
job
of
curating,
their
their
tooling
ecosystem,
again
for
both
open
source
tools,
as
well
as
commercial
tools
for
folks
who
wanted
to
create
them.
B
We're
seeing
more
and
more
things
integrated
into
the
existing
build
tools,
and
you
know
in
this
world
you
may
want
to
sort
of
say:
hey,
what's
the
s-bomb
of
my
repo
of
my
source,
but
really
we
want
to
sort
of
move
people
to
think
about
creating
the
s-bomb
at
build.
We
all
know
that
right,
there's
some
dark
arts
in
in
build
tools
and
compilers,
and
so
you're
really
only
get
to
get
the
ground
truth
of.
B
What's
in
your
software
from
the
moment,
your
software's
actually
built
where
we're
still
learning
is
some
of
the
glue
that
puts
the
different
parts
of
the
build
chain
together,
and
this
is
actually
been
great
to
sort
of
see
people
say
on
twitter.
Well,
how
do
I,
how
do
I
plug
this
into
this?
Oh,
that's
a
good
question
and
then,
a
few
days
later,
hey
I
solved
your
problem
check
out
this.
B
You
know
and
so
there's
a
great
opportunity
for
people
to
actually
come
up
with
new
things,
and
the
last
thing
I'll
say
on
one
of
things:
that's
that's
still
known
hard
is
software
identity
is
an
entity.
Resolution
is
actually
still
a
tricky
issue,
especially
if
you're
in
a
slightly
less
well-trodden
corner
of
the
software
ecosystem.
If
package
managers
are
still
sort
of
a
rough-hewn
log,
cabin
tech
for
your
corner
of
software,
then
the
challenge
of
an
s,
the
goal
of
an
s
bomb
is.
B
When
you
tell
me
what
your
software
is,
I
should
be
able
to
know
what
that
software
is
and
in
well-defined
areas.
That's
super
easy
right.
We
have
well-defined
name
spaces,
but
we
don't
always
have
that
and
that's
some
of
the
things
that
we're
going
to
have
to
think
about
moving
forward
is
how
do
we
make
sure
that
we
can
actually
map
to
the
stuff
we
care
about?
We
can
map
to
the
vulnerability
databases
we
can
map
to
the
license.
Databases
things
like
that.
A
B
D
Yeah-
and
I
think
one
thing
to
really
highlight
is
what
alan
mentions,
especially
with
compilers,
like
we
look
at
what
the
inputs
are
on
a
given
system,
and
we
say
these
inputs
led
to
some
to
some
output
and
by
inputs
we
don't
necessarily
mean
like
this
is
file.c
like
you
actually
have
to
drive
down
into
the
contents,
and
one
of
the
examples
I
tend
to
use
is:
if
I
had
something
that
was
called
exploit.exe
and
I
renamed
it
to
principal
dot.
Exe
is
it?
Is
it
still?
D
Was
it
modified
in
in
some
ways
you
have
to
look
at
the
environment
that
is
there,
and
you
also
have
to
look
at
the
process
and
the
s-bomb
does
not
necessarily
tell
you
what
was
the
process
that
this
thing
took
in
order
to
become
that
thing,
so
there's
a
variety
of
of
additional
things.
We're
eventually
going
to
have
to
look
at
the
s-bomb
represents
the
first
major
turn
of
the
crank
and
it's
a
huge
crank.
D
So,
like
don't
get
me
wrong
with,
that
is
super
important,
but
it's
not
the
only
thing
that
we
don't
want
to
stop
at
smum.
We
want
to
take
a
look
at
how
do
we
drive
this
towards,
so
we
could
actually
look
at
the
contents
and
say
this
particular
section
of
code,
like
here's,
a
here's,
a
thought
experiment,
how
many,
how
many
people
in
the
industry
have
copied
from
stack
overflow
and
pasted
that
into
their.
C
D
D
It's
been
used
impossible
tasks
today,
and
so
we,
if
we
can
get
down
to
the
content
and
get
down
to
the
fingerprinting
of
that
of
that
information,
then
it'll
still
be
a
difficult
task,
but
do
we
at
least
have
a
chance
of
finding
some
of
these
things
saying
like
this?
Never
code
led
to
these
cves
we're
also
running
that's
the
bit
of
code,
and
so
we
eventually
need
to
to
find
more
savvy
ways
to
do
that.
C
So
I
think
it
would
be
awesome
if
the
cloud
native
community
took
a
look
at
what
distro
folks
are
doing.
Nowadays.
There
are
lots
of
folks
that
point
to
reproduciblebills.org,
but
there
are
many
other
distro
tools.
Suppliers
that
implement
this
in
some
ways
you
know
in
many
different
ways,
and
we
should
actually
you
know,
take
inspiration
from
them.
A
The
last
question
here
which
I
want
to
wrap
up
with,
we
have
thousands
of
you-
know
the
most
talented
engineers
in
the
world
here
cloud
native
con
kubecon,
if
you
could
wave
a
magic
wand
and
have
them
kind
of
you
know,
change
something
about
software
completely
get
creative
here
like
what
to
improve
software
supply
chain
security
and
s
bombs
forever.
You
know
what
what
would
you
change
about
the
way
we
build
software.
C
Oh,
I
can
go
on
this.
I
I
I
often
call
myself
like
a
code
mom,
because
I'll
I'll
tell
you
know
developers
to
clean
their
room.
Your
mom,
doesn't,
you
know,
take
care
of
your
code.
You
take
care
of
your
code.
It
is
your
responsibility
to
know
to
understand
what
your
dependencies
are,
whether
they're
the
right
dependencies
and
you
know.
What
exactly
are
you
installing
on
your
container
that
you're
pretending
is
your
desktop?
C
D
But
I
I
wish
that
people
would
be
more
proactive
on
on
some
of
this
stuff
to
to
help
find
where,
like
what
some
of
these
processes
and
techniques
are,
and
also
that,
like
I've,
found
that
people
are
more
than
willing
to
help
like
you.
Just
if
you
just
hop
onto
twitter,
literally
and
just
say
cloud
native,
I
need
help
with
this,
and
how
would
I?
How
would
I
secure
the
system
or
you
tag
a
couple
key
people
who
are
in
that
space?
You'll
get
a
lot
of
visibility
and
you'll.
D
Very
likely
get
somebody
to
at
least
point
you
in
the
right
direction,
but
it's,
but
it
still
feels
very
ad
hoc,
very
bespoke
type
of
communication.
There's
there's
not
really
a
group
that
says
here's
a
set
of
patterns
of
cookie
cutter
things
that
I
can
apply
now
that
work
across
80
of
all
projects
that
that
would
help
you
set
up
that
initial,
that
initial
framework,
and
so
so.
I
think
that
there's
still
a
lot
of
more
like
we
need
to
be
careful.
We
don't
kill
innovation,
but
there's
there's
also
basics
that
apply
in
most
scenarios.
B
B
Things
that
I'm
looking
forward
to-
and
this
is
where
I
get
to
have
a
plug,
whereas
if
you'd
like
to
get
involved
in
the
technical
side
and
in
the
policy
side,
the
global
s-bond
community
needs
your
help.
Looking
forward,
as
I
mentioned,
there's
a
lot
we
still
haven't
figured
out
around
sort
of
the
sas
model
in
general,
even
before
we
get
to
the
great
cloud
native
work
that
all
the
code
kubecon
experts
are
using,
which
is
hey
tracking
identity
behind
third-party
apis
or
microservices
or
dynamically
generated
code.
B
What
does
transparency
look
like
in
those
domains?
These
aren't
areas
where
we
don't
have
any
answers,
but
we're
going
to
need
to
sort
of
find
a
way
to
talk
about
it
in
a
way.
That's
sort
of
tech
neutral
in
scales,
and
the
last
thing
I'm
going
to
add
when
I'm
looking
ahead
to
this
is
the
more
you
the
more
I'm
in
security.