►
From YouTube: Keynote: The Next Steps in Software Supply Chain Security - Brandon Lum, Software Engineer, Google
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.
Keynote: The Next Steps in Software Supply Chain Security - Brandon Lum, Software Engineer, Google
We've made a lot of progress in the realm of supply chain security in recent years! However, there is still much to do. A lot of efforts have been put into developing the "producing" aspects of the Software Supply Chain - SLSA, Tekton (and other build systems), Software Bill of Materials (SBOM). This has led to a much higher fidelity security metadata than we've ever seen. As we move forward, the "consuming" aspects of the Software Supply Chain will need to be developed.
Policy, Aggregation and Synthesis are key aspects of this side of the problem. We will share some ongoing open source effort to address them and highlight gaps within the space that need to be filled.
A
Hi
I'm
Brandon
I
work
on
the
Google,
open
source
security
team
and
naturally
part
of
that
is
securing
open
source
and
actually
part
of
that
is
supply,
chain
security
right.
So
let's
talk
about
what
everyone's
been
talking
about
over
here
we
see
the
supply
chain
security
Bingo
got
so
software
supply
chain.
Security
is
something
everyone's
been
talking
about.
We've
seen
the
charts,
so
it's
going
up
the
error.
So
it's
going
up-
and
you
know
these-
this
is
important
right.
Indeed,
software
supply
chain
compromises
and
attacks
happen
on
the
rise
of
late
right.
A
However,
the
industry
also
has
gotten
together
and
given
a
response
to
match,
we've
seen
a
lot
more
efforts,
a
lot
more
working
groups,
a
lot
more
foundations
and
organizations
prioritizing
supply
chain
security,
in
fact,
even
a
cognitive
security.
Can't
this
time,
we've
seen
a
very
large
number,
the
most
number
of
submissions
coming
around
the
topic
of
supply
chain
security.
A
So,
let's
just
look
at
the
all
the
cool
new
and
existing
projects
that
have
been
trying
to
solve
the
supply
chain
security
problem.
This
goes
across
many
different
areas,
including
build
systems,
as
you've
heard
already
in
today's
keynote
signing
trusts
software
metadata
and
scanners
right.
So
that's
a
whole
lot
going
on
here.
I'm
gonna
spend
a
little
bit
kind
of
talking
a
little
bit
about
what
the
layers
are
and
what's
going
on,
the
progress
we
are
making
and
then
talk
a
little
bit
more
about
what
are
the
next
steps.
A
Where
should
we
go
so
to
start
in
this
list?
We
have
projects
that
help
set
a
strong
Foundation
of
trust.
You've
heard
it
at
a
time
six
star
and
kind
of
underpinning
that
tough
or
the
update
framework.
They
help
keep
signing
simple
and
open,
and
in
addition,
we
also
have
zero
trust
projects
like
spiffy,
Inspire
and
key
lime
that
are
integrating
with
the
entire
ecosystem
as
well.
A
We've
also
seen
a
lot
of
activity
in
progress
in
terms
of
software
metadata
standards
such
as
salsa
they're,
working
on
their
1.0
release.
That
will
have
a
draft
in
a
couple
weeks
and
hopefully
GA
in
the
next
one
or
two
months,
and
if
you're
in
the
U.S
and
you've
heard
about
the
executive
order,
which
I
think
most
already
have
and
affected
by
s-bombs,
we
see
both
spdx
and
cycle
and
DX
standards
as
well
becoming
more
popular
and
on
top
of
that
are
coming
upcoming,
tooling,
which
is
very
important,
and
we
see
things
like
vulnerability.
A
Exploitability
exchange,
that's
coming
out
of
the
Seesaw
working
groups
to
kind
of
tackle.
You
know
now
that
I
know
what
my
vulnerabilities
out
of
all
my
scanners,
how
do
I
triage
them?
What's
important
to
me?
What
is
not,
maybe
some
vulnerabilities
I
am
not
affected
by
and
finally,
of
course,
we
have
build
systems
like
tecton
and
the
open
ssf
Fresca,
who
have
helped
to
be
able
to
create
these
trusted
artifacts.
A
One
thing
you
notice
about
these
projects
that
we
just
looked
at
is
a
lot
of
them
are
focusing
on
the
producing
side.
How
do
I
produce
trusted
software?
How
do
I
produce
software
metadata?
That
is
useful.
You
know
how
do
I
get
s-bomb.
Sorry,
that's
the
number
one
question
that
everyone's
talking
about,
but
as
with
any
supply
chain
right,
there
is
producers
that
are
consumers
as
well,
and
so
we've
done
a
great
job.
Producing
trusts.
There's
many!
However,
there
are
so
many
open
questions
about.
What
do
we
do
with
this
right?
A
We
have
all
these
documents.
How
do
you
evaluate
them?
We
have
questions
like
okay,
I
have
s-bomb
what
do
I
do
with
it?
How
many
levels
deep
do
I
have
to
check
for
things.
You
know
how
many
Devils
deeper
salsa
do:
I
have
to
check
transitive,
salsa
or
even
So
within
each
software
metadata
document,
which
of
the
fields
are
important,
which
can
I
just
safely
ignore.
A
So
today
we
are
faced
with
an
overwhelming
amount
of
software
supply
chain
metadata
right
and
we
somehow
need
to
find
meaning
out
of
it
and
kind
of
like
I
feel
like
this.
This
picture
kind
of
expresses
how
I
look
when
I
see
like
a
300
megabyte
s-bomb
I.
That's
basically
not
much
that
that
you
can
make
meaning
out
of
it
besides
trying
to
grab
through
a
few
things.
A
A
A
So,
let's
talk
about
aggregation
and
synthesis
and
and
in
a
nutshell,
this
is
about
bringing
all
the
metadata
together
and
Performing
intelligent
linking
between
them
right
so
best
way
to
illustrate
this
may
be
issue
an
example.
Let's
say
you
have
a
homegrown
application
like
an
Acme
application
right.
So
first
thing
you
need
to
do
to
reason
about
security
is
first,
you
need
to
know
about
who
built
this
application
internally.
Where
was
it
built?
So
you
have
to
pull
data
from
internal
teams,
internal
systems,
build
systems,
Source
repositories.
A
These
is
threat
intelligence
right,
given
all
this
metadata
I
have.
How
do
I
know
what's
important?
What
do
I
have
to
check
for
what
affects
my
security
posture,
and
so
this
includes
things
like
CVS
right,
that's
the
one
that
we
are
most
commonly
familiar
with,
but
now
we
have
Vex
and
addition
to
that.
You
know
we
want
to
kind
of
think
a
little
bit
further
in
terms
of
now.
I
need
to
think
about
developers
and
actors
of
who's
producing
what
in
the
software
so
that
I
chain.
A
By
collecting
all
these
s-bombs
and
files
and
putting
them
in
a
single
directory,
it
doesn't
really
do
much
right,
we're
just
ending
up
with
files
in
the
same
directory,
and
maybe,
if
you're
like
really
good
with
prep.
You
can
do
a
lot
of
great
things
with
it,
but
I
think
the
question
here
is:
you
know
we
need
to
be
able
to
link
them
intelligently
and
be
able
to
perform
queries
over
them.
A
A
So
examples
of
projects
that
do
aggregation
synthesis
today
we
have
the
graph
understanding,
artifact
composition,
that
we're
working
on
together
with
a
couple
other
organizations
like
kusari,
Purdue
and
City,
and
the
idea
here
is
to
be
able
to
be
a
take
these
data
sources
and
to
be
able
to
link
them
intelligently.
So
you
can
query
them
as
a
graph
and
of
course
we
have
public
data
source
aggregators
like
depths
of
depth
and
repology,
that
give
you
information
about
open
source
libraries,
their
security
as
well
as
licensing.
A
And,
of
course
you
know,
we
have
package
managers
that
have
been.
You
know,
silently
doing
the
job
for
many
years
at
to
some
regard,
such
as
Pi,
Pi,
ruby,
gems
and
folkat
Native.
You
know
oci,
Registries
and
I
just
want
to
point
out
here
that
we,
we
actually
have
a
talk
this
afternoon
about
how
we're
doing
the,
how
we're
attaching
s-bombs
and
salsa
attestations
to
oci
Registries
and
there's
a
talk
this
afternoon
by
Brandon
Mitchell.
A
So
going
on
to
the
next
layer
now,
once
you
have
the
metadata,
aggregated
and
synthesized,
we
need
to
be
able
to
make
policies
on
that
right.
So,
on
one
end
of
this
of
the
coin,
we
have
you
know
how
do
we
actually
enforce
these
policies
and
I
think
we
are
pretty
much
set
on
that
we
have
cnci
projects
like
Kaiba,
no
open,
open
policy
agent
that
can
do
that
and
if
you're
in
the
Enterprise,
you
have
your
favorite
ones
from
your
government
insurance
and
control
and
cmbb
systems.
A
A
Can
we
break
it
down
to
tangible
questions
that
we
can
tackle?
Are
we
talking
about
vulnerabilities,
build
provenance,
tooling
Developers,
how
many
years
of
transitive
dependencies
do
we
care
about?
How
do
we
reason
about
trusts
and
risks
and
policy,
and
these
are
largely
unanswered
questions
and
tax
security
is
starting
an
effort
to
Rally
the
industry
on
defining
what
good
looks
like
for
software
supply
chain
policy,
so
this
is
undergoing
as
part
of
the
supply
chain
working
group
that
meets
every
Thursday.
A
So
some
kind
of
questions
we'll
be
exploring
in
the
group
is
various
policies.
I
think
they
they
kind
of
break
down
into
three
main
categories.
We
have
reactive,
preventative
and
proactive,
so
reactive
is
kind
of
like
you
log4j.
We
talked
about
the
open
SSL
on
vulnerability
this
morning
you
know,
there's
a
new
hot
vulnerability,
that's
out
question
one
is
am
I
affected
and
then
we
go
ahead
to
say
how
am
I
affected,
which
software
is
being
affected
and
then
how
can
I
go
about
to
remediate
and
draw
my
entire
organization
and
we
have
preventive
policies?
A
Let's
say
you
know,
I
want
to
be
able
to
check
if
software
hits
a
compliance
requirement
before
deploying
into
my
cluster.
This
consists
not
only
of
measures
like
vulnerability,
scanning
or
fuzzing,
but
we
also
want
to
include
organization
claims
and
certification
on
software,
for
example,
you
know
certifying
for
prod
certifying
that
certain
departments
only
can
run
software
on
certain
clusters.
A
And
finally,
we
have
what
what
we
call
Proactive
policies-
and
this
is
somewhat
a
little
bit
more
unexplored,
but
it's
trying
to
identify
you
know
the
next
log
4J
before
it
happens
for
those
that
are
familiar
with
the
xkcd
comic.
Basically,
we
are
trying
to
find
the
underpinning
libraries
that
are
critical
to
our
open
source
infrastructure.
A
So
there's
some
priority
out
here,
for
example,
the
open
ssf
criticalities
cost.
However,
as
we've
seen
with
on
the
log
for
JS
log
for
Shell
case
is
critical.
These
scores
are
only
one
part
of
the
picture
and
that
definitely
are
more
Matrix
and
more
analysis
and
policies
that
we
can
make
in
order
to
be
more
proactive
and
finding
these
before
it
happens.
A
So
in
conclusion,
we've
made
a
lot
of
good
progress
in
the
world
producing
good
software
supply
chain
security.
We
need
to
start
making
easy
to
consume.
What
we've
built
tech
security
has
many
efforts.
I
do
encourage
everyone
to
drop
by
to
to
have
a
chat
with
us
and
get
involved,
and
we
also
have
a
couple
of
talks
happening
today.
Besides
the
one
that
I
mentioned,
we
also
have.