►
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
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
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
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
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
A
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
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
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
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
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.
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.
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
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
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
A
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.
B
G
G
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
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
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
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
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
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
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
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.