►
From YouTube: We Built the Kubernetes SBOM and Now You Can Write Your Own! - Adolfo García Veytia, uServers
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.
We Built the Kubernetes SBOM and Now You Can Write Your Own! - Adolfo García Veytia, uServers
At the end of 2020, SIG Release set a goal to produce a Software Bill of Materials for Kubernetes to provide the community and downstream consumers with a verifiable manifest to attest the completeness and consistency of the artifacts built and published with each release. Adolfo will tell how the Release Engineering team built the Kubernetes SBOM and how this effort resulted in a set of libraries and tools which can be leveraged by software developers and other projects to create their own SPDX-compliant Bill of Materials out of files and container images with automatic license detection. He will address the role an SBOM plays in the software supply chain puzzle, enumerating its benefits for developers and operators. He will do a review of the SPDX standard (Software Package Data Exchange) and the rich relationships between software components it can express. The session will feature a live demo of building an SPDX SBOM using said tools which are already available to download.
A
So
hi
and
welcome
everyone
thanks
for
attending
the
session.
I
know
it's
fridays
and
the
conferences
are
always
the
best,
the
worst
days
to
have
a
session
in
the
morning
my
name
is
alofa
garcia
and
I
am
one
of
the
tech
leads
with
kubernetes
release,
and
so
just
a
little
bit
about
me.
I
worked
for
my
whole
life
for
my
own
company
and
then
they
until
they
pandemic
hit
and
had
to
switch
jobs,
and
I
I
am
now
a
senior
devops
engineer
at
marmost.
A
I
have
two
little
girls
and
I
also
like
to
travel
the
world
with
my
bicycle.
Whenever
I
can
and
so
the
beginning
of
this
year,
I
let
the
effort
to
produce
an
s
bond
for
kubernetes
all
right.
So,
let's
start
a
little
bit
to
talk
a
little
bit
about
sig
release
and
what
we
do
so
sig
release
is
a
special
interest
group
that
does
the
kubernetes
releases.
Whenever
you
see
a
new
kubernetes
patch
release
or
a
new
version
coming
out,
we
are
the
guys
that
work
to
make
that
happen.
A
So
we
also
form
the
kubernetes
release
team
that
is
managed
by
the
kubernetes
release,
lead
who's
joining
us
today,
here
hi
ray,
and
we
also
manage
the
actual
decision
of
what
goes.
What
goes,
what
gets
cherry
picked
to
the
supported
branches
of
kubernetes
and
the
the
other
thing
we
do
that
is
maybe
worth
considering
today
is
that
we
are
in
task
of
continually
improving
the
kubernetes
release
process
to
keep
it
up
to
date
to
practice
the
same
best
best
practices
and
standards
that
you
keep
coming
up.
A
I
wanted
to
go
briefly
into
this,
because
the
kubernetes
release
has
many
different
kinds
of
artifacts
many
different
ways
of
distribution,
and
so
we
think
it's
a
good
example
of
why
having
an
s
bomb
is
a
beneficial
thing
for
a
project
of
this
size,
so
the
most
people
are
used
to
how
consuming
kubernetes
by
its
container
images,
we
produce
five
different
images
for
five
different
architectures,
and
if
you
cross
that
together,
you
get
25
images,
but
there's
a
lot
more
to
a
kubernetes
release
than
just
the
images
we.
Those
images
are
produced.
A
We
support
three
different
operating
systems:
linux,
macos
windows.
We
have
we
built
some
of
the
artifacts
and
the
images
for
the
what
we
call
the
supported
platforms,
which
are
currently
the
386
amd
armor
64.,
the
bpc60
and
that's
the
idms
390x
platform.
We,
as
I
said
before,
we
have
25
images
with
each
release.
We
produce
53
naked
binaries.
The
naked
banners
are
what
you,
whenever
you
download,
for
example,
a
copy
of
cube,
ctl
cubeco,
ready
to
run.
A
So
our
mission
is
to
provide
guidance
and
tooling
to
facilitate
the
production
of
automated
releases.
If
you
take
a
look
at
this
statement,
miss
mission
statement,
it
doesn't
specifically
say
kubernetes
in
it.
That
is
why
we
try
to
produce
some
of
our
tools
as
and
may
make
them
as
general
purpose
as
possible.
A
Then
we
have
a
thing
called
publish
release
which
allows
you
to
upload
and
sync
your
releases
with
github
and
finally,
the
bomb
tool,
which
is
the
thing
that
we're
talking
about
today,
so
the
s1
definition.
So
I
think
this
is
the
previous
definition
right
now.
This
is
the
preferred
it
has
been
updated
since,
but
I
wanted
to
more
than
take
a
look
at
the
actual
s-bone
definition.
A
Tell
you
a
little
bit
of
what
I
think,
how
I
see
the
ebola
material.
So
when
you
see
a
bill
of
materials,
you
have
it's
a
document
that
lists
the
components
in
a
in
a
software
release
and
it
allows
you
to
determine
the
relationships
among
them.
So,
if
you
think
about
the
work
warehouse
lock,
this
a
bit
of
materials
would
would
really
quickly
allow
you
to
determine
where
things
are.
A
But
the
way
an
important
thing
to
note
here
is
that
we
are
sig
release.
We
are
not
sick
as
one,
so
what
our
focus
is
more
on
how
we
can
actually
describe
a
more
complex
release
that
spans
many
distribution
channels
and
kinds
of
artifacts,
so
I
tend
to
think
about
the
release
a
little
bit
more
like
this,
like
a
market.
So
if
you
think
about
a
market,
you
probably
can
find
some
of
the
items
that
sell
there
in
different
presentations.
A
So
if
you
think,
for
example,
you
may
have
a
tomato
and
that
tomato
can
may
be
available
in
its
raw
form
for
you
to
buy
by
the
by
the
weight
or
you
can
maybe
could
find
that
transform
to
a
salsa
instead
of
a
sandwich
or
different
presentations,
and
for
me
a
software
release
is
kind
of
the
same
thing.
So
if
you
remember
the
the
kinds
of
artifacts
that
a
kubernetes
release
produces,
we
have
the
same
components
packaged
in
different
ways.
A
Then
you
start
adding,
for
example
your
container
images
and
then
you
add
your
binaries,
then
you
add
more
binaries
and
your
packages
and
then
the
dependencies,
the
transient
dependencies
and
then
all
of
a
sudden.
You
get
everything
in
there,
except
for
the
kitchen
sink
or
maybe
you
do
have
the
kitchen
sink.
Like
in
the
picture,
and
so
what
I,
what
we
chose
to
do
is
to
start
thinking,
so
we,
the
first
says
that
we
produced
was
a
single
monolithic
file.
A
So
we've
been
thinking
about
other
ways
that
we
may
split
the
s-bomb
into
more
consumable
documents,
more
leaner
ways
of
doing
that.
So
I
tend
to
think
about
a
way
that
we
could
produce
linear
response
for
what
could
potentially
consume
them.
So,
if
you
think
about
the
source
code,
maybe
that
would
go
into
some
kind
of
source
code
tool
like
code
search
things
like
that
that
could
could
actually
take
advantage
of
the
large
number
of
items
that
are
in
there
so
same
thing
with
the
containers.
A
The
container
images
could
be
better
suited
for
things
that
will
actually
consume
the
container
images.
So
if
you
think
you
could
have
like
a
an
admission
controller
in
kubernetes,
that
would
check
the
the
container
images
coming
to
make
sure
that
everything
is
in
place
or
that
to
match
them
against
a
certain
foreign
abilities
and
so
on
and
same
thing
for
the
binaries.
The
binaries
are
intended
for
the
operating
system.
So
it
would
make
sense
to
check
them
in
there
rpms
so
on.
A
So
our
if
you
were
at
the
keynote
this
morning,
you're
aware
that
there
are
two
great
efforts
going
on
to
produce
s-bombs
we
went
the
linux
foundation
way,
which
is
spdx,
which
is
now
an
international
standard.
So
I'm,
of
course,
I'm
going
to
repeat
a
lot
of
what
was
said
that
this
morning
in
the
in
the
keynote,
but
I'll
try
to
give
you
spdx
looks
like
this:
it's
that's
a
header
of
the
spdx
document
and
a
fragment
of
a
file
listed
in
there.
A
A
The
first
thing
that
you
can
leverage
is
the
ability
of
spdx
to
do
two
things:
relationships
and
packages.
Using
those
constructs
you
can
start
splitting
parts
of
your
s1
apart
from
each
other
and
the
first,
the
first.
The
first
thing
to
to
that
you
should
package.
Is
your
source
code
and
we
inside
of
the
kubernetes
algorithm
treated
like
a
like
a
separate
package
of
that
bundles
all
of
the
source
code
together
and
then
we
simply
point
all
of
the
artifacts
as
being
built
from
that
from
that
package.
A
A
That's
that's
the
way
we
try
to
structure
container
images
when
describing
them
here
and
then,
after
that,
you
can
start
making
more
complex
decisions
like,
for
example,
here
we
have
a
a
potential
s1
detailing
the
binaries
and
the
rpms
sp
spawn
into
a
different
document,
and
in
there
we
have
the
dependencies
bundled
into
another
package.
So
the
idea
is
to
make
these
units
more
consumable
and
available
and
and
better
suited
to
processed
by
the
tools
that
could
potentially
use
them
in
the
future.
We're
still
understanding
who
is
going
to
use
them.
A
Are
you
going
to
use
them
inside
of
your
processes
outside
to
make
matches
with
other
systems
and
so
on?
So
how
about
our
tool?
All
of
the
code
that
we
wrote
to
generate
the
kubernetes
releases
derived
into
a
original
spdx
implementation,
which
is
which
runs
inside
of
the
release,
the
equivalent
release
process?
Every
time
we
we
got
our
release,
but
we
we
brought
those
libraries
and
built
this
this
la
this
general
purpose,
utility
that
you
can
use
to
to
to
run
and
process.
A
Your
your
repository,
so
the
the
easiest
way
to
to
add
to
create
a
bill
of
materials
for
a
project
is
just
a
cd
into
your
repository
file,
run
bom
generate
in
the
path
of
the
directory,
and
it
will
it'll
speed
up
your
bit
of
materials,
describing
that,
of
course,
a
bill
of
materials
to
be
complete
and
useful.
You
have
to
add
more
things
to
it,
so
you
can
pass
it
other
kinds
of
artifacts
to
to
be
to
get
included
into
the
into
developer
materials.
A
You
can
add
directories,
you
can
add
images
that
are
stored
in
the
registries
and
you
can
add
a
table.
The
the
travel
flag
down.
There
is
a
container
image
but
exported
as
a
docker
archive
in
your
file
system
and
as
well
single
files.
You
can
add
all
of
those
kind
of
artifacts
to
your
to
your
little
materials.
Now.
The
other
thing
that
this
thing
does
is
that
you
can
have
a
declarative,
s-bomb
definition
inside
of
your
repository
and
add
the
bomb
utility
as
a
step
in
your
ci
cd
pipeline.
A
A
A
A
It's
a
go
module
standard,
go
project
with
its
tests
and
and
files
in
there.
So
let
me
remove
this
one
because
that's
not
needed
now,
okay,
so,
for
example,
this,
when
you
compile
this
project,
it
spits
out
in
this
output
director
here,
it's
binary.
So
if
you
wanted
to
have
absolutely
the
first
thing
I
wanted
to
demo
is
the
thing
where
I
was
saying
that
you
can
just
point
it
to
the
directory,
run
it
and
have
the
url.
A
So
if
I
just
pass
it
down
a
directory
as
a
as
a
source
and
run
it,
it
will
run
and
process
everything
inside.
So
let
me
give
you
a
brief
overview.
What's
what
it's
doing
there?
So
it
starts
by
processing
the
files
and
directory
listing
everything
it.
It
goes
and
fetches
the
spdx
license
lists
from
the
spdx
website,
and
so
spdx
has
a
set
of
defined
open
source
licenses.
A
Oh
so
probably
this
is
the
license
file
for
the
whole
project
and
if
it
finds
one
of
those
predetermined
by
predetermined
means
like
they
are
not
quite
scientific
study
of
the
licensed
names
that
people
use
but
they're
kind
of
hardcoded
in
there
for
the
moment.
But
it
will,
you
will
use
them
as
defaults
and
it
will
actually
look
for
other
files
or
licensing
information
instead
of
other
of
other
files
as
well,
but
it
looks
for
so.
It
asks
itself.
A
What's
the
license
that
I
would
use
as
a
default
for
this
project,
then
the
next
step
is
that
the
tool
will
actually
read
and
honor
your
git
ignore
files.
So
if
whatever
you
set
in
your
git,
ignore
it
it'll
launch
those
patterns
and
keep
them
out
of
the
s1
when
you're
running
in
directory
mode
like
this,
then
it
scans
the
files
the
whole
file
tree
and
adds
them
to
the
directory.
A
It
right
here.
It's
detecting
that
the
director
contains
a
a
go
project,
oh
by
the
way.
The
only
since
this
is
this
was
written
for
kubernetes,
the
only
language
that
we
fully
support
and
for
the
moment
it'll
say
it
like
this
is
go
it'll.
It
will
allow
you
to
index
container
images
binaries
and
things
like
that
from
in
in
derived
and
compiled
from
other
languages.
A
So
once
it's
it's
got
the
information
it
needs
to
run.
It
will
actually
go
and
fetch
all
of
the
go
modules,
download
them
or
use
them
in
from
the
local
go
cache
to
actually
go
inside
of
each
of
the
directories
of
the
pro
of
the
programs
and
look
for
licensing
information
to
include
them
in
the
in
the
final
output
and
it
found
all
the
dependencies
and
it
wrote
so
it
wrote
the
file
so
the
the
first
new
feature
for
others
that
have
perhaps
previously
looked
at
this
tool
or
not.
A
So
if
you
see
the
help
for
the
bomb
utility
you'll
see
it,
and
it
has
two
two
main
modes
of
operation:
oh
completion,
there,
yes
of
va
for
supply
chain
and
features
getting
added,
so
the
the
the
two
models
of
operation
are
generate
and
document.
So
the
first
one
is
generation
of
documents
and
the
other
is
ways
of
working
with
documents.
A
A
So
if
you
take
a
look
at
the
actual
spdx
code,
it's
like
really
hard
for
humans
to
understand.
What's
going
on
there,
of
course,
if
you
take
some
time
and
try
to
visualize,
what's
going
on
that,
you
can
certainly
make
sense
of
it,
especially
in
a
simple
s1
like
this
one,
but
I
thought
that
this
kind
of
visualization
should
vary
and
help
people
understand
better
how
their
s
bombs
are
structured.
A
At
the
end,
it
says
that
it
describes
server
files,
because
what
it
means
is
that
you
have
the
root
null
of
the
document
and
from
there
then
the
next
derivation
is
the
next
branch
or
yeah
branch.
You
could
see
it
as
having
packages
or
files
attached
to
it
and
what
it's
saying
there
is
that
it
doesn't
have
any
files,
so
wow
an
important
thing
to
notice,
though
we
are
defining
we're
like
showing
here
the
s1
in
a
tree
like
fashion,
but
it's
just
a
simplification
to
make
it
easier
to
understand.
A
If
you
think
about
the
many
many
many
one-way
relationships
that
that
an
s-1
contains,
it
would
be,
I
think,
better
suited
to
to
visualize
it
as
a
graph
more
than
a
tree
like
this.
Since,
since
one
package,
one
file
can
span
multiple,
multiple
relationships
and
with
other
things
inside,
but
I
mean
certainly
helps.
As
you
can
see
here,
we
can
kind
of
understand
how
the
es1
was
built.
A
A
A
A
We
can
take
a
look
at
the
outline
of
this.
The
way
it
structured
it
so
the
this
is
one
has
one
package
which
points
to
the
actual
tag
of
the
image
and
then
itself
it's
a
package
which
contains
all
of
the
images
in
there.
As
I
was
saying
before,
things
can
be
related
to
other
things,
and
in
this
case
you
can
see
here
the
same.
A
A
This
here
is
the
the
yaml
definition
for
the
for
the
project.
I'm
running,
probably,
if
you
take
a
look
here,
what
we're
defining
here
to
be
included
in
the
s1
base,
the
directory,
where
we
are
running
as
a
single
file,
which
is
the
bind
the
compile
binary
that
gets
written
into
the
output
and
then
the
container
image
we
give
it
the
license
of
apache
too,
then
the
other
thing
is.
A
So
what
I've
done
here
is
that
I've
actually
included
those
libraries
into
the
s1
tool
so
that
whenever,
if
you-
if
you
don't-
if
I
don't
know
if,
if
you're
familiar
with
the
at
the
station
file,
so
the
attestation
files
are
a
list
of
components
similar
to
an
s1,
but
but
they
can.
It
contains
information
so
that
you
can
trace
those
those
items
back
into
the
cicd
chain
back
and
actually
find
out
where
those
will
build.
A
So,
if
you
think
about
an
s1,
you
are
already
tracing
all
of
the
artifacts
that
get
produced
in
the
in
the
s1,
and
you
already
have
that
information.
So
what
this
tool
can
help
you
achieve
is
produce
like
an
empty
attestation
file
that
includes
all
of
the
files,
so
you
can
reuse
them
and
maybe
build
your
whole
provenance
from
there.
A
A
So,
let's
see
what
happens
so
I
I
run
the
tool
and
I
pass
it
the
tested
the
configuration
file
so
that
it
detects
and
reads
the
yaml
configuration
and
it's
doing
the
go
dependency,
construction
and
it's
adding
here.
This
is
this-
is
the
actual
provenance
conversion
of
the
artifacts
and
the
container
image.
So
if
we
were
lucky,
we
should
have
the
the
s1
ready.
A
A
Then
you
you,
if
you
complete
the
information
to
this
file,
you
have
the
s-bump
and
as
well
the
the
necessary
attestation
to
make
potentially
make
your
your
your
release,
salsa
level,
one
compliant,
because
the
if
all
you're
missing
is
the
provenance,
the
metadata
which
this
thing
makes
you
create
and
yeah.
I
think
this
is
those
are
the
main
points
of
of
the
tool
that
the
way
they
work
yeah,
probably
those
are
the
ones
and
then
a
little
bit
of
a
future
direction
of
this.
A
A
Then
we
been
in
talks
with
the
linux
foundation,
s-bomb
generator
folks
to
maybe
see
into
merging
our
efforts,
and
that
way
we
could
maintain
their
project
and
we
would
benefit
by
gaining
more
languages
than
our
tool
could
be
an
an
an
option
and
then
the
final
one.
Well
not
the
final
one,
but
spd-x
allows
you
to
output,
not
in
just
that
format
that
you
saw
there,
which
is
called
tag
value.
A
It
also
allows
you
to
output
in
many
other
formats
from
rdf
json
yaml,
and
we
only
currently
output
to
to
the
attack
value,
which
is
a
valid
one.
But
if
you
needed
in
the
one
of
the
others
are
still
missing
and
then
at
some
point
I
would
certainly
like
to
add
some
validation
and
verification.
There
are
still
divergences
in
spdx
tools
in
the
way
they
interpret
things
so
the
way
you
saw,
for
example,
container
images
listed
here
or
some
of
the
packaging
that
goes
on
in
there
different
vendors
tool.
A
But
what
I
would
like
to
add
to
this
tool
in
a
not
very
distant
future
is
the
capability
to
ensure
that
if
it
produces
an
s
bomb,
it
can
be
reverted
and
to
make
sure
that
the
actual
output
corresponds
to
the
things
that
it
understood
and
saw
in
your
artifacts
and
yeah,
and
that's
that's
the
that's
it
for
for
for
what
I
had
prepared
and
if
you
want.
Those
are
my
my
deals.
A
If
you
want
to
contact
me,
ask
me
anyway,
just
I
usually
go
by
work
most
almost
everywhere
and
if
you
search
for
the
blue
link
there,
it
will
be.
When
I
upload
the
slides
you
can.
You
can
use
that
one.
I
did
a
version
of
this
presentation
where
we
demonstrate
the
how
to
integrate
the
s-bomb
tool
inside
of
a
text
on
release
pipeline
and
having
it
as
a
task,
and
you
you
can
see
it.
There
there's
also
a
ripple,
a
repo
with
the
with
that
content
in
there
and
yeah.