►
From YouTube: Discussion of SBOMs at Microsoft and Google
Description
Adrian Digilio from Microsoft discusses Microsoft’s Open Source SBOM Tool and Isaac Hepworth from Google discusses Google’s approach to SBOM adoption.
A
So
hello,
everybody,
I'm,
I'm,
Adrian
diglio
from
Microsoft
I
got
a
lot
of
information
to
cover
today,
so
I'll
be
going
a
little
a
little
quick,
I'm
I'm
I
lead
the
secure
software
supply
chain
team,
of
which
s-bombs
is
just
one
piece
of
our
overall
supply
chain
security
strategy.
A
I'm
gonna
cover
overviews
of
the
Microsoft
s-bomb
tool,
which
we've
open
sourced
I'm,
also
going
to
provide
a
demo.
So
you
could
see
it
in
real
life
I'm,
going
to
cover
some
challenges
that
we
faced
about
just
the
the
level
of
maturity
of
s-bombs
and
where
we
are
today
and
where
we'd
like
to
see
it,
Go
and
and
and
I'll
dip,
my
toe
into
the
future.
A
So
so
for
those
that
are
still
getting
acquainted
with
with
s-bombs,
they
provide
various
benefits
based
on
which
which
Persona
we're
talking
to
so
for
a
software
producer,
the
the
ones
that
are
generating
s-bombs.
It
gives
you
a
baseline
of
inventory
of
your
dependencies
for
for
each
deployed
version
of
your
software.
A
Many
many
teams
out
there
today
are
using
SCA
tools.
Software
composition,
analysis
tools
that
that
already
kind
of
give
them
that
inventory
of
of
dependencies
used
at
typically
at
build
time,
but
when
you
have
an
s-bomb,
this
allows
you
to
associate
it
with
a
successfully
deployed
application,
and
then
you
can
actually
have
confidence
that
these
are
your
dependencies
that
have
been
shipped
to
production
by
delivering
s-bombs
to
your
customers.
A
You
are
providing
software
transparency
and
when
you
look
at
all
the
different
building
blocks
that
that
equate
to
trust
transparency
is
one
of
those
building
blocks,
so
you're
helping
build
trust
with
your
customers.
A
If,
if
you
are
using
software,
that
is
not
code
signed
for
some
reason
or
another,
it
is
possible
to
Leverage
The
s-bomb
to
help
provide
some
software
Integrity
validation
scenarios,
and
it
also
helps
you
comply
with
regulatory
requirements
from
a
consumer
side.
When
you
have
this
transparency,
you
have
this
insight
into
these
supply
chain
dependencies.
You
can
start
to
answer
that
question
am
I
affected
and
what
is
affected
and
once
you
know
what
is
affected
so
imagine
imagine
the
Persona
of
of
somebody.
A
That's
on
the
operation
side,
that's
trying
to
manage
risk
across
all
the
software.
That's
deployed
in
their
environment
once
once
the
headline
comes
out
that
says:
here's
log4j
version
2
now
they
can
say,
am
I
affected.
Okay
I
am
where
am
I
affected?
Oh
it's
within
this
application
and
I
happen
to
know
that
this
application
sits
within
this
part
of
my
overall
Enterprise
architecture.
A
So
then
they
can
start
to
do
risk
evaluations
to
know
what
are
the
layers
of
defenses
that
are
in
place
before
an
adversary
might
be
able
to
exploit
that
vulnerability.
A
Then
you
know
once
you
know
that
you
are
affected,
you
can
enter
a
state
of
heightened
watch,
so
you
can
be
on
the
lookout
for
for
an
emergency
patch
like
an
out-of-cycle
patch
and
and
be
prepared
to
implement
the
patch
as
soon
as
you
receive
it.
Alternatively,
you
can
be
on
the
lookout
for
applicability,
vulnerability,
applicability,
statements
from
your
vendor,
things
like
like
Vex
or
vdr
documents
to
where
they
might
claim
that
the
vulnerability
is
not
exploitable.
A
A
A
So
what
do
I
mean
by
cross-platform
it's
available
as
a
binary,
so
it's
an
exe
for
Windows
environments
and
it's
a
dll
for
Linux
and
Mac
environments.
A
So
because
it's
a
binary,
you
can
run
it
in
any
CI
workflow.
So,
whether
you're
in
GitHub
or
Azure,
devops
or
Circle,
Ci
or
git,
lab
or
or
whatever
happens
to
be,
you
can
run
it
in
any
workflow
and
if
you
are
in
in
GitHub,
somebody
else
created
a
GitHub
action
for
it.
A
A
And
additionally,
what
I
meant
when
I
said
it's
a
general
purpose,
a
spawn
generator
is
because
it
supports
Auto
detection
of
so
many
different
types
of
dependencies.
Today
over
here
on
the
right,
you
can
see
this
First
Column
scanning
with
the
check
mark.
Those
are
all
the
types
of
components
that
we
Auto
detect
today
and
the
second
column
on
the
right,
the
graph
creation,
if
there's
a
check
mark
there.
That
means
we
also
detect
the
transient
dependencies
as
well
and
I'm
going
to
be
demoing
that
to
you
today,.
A
So
when
we
built
our
tool,
we
we
had
to
make
sure
that
the
s-bombs
we
output
are
our
executive
order
compliant.
So
the
ntia
created
these
seven
different
fields
and
we
mapped
those
to
spdx,
and
when
we
looked
at
the
spdx
spec,
some
of
those
fields
were
optional
in
the
spec,
so
we
knew
we
needed
to
make
them
mandatory.
So
our
tool
always
has
these
fields,
plus
some
of
the
other
mandatory
spdx
Fields
as
well,
plus
some
optional
ones
as
well
and
I'll
get
into
that.
A
Another
really
neat
feature
that
our
tool
does.
Is
it
references
other
s-bomb
documents,
so
if
I
pull
in
dependencies
and
those
dependencies
have
s-bombs
I
can
reference
those
s-bombs
in
the
s-bomb
that
I
generate
for
my
software.
Additionally,
as
you
could
imagine,
Microsoft
has
some
pretty
complex,
build
scenarios.
So,
for
example,
there's
like
layered
builds
where
you
know
some
of
our
large
Flagship
software
like
like
Windows
SQL
exchange
office.
A
A
One
s-bomb,
that's
representative
of
all
of
those
cumulative,
builds
that
it
took
to
produce
that
software,
and
so
we
came
up
with
this
great
way
to
be
able
to
reference
other
s-bombs,
so
that
a
determined
consumer
can
be
able
to
pull
in
the
full
dependency
tree
across
all
the
various
builds.
A
All
right,
so,
let's
hop
into
a
demo
I'm
going
to
compare
rsbom
generator
against
a
cyclone
DX
s-bomb
generator
and
I'm,
not
comparing
spdx
to
Cyclone
DX.
Both
of
those
are
perfectly
fine.
What
I
really
want
to
showcase
here
is
the
difference
between
the
dependency
detection
technique.
A
So
here
you
can
see
I
have
this
repo,
it's
open
source
I'll
share
a
link
to
this
repo.
A
Later
I
have
11
python
packages
listed
in
this
requirements.txt
document,
and
what
I'm
going
to
do
is
show
you
my
yaml
file,
so
for
this
demo
I'm
going
to
kick
off
a
build,
and
you
could
see
that
I'm
performing
this
build
on
Ubuntu
for
this
demo
to
demonstrate
that
it's
a
cross-platform
I'm
checking
out
Python
and
using
python
3.8
and
here
I'm
running
the
s-bomb
tool,
so
I'm
I'm,
making
a
network
call
to
go,
grab
the
binary
and
then
I
am
running
the
tool
and
I'm
using
these
various
flags.
A
And
it's
going
to
Output
my
my
s-bomb
right
after
this
task.
I'm
then
going
to
run
that
Cyclone
DX
GitHub
action
to
generate
an
s-bomb
from
their
tool.
Normally
you
wouldn't
be
generating
two
Bill
two
s-bombs
in
in
one
build,
but
you
know
I'm
just
doing
this
for
demo
purposes.
A
So
here
we
go,
we
can
watch
this
all
happen.
It's
now
generating
the
s-bomb
using
the
Microsoft
s-bomb
tool
done
and
it's
generating
the
Cyclone
DXs
bomb
and
then
done
and
done
so.
You
could
see
that
the
Microsoft
s-bomb
tool
took
six
seconds
and
the
Cyclone
DX
s-bomb
tool
took
two
seconds
now
when
these
things
have
been
outputted.
You
could
see
here.
Theirs
is
an
XML
version.
I've
already
grabbed
the
contents
of
these
s-bombs
and
and
threw
them
in
here.
So
you
could
see
here's
the
Cyclone
dx1.
You
could
see
that
it.
A
It
identifies
the
11
components,
whoa,
sorry,
it
identifies
the
11
components
that
were
listed
inside
that
requirements.txt
file
and
the
reason
why
it
did.
That
is
because,
when
you
look
at
their
page
it
says
hey,
give
me
a
requirements.txt
file
and
I
will
give
you
an
s-bomb,
so
it
literally
just
grabbed
that
list
and
created
an
s-bomb
out
of
it.
When
you
look
at,
let
me
go
back
to
the
build
output
here
and
you
come
back
here
and
you
look
at
the
Microsoft
s-bomb
tool
and
we
start
scrolling
down.
A
You
can
see
here
that
this
is
where
it's
starting
to
check
and
see
what
are
all
the
different
dependencies
that
might
possibly
be
used
that
we
that
we
Auto
detect
for
and
zero
zero
zero
zero
zero.
Here
we
go:
here's
the
python
pip
packages.
We
detected
the
11
that
were
listed
in
the
file,
but
we
actually
detected
a
total
of
26
and
that's
because
we
do
the
we
detect
the
transient
dependencies.
So
when
you
look
at
our
documentation
here
right,
here's
component
detection,
our
our
Microsoft
s-bomb
tool,
uses
component
detection
inside
of
it.
A
A
A
This
is
a
product
from
Psy
beats,
it's
called
s-bomb
studio
and
there
are
many
other
s-bomb
consumption
tools
like
it,
but
I've
thrown
both
in
here,
and
you
can
see
that
here's,
the
Cyclone
DX
XML
document
and
here
are
the
11
packages
it
detected
and
one
of
them
Babel
has
one
vulnerability
here
and
you
can
click
on
vulnerabilities
and
you
can
see
that
this
is
a
a
high
vulnerability
and
that
it
allows
attackers
to
load
arbitrarylocal.dat
files
via
directory,
traversal,
right
and
and
here
here's
the
Microsoft
desk
bomb
tool.
A
So
you
can
see
the
26
that
we
found,
and
so
you
know
it
actually
has
more
license
information
as
a
result,
and
so
it's
a
more
complete
s-bomb,
because
our
tool
has
these
kinds
of
detection
techniques
that
completes
my
My
Demo.
So
some
of
the
challenges
that
we
faced
are
s-bomb
tools.
Don't
Auto,
detect
everything
there
are.
You
know.
Developers
are
very,
very
creative
and
there's
a
myriad
of
ways
that
developers
can
consume
open
source
into
a
a
build,
and
so
you
know
within
Microsoft.
A
We
actually
have
a
way
to
manually
declare
OSS
that
you're,
using
that
our
tool
doesn't
Auto
detect
yet,
and
so
that's
kind
of
like
a
shortcoming.
I
guess
across
the
industry
is
that
you
know
these
these
kinds
of
detection
techniques.
You
know
SCA
tools
have
been
around
for
a
while,
but
they're
still
not
like
a
hundred
percent
comprehensive.
A
Pan
the
s-bomb
represent
what
gets
installed.
So
this
is
a
conversation
that
we've
been
having
at
Microsoft,
so
large
applications
such
as
Visual
Studio.
When
you
go
to
install
visual
studio
and
you're
a
C
plus
plus
developer,
you
might
only
install
the
C
plus
modules
and
not
install
any
of
the
c-sharp
modules,
so
the
s-bomb
in
order
to
to
list
out
the
dependencies
that
are
there,
you
only
really
want
to
list
out
the
dependencies
for
what
got
installed.
A
Not
the
full
comprehensive
list
of
everything,
that's
included
at
build
time,
and
so
you
know
we're
coming
up
with
some
creative
ways
on
on
delivering
an
s-bomb
based
on
what
gets
installed.
A
A
Our
our
current
school
of
thought
is
that
that
each
patch
that
gets
delivered
to
patch
the
operating
system
needs
to
have
its
own
s-bomb
and
its
s-bomb
needs
to
be
knowledgeable
about
the
s-bomb
for
the
base
OS,
because
if
the
base
OS
says
I'm
using
boost
version
1.0
and
then
Here
Comes,
this
patch,
that
patches
boost
1.0,
the
s-bomb
for
the
patch
needs
to
say,
removes
package
boost,
1.0,
ads
package,
boost
version,
1.1
and
because
that's
kind
of
and
then
and
then
these
s-bomb
management
tools
that
consume
all
of
these
s-bombs
need
to
be
able
to
trace
all
of
the
different
patch
s-bombs
to
make
sure
that
they're
only
surfacing
the
the
latest
version
of
component
that's
installed,
based
on
all
the
patches
that
have
been
applied,
s-bombs
can
be
used
to
show
OSS
vulnerabilities,
but
not
all
OSS
vulnerabilities
are
exploitable
in
the
way
that
each
application
uses
that
that
dependency.
A
So
as
as
discussed
earlier,
this
is
where
Vex
documents
come
in.
A
There's
there's
been
some
some
online
articles
that
suggest
that
customers,
don't
trust
like
fully
trust
a
a
vendor's
claim
in
a
Vex
document
like
hey
this.
This
vulnerability
doesn't
apply
the
way
that
I've
used
the
component-
and
you
know
I
I-
would
love
to
think
that
the
industry
can
can
innovate
here
and
come
up
with
some
sort
of
automated
testing
to
kind
of
more
provably
demonstrate
that
it
wasn't
able
to
be
exploited
within
their
application.
A
I
I
hope
that's
the
direction
that
the
industry
goes
to
help
produce
trustable
Vex
documents.
Additionally,
where
do
customers
subscribe
to
get
vexap
updates
today?
They
know
how
to
how
to
see
all
these.
You
know
vulnerabilities
and
there's
all
these
different
vulnerability
databases,
but
there
isn't
a
single
place
or
for
vendors
to
publish
their
Vex
documents
so
that
consumers
can
can
consume
them.
A
I
see
that
there's
a
hand
up,
but
I'm
almost
done.
Distribution
from
producer
to
Consumer
is
is
a
little
bit
of
a
challenge.
So
if
it's,
if
it's
a
binary,
yes,
the
the
the
school
of
thought
there
is
to
include
the
s-bomb
within
the
compiled
code
so
that
the
s-bomb
travels
with
the
binary.
That
makes
a
lot
of
sense.
A
We've
done
that
with
Powershell,
with
specifically
the
PS
Redline
module,
but
then
there's
other
different
software
types
where
the
consumer
won't
have
access
to
the
bits
and
therefore
can't
get
access
to
the
s-bomb.
A
If
that's
how
your
transferring
the
s-bomb
so
like,
and
specifically
with
with
containers
like
like
Docker
containers,
they've
already
built
mechanisms
within
within
container
Registries
to
store
the
s-bombs
side
by
side
with
the
container
and
as
you
promote
it,
from
Dev
to
test
to
prod
the
s-bomb
travels
with
with
the
container
image
that
it's
for
things,
such
as
like
embedded
systems,
iot
devices
cloud
services,
we
need
another
mechanism
with
which
to
distribute
s-bombs
and
so
Microsoft
has
been
leading
the
charge
on
skit
supply
chain,
Integrity,
transparency
and
trust.
A
It
is
both
a
ietf
standardization
effort
and
it's
also
a
service
that
Microsoft
is
building
to
allow
people
to
store
conformance
data
so
think
of
the
executive
order.
There's
all
these
requirements
for
a
secure
development,
environment
skit
is
a
way
that
we
can
exchange
our
conformance
data,
our
our
attestations
that
we
are
conforming
with
each
one
of
the
requirements
and
an
s-bomb
is
just
one
of
the
types
of
data
that
that
it
will
house
and
be
able
to
distribute.
A
Today
we
are
working
on
building
numbers
three
and
four
in
the
diagram
and
numbers
one.
Two,
five
and
six
are
available
today,
so
we
can
actually
start
realizing
these
types
of
workflows
by
by
signing
the
attestations
and
s-bombs
with
with
industry,
specifications
and
standards
such
as
cozy.
A
There
are
clients
that
you
can
use
today
to
sign
these
things,
such
as
as
notary,
and
you
can
use
open
source
client
tools
such
as
oras
to
to
publish
this
evidence
to
oci
data
stores
and
in
oci
data
stores,
something
like
Azure
container
registry
or,
if
you're,
on
AWS,
the
the
ECR
equivalent
and
that's
it.
For
me,.
C
D
Hi
there,
thank
you
Ginger
yeah.
Can
you
hear
me?
Yes,
video
check,
excellent
Adrian,
great
presentation
very
short
and
to
the
point
I
just
wanted
as
a
member
of
all
five
s-bomb
groups,
as
well
as
the
skip
ietf
effort.
I
just
want
to
make
a
couple
comments.
There
I
think
Vex
is
making
very
quick
progress.
There's
a
couple
of
other
of
our
band
on
the
phone
here.
D
A
D
Thing
is
on
skit,
I
do
think
skits
a
little
further
out.
We
just
got
the
working
group
Charter
and
ietf.
There
are
a
number
of
other
supply
chain
systems
that
are
skit's,
gonna
have
to
model
I.
Think,
and
it
is
you
know
it's
very
promising
and
we're
very
excited
about
it.
Happy
Microsoft
is
is
leading
the
charge
there
as
Adrian
says,
and
that's
it's
all
I
think
very
positive.
D
I
will
also
say
that
there
are,
there
have
to
be
a
number
of
other
confidential
ways
of
sharing
s-bombs,
given
the
caution
of
suppliers,
in
particular
with
sharing
those
right,
so
skit's
not
going
to
be
ready
for
a
while
and
secure
document
sharing,
and
some
kind
of
clergy
manual
process
is
probably
what
we're
going
to
end
up
with
for
the
interim.
A
There
Adrian-
yes,
yes,
so
even
without
skit,
with
the
with
the
whole,
you
know
signed
receipts
and
and
immutable
Ledger
and
and
all
all
that
awesomeness
we
can
still
be
signing
our
s-bombs
to
protect
their
integrity
and
be
storing
them
in
in
oci
data
stores.
To
start
with
yep.
Absolutely
great!
Thank
you
for
the
afternoon,
thanks
yeah!
No
thank
you.
B
All
right,
I
tried
again
if
you're,
not
seeing
it
I
might
say
if
you
can
use
put
it
in
the
chat.
I
would
be
happy
to
give
you
a
dramatic
voice
over
in
whatever
way
that
you'd,
like
Chris,
you
had
a
question
and
I've
just
turned
on
your
microphone.
E
Which,
apparently,
has
worked
correct,
so
I
just
want
to
build
on
the
on
what
Charlie
said
you
know
and
again
thanks
Adrian
a
good
walk
through
and
to
Charlie
points
every
you
know
here.
What
we're
seeing
is
the
shapes
of
things
to
come.
You
know
and
whether
and
who
uses
skit
and,
for
example-
or
you
know
the
different
s-bomb
formats
and
so
forth,
but
I
find
reassuring
and
good
guidance.
Good,
good
guidance
out
of
all
this
is
that
we're
seeing
repeating
structures,
you
know
and,
and
the
you
know
what
I
like
about.
E
You
know
as
Charlie
says,
as
a
member
of
I,
think
all
five
of
the
Cesar
groups
and
the
skit
group
and
and
the
Tom
group
of
the
Devon
group
and
everything
you
know
it's
we're
getting
more
clarity
that
it's
not
about.
You
know
it's
not
about
what
we're
going
to
do
it's
about
how
we're
going
to
do
it.
You
know,
and
each
of
these
parts
what
I
like
about
skit
is
that
is
that
ability
we
all
need
the
ability
to
compare
policies
with
claims
with
evidence
and
a
lot
of
big
vendors
have
done
this
internally.
E
You
know
as
one-offs
and
each
of
them
like
Microsoft
and
like
like
Charlie's
company
like
like
you
know,
let
everybody
be
named.
We
all
know
who
we
are
are
coming
to
conclusion,
that
we
need
a
standardized
way
to
do
this,
so
we're
seeing
the
components
and
I
think
you
know
a
lot
of
these
things
do
go
forward.
I
think
skit
will
will
make
it,
but
it's
for
most
of
us
out
here
for
most
of
the
the
players
in
the
field.
It
doesn't
really
matter
what
the
acronyms
are.
C
B
A
Yeah
so
I
just
replied
to
him
in
chat.
We
have
the
I
guess
I'll
share
my
screen
one
more
time.
A
Just
one
example:
there's
there's
a
few
other
examples
that
exist
out
there:
I'm
just
not
knowledgeable
of
all
of
them,
but
PS
read
line
is
a
module
of
for
Powershell,
and
when
you
look
at
the
file
list,
you
can
see
that,
as
of
this
version
2.2.5
they
are
including
the
s-bomb
here
and
when
you
actually
install
this,
this
module
on
disk
this,
the
the
s-bomb
actually
is
there.
It's
present
in
a
in
a
directory
called
underscore
manifest,
and
so
so
some
teams
have
already
started,
including
this,
but
but
not
all.
A
There
are
other
to
to
give
shed
some
insight.
There
are
other
teams
like
like
Windows
that
that
their
s-bomb
is
extremely
large
and
they're
also
listing
dependencies
such
as
like
firmware
and
drivers
from
from
vendors,
and
each
of
these
vendors
has
certain
licensing
terms
and
agreements,
and
we
need
to
make
sure
that
we're
abiding
by
all
of
those
and
not
disclosing
to
something
that
we're
not
allowed
to
disclose
due
to
the
licensing
agreements.
So
they
are
working
through
a
a
way
that
we
can.
A
We
can
check
and
and
make
sure
that
that
their
very
large
s-bomb
is
is,
is
safe
for
sharing,
and
so
you
know,
kind
of
kind
of
calling
back
to
the
ntia
documents
of
you
know.
I
I
think
there's
some
teams
that
just
kind
of
need
to
get
comfortable
sharing
this
information.
A
You
know
we
we
certainly
don't
want
to
get
into
any
sort
of
legal
trouble
simply
by
putting
an
s-bomb
out
there.
So
so
we're
we're
doing
a
lot
of
our
due
diligence
up
front.
First
to
make
sure
we
have
processes
in
place
that
check
for
things
prior
to
just
releasing
them.
B
Adrian,
thank
you
for
that.
I
saw
that
Tom
had
a
follow-up
question
and
I
was
going
to
ask
if
that
could
be
answered
via
chat.
I
was
going
to
go
ahead
and
switch
over.
We
have
Isaac
Hepworth
from
Google
who's
joining
us
and
I
wanted
to
make
sure
that
we
preserved
enough
time
for
his
presentation,
so
Isaac
I
would
love
to
transition
the
microphone
to
you.
F
B
G
G
Okay,
I'm
gonna
try
a
slideshow
mode
one
more
time.
Is
this
still
bad
or
should
I
just
go
back
to
flipping
through
bit
by
bit.
F
We
will
flip
through,
like
this
easy
peasy,
so
that
was
a
great
presentation
from
Adrian
I'm,
hoping
that
this
will
be
somewhat
complementary
and
not
duplicative,
I
think
there's!
You
know
this
is
more
of
a
at
a
concept
level
and
takes
you
through.
You
know
how
Google's
been
thinking
about
about
s-bombs
and
Google's
been
internally
living
the
s-bomb
lifestyle
for
a
while,
but
short
of,
actually,
you
know
producing
spdx
documents.
So
what's
been
interesting,
is
this
this
journey
of
you
know
formalizing.
F
F
These
slides
reaches
you,
so
you
have
access
to
them
for
reference
and
so
on,
and
but
we're
going
to
talk
a
little
bit
about
you
know
what
s-bombs
are
and
you're
all
familiar
with
that
so
I'm
not
going
to
spend
so
much
time
talk
about.
You
know
their
importance
the
requirements
as
we
see
them
and
how
we've
developed
our
approach
to
those
requirements
and
then
some
nuances,
and
that
we've
seen
as
we've
been
on
this
journey
as
well.
F
So
obviously
you
know
this
is
familiar
to
all
of
you.
You
know
an
s-bomb,
you
know
from
scissor.gov
is
nested
inventory,
it's
a
list
of
ingredients
and
I
like
this
food
analogy
a
lot
this
has
got.
This
really
has
legs
when
you
think
about
ingredients
and
that's
bombing
ingredients,
you
can
think
of
you
know
salsa
provenance,
for
example,
being
the
recipe
for
those
ingredients.
F
You
know
to
Adrian's
point
about
build
time
and
versus
you
know,
SCA
type
tools
for
s-bomb
Generation.
You
can
think
of
that.
As
you
know,
hey
you
can
look
at.
You
know,
generating
a
list
of
ingredients
for
peanut
butter
by
going
for
the
peanut
butter
Factory,
watching
it
being
made.
Take
notes,
write
a
list
of
everything
you
see
going
into
the
pot
and
you
get
a
list
of
ingredients.
That's
build
time
as
a
bomb.
F
You
can
also
take
peanut
butter
off
the
shelf
and
put
it
through
a
mass
spectrometer
and
try
and
tease
out
what
you
think
is
inside
it,
and
that
would
be
you
know
some
kind
of
post-hoc
or
post
facto.
You
know
SCA
Type
S
bottom,
but
this
this
food
analysis,
energy,
I'll,
come
back
to
you
later
in
this
presentation
as
well,
but
I
really
like
it.
It's
helpful
for
conceptualizing
some
of
some
of
this
area.
F
We've
we
found
ntia.
Had
this
great
document
around,
you
know:
s-bomb
use
cases,
it's
a
2019
era
document,
but
you
know
it
provides.
You
know
a
great
view
in
these
three
categories:
producing
software
choosing
software
and
operating
software.
You
know
how
s-bombs
are
useful,
individual
use
cases
and
which
which
motivate
their
production
and
proliferation
and
so
on.
So
this
is
interesting
and
useful,
introductory
material
in
terms
of
Ys
bomb.
F
These
use
cases
are
all
very
instructive
in
terms
of
Ys
form
right
now,
as
we
all
know,
and
the
the
time
pressure
and
the
the
particular
currency
that
s-bomb
has
in
the
industry
today
and
comes
a
lot
from
the
executive
order
of
last
year,
and
then
you
know,
practitioners
and
implementers
and
have
been
have
moved
up
yet
another
gear
in
the
last
months
since
the
OMB
memo
and
came
and
made
some
timelines
around.
F
This
super
real
and
I've
been
developing
a
whole
bunch
of
new
friends
in
government
and
trying
to
understand
a
sea
of
acronyms
in
terms
of
the
number
of
groups
in
government
who
have
opinions
about
s-bombs
and
supply
chain
security,
and
this
morning,
as
I
was
flipping
through
these
slides
present
I'm
preparing
for
this
I
added
a
couple
more
to
this
slide
and
I
think
this
will
be
a
habit
of
mine
that
you
know
as
I
continue
on
this
journey
and
discover
new
teams
and
new
groups
and
new
agencies
and
new
parts
of
the
government
who
have
opinions
in
this
area.
F
Journey
for
me,
just
in
terms
of
how
the
government
operates,
which
of
these
opinions
coming
out
from
these
various
groups
are
normative
in
nature,
which
are
prescriptive,
which
are
descriptive,
which
are
guidance
versus
rule
making,
which
are
policy
versus
it's
a
it's
a
whole
lot
of
stuff
to
understand,
and
certainly
I've
had
my
struggles
with
that,
but
starting
thinking
about
the
executive
order-
and
you
know
what
do
we
do
to
to
think
about
you
know
conformance
with
you
know
the
executive
order.
F
I
started
off
with
this
first
draft
of
the
requirements,
it's
pretty
simple!
Well,
you
know:
hey,
we've
got
to
produce
s-bombs,
so
here's
my
requirement.
It's
simple
for
every
Google
product
we're
going
to
produce
an
s-bomb
in
identifying
the
component
dependencies,
and
you
start
with
that,
and
you
begin
to
kind
of
picket
and
prodded
it
a
little
and
before
long
you
land
on
well,
hang
on
what
does
this
mean
exactly?
How
should
I
think
about
an
s-bomb
and
what
is
it?
F
I
should
be
generating,
and
you
know
we've
certainly
had
teams
who
you
know
have
you
know
an
s-bomb
in
the
form
of
a
text
file
or
a
Google
sheet
listing
component
dependencies,
but
that's
not
quite
what
we're
talking
about
here
and
so
the
Department
of
Commerce
has
this
useful
report
the
minimum
elements
of
a
software
bit
of
materials.
F
It
specifies
I,
think
you
know,
Adrian
covered
this
as
well.
The
core
data
fields
which
are
required.
The
formats
in
which
we
should
you
know
create
RS
bombs.
Spdx
is
a
is
a
great
Target
for
us
and
then
I
really
liked
in
this
document
as
well.
F
This
the
recognition
that
as
we're
getting
started
on
this
journey
accommodation
of
mistakes,
is
an
important
part
of
this
from
an
overall
change
management
perspective,
we're
trying
to
Institute
an
entirely
new
set
of
practices
in
a
vast
industry
and
so
a
recognition
that
you
know
as
part
of
this
transformation
and
there's
going
to
be
a
need
to
be
a
certain
permissiveness
on
this.
F
On
the
behalf
of
software
producers
and
s-bomb
consumers
around,
you
know
good
faith
mistakes
and
you
know
identifying
known
unknowns
and
so
on
an
independency
chain,
and
so
I
I
point
to
this
on
that
slide,
because
I
thought
this
was
a
a
very
welcome
injection
of
pragmatism
into
this
as
a
change
management
exercise.
F
So
you
know
we're
going
to
clarify
this
s-bomb
here
we've
referred
to
this
ntia
report
and
so
our
requirement.
The
second
draft
now
looks
like
this,
so
it's
going
to
be
pretty
simple:
we're
going
to
take
each
Google
product
and
for
each
one
produce
an
s-bomb
in
line
with
these
minimum
requirements
identifying
component
dependencies,
and
you
stare
at
this
for
a
little
while-
and
you
realize
well
for
each
Google
product.
Really,
you
know.
Where
do
we
begin
which
one's
the
most
important
ones?
How
should
we
reason
about?
F
You
know
the
list
of
tens
of
thousands
of
Google
software
products
and
and
where
to
begin
there,
and
yet
again
you
know
we
we
find
that
there's
a
PDF
on
it
on
a
gov
somewhere
and
with
some
useful
guidance,
and
you
know
in
this
case
it's
nist.
They
have
a
definition
of
what,
if
what
is
critical
for
these
requirements,
and
so
you
know
we
chose
to
use
this
to
guide
our
prioritization
internally
and
so
as
we're.
F
You
know,
developing
an
MVP
S4
implementation,
Where
Do,
We
Begin
and
using
the
nist
guidance
to
produce
a
prioritized
list
of
first
party
on-premise
software
products,
So
Okay,
so
we've
got
our
third
draft
of
the
requirements
so
we're
now
talking
about
for
each
Google
product
in
scope
in
this
prioritized
list
produce
the
s-bomb
nti's
minimum
requirements
component
dependencies
and
we're
done
here
right.
F
F
My
goodness,
you
know
yes,
there's
the
the
question
about
transitive
dependencies
and
kind
of
you
know
following
down
that
chain
as
well,
but
there's
also
various
dependency
types,
just
taxonomically
as
well
that
runtime
dependencies
you
know
what
is
it
that
actually
ships
on
this
on
the
floppy
disk
right
with
the
software
bundle
dependencies
shared
dependencies
and
that's
one
type,
there's
also
build
dependencies.
F
You
know
it
would
be
reasonable
in
the
peanut
butter
analogy
to
identify
the
machines
that
were
a
part
of
the
you
know,
the
peanut
butter
production
of
the
factory,
because
I
want
to
know
if
one
of
them
has
a
defect
and
is
leaking
shards
of
metal
or
engine
oil
into
peanut
butter.
That's
a
useful
thing
to
know
about
the
peanut
butter.
I
get
off
the
shelf,
and
so
you
know
at
least
conceptually
and
build
dependencies
could
be
important
to
reasoning
about
the
software.
F
We
produce
tools
that
are
used
to
build
the
software,
any
defects
they
may
have
service
dependencies.
You
know
we
talked
about
chrome,
chrome,
you
know
you
download
it.
You
install,
it
runs
on
your
computer,
but
then
you
know
it
also
talks
to
Google
services.
It
syncs
its
passwords,
it
syncs
bookmarks,
there's
a
sign-in
feature
in
Chrome,
it's
identity
aware,
so
it
has
design
dependencies
on
cloud
services
platform
dependencies
as
well,
though
we're
going
to
go
down
and
look
at
you
know
what
platform
is
this
thing
running
on?
F
You
know
what
parts
that
platform
are
we
shipping
with
the
software
or
not
or
depending
on,
and
then
configuration
is
another
relevant
dependency
type
to
think
about
and
before
you
long
you,
okay,
we're
gonna,
pick
one
and
go
with
that
for
now
and
and
so
bundled
runtime
dependencies,
including
transitive,
one
seems
like
a
reasonable
place
to
start
for
shipping
software,
one
of
the
bits
and
bytes
you're
shipping
on
the
floppy
disk.
Tell
me
about
those.
Let's
start
there
and
we
can.
F
You
know
we
can
reason
onwards
from
there
as
need
be
so
we're
done
right.
We've
got
our
fourth
draft
of
the
requirements:
okay,
let's
ship
it
and
get
this
done
well,
we've
got
some
more
work
to
do
because
when
it
comes
to
identifying
these
bundled
runtime
dependencies,
there's
more
work
to
do
and
identifying
software
components
is
a
problem
of
its
own.
F
F
You
know
the
CPS
they're
slids,
there's
pearls,
there's,
there's
a
number
of
different
ways
that
you
could
identify
uniquely
a
given
software
components,
and
so
we
need
to
get
a
pretty
specific
about
how
actually
we're
going
to
do
that
and
looking
at
you
know
this
is
a
an
external
deck.
So
I
have
some
redactions
in
it,
but
you
know
we
have
Google's
monoreepo.
F
Thousands
of
you
know
vended
open
those
dependencies
in
Google's,
mono
repo,
and
we
need
to
make
sure
for
every
one
that's
dependent
on
for
shipping
software.
We
have
a
way
to
unambiguously
identify
it
in
a
useful
way
and,
ideally
that
identifier
would
actually
key
into
things
like
osv
or
mvnd
or
CVS,
and
so,
when
vulnerabilities
appear,
the
you
know,
the
software
that's
identified
in
the
vulnerability.
F
I
can
then
use
that
as
a
lookup
into
my
s-bomb,
and
so
ideally,
I'd
use
some
identification
namespace
which
allows
for
that,
and
so
you
know,
the
the
next
version
of
the
requirements
becomes.
Okay,
we're
going
to
make
sure
we
identify
using
unambiguous
external
identifiers
these
dependencies
and
we're
going
to
add
this
on
the
end
here
to
make
it
clear
that
our
aim
here
is
to
make
vulnerability
management
easier
for
customers.
That's
going
to
be
our
Focus
here,
and
so
that's
going
to
inform
our
choice
of
identifier.
F
So
this
nth
draft
of
the
requirements
and
we've
gone
through
a
number
of
iterations
now-
and
you
know
this
made
it
almost
verbatim
into
you-
know
that
the
normative
document
we
have
internally
around
how
we're
going
to
approach
s-bombs
from
an
MVP
perspective
that
you
know
compliance
we're
going
to
look
at
software
processing
scope,
we're
going
to
hit.
F
So
that's
what
I
need
to
recognize.
That's
a
Whistle
Stop
tour
of
getting
us
to
this
point.
There
are
a
few
more
things
which
which
are
worthwhile
interesting
to
talk
about
and
again
can
consultation
with
internal
teams.
This
first
one
Optics,
you
have
people
going.
Oh,
my
goodness,
you
know
this
is
sharing
our
proprietary
data
about
how
we
make
our
software
and
what
are
people
going
to
say
if
they,
if
they
see
what
you
know,
the
ingredients
are
and
again
the
food
analogy
is
instructive
and
I've
been.
F
You
know,
doing
some
research
and
pulling
on
this
thread
too,
and
looking
at
you
know
when
the
FDA
introduced
in
you
know,
1938
there
was
the
food,
drug
and
cosmetics
act
which
started
to
mandate.
You
know
Food
suppliers
to
put
ingredients
labels
on
their
products
and
seeing
the
food
industry
reaction
to
that
there
was.
There
was
a
certain
set
of
analogies
there
as
well
about
well.
This
is
proprietary
and
gosh.
F
What
would
people
say
if
they
knew
that
we're
putting
bitumen
in
their
peanut
butter
or
whatever
it
may
be,
and
there's
a
similar
set
of
considerations
about?
How
is
is
this
gonna
look
and
what
you
know
how
comfortable
am
I
sharing
the
ingredients
of
my
you
know:
butter,
slash
software,
it's
an
interesting
consideration.
My
opinion
is
that
you
know
in
the
same
way
that
you
know
any
packaged
food.
You
pick
off
the
grocery
store
shelf
today
has
an
ingredients
list
on
it
and
it's
unremarkable
and
it's
commonplace
and
I.
F
Think
public
s-bombs
for
software
are
going
to
become
unremarkable
and
commonplace
I'm
in
the
next
five
to
ten
years,
and
these
concerns
are
going
to
melt
away
in
a
similar
way.
Supportability
is
an
interesting
aspect,
and
you
know
just
from
the
perspective
of
if
we
tell
people
what's
in
the
software,
we're
going
to
get
a
lot
of
questions
about
it
and
we
need
to
make
sure
we're
ready
to
handle
those
questions
and
with
staff
to
do
it
and
we
can
handle
the
inbound
and
it's
not
a
bad
thing.
F
We
want
to
be
responsive,
but
it's
certainly
a
factor
that
the
more
information
you
provide
out
there
and
the
more
you
should
expect
to
get
asked
about
it.
Distribution,
I'm
not
going
to
talk
about
too
much
Adrian
talked
about
this
I'd
say
it's
generally
an
unsolved
problem.
You
know,
skit
is
a
super
interesting
I'm,
certainly
tracking
that
you
know
the
open
ssf
has
sing
store
and
which
you
know
you
squint,
and
it
looks
a
little
bit
like
skit.
F
It's
certainly
from
a
from
a
trust
and
you
know
an
Integrity
perspective,
and
these
are
interesting,
and
these
are
interesting
Solutions.
Just
to
give
you
a
data
point
on
on
distribution
of
S1
Summit,
some
s-bombs,
maybe
hundreds
of
megabytes
in
size-
these
these
are
not
kind
of
hey
I.
Can
you
know
print
this
out
and
put
it
in
my
wallet
type
documents?
F
These
can
be
enormous
documents,
and
so
thinking
about
you
know
developing
Central
stores
and
you're
thinking
in
terms
of
massive
scale,
but
I
dare
say
it's
not
a
very
well
solved
problem,
and
then
we
have
this
mythical
creature
down
at
the
bottom
here:
the
SAS
bomb
where
gosh?
What
does
this
even
mean?
If
I
look
at,
you
know
docs.google.com
and
you
know
I'm
presenting
from
docs.google.com
at
the
moment
as
a
product?
What
does
the
s-bomb
look
like
for
this
thing?
You
know
Does.
It
include
all
of
the
dependencies
we
have
on.
F
You
know
Google's
identity
system
Does.
It
include
dependencies
on
you
know
the
the
back
end
storage
for
storing
these
documents.
Does.
It
include
the
the
front-end
systems,
which
is
between
your
browser
and
our
internal
Services
Does.
It
include
our
geodns,
which
your
browser
uses
to
locate
those
so
Services
the
explosion
and
scope
that
you
have
when
you're
thinking
about
you
know
s-bombs
for
hosted.
Software
is
massive
and
again
I
pointed
this.
F
As
kind
of
you
know
this
shadow
of
a
Yeti,
because
and
in
the
southbourne
there's
this
kind
of
mythical
creature,
no
one's
really
defined
it
terribly
well,
and
you
know,
there's
also,
you
know,
concerns
around
what
risk
you're
introducing.
Are
you
as
Microsoft
as
Google?
As
you
know,
a
software
you
know
as
a
SAS
provider,
are
you
providing
a
road
map
to
attackers
by
sharing?
You
know
the
contents
of
your
SAS
software
so.
G
F
Obviously,
this
is
a
work
in
progress,
but
it's
it's
something
which
today
I
consider
largely
I,
don't
have
any
satisfactory
answers
from
anyone
on
what
SAS
bombs
should
look
like
just
quickly
on
future,
and
this
touches
on
something
which
came
up
in
the
Q,
a
I
think
overall,
from
a
vision,
perspective,
I'm.
Looking
at
you
know
this
stack
here
where
you
know
having
a
foundation
of
trust,
whether
this
be
skit
or
Sig
store.
F
But
a
way
of
you
know
having
strong
identities
sign
you
know,
have
signing
capabilities,
Federation
of
this
store
and
flexible
ways
to
Anchor
Trust.
On
top
of
that
Foundation,
you
can
then
begin
to
reason
about
sets
of
attestations
and
metadata
about
software.
On
top
of
that
trust
foundation,
so
s-bomb
is
one
salsa
provenance
is
another
osv
and
Vex
is
another
openss
scorecards
is
another,
but
you
know
we're
developing
as
an
industry,
a
veritable
sea
of
metadata
about
software,
and
you
know
to
the
extent
that
we
can.
F
You
know
at
least
kind
of
you
know,
make
this
this.
This
data,
high
integrity,
High
signal
and
High
Fidelity
and
trusted.
That's
great.
We're
then,
faced
with
the
problem
of
how
do
we
begin
to
Aggregate
and
reason
about
this
data
as
a
whole.
I
would
like
to
be
able
to
join
s-bombs
to
osv
and
Vex
statements.
F
Where
do
you
begin
and
so
and
then
at
the
top,
you
know
how
do
you
turn
the
meaning
from
this
data
into
actual
value,
to
derive
policy
risk
and
compliance
governance,
and
so
on,
I
I'm
out
of
time?
I
could
talk
about
this.
This
topic
forever
I'm,
gonna,
I'm
gonna,
so
I'm
glad
that
I'm
constrained
by
the
clock
here.
So
with
that
I'm
going
to
wrap
up
just
a
quick
recap
talked
a
little
bit
about
what
s-bombs
are.
F
B
F
Oh,
my
goodness,
I
can't
even
see
the
chat
so
I
give
myself
some
props
for
even
managing
to
do
that.
B
Fair
enough
that
that
has
happened,
I'm
going
to
put
an
email
out
in
the
chat,
if
you
have
additional
questions
that
you
weren't
able
to
get
answered
today,
I'd
be
glad
to
forward
them
to
our
presenters
on
behalf
of
the
group
and
send
answers
back.
Of
course,
everybody
in
the
group
would
love
your
slides.
If
that
is
possible,.
B
Set
and
I'll
alert
the
team
for
when
that's
ready,
because
I
don't
know
about
you,
but
I've
got
several
co-workers
that
I'd
like
to
have
tune
into
this
and
get
that
insight
as
well
so
Adrian
Isaac.
Thank
you
very
much
to
for
coming
and
talking
with
us.
We
really
appreciate
understanding
what
you're
doing
and
starting
to
plan
not
only
for
what
we
do
with
s-bombs
right
now,
but
to
understand
where
things
are
headed
in
the
future.