►
From YouTube: SBOM Everywhere - Kate Stewart, Vice President of Dependable Embedded Systems, Linux Foundation
Description
SBOM Everywhere - Kate Stewart, Vice President of Dependable Embedded Systems, Linux Foundation
---
Open source software is pervasive in data centers, consumer devices, and applications. Securing open source supply chains requires a combination of automated tooling, best practices, education, and collaboration.
Join the growing list of organizations supporting the advancement of securing open source technology and funding the development and adoption of OpenSSF initiatives. https://openssf.org/
A
So
not
only
is
that
important
to
know
what's
in
the
product,
it's
also
important
to
know
what
is
building
your
product
as
what
is
you're
depending
on
with
your
product,
because
that's
all
part
of
your
software
supply
chain,
and
so
some
of
this
things
have
not
been
as
visible
in
the
past,
and
we
need
to
be
looking
at
that,
and
obviously
it's
pretty
quick
for
a
developer
to
fix
vulnerability.
Once
they're
known,
however,
the
cost
to
remediate
for
users
is
the
large
problem,
so
giving
them
bandwidth
and
time
to
make.
A
These
fixes
is
something
that
we're
going
to
have
to
take
care
of
in
the
industry
and
part
of
that's
going
to
be.
How
do
we
get
that
now?
Various
surveys,
including
the
one
the
LF
did
last
year,
you
know
98,
are
using
open
source
today
is
what
we're
finding
and
about
95
are
concerned
about
software
security,
so
how
how
concerned
they
are
and
how
much
they're
taking
action.
Obviously
I
think
the
prior
speaker
gave
a
pretty
good
summary
of
it,
but
we
need
to
look
at
how
to
make
this
forward.
A
The
number
two
action
was
use
s-bumps
to
better
secure
the
source
and
when
you
think
about
it,
it
makes
a
lot
of
sense.
You
just
need
to
know,
what's
there
to
know,
if
you
have
a
problem
or
not,
and
so
we
really
have
not
had
the
discipline
in
the
industry
consistently
to
make
some
of
these
things
available
at
scale
and
that's
where
we
need
to
go
to
right.
A
A
I
I
know
all
the
pieces
that
are
connecting
to
me
and
they're
things
that
are
unknown
and
that's
also
an
important
distinction
like
I.
Do
I
have
risk
here.
If
things
are,
if
you
don't
know,
you've
got
closure
on
all
your
dependencies,
you
have
potentially
of
risk
of
not
knowing
something
and
so
being
figuring
out.
A
How
we
can
get
that
standardized
in
an
effective
form
is
one
of
the
challenges
we
have
being
able
to
be
explicit
and
be
able
to
potentially
link
from
one
s
bomb
to
another
s-bomb
to
sort
of
be
able
to
trace
of
full
flow
back.
These
are
the
challenges
because
of
the
it's
so
fast
to
build
open
source
right
now,
the
devops
side,
things
like
that
being
able
to
every
time
you
do
a
build.
A
You
pretty
much
need
to
have
a
s-bomb
generated,
so
you
really
can
track
yourself
down
through
time
and
we're
not
quite
there
yet
we're
getting
better
part
of
the
motivation.
That's
happening
for
this
is
the
executive
order
came
out
last
year
from
the
government
and
when
we
did
the
survey
towards
the
end
of
the
year,
you
know
almost
80
percent
of
the
company
said
that
they
would
be
that
did
the
survey
for
us
said
they'd
be
using
s-bombs
this
year.
A
Now
most
of
them
are
just
producing,
there's
still
weaknesses
on
the
consumption
side
and
then
taking
that
information
to
make
effective
decisions.
There's
still
work
to
be
done
on
the
production
side
too,
to
get
to
scale
and
be
efficient
and
robust
and
hardened.
But
the
starting
points
are
there
in
both
places,
and
there
is
now
economic
motivators
from
the
executive
order
to
do
it,
but
we're
also
seeing
in
Europe
here
there's
a
lot
of
legislation
coming
up.
That's
expecting
s-bombs
as
well,
so
it's
not
just
a
U.S
phenomena.
A
It's
pretty
much
a
worldwide
and
the
awareness
of
the
vulnerability
in
the
supply
chains
is
what's
really
motivating
a
lot
of
changes
that
hadn't
been
happening
before
so
one
of
the
questions
become.
Is
you
know
what
is
a
minimum
s
bomb?
What
is
the
nest
bomb?
The
NTI
came
out
with
a
definition
after
it
it.
A
There
was
a
multi-stickerable
stuff
that
went
from
2018
to
2021,
and
then
they
did
a
their
own
little
listening
session
explicitly
and
some
of
most
of
the
recommendations
from
that
multi-stakeholder
were
taken
in,
but
they
did
factor
out
a
few
things
and
so
at
the
heart
of
it.
There's
some
data
fields
that
you're
expected
to
have.
A
There
is
some
support
you
should
be
able
to
take
in
support
for
Automation
in
some
formats
will
recognized
for
that
and
then
there
she
needs
to
be
certain
practices.
Things
like
that
depth,
the
known
unknowns,
the
distribution
delivery.
All
of
these
are
areas
that
there's
things
that
we
need
to
complement
these
s-bombs
with
to
have
a
working
ecosystem
so
that
minimum
s-bomb.
That
gets
you
starting
point,
but
there's
a
lot
more
information.
People
want
to
capture
than
just
those
minimum
Fields.
A
However,
if
you
want
to
call
yourself
an
s-bomb,
you
have
to
release
these
okay,
that's
kind
of
where
the
industry
seems
to
be
gelling
around
at
this
point
in
time
and
so
understanding
you
know
when
it
was
created
who
created
it.
What
are
what
are
the
relationships
that
are
there
and
they
just
have
simple
relationships,
and
here
there's
a
lot
more
richer
set
that
we
really
kind
of
need
for
having
true
knowledge,
then
there's
various
identifiers
and
versioning
of
the
component
and
the
component.
Now
the
component
is
deliberately
ambiguous.
A
It's
a
unit
of
software.
This
could
be
a
source
file.
This
could
be
a
binary.
This
could
be
an
output
of
a
build
anything
that
potentially
a
library
firmware
image,
whatever
that's
component
and
how
you
assemble
these
things
together
is
what
gives
you
the
knowledge
and
so
there's
a
software
life
cycle
that
we
start
to
play
with
it
nowadays.
A
A
lot
of
the
discussions
I've
been
participating
in
in
the
last
few
years
are
people
sort
of
I
know
about
this,
and
this
is
what
I
want
to
talk
about,
and
we,
the
software
chandron,
basically
contributed
the
software
to
that
survey
a
couple
years
ago
and
I
think
it
pretty
much
serves,
shows
the
scale
of
the
problem.
It's
been
a
slightly
revised
version
of
it
that
Bob
Martin
helped
work
on
talking
about
retiring
and
end
of
lifeing,
and
so,
but
what
we
have
is
we
have
effectively.
A
Let
me
go
here
again:
the
cursor
there
not
getting
the
cursor
good
when
you're
planning
and
you're.
Basically
looking
at
you
know
bringing
in
software
that
you're
going
to
combine
into
your
product
to
procurement,
and
you
know
initial
development
you're
going
to
want
to
know
what
you're
bringing
in
and
so
these
are
either
usually
Source
s,
bombs
or
they're,
maybe
an
analyzed
third-party
s-bomb.
A
So
if
someone
gives
you
a
binary,
you're
bringing
it
in
you've
got
no
other
information
you're
going
to
maybe
throw
it
through
a
binary
analysis
tool
to
understand
what
your
risks
are.
If
you're
going
to
use
it,
it's
all
risk-based
decisions
but
having
those
pieces
of
input
before
you
build
your
product
from
there.
A
A
So
we
have
different,
tooling,
that's
coming
into
play
here.
The
type
of
tool
that
will
generate
a
sources
bomb
is
different
than
the
type
of
tool
that
will
generate
your
config
runtime
s-bomb,
and
we
have
needs
for
all
of
these
to
get
s-bombs
everywhere
so
that
we
have,
you
know
true
line
of
sight
as
to
what
do
I
need
to
fix.
A
A
Okay,
my
definition,
Kate's
personal
definition
of
this
is
I
want
to
change.
One
line
in
my
build
and
I
want
to
have
a
coherent
s
bomb
out
of
there.
I
want
to
have
one
command
line
to
generate
things
one
way
or
the
other
I'm
not
quite
sure
what
it
needs
to
look
like
for
a
deployed
s-bomb,
but
it
needs
to
be
simple
because
if
we
don't
make
it
simple,
it's
not
going
to
happen
so
getting
us
to
this
s-bomb
everywhere.
We
need
to
figure
out
how
to
make
this
simple.
A
We
need
to
figure
out
how
to
put
the
Tooling
in
place.
We
need
to
figure
out
how
to
make
the
tooling
robust,
because
there's
a
lot
of
prototypes
out
there,
but
building
up
consensus
and
trust
in
these
tools
is
the
stage
we're
in
right
now
and
we
have
various
efforts
that
are
starting
in
that
direction.
A
So
this
stream
9
is
you
know,
approving
the
tooling
and
then
approving
the
training,
so
it
makes
it
easy
for
people
to
use.
This
is
what
we're
looking
at
as
part
of
the
Stream,
and
we
had
meetings
in
DC
in
May
and
then,
after
that,
we
started
over
the
summer
meeting
regularly
as
a
group
as
part
of
the
tooling
special
interest
group.
Sorry,
the
tooling
working
group
under
openssf.
So
this
this
is
a
Sig
under
the
tooling
working
group
right
now,
and
so
we
meet
every
two
weeks.
A
In
fact,
the
meeting's
happening
right
about
now
actually
over
in
North
America.
So
it's
time
zone
friendly
for
Europe
as
well,
and
what
we're
trying
to
do
is
make
sure
the
security
use.
Cases
are
well
documented
and
then
making
sure
that
the
formats
and
standards
can
basically
support
them,
and
then
the
tools
are
available
to
it.
That's
kind
of
what
we're
going
for,
and
so
the
approach
we're
looking
at
is
getting
those
requirements
cleaned
up.
Okay,
everyone
has
like
say
trying
to
get
past
everyone
talking
at
each.
A
You
know
talking
past
each
other
with
what
their
use
cases
are
and
having
them
document
in
a
common
understanding
that
gives
us
a
set
of
requirements
so
that
we
can
make
sure
that
the
various
tools
satisfy
or
don't
satisfy
certain
types
of
requirements,
and
then
we
can
basically
look
at
creating
a
taxonomy
where
people
can
find
things
having
them
out
in
the
open
source
and
then
having
education
on
how
to
use
those
tools
to
satisfy
those
requirements.
People
are
going
okay.
How
do
I
go?
How
about
use
this
tool?
How
do
I
do
this
Playbook?
A
A
So
there
were
some
initial
goals
forward
and
we're
sort
of
starting
to
work
on
the
first
few
of
that.
Spdx
is
part
of
this
and
we're
you
know
committed
as
part
of
this
project
from
SPX
to
work
on
the
security
profile
to
satisfy
this,
and
so
there
is
the
SPX
Community.
That's
working
on
this
and
there's
various
people
here
from
that
community
and
in
fact,
I
think
I
see
Thomas
at
the
very
back
or
the
row
he's
leading
the
security
profile
from
the
spdx
group.
A
And
so,
if
you've
got
to
sort
of
talk
about
that,
but
we
are
wanting
to
work
here
to
make
sure
that
we
can
make
spdx
effective
for
this
type
of
thing
and
then
having
these
freely
widely
available
tools
like
the
command
line,
interpreters.
Things
like
that
and
then
you
know
very
trying
to
get
package
managers
out
there
and
effectively
used.
Nisha
is
working
on
one
of
the
online
tools
and
she's
here
and
happy
to
talk,
and
yes,
five
minutes.
Okay
and
so
we've
got
a
variety
of
other
people.
So
this
is
work.
A
A
If
you
want
to
get
engaged
we're
up
on
GitHub
under
the
openssf
repository
the
security
tooling-
and
you
will
see
us
down
here
and
there's
an
open
mailing
list,
people
are
welcome
to
subscribe,
especially
if
you've
got
use
cases
you
want
to
make
sure
are
represented.
Please
do
please
subscribe
and
then
please
start
looking
at
as
things
emerge
and
put
comments
in
and
if
you
can
attend
the
meeting
great
but
start
to
provide
your
inputs
is
what
we're
looking
for.
A
And
so
where
we
are,
as
a
group
I've
got
links
here,
the
Espionage
cases
for
security.
That's
when
we're
trying
to
get
those
cases
documented
requirements.
There
is
a
template
for
s-bomb,
tooling.
One
of
the
people
say
you
know.
One
thing
we're
seeing
is
okay.
Well,
how
do
I
have
the
tool
to
do
this?
A
Well,
Landscapes
are
a
solution
we've
used
in
other
projects,
we're
going
to
try
to
apply
a
landscape
here
and
have
various
filtering
criteria
so
trying
to
Define
which
filters
we
want
to
care
about
and
then
classify
these
tools
against
these
filters
so
that
people
can
find
tools
that
they
want
to
use
for
certain
purposes.
I
think
that's
generally,
where
we're
going
and
then
the
other
thing
that's
work
in
progress.
Thank
you
very
much
to
the
open
ssf.
There
is
now
some
funding
allocated
for
getting
our
python
libraries
and
spdx
cleaned
up
and
refactored.
A
They
had
gotten
rather
crafty,
to
put
it
mildly
for
2-2,
and
so
the
two
two
and
two
three
versions
of
spdx.
We
have
a
team
working
on
that
and
they'll
be
working
on
being
visible
in
the
open
source
as
they're
evolving.
This
improving
the
tooling
library
for
python
we've
got
a
pretty
good
Java
Library.
Already
it's
up
to
date
with
the
two
three
and
there's
some
work
going
on.
A
I
think
Brandon
is
working
with
the
go
libraries
and
so
forth.
So
we've
got
different
languages
for
having
libraries
and
Stranded
interfaces
into
using
this,
so
that
people
can
just
generate
the
new
versions
and
with
that
that's
pretty
much
all
I've
got
so
I.
Think
I'm
within
my
five
minute
limit
four
minutes.
It
took
anyone
with
questions,
go
for
it.
B
A
B
A
Having
partial
information
I
think
it's
a
function
of
the
tools
that
you're
working
with
and
the
tools
need
to
be
hardened.
We
have
in
SPX
we
about
we'll,
probably
have
one.
This
fall
we'll
have
effectively
what
we
call
a
bake
off
or
a
doc
Fest,
and
we
want
to
have
anyone
who's,
having
tools
that
are
producing
output,
that's
wrong,
come
and
compare
with
other
tools
on
the
same
input
so
that
we
can
understand
the
semantics.
A
A
It's
is
the
tool
doing
the
right
thing
or
not,
and
you
need
to
judge
it
against
another
tool
to
make
sure
that
there's
coherence
between
the
tools,
so
it's
a
tool,
hardening
problem
and
I
think
documenting
against
the
tool
that
you're
working
with
that
there's
an
issue
and
what
you
think
the
issue
is
and
starting
to
work
with
the
tool
that
you
know
the
tool,
either
vendor
or
Community
to
refine
things.
When
you
see
issues
will
eventually
get
to
the
stage
where
we
have
full
reproducibility
across
multiple
iterations
Thomas.
A
Yeah,
so
some
of
the
data,
the
other
thing
I
will
encourage
you
to
do,
is
on
Thursday
afternoon.
Nisha
is
having
an
s-bomb,
both
s-bomb,
tooling,
buff
and
so
looking
for
gaps
and
where
we
need
to
work
on
the
tooling.
So
I
would
encourage
you
probably
to
go
and
show
up
at
that
buff
and
start
going
into
the
details
with
Thomas,
Anisha
and
others
about
what
the
issues
are.
Okay,
any
other
questions
quickly.
A
A
So
the
NTI
stuff
was
basically
saying:
You
must
have
at
least
one
layer
down.
Okay,
realistically,
you
want
as
much
information
as
you
can
get
and
if
you
don't
have
the
ability
to
do
the
layers
down
or
further
partial
layers,
you
need
to
Signal
it
explicitly
that
it's
an
unknown
and
so
and
that's
an
area
where
the
tooling
really
hasn't
caught
up
to
what
should
be
done.
A
From
my
perspective,
at
least
so
having
the
known
unknowns,
I
was
referring
to
earlier
there's
ways
of
specifying
that
explicitly
in
spdx
and
if
it's
not
explicitly
specified
it's
assumed
as
known.
However,
there's
ways
of
signaling
that
you
do
have
unknowns
there,
but
the
truly
isn't
generating
that
much
go
ahead.
Brian.
A
No,
it
doesn't,
for
instance,
I've
got
one
of
the
projects.
I've
got
Zephyr
that
I
work
with
a
lot
as
part
of
its
build
flow,
so
it's
CC,
plus
plus
you're,
generating
out
3s
bombs
automatically
from
one
line
change
in
your
build
2s
sources,
one
for
the
Zephyr
sources,
one
for
the
app
sources
and
then
a
third
for
the
build,
which
is
all
the
dot
O's
that
actually
made
it
in
from
those
sources
into
your
final
binary.
Things
like
that
are
in
yocto.