►
Description
Presented by: Courtney Claessens
Seems like every security team is talking about Software Bills of Materials (SBOMs) lately. SBOMs create an inventory of your software components and are a new requirement for many organizations. Beyond checking a compliance box, though, they provide data that helps to assess, minimize, and remediate your software’s risk. This session gives an overview of SBOMs and how they can be used in your security practice for your GitHub projects, so you can more confidently consume open source.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
Hi
I'm
Courtney
a
product
manager
at
GitHub,
working
on
the
dependency
graph.
Our
goal
is
to
give
you
the
dependency
data.
You
need
to
help.
Keep
your
software
secure
today,
we're
going
to
be
talking
about
software,
builds
of
materials
or
s-bombs
which
create
an
inventory
of
your
software
components.
A
This
inventory
can
help
you
with
making
decisions
around
your
software
security
and
risk
we're
going
to
do
a
quick
dive
into
what
s-bombs
are
and
why
people
are
using
them
and
then
look
at
how
we
can
shift
the
idea
of
s-bombs
from
being
a
regulatory
chore
that
some
people
have
to
making
them
an
integrated
part
of
your
security
practice
that
helps
you
consume
open
source
software
with
confidence.
The
widespread
use
of
Open
Source
packages
is
pretty
much
the
biggest
change
in
how
we've
built
software
that
we've
seen
in
decades.
A
78
of
code
written
in
commercial
code
bases
use,
is
external
components
and,
since
those
components
rely
on
other
components,
you
can
have
a
fairly
small
project
that
has
a
pretty
lengthy
supply
chain
and,
if
you're,
relying
on
a
package
that
is
itself
relying
on
a
package
that
has
a
vulnerability.
Your
entire
project
can
be
vulnerable
and
this
typically
isn't
good,
so
enter
supply
chain
security.
How
do
we
secure
the
components
and
practices
involved
in
creating
and
deploying
software?
A
We
want
to
avoid
supply
chain
compromises
brought
on
by
Upstream
vulnerabilities
and
protect
against
the
risk
of
supply
chain
attacks
and
s-bombs
can
play
a
key
role
in
this
process.
Software
bills
and
materials
are
an
inventory
of
everything
that
your
software
uses.
It's
your
supply
chain
summed
up
in
a
specific
machine,
readable
format.
A
They
become
more
popular
recently
since
there
have
been
some
regulatory
requirements
from
different
governments
saying
that
you
should
have
them
and
as
an
industry,
though
we're
still
in
the
early
days
of
s-bomb
generation
in
usage,
so
we
can
anticipate
a
lot
of
maturity
to
come
in
this
area,
but
there
are
some
defined
components
that
are
included
across
s-bombs.
Today,
your
s-bomb
is
a
file
that
includes
information
on
your
dependencies.
It's
like
Asset,
Management
tracking,
what
we're
using
in
a
fact,
Gathering
manner.
A
It
holds
dependency
versions
and
relationships
to
each
other,
they're
licensed
data,
and,
more
typically
in
XML
or
Json.
These
should
get
updated
with
each
code
change.
So
you
always
have
an
accurate
account
of
your
dependencies,
so
even
in
this
pretty
nascent
stage,
they
can
still
be
foundational
for
bringing
transparency
into
your
project
in
a
standardized
way,
both
for
you
and
for
the
people
that
use
your
software,
and
this
can
help
build
trust
with
your
users
too,
but
until
you
do
anything
with
them,
they're
just
files.
A
The
utility
of
the
data
is
here,
though,
regardless
of
what
format
it's
in
so
here
we
can
start
to
think
about
the
difference
between
producing
s-bombs
in
a
specific
format,
because
we
need
to
and
consuming
them
to
get
some
insights
from
the
data
that
they
house
at
their
core.
S-Bombs
give
us
transparency
into
our
projects,
and
then
we
can
make
some
decisions
around
what
we're
using.
A
If
you
need
to
adhere
to
certain
license
policies
or
you
don't
want
to
be
using
dependencies
that
are
deprecated
and
so
on,
but
most
interestingly,
maybe,
is
that
this
info
lets
us
answer
questions
in
the
wake
of
a
security
event
like
am
I
affected
by
this
vulnerability
and,
more
importantly,
where
am
I
affected
by
this
vulnerability,
and
this
leads
you
to
identifying
how
risky
that
particular
vulnerability
is
and
how
to
prioritize
it.
S.
Bonds
are
not
a
security
Panacea
by
any
means,
but
they
can
be
a
foundational
layer
where
further
security
practices
can
be
built.
A
They
don't
always
contain
vulnerability
data,
but
when
we
take
an
s-bomb
and
couple
the
dependency
data
with
up-to-date
actionable
vulnerability
data,
we
can
turn
s-bombs
into
more
than
the
sum
of
their
parts.
We
don't
want
to
add
a
ton
of
extra
work
for
people.
We
just
want
to
get
the
advantages
of
s-bombs
in
the
easiest
way
we
can
with
GitHub.
We
can
incorporate
both
their
production
and
consumption
into
some
existing
processes
and
tools
to
bring
the
information
to
where
you're
working
with
a
medley
of
GitHub
actions,
the
dependency
graph,
the
advisory
database
and
dependabot.
A
We
can
generate
s-bombs
and
put
them
to
use
in
your
security
practice.
Your
comprehensive
list
of
dependencies
is
matched
with
a
comprehensive
advisory
database.
Github
is
the
second
largest
cve
numbering
Authority,
and
you
can
receive
alerts
on
any
known
vulnerabilities
that
may
be
lurking
in
your
software.
The
key
part
of
this
workflow
is
the
dependency
graphs
dependency
submission
API.
A
We
talked
earlier
about
how
the
dependency
graph
gives
you
pretty
much
the
same
data
that
s-bombs
do,
but
by
default
the
dependency
graph
can
only
do
this
comprehensively
for
certain
ecosystems,
ones
that
have
manifest
files
that
contain
all
the
projects,
dependencies
that
are
simple
to
parse
for
ecosystems,
where
it's
difficult
to
detect
all
the
dependencies
like
when
they're
resolved.
At
build
time,
we
have
the
submission
API,
a
route
for
you
to
upload
dependencies
for
any
ecosystem
or
upload
s-bombs
and
then
they're
in
your
supply
chain,
security,
workflow
and
you're
Off
to
the
Races.
A
So,
while
those
steps
may
seem
like
a
lot
of
work,
but
it's
mostly
aesthetic
and
forget
it
operation,
so
let's
see
what
it
looks
like.
So
here
we
have
a
fairly
simple
Maven
repository
Maven
uses
a
pomxml
to
list
the
Project's
dependencies,
but
these
don't
include
transitive
dependencies.
So
it's
easy
to
miss
things
like
log4j,
when
they're
being
pulled
into
your
application,
we
can
use
an
s-bomb
tool
to
catch
everything
inside
this
repo
and
then
upload
it
to
the
repositories
dependency
graph
and
we
can
start
with
GitHub
actions.
A
So
I
have
this
workflow
file
that
generates
and
updates
an
s-bomb.
This
uses
encore's
sift
tool
for
generating
software
bill
of
materials
from
container
images
and
file
systems
down
here
we're
building
the
project
with
Maven,
which
is
the
basis
for
the
s-bomb
and
gives
us
an
accurate
view
of
what
dependencies
are
actually
being
included
when
the
project
is
built,
build
time,
detection
of
dependencies
we're
using
ancor's
s-bomb
action,
which
leverages
sift
to
produce
an
s-bomb
in
the
spdx
format.
A
It'll
use
the
jar
file
from
the
build
and
then
behind
the
scenes
is
transposing
the
spdx
format
into
the
snapshot
format.
We
need
for
the
dependency
submission
API
and
then
it's
uploading
that
s-bomb
to
the
dependency
graph
note
that
this
workflow
happens
on
push
so
we're
always
getting
the
latest
representation
of
the
repository.
So
this
all
happens
relatively
quickly.
Once
we
set
up
the
workflow
file,
we're
good
to
go,
let's
go
to
the
dependency
graph
and
see
how
we're
consuming
this
s-bomb.
A
We
can
see
the
dependencies
defined
in
the
pom
XML
that
dependency
graph
scans
automatically,
and
we
have
detected
one
vulnerability
when
we
scroll
down.
We
can
see
the
dependencies
that
are
pulled
out
of
that
s-bomb.
These
are
the
dependencies
associated
with
the
jar
file
and
they
look
a
bit
different
from
the
default
scan
of
the
Palm
XML.
A
It's
a
more
accurate
view
with
build
time,
detection
and
since
dependabot
kicks
in
automatically
once
we've
uploaded
the
s-bomb,
we
see
a
few
more
vulnerable
dependencies
that
didn't
pop
up
before
we
link
dependencies
back
to
their
GitHub
repositories.
So
beyond
vulnerabilities,
we
can
access
more
information
about
them.
That's
interesting
for
us
to
know.
A
We
can
see
the
number
of
stars
and
forks
of
the
dependency
when
it
was
last
updated
and
such
which
is
helpful
to
detect
if
we're
using
something,
that's
typo,
squatting
or
has
been
deprecated
and
gives
us
more
fodder
for
making
decisions
on
how
we
can
manage
our
dependencies.
So
that's
the
s-bomb
consumption
side,
let's
pop
over
back
to
the
production
side
and
take
a
look
at
the
workflow
artifacts,
we
can
access
the
s-bomb
that
was
created
in
our
workflow
Run,
download
it
and
take
a
peek
inside
to
see
what
an
sbomb
file
actually
looks
like.
A
So
we
have
some
information
on
the
supplier
name,
anchor
information
on
our
packages,
their
name,
some
external
identifiers
like
pearls
and
the
version
number
again.
You
know
it's
a
Json
file,
not
necessarily
the
most
interesting
thing
for
humans,
but
when
we
embed
it
within
our
existing
security
processes,
we
end
up
getting
more
information
like
these
dependabot
alerts
in
a
familiar
way.
So
the
key
here
is
that
files
by
themselves
don't
really
mean
a
whole
lot.
A
It's
how
we
use
them
that
makes
them
have
any
utility
and
when
we
make
them
easy
to
generate,
explore
and
plug
them
into
existing
vulnerability
management
processes,
they
can
help
drive
better,
more
reliable
security
outcomes.
Some
things
to
leave
you
with.
We
showed
one
action
that
submits
s-bombs
to
the
dependency
graph,
but
there
are
other
actions
for
you
to
explore
both
for
generating
and
submitting
s-bombs
and
for
submitting
dependencies
for
other
ecosystems
that
are
not
supported
out
of
the
box.