►
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.
Finding Your Way: A Survey of Supply Chains - Aeva Black, Microsoft
With the explosion of interest in SBOMs, it's likely that you've just heard of a few projects for the first time -- even if those projects aren't new, they may be new to you, and you might be asking yourself, "how is X different from Y?" You might also be wondering which projects you should select in order to satisfy the requirements of the Executive Order!
As when starting out on any journey, before entering unfamiliar territory, it is important to understand the lay of the land, pack the right supplies, and get to know your traveling companions.
In this talk, a few maps of the open source supply chain landscape will be shared. Attendees will gain a sense of both the breadth and depth of the challenges ahead, and learn to identify a few essential types of tools for their journey.
A
Hello
supply
chain
security
conference
los
angeles,
my
name
is
ava
and
I'm
joining
you
today
from
rainy
seattle,
I'm
going
to
show
you
a
brief
overview
of
the
breadth
of
current
development
efforts
in
the
open
source
software
supply
chain
landscape
to
help.
Anyone
who
is
new
to
the
space
find
their
way
and
then
I'll
spend
a
little
time
talking
about
one
of
the
many
tools
that
folks
are
building
right
now.
That,
I
think,
will
be
most
helpful.
A
My
writing
teacher
once
said.
You
start
writing
a
book
by
writing
the
ending.
So
I'm
going
to
kind
of
cheat
now
and
I
and
I'll
tell
you
how
I
imagine
this
journey
ending
before
we
start
what,
if
there
was
an
easy,
efficient
way
at
launch
time
to
enforce
a
policy
that
could
check
each
executable
object's
complete,
build
tree
against
a
then
current
list
of
known
vulnerable
source
files.
Wouldn't
that
be
awesome?
Wouldn't
that
solve
a
lot
of
the
challenges
we
collectively
have?
A
This
might
seem
like
fiction
like
I'm
just
dreaming,
but
it's
good
to
know
what
I
want
to
head
towards,
and
I
think
it's
possible
so
now
that
we've
imagined
that
end.
Let's
work
backwards,
what
are
some
obstacles,
what
what
monsters
might
lurk
in
this
landscape
and
what
friends
can
we
make
along
the
journey
and
that's
how
I
how
I
began
a
few
months
ago,
and
I
asked
a
lot
of
questions
I
met
with
a
lot
of
folks.
I
listened
to
stories
from
different
communities
and
with
each
person
I
met.
A
A
So,
as
I
made
a
list
of
projects
that
I
knew
and
I
reached
out
to
folks
and
I
met
with
their
communities
and
that
list
grew
and
grew,
and
now
today
I'm
aware
of
12
open
source
foundations
doing
work
in
the
space.
A
whole
lot
of
work
on
reproducible
builds
several
different
linux,
distros
and
compilers,
and
another
42
open
source
projects
working
specifically
on
software
supply
chain
security,
and
I
began
to
think
of
these
kind
of,
like
all
these
different
villages.
A
Different
projects
grouped
based
on
what
part
of
the
ecosystem
they're
in
and
lots
of
groups,
are
busy
trading
ideas
and,
and
some
groups
don't
quite
use
the
same
terminology
yet
for
the
same
things.
But
I
do
want
to
share
with
you,
even
though
I
don't
have
time
to
go
into
everything,
a
quick
overview
of
the
five
categories
of
tools,
a
way
of
grouping
these
different
projects.
Together,
we
have
standards,
we
have
s-bomb
generation
tools,
we
have
scanning
tools
to
review
things
that
have
already
been
built.
A
And
across
all
of
my
conversations
with
people
in
different
groups
and
different
foundations,
there
are
two
concepts
that
have
really
anchored
my
exploration
and
helped
me
sort
of
function
like
a
these
concepts
function
like
a
rosetta
stone,
letting
me
translate
concepts
between.
So
I
translate
terminology
between
different
communities
that
aren't
yet
using
the
same
words
when
they
mean
the
same
things
and
those
terms
are
claims
and
policies.
A
A
An
s-bom
is
a
claim
generated
by
some
tool
or
process
like
in
toto.
That
says,
here's
information
about
this
thing.
You
might
care
about
that.
That
claim
needs
to
be
stored
and
conveyed,
so
it
can
reach
you
possibly
independently
of
the
conveyance
of
the
object
that
it
relates
to.
Some
claims
might
be
stored
in
a
container
registry.
A
A
You
might
even
ask
an
auditor
to
verify
a
claim
and
it's
with
an
object,
evaluating
their
trustworthiness
and
making
yet
another
claim
that
refers
to
the
first
claim:
an
automated
decision-making
process
that
might
establish
such
criteria
as
who
you
trust
or
what
evidence
you
require,
or
how
to
verify.
All
that.
That
is
the
domain
of
policy.
A
Well,
what
do
we
do
right?
We
we're
now
armed
with
a
map
and
a
translation
guide.
So
let's
revisit
my
initial
thesis.
Do
we
have
enough
tools
to
build
an
efficient
way
to
enforce,
launch
time
policy
against
a
build
tree
for
every
incoming
binary,
and
even
if
every
open
source
project
did
ship
with
an
accurate
sbom
with
dependency
references
to
build?
This
I'd
need
to
find
all
of
those
bring
them
all
together,
digest
them
build
the
database
clean
out
any
errors
in
it
and
then
perform
that
runtime
policy
evaluation?
A
A
build
process
is
often
usually
separate
from
the
s-bom
generation
process,
and
that's
it
also
additional
complexity
and
work
for
project
maintainers
and
many
s-bom
tools.
Don't
capture
the
full
build
tree
or
scanning
tool
that
you
might
run
later
only
looks
for
package
name
and
version
strings
and
doesn't
really
scan
the
content.
A
Now,
remember
how
I
said
at
the
beginning,
I
kind
of
cheated
and
told
you
the
end
of
the
story.
First,
I
want
to
talk
a
little
bit
about
a
project
that
I
found
along.
This
journey
called
get
bomb,
and
this
approach
learns
from
many
of
the
excellent
qualities
of
git.
It's
decentralized.
It's
a
merkle
tree.
It's
compact!
A
It
builds
a
lot
of
powerful
functionality
from
just
a
few
simple
primitives
and
git
is
already
a
de
facto
standard.
So
we
don't
need
to
go
through
a
lengthy
standards
development
process,
even
if
we
all
use
git
every
day.
I
don't
want
to
assume
that
everybody
knows
how
git
works
under
the
hood,
so
I'm
going
to
give
a
short
recap
of
the
relevant
functionality.
A
And
git
is
really
a
database
map
database,
that's
masquerading
as
a
version
control
system,
cleverly
using
your
file
system
as
a
storage
engine.
There
are.
There
are
three
types
of
objects
stored
by
git,
blobs
commits
and
trees,
and
every
object
is
stored
as
a
separate
plain
text
file
on
disk,
with
the
same
format
with
a
fixed
size,
header
and
a
descriptor
of
the
type
of
file
and
the
size
of
the
file
followed
by
the
raw
content.
A
These
files
are
all
named
deterministically.
It's
the
shop
one
hash
of
the
file,
so
they're
guaranteed
to
be
unique
globally,
even
right.
That
means,
if
I
have
the
same
content
anywhere,
it
is
stored.
It
has
the
same
referent
the
same
git
ref.
So
we
get
deduplication
across
trees
and
branches.
We
even
get
deduplication
on
a
centralized
service
like
github
and
you
and
I
could
even
reference
the
same
file.
A
Now
we
can
splash
on
some
metadata
to
capture
those
differences
like
the
different
path
on
my
computer
or
the
timestamp
or
copyright
or
the
propenence
of
a
file
if
I've
built
it.
But
we
still
know
because
we've
separated
or
git
has
separated
the
metadata
from
the
actual
file
content
what's
changed
and
what
hasn't
so
from
git's
perspective.
Every
artifact
is
just
a
blob,
it's
just
a
bite
array
and
we
can
build
a
tree
out
of
those
byte
arrays,
including
trees
themselves,
as
a
text
file
as
a
blob.
A
So,
as
I
mentioned
earlier,
s-bombs
today
typically
combine
metadata
with
the
artifactory
right,
if
I
have
say
an
spdx
s-bomb
describing
a
project
and
it's
referencing
several
other
projects
that
are
dependencies.
Those
s-bomb
documents
are
referencing
each
other.
We
have
the
artifact
id
and
all
the
meta
metadata
about
it
in
documents
that
are
forming
a
tree
like
this,
but
git
separated
them
for
good
reason
and
so
with
git
bomb.
A
We're
proposing
to
do
the
same
thing
now
and
one
reason
among
several
is
that
we
want
an
efficient
way
to
scan
the
whole
tree
for
known
vulnerabilities.
So
we
want
the
tree
to
be
small
and
easy
to
scan
and
a
tree
can
contain
references
to
any
kind
of
file
right
and
input
files
could
be
source
files
or
header
files
or
object
files
or
other
libraries
or
other
container
images.
Remember
every
artifact
is
just
a
blob
and
we
can
build
trees
out
of
these
in
our
build
process.
A
A
A
What
are
the
last
couple
pieces
that
we
need
to
get
there
to
have
git
git
bomb
documents
automatically
generated?
We
would
need
to
do
three
more
things.
We
need
to
embed
the
get
ref
of
the
git
bomb
in
the
actual,
build
output
from
the
compiler
or
the
build
step
generate
the
git
bomb
directly
in
that
process.
Not
after
the
fact
right,
we
could
embed
it
in
the
elf
header
or
the
container
manifest,
and
the
the
actual
compiler
or
linker
has
authoritative
knowledge.
So
it's
not
going
to
be
as
prone
to
errors.
A
One
of
the
biggest
upsides
to
this
approach,
I
believe,
is
that
it
doesn't
require
any
additional
work
for
most
open
source
developers.
If
these
changes
were
added
to
compilers
or
container
build
processes,
then
most
open
source
projects
get
it
for
free.
They
just
run
their
existing,
build
tools
or
compilation
process
and
there's
additional
metadata
generated
by
it
that
can
be
used
downstream.
A
That's
the
end
of
the
story
for
today
folks,
stay
tuned
hope
to
see
you
around
hope,
you're
having
a
great
conference.
You
can
find
me
online
on
twitter
or
elsewhere
and
if
you
want
to
get
involved
in
get
bomb,
we've
got
a
temporary
channel
set
up
on
the
open,
ssf
slack
for
now.
Just
dm
me
on
twitter
and
I'll
point
you
toward
to
where
we're
working
thanks.
So
much
bye.