►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 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.
So, SBOMs Matter…Now What? - Sophie Wigmore & Frankie Gallina-Jones, VMware
Speakers: Sophie Wigmore, Frankie Gallina-Jones
Lately, the main conversation in the software bill of materials space has largely been around why you need a SBOM to solve your security concerns, and what it can add to your secure software supply chain. At this point, community buy-in is strong, but critical questions remain undecided: How is this technology best employed in a Kubernetes setting? Which of the options in this space is right for each use case? In an emerging space within the cloud native community, there is a lot to learn, and it seems as though the best practices are changing all the time. In this session, attendees will be walked through the pros/cons of different SBOM approaches by people who have spent over a year exploring this topic, defining best practices, and building open source solutions with SBOMs. Additionally, attendees will get a demonstration of how Paketo Buildpacks-generated application images already contain an embedded SBOM, by leveraging Syft.
A
B
A
So
today,
we're
actually
here
to
talk
to
you
about
s-bombs,
though
the
software
bill
of
materials,
because
there's
a
lot
of
interest
around
them
and
people
seem
to
think
that
they
really
matter
so
over
the
past
year,
we've
been
implementing
features
related
to
s-bombs
in
our
build
packs
and
trying
to
answer
their
question
now.
What
so,
hopefully,
if
you're
here
today,
you've
heard
of
the
s-bomb
before,
but
if
not,
we
have
a
quote
from
the
U.S
cyber
security
and
infrastructure
security
agency.
A
A
B
Yeah,
so
the
short
answer
here
is
that
they're
essential
for
supply
chain
risk
management.
Right
in
recent
years,
it's
become
increasingly
clear
that
components
inside
of
software
can
expose
that
software
and
the
orgs
that
make
them
to
risks
right.
One
clear
risk
is
the
risk
of
a
vulnerable
or
malicious
component,
making
its
way
into
a
supply
chain
causing
you
problems,
there's
also
the
risk
of
litigation,
or
you
know,
legal
action
if
you're
using
components
that
aren't
properly
licensed
or
not
properly,
attributing
those
components.
B
B
In
fact,
in
the
2021
anchor
software
supply
chain
report,
they
found
that
only
25
of
respondents
said
that
they
produce
an
s-bomb
for
the
containerized
apps
they
build,
and
while
the
year
2022
has
kind
of
been
the
year
of
the
s-bomb
in
a
way,
adoption
is
still
nowhere
near
100,
but
interest
is
high.
So
why
is
rollout
so
slow?
B
We
at
paquetto
build
packs,
think
there's
a
pretty
good
reason
for
that
right
now,
software
makers
are
trying
to
figure
out
how
to
keep
delivering
the
software
that
they're
great
at
delivering
and
also
deliver
software
bills
of
materials,
which
is
a
completely
separate
thing,
with
its
own
set
of
nuances
right.
It's
a
hard
problem
to
solve,
in
other
words,
Engineers,
like
you
and
me,
are
asking
now
what
about
a
year
ago,
paquero
build
pack
started
to
see
growing
demand
for
s-bombs
from
our
users.
B
These
are
people
who
are
containerizing
their
source
code
using
build
packs,
and
so
we
wanted
to
provide
us-bomb
automatic
generation
as
a
feature,
and
so
we
were
left
asking
ourselves
now.
What
what
would
it
actually
mean
to
produce
something
useful
for
our
stakeholders
and
our
users,
stakeholders.
A
Yeah,
so
the
questions
that
were
made
to
be
answered
here
are:
how
can
I
actually
adopt
this
for
my
project?
How
can
we
meet
expectations
of
our
consumers
as
it
comes
to
s-bombs,
and
how
can
we
make
sure
we're
just
meeting
best
practices
in
the
industry?
So,
in
our
exploration
of
this
topic
at
paquetto,
we
found
it
easiest
to
understand
the
how,
by
breaking
it
down
into
five
smaller
sub-problems?
A
Why
what
who,
where
and
when
and
the,
why
is
already
pretty
well
understood-
there's
tons
of
research
in
these
articles
on
this
subject
already,
so,
throughout
the
course
of
this
talk,
we're
going
to
break
down
the
remaining
questions
and
try
and
provide
some
examples
of
how
we've
tried
to
answer
those
questions
in
our
implementation
at
picketto
build
packs.
So
the
first
question
on
our
list
is
what
constitutes
a
useful
s-bomb.
A
S-Bomb
is
kind
of
a
catch-all
term
once
you
start
looking
into
it
that
encompasses
a
number
of
different
formats,
schemas
data
fields
and
use
cases,
so
what
constitutes
as
useful
will
definitely
differ
depending
on
who
you
ask
our
super
important
clarification
to
make
when
we're
talking
about.
What's
in
an
s-bomb
is
that
it's
not
just
an
enumeration
of
vulnerable
packages,
it's
a
full
list
of
ingredients.
Identifying
vulnerable
components
is
one
use
of
s-bombs,
but
there
are
very
many
others,
and
these
ideas
are
often
conflated.
B
Secondly,
if
we
look
a
little
closer,
we
notice
that
the
one
on
the
left
implements
version
1.4
of
the
CDX
spec
and
the
one
on
the
right
implements
version
1.3,
as
December
versioning
indicates.
Theoretically,
1.4
is
Backward
Compatible,
but
in
practice
Downstream
consumers
may
not
be
equally
able
to
consume
both
of
these
so
again,
getting
clear
about
this
distinction
will
help
you
in
the
long
run
and,
lastly,
possibly
most
glaringly.
B
B
A
That
perfectly
leads
us
into
our
next
question,
who
wants
s-bombs?
This
phase
involves
discovering
who
your
stakeholders
are
and
understanding
their
use
cases,
and
this
might
seem
like
a
pretty
simple
and
obvious
task
and
question
to
ask,
but
spending
time
here
is
really
important
and
will
save
you
a
lot
of
time
in
the
long
run
as
we've
learned.
A
So
the
entire
question
of
who
wants
s-bombs
is
meant
to
inform
our
earlier
question
of
what
that
has
problem
should
actually
look
like.
So
that's
why
it's
very
important
to
be
aware
of
the
different
nuances
of
the
options
that
we
have
in
this
space.
There
are
a
few
top
level
categories
that
we're
going
to
focus
on
where
you'll
need
to
meet
choices,
schema
data
values
and
formats.
A
So
from
this
visual
above
you
can
see
that
there
are
plenty
of
choices
to
be
made
depending
on
your
stakeholders,
some
having
different
strengths
and
weaknesses,
depending
on
your
use
case.
So
a
few
examples
if
your
stakeholders
are
interested
in
licensed
compliance
auditing
use
cases
for
their
s-bombs,
you
might
choose
spdx,
as
your
s-bomb
schema,
because
it's
ideal
for
complex
license
information.
A
You
still
want
to
align
with
them
about
the
format
that
they
expected
in,
because,
depending
on
how
they
plan
to
consume
the
s-bomb,
it
will
matter
if
it's
in
Json
or
XML
or
another
format.
Another
major
use
case
that
we
already
talked
about
is
vulnerability
scanning.
In
that
case,
you
might
want
to
use
Cyclone
DX,
because
it
has
flexible
support
for
a
number
of
different
dative
fields,
especially
relating
to
package
identification.
A
Finally,
a
third
and
final
use
case
that
we'll
talk
about
is
that
people
might
just
want
to
use
s-bombs
for
looking
at
dependency
drift
in
their
applications.
In
this
case,
they
might
not
even
care
about
the
schema
that
their
s-bomb
is
provided
in
as
long
as
it's
you
know,
maybe
it's
human
readable,
maybe
that's
what
they
need
and
as
long
as
it
includes
versions
or
checks,
some
information
for
chain
of
custody
concerns.
That
might
be
what
you
need
in
that
case.
So
conversion
between
these
different
schemas
can
also
be
lossy.
A
Answering
these
questions
in
paquetto,
build
packs
was
pretty
challenging
because
we
have
a
very
broad
array
of
Downstream
consumers.
So
for
that
reason
we
support
three
different
schemas
as
PDX
sift
and
Cyclone
DX,
and
we
cast
kind
of
a
wider
net
in
what
our
stakeholders
might
need.
We
know
that
vulnerability
scanning
is
a
major
use
case
for
our
customers,
so
package,
URLs
and
cpes
are
certainly
present
in
our
s-bombs
and
another
major
requirement
that
we
had
was
stable,
schema
versions.
A
So
our
Downstream
consumers
need
to
reliably
be
able
to
consume
documents
without
fear
of
incompatibilities
with
new
schema
bumps
that
come
out.
We
support
older
schema
versions
as
well
as
some
of
the
newer
ones
as
they
come
out.
Another
primary
concern
that
we
focus
on
trying
to
solve
was
all
the
different
languages
that
we
support
in
the
packetto
build
packs
project.
A
Once
you
understand
what
an
s-bomb
looks
like
for
your
users,
we
recommend
finding
performance
software
to
be
the
experts
in
generating
your
s-bombs
as
well.
S-Bomb
generation
is
pretty
difficult
and
there
are
plenty
of
amazing,
open
source
tools
out
there
to
do
this,
for
you
and
for
that
for
us
that
was
sift.
A
A
All
right
so
here
we
have
a
very
simple
react:
app
that
we're
going
to
containerize
with
build
packs,
and
we
are
going
to
use
the
paxioli,
which
is
an
upstream
tool
from
the
cloud
native,
build
packs
projects
to
orchestrate
our
build
packs.
Here
we
are
specifying
the
name
as
front
end.
Nginx
we're
specifying
a
few
build
packs
that
we
want
to
use
and
then,
most
importantly,
at
the
bottom,
we're
specifying
s-bomb
output
directory
that
we
want
to
tell
the
Pax
CLI
to
dump
all
of
our
s-bomb
documents
into
when
we're
done.
A
Okay,
so
now
we're
going
to
let
the
build
run,
we've
sped
it
up
a
little
bit
for
the
purposes
of
getting
this
demo
done
on
time,
but
we're
installing
different
things
here.
You
can
see
we're
using
the
npm
install
build
pack
from
paquetto
and
we're
generating
an
s-bomb
for
all
of
those
different
node
modules
that
we're
installing
with
that
build
pack.
Additionally,
we're
installing
other
things
during
the
build
like
nginx
configuring
it
and
generating
a
related
s-bomb.
A
A
A
Right
so
here
you
can
see
the
S1
output
directory
and
it
is
a
nested
directory
structure
of
all
of
the
s-bomb
documents
that
we
generated
during
the
build.
So
there's
three
different
formats
like
we
said:
Cyclone,
DX,
spdx
and
sift
schema
s-bombs,
and
they
are
arranged
by
the
build
packs
that
generated
them.
So
each
of
the
individual
processes
that
contribute
something
to
your
final
application.
Image
have
s-bomb
directories
here.
B
Here,
we're
going
to
be
showing
you
a
simple
python,
app
that
uses
pip
for
package
management
to
build
a
flask
server
and
serve
the
piketto
logo.
So
as
before,
let's
see
oh,
you
made
this
look
easy,
Sophie,
okay,
great!
So
as
we
can
see
our
simple
python
app
we're
going
to
use
the
paxili
once
again
to
run
a
build
this
time
with
the
python
build
pack
and
again
notice
we're
using
that
s-pom
output
directory
that'll
put
the
s-bombs
on
our
local
file
system.
B
We
kick
off
the
build
and
the
build
packs
start
doing
their
thing,
which
in
this
case,
includes
running
the
C
python,
build
pack
that
installs
the
python
runtime
and
generating
an
s-bomb
for
that
python.
Runtime
also
generating
an
s-bomb
for
pip,
which
also
needs
to
be
present
in
the
build
container
and
then
running,
pip
install
and
generating
an
s-bomb
for
the
packages
that
were
installed
during
that
process
as
well.
B
B
B
A
B
So
here
on
the
left,
you
can
see
that
sort
of
zoomed
in
view
of
just
one
dependency
from
the
python
app
and
on
the
right
that
remapping
package
again
from
the
react
app
off
the
bat
that
we
can
see.
First
of
all,
that
these
documents
look
very
similar.
So
if
you're
trying
to
manage
s-bombs
across
your
organization-
and
you
work
with
a
bunch
of
different
languages-
we've
already
got-
you
know
potentially
mergeable
and
comparable
us
bombs,
Happening
Here.
B
We
can
also
notice
that,
as
we
mentioned
before,
we
have
cpes
and
Pearls
two
unique
package
identifiers
that
are
quite
relevant
to
our
stakeholders
for
vulnerability,
identification
and
we've
also
got
license
information
for
this
react
package.
That's
something
that
stiff
supports
right
now,
not
quite
there
yet
for
pit
packages,
but
that's
an
expansion
point
for
sift
and
lastly,
we've
got
a
little
bit
extra.
That's
not
part
of
some
of
the
specs,
which
is
the
package
manager
or
package
ecosystem
where
the
package
came
from
and
the
file
where
the
package
is
enumerated
in
the
source
code.
A
So,
as
these
examples
hopefully
show
we
try
to
generate
useful
s-bombs
for
all
the
different
languages
that
we
support
in
the
project.
So
at
this
point
we've
got
s-bombs
yay
mission
accomplished,
but
unfortunately,
even
though
it
feels
like
we've
done
the
bulk
of
the
work
at
this
point,
we
still
have
two
pretty
important
concerns
left
to
address.
A
So
the
first
of
these
is
where
should
the
s
balance
be
stored
once
they're
generated,
so
a
key
stepping
stone
in
espalm
consumption
and
adoption
is
convenience
of
access
making
the
wear
very
important,
creating
quality
s-bombs
is
great,
but
it's
not
that
helpful
if
they're
really
difficult
to
access
going
back
to
our
earlier
example
of
ingredients
and
nutrition
facts,
it's
pretty
easy.
Just
turn
a
can
around
and
get
the
information
that
you
need
and
much
more
difficult
to
get
that
information
if
it's
separated
and
located
somewhere
else.
A
So
a
key
part
of
figuring
out
where
to
store
your
s-bomb
is
coming
into
an
alignment
with
where
consumers
expect
to
reasonably
find
their
s-bomb
documents.
Persisting
s-bomb
documents
directly
alongside
the
image
it
was
generated
for,
is
generally
a
pretty
good
practice.
Ensuring
that
you
can
retrieve
them
easily
with
your
corresponding
artifact
artifact.
A
So
in
the
example
we
showed
just
now,
we
use
build
packs
with
a
Pax
CLI
to
Output
an
oci
image
on
your
local
Docker
demon.
We
also
dumped
all
of
the
build
pack
generated
s-bomb
documents
directly
onto
your
local
file
system.
So
at
this
point
normally,
you
would
probably
publish
your
oci
images
to
a
registry
and
you'll
need
to
do
something
similar
with
your
s-bomb
content.
Ideally,
you'll
store
these
together
or,
if
they're
separate
you'll
have
a
way
to
associate
them.
B
But
no,
of
course,
if
you've
been
playing
along,
you
notice
that
there
is
one
question
left
unanswered
and
this
one
is
a
new
one
nuanced,
but
important
one
to
consider,
and
that
is
when
should
s-bombs
be
generated.
In
order
to
understand
why
we're,
even
bothering
to
ask
it's
useful
to
motivate
why
this
matters,
in
other
words,
what
could
change
depending
on
when
you
generate
an
s-bomb,
so
here
to
quote
from
anchors
2022
white
paper,
the
software
bill
of
materials
and
its
role
in
cyber
security.
B
The
use
of
s-bombs
for
containerized
applications
provides
a
unique
opportunity
to
watch
for
s-bomb
drift.
Unexpected
changes
in
the
contents
of
a
software
application,
which
can
indicate
potential
tampering,
new
versions
or
changes
in
dependencies
generating
an
s-bomb,
creates
a
snapshot
of
the
components
of
your
container
at
a
specific
time
during
the
development
process,
by
generating
an
s-bomb
for
each
build
and
at
each
step
in
the
development
process,
you
can
look
for
differences
over
time.
B
So
with
that
being
said,
it
comes
into
view
that
when
we
ask
when
we're
sort
of
talking
about
a
bunch
of
wins,
ideally
multiple
snapshots
throughout
development,
so
when
might
be
a
good
time
to
take
a
snapshot,
perhaps
most
obviously
you
can
scan
your
oci
image
to
generate
an
s-bomb
when
it's
pushed
into
your
registry
ready
to
run
in
prod.
Let's
say
that
seems
pretty
reasonable.
B
You
can
achieve
these
minimal
images
with
you
know
your
well-written
multi-stage
Docker
file.
You
can
also
use
paquetto,
build
packs.
That'll
handle
it
automatically,
but
bear
in
mind
that
when
you
scan
a
minimal
image
to
generate
an
s-bomb,
you
may
get
back
a
minimal
amount
of
information
right,
a
component
that
could
still
impact
the
security
or
compliance
posture
of
your
application
may
have
already
flooded
the
scene
of
the
crime.
B
So
with
that
being
said,
also
probably
reasonable
to
scan
your
source
code
right
before
you
compile
things
down
before
you
clean
things
up,
you
can
scan
source
code
and
identify
packages
from
things
like
a
package.json,
a
requirements.txt,
but
there's
still
a
crucial
step
in
the
development
process
that
is
not
covered.
The
container
build
itself
to
see
why
this
matters,
let's
return
briefly
to
the
food
analogy,
suppose
that
I
have
a
serious,
peanut,
allergy
right,
I'm,
definitely
going
to
care
if
there's
peanuts
in
the
food
I'm
eating
right.
B
The
oci
image
I'm
also
probably
going
to
care
if
there
are
peanuts
as
the
raw
materials
going
into
the
thing
I'm
eating
the
source
code.
But
if
my
allergy
is
severe
enough,
I'll
also
certainly
care
if
the
facility,
where
my
food
was
made
processes
peanuts
right,
a
contaminant
can
be
introduced
in
the
preparation
process
itself.
B
The
same
holds
true
when
you're
containerizing
applications
a
lot
can
happen
in
the
time
between
taking
source
code
and
turning
it
into
a
final
app
image
if
you've
ever
written
a
Docker
file
of
any
complexity.
You
know
this
to
be
true
right.
A
compiler
or
a
transpiler
could
be
used
in
your
Docker
file.
That's
not
checked
in
to
your
source
code
and
not
in
your
final
app
image.
B
How
will
you
know
if
that's
exposing
you
to
a
vulnerability
alternately,
a
bad
actor
can
inject
source
code
or
dependencies
into
your
build
container,
contaminating
source
code
that
you
thought
was
otherwise
safe
to
use
or
fully
accounted
for
so
now,
Sophie's
going
to
show
us
a
concrete
example
using
our
react
app
from
earlier.
That
demonstrates
how
s
volumes
generated
during
a
build
can
reveal
vulnerabilities
that
you
would
otherwise
Miss
by
just
scanning
the
oci
image.
At
the
end.
A
A
And
there
are
none,
we
can
repeat
the
same
experiment
just
for
Debian
packages,
for
example,
and
we
see
that
there
are
tons
found-
and
you
know
that
kind
of
makes
sense,
because
during
the
build
we
transpiled
our
JavaScript
code
into
static
assets
and
then
they
no
longer
need
access
to
node
modules.
So
the
build
packs
clean
them
up.
We
have
a
minimal
final
application
image
and
because
of
that,
there's
no
way
an
s-bomb
generator
could
pick
up
any
node
modules
if
they're,
just
simply
not
on
the
final
application
image.
A
A
And
we
see
that
there
are
tons
of
npm
packages,
node
modules
found
in
that
s-bomb
and
when
we
look
at
the
Debian
packages,
we
unsurprisingly
see
that
there
are
none,
and
that
makes
sense
right.
Our
we
have
an
s-bomb
just
dedicated
to
the
npm
packages
that
get
installed
during
your
build
and
there's
a
separation
of
concerns,
so
that
s-bomb
only
contains
those
packages.
A
Just
to
take
it
all
the
way
home
here,
we
can
also
use
the
s-bombs
for
some
of
the
use
cases
that
we
mentioned
earlier.
So
here
we
just
have
a
screenshot
of
using
the
gripe
vulnerability
scanner
from
Encore
and
we're
using
that
on
the
npm
install
s-bomb
that
we
had
so
here
you
can
see
that
we
had
found
a
bunch
of
npn
packages
and
they
had
a
bunch
of
CVS
in
them,
including
some
that
are
critical
and
high.
A
A
You
can
see
here
that
we
have
s-bomb
entries
for
node,
which
is
what
we
installed
with
the
node
engine,
build
pack
during
the
build,
as
well
as
nginx,
which
we
installed
with
the
nginx
build
pack,
and
neither
one
of
these
things
would
potentially
show
up
in
the
source
code
of
your
application.
So
it's
pretty
important
that
the
build
packs
generate
an
s-bomb
for
every
single
thing
that
gets
installed
during
your
build.
There's,
no
way
for
absolutely
anything
to
make
it
into
your
image
without
having
it
automatically
generated
s-bomb
for
it.
B
So
to
summarize,
when
you
came
into
this
talk,
you
probably
had
some
sense
that
s-bombs
are
important.
You
chose
to
show
up
and
over
the
course
of
the
talk,
you've
seen
the
key
considerations
that
we,
a
picetto,
build
packs,
bore
in
mind
when
we
were
figuring
out
how
to
generate
useful
s-bombs
for
our
stakeholders
at
every
stage
of
the
development
process,
including
during
container
builds.
B
B
C
This
is
awesome,
so
I
was
wondering
for
act
for
actioning
on
this
data.
You
mentioned
you
know,
potentially
combining
all
the
s-bombs
created
throughout
every
step
of
the
process.
Have
you
guys,
like
thought
about?
You
know
a
way
to
combine
that
data
and
make
one
like
massive
s-bomb
that
you
can
use,
or
is
that
even
practical
have
any
thoughts
on
that.
A
This
one
yeah,
it's
definitely
a
valid
question.
I
think
that
would
be
something
there's
kind
of
a
distinction
between
the
build
pack
implementation
and
the
platforms
that
we
use
like,
for
example,
we
used
the
paxili
here
you
could
use,
you
know
kpac
or
something
like
that
and
I
kind
of
think
that
the
merging
capabilities
would
be
something
that
should
occur
more
on
the
platform
side.
But
that's
honestly,
a
good
consideration.
We
could
definitely
see
if
there's
a
flag
we
could
introduce
to.
You
know,
merge
them
together.
B
D
D
B
At
yeah,
so
the
question
here
is
about
prominence
of
the
components
that
the
build
packs
are
installing
and
the
build
packs
themselves
yeah.
So
right
now
we're
not
doing
anything
with
Intel
in
total
attestation.
That,
like
could
be
something
I
suppose
we
could
look
at
depending
on
if
it's
going
to
provide
value.
One
thing
to
bear
in
mind
is
that
some
of
the
dependencies
that
paquetto
build
packs
installed
like,
for
example,
the
python
runtime
that
we
install
we're
actually
compiling
from
source.
So
that's
like
coming
from
a
trusted
vendor.