►
From YouTube: Repurposed Purpose: Using git's DAG for Supply Chain Artifact Resolution - Ed Warnicke, Cisco
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Repurposed Purpose: Using git's DAG for Supply Chain Artifact Resolution - Ed Warnicke, Cisco
What if we could know the complete and reproducible artifact tree for every binary, shared object, container, etc (including all dependencies) and you could efficiently cross-reference that against a database of known vulnerabilities before you deploy? If you had had that information, could you have remediated Log4Shell faster? Might it even help open source maintainers identify at-risk dependencies sooner? In this talk, Aeva and Ed will share why they're so excited about GitBOM and explain what it is (hint: it's not git and it's not an SBOM). If the demo gods are willing, they will show you how you can generate a GitBOM with a simple command-line tool, and explain why you won't have to. Finally, if you want to add support for GitBOM to your favorite tool or language, this talk will give you enough information to get started.
A
So
welcome
all
of
you
before
we
get
going.
There
are
a
few
things
I
just
want
to
lay
out
for
all
of
you.
So,
first
of
all,
I
like
a
very
interactive
audience,
so
there's
a
question
that
occurs
to
you
in
the
course
of
the
conversation
in
the
course.
The
talk
ask
it
immediately,
because
if
you're
wondering
about
it,
there
are
other
people
in
the
room
who
are
going
to
be
wondering
about
it.
So
the
second
thing
is-
and
this
is
part
of
being
interactive
with
the
audience.
A
I
also
am
going
to
ask
you
questions
through
the
course
of
the
talk
now.
Most
of
these
could
just
be
raise
your
hand,
kind
of
questions
to
get
a
feel
for
what
your
experience
is
like.
So
I
can
tailor
what
I
say,
but
like
an
even
scientist,
the
very
first
thing
we're
going
to
do
is
calibrate,
so
how
many
of
you
can
raise
your
hands?
A
That's
actually
a
really
good
percentage,
I'm
generally
speaking,
excellent
cool.
So
diving
right
in
how
many
of
you
remember
the
colonial
pipeline
hack
about
you
know.
Last
year
may
time
frame.
You
know
expensive
gas
on
the
east
coast,
so
this
was
a
cyber
attack
and
it
turned
out
that,
as
a
result
of
this
obama,
administration
issued
a
cyber
security
executive
order,
which
was
remarkably
well
written.
A
I'm
the
kind
of
geek
who
reads:
executive
orders
recreationally
over
the
course
of
decades,
and
it's
really
unusual
to
read
one
on
that
touches
on
a
technical
matter
that
actually
gets
so
much
right
and
one
of
the
things
that
came
up
in
that
cyber
security
executive
order
was
software
bills
of
material
s-bombs.
In
other
words,
what
is
actually
in
the
software
you're
running
now?
This
was
in
may
of
2021.
A
A
They're
now
iso
standard
for
expressing
software
bills
of
material,
but
this
is
where
I
found
myself
in
2008.,
so
in
the
mid-2000s
landed
on
my
lap
at
cisco,
where
we
were
shipping
tens
of
thousands
of
software
releases
a
year
and
we
needed
to
be
able
to
know
precisely
what
was
in
them
for
a
variety
of
reasons.
The
first
reason
was
for
open
source
license
compliance,
but
our
third-party
security
people
rapidly
realized
that
knowing
what's
in
your
software,
is
the
key
to
doing
modern
securities.
A
So
as
with
anything
else,
when
you
do
it
early-
and
this
is
certainly
the
case
when
I
was
building
out
s
bombs
at
an
industrial
scale-
at
cisco
mistakes
were
made
you're
trying
something
for
the
first
time.
You
don't
actually
understand
all
the
wrong
answers,
so
you
try
a
bunch
of
things
that
look
plausible,
but
the
flip
side
of
making
mistakes
early
on
is
you
learn
a
ton
about
the
problem
space.
A
A
And
so
I
gave
this
talk
literally.
If
you
look
at
the
timeline
may
6th,
the
colonial
pipeline
hack
happens,
may
12th
the
cyber
security
executive
order
lands
about
two
weeks
later.
I
give
this
talk
to
the
ntia
and
a
bunch
of
the
folks
getting
together
describing
what
has
become
known
as
git
bomb,
which
is
one
of
those
crazier
ideas,
and
we
will
go
into
great
detail
on
here
shortly,
this
sort
of
percolated.
In
the
background
over
the
summer
and
the
fall
until
in
february,
2000
2022,
we
publicly
launched
the
get
bomb
community.
A
A
So,
but
the
real
story
here
is
actually
how
you
think
about
this
process.
So
when
I
came
back
into
the
s-bomb
world,
you
sort
of
start-
and
you
think
you
look
around
and
you
try
and
figure
out
what's
going
on
with
supply
chain
security,
and
this
is
actually
what
it
looks
like
the
first
time
you
look
at
it
from
the
outside,
and
please
note
I
had
a
lot
of
experience
in
this
area.
This
is
still
what
it
looks
like
now.
A
This
is
not
meant
to
disparage
the
really
cool
things
that
are
happening,
because
you
do
have
really
interesting
things
happening
like
in
toto
that
is
collecting
attestations
from
everyone
along
a
chain
of
what
they
did
in
the
process
of
producing
your
software
or
the
spdx
process
that
it
continued
to
mature
or
some
of
the
signing
things
that
are
going
on.
All
of
these
are
good
things,
but
it's
also
kind
of
a
lot.
A
A
A
A
And
one
of
the
other
things
that
I
had
learned
over
the
years
is
often
you
can
make
systems
more
complicated
by
just
how
you
look
at
them.
So
real
simple
example.
We
can
all
sort
of
take
back
to
our
school
days.
If
I've
got
a
bunch
of
items
along
the
line,
I
can
specify
all
the
items
along
that
line
with
two
coordinates
right,
so
the
complexity
of
my
system
is
two
variables,
but
that's
not
actually
what's
going
on
here.
A
If
you
tilt
your
head
to
one
side
a
little
bit,
you
can
discover
you're,
actually
only
dealing
with
one
line,
you're
dealing
with
one
variable,
and
so
what
we're
going
to
talk
about
here
today
with
git
bomb,
is
a
little
bit
of
that
head,
tilting
towards
a
simpler
way
of
looking
at
a
corner
of
the
world.
In
the
effort
to
make
this
all
more
tractable.
A
A
A
So
drilling
into
the
first
question
identity.
What
is
this
software
artifact?
So
we
should
probably
first
talk
about
what
we
mean
by
a
software
artifact.
It's
basically
any
software
object
of
interest.
It
could
be
source
code
of
any
language
right.
So
a
c
file,
an
h
file,
a
java
file,
a
python
file,
a
go
file,
a
rust
file.
Any
of
those
are
software
artifacts.
A
It
could
also
be
further
up
the
chain
of
production.
Maybe
it's
object
files
that
got
compiled
by
somebody
into
an
sdk
where
they're
not
giving
you
the
source
code
files
that
give
you
the
object
files
in
my
world
doing
embedded
development.
This
happens
all
the
time
from
chipset
vendors,
it's
very
common.
A
It
could
be
class
files
in
java
the
result
of
compiling
your
java
to
java
bytecode.
It
could
be
jar
files
that
aggregate
them
together.
It
could
be
compiled
python
code.
It
could
be
an
executable
of
any
sort
on
any
of
the
systems.
You
might
be
running
on
windows,
linux
mac,
it
could
be
a
deb
or
rpm
package
or
it
could
be
a
docker
image.
A
So
the
first
observation
we
make
is
there's
a
lot
of
ways
to
talk
about
artifacts
being
equivalent
right.
If
I
have
two
simple
python
scripts,
then
I
change
the
variable
name
in
one
of
them
and
not
the
other
in
some
sense,
they're
equivalent.
They
do
the
same
work,
but
that
kind
of
equivalency
is
very
localized
to
the
language
and
environment
you're
working
in
and
so
in
gitbang
we
adopted
the
world's
simplest
notion
of
equivalency.
A
Now.
The
first
question
you
might
ask
is:
what
would
we
like
to
be
true
about
identifiers
right?
My
first
name
is
ed.
It's
a
terrible
identifier,
it's
great
for
conversation.
There
are
a
lot
of
ed's
in
the
world,
so
it
turns
out
what
we
actually
wanted.
Identifiers
for
artifacts
is
we'd
like
them
to
be
canonical.
A
Independent
parties
who
have
exactly
the
same
artifact
should
be
able
to
derive
the
same
id.
If
I
have
a
docker
container,
you
have
the
same
docker
container.
We
should
have
the
same
id.
If
I
have
an
executable
that
was
compiled
from
c,
you
have
exactly
the
same
bytes.
We
should
have
the
same
identifier.
A
The
second
is
uniqueness.
Non-Equivalent
artifacts
should
have
distinct
ids,
that's
back
to
the
problem
with
ed
as
an
identifier.
It's
not
unique.
Many
people
are
named
dead
and
then
the
last
thing
you'd
like
it
to
be
is
immutable.
You
don't
want
it
to
be
the
case
that
identifiers
change
over
time
if
I've
got
a
set
of
artifacts.
A
So
it
turns
out
there's
a
large
number
of
non-solutions
to
this
problem
that
have
been
explored.
I
will
mention
a
few
of
them.
This
is
not
an
exhaustive
list
right,
so
the
first
one
is
file
name.
We
all
use
file
names
every
day,
they're
a
fantastic
way
to
find
things.
They
locate
things
in
your
file
system,
but
they
actually
don't
tell
you
anything
about
the
identity
of
the
thing
they
are
non-canonical.
A
You're
right,
I
make
name
the
file
foo.c
with
a
path
in
my
home
directory
or
someone
else
may
name
it
as
a
path
in
their
home
directory.
I
can
change
the
file
under
the
same
name
and
it
retains
the
same
file
name.
It's
not
immutable.
It's
also
not
unique
on
different
systems.
I
can
have
the
same
file
name
with
entirely
different
contents.
A
A
A
A
A
All
right,
we'll
keep
going
so
the
good
news
with
that
identity
is.
This
is
already
completely
solved
by
git
right.
Git
has
already
solved
the
problem
of
identity
for
for
arrays
of
bytes
for
source
code
files,
so
git
computes
an
object
id
for
the
contents
of
every
file
that
it
stores
in
a
git
repository.
A
It
takes
the
contents,
not
the
file
name,
not
the
location.
The
actual
array
of
bytes
stick,
you
know
kicks
out
a
20,
byte
hash
and
most
of
the
source
code
files
that
you
care
about
in
the
world
today
are
already
being
indexed
by
git
in
a
repository
somewhere.
So
we've
already
indexed
the
vast
majority
of
the
most
interesting
artifacts
in
the
system.
A
A
Now,
a
miracle
tree
is
very
simple:
it's
a
tree
where
every
leaf
node
is
labeled
with
a
cryptographic
hash
of
its
data
block,
so
every
file
has
an
id
and
every
non-leaf
node
everything
that
relates
things
together.
Something
like
a
directory
tree
is
labeled
with
the
cryptographic
hashes
of
the
labels
of
its
child
nets.
A
A
A
A
So
it
turns
out
when
you
start
thinking
about
this,
you
realize
that
it's
not
just
for
static
things
that
live
on
just
like
the
executable.
You
can
also
do
this
for
running
executables,
where
you
can
have
your
graph
contain,
not
only
the
executable
and
all
the
stuff
that
went
into
it,
but
any
shared
objects
that
you
linked
dynamically
at
runtime
and
all
the
things
that
went
into
them
and,
of
course,
this
also
works
for
java
java
class
files.
It
works
for
go
it
works
for
python.
It
works
for
basically
every
length
it
works
for
rust.
A
A
And
then
use
the
get
object
ids
as
the
identifiers
for
each
of
those
artifacts
in
the
tree.
Now
this
is
super
easy
because
on
the
bottom,
they're
already
being
stored
in
get,
but
it
turns
out,
you
can
compute
easily
the
get
object,
idea
of
a
thing
without
storing
it
in
get
it's
literally.
A
simple
hash
function
so
very
easy,
but
implemented
literally
thousands
of
times
in
the
ecosystem.
Already.
A
A
You
have
a
very
straightforward,
simple
document
format
that
we
all
agree
on
that
says:
okay,
if
I'm
something
like
artifact
2,
that
only
has
leaf
artifacts
as
children,
I'll
just
have
new
line,
terminated
records
that
say
blob
space,
the
get
object,
id
of
artifact
four
blob
space,
the
get
object,
id
of
artifact
five
and
we'll
put
all
of
that
in
lexical
order.
So
we
all
get
the
same
one
every
time
independently
and
we'll
call
this
the
get
bomb
dock
for
artifact
2..
A
Now
artifact
1
is
interesting
because
in
artifact
one-
and
this
is
where
we
get
into
the
merkle
treeness
of
it
all-
it
contains
artifact
two
and
artifact
three.
They
were
built
into
it
like
the
dot
o
files
coming
up
into
an
executable,
and
for
that
you
start
the
same
way:
blob
space
and
the
representation
of
the
artifact.
A
A
In
fact,
spdx
has
done
a
killer
job
of
this
so
far,
but
they're
describing
a
ton
of
information.
They
include
information
about
human,
understandable
names.
They
include
information
about
who
gave
it
to
you.
They
include
information
about
when
it
was
built.
Sometimes
there's
a
huge
amount
of
metadata
that
they
include,
all
of
which
is
interesting
and
important,
but
it's
complicated
and
so
get
bomb
takes
the
attitude
of
saying
look,
look,
look.
A
A
And
of
course,
then,
this
breaks
down
if
you're,
just
thinking
about
get
bombs
and
s-bombs
gitbum
just
constructs
the
artifact
tree
and
you
can
use
whatever
s-bomb-shaped
thing
makes
you
happy.
Plus
you
can
store
other
kinds
of
metadata.
Maybe
you
want
to
use
something
that
involves
in
toto
to
capture
cryptographic,
verification
of
who
built
it
or
who
tested
it
or
who
deployed
it.
All
of
that
can
refer
to
the
same
tree
by
using
the
get
object,
ids.
A
A
Can
you
trust
this
knowledge,
so
how
many
of
you
thought
signatures
when
I
was
saying
trust,
we've
all
been
so
good.
Very
few
we've
all
been
conditioned
to
think
about
secure
signatures
in
terms
of
trust
and
security,
so
signatures
are
fantastic,
but
all
they
really
tell
you
is
that
somebody
who
had
access
to
a
private
key
produced
the
signature
for
a
set
of
bytes.
It's
all
you
know
now
we
can
choose
to
have
that
signify
that
it
came
from
a
trusted
supplier
that
we
believe
is
appropriately
looking
after
their
keys.
A
A
Now,
to
put
this
much
more
simply,
trust
is
always
time
dependent.
In
other
words,
it
depends
on
when
you're
talking
about.
Maybe
I
trust
this
software
today,
but
tomorrow
we
discover
a
very
bad
cve
with
it
and
we
don't
trust
it
anymore.
It's
asymmetrical,
meaning
that
you
trust
me
doesn't
necessarily
mean
that
I
trust
you
and
it's
contextual
right.
It's
within
the
context
that
you're
trusting
a
thing.
A
Which
builds
brings
us
around
to
build
tools
now
build
tools
are
fascinating
things
like
compilers
and
linkers,
because
they
transform
their
inputs,
but
in
a
way
that
makes
it
impossible
to
know
intrinsically
what
went
in.
If
I
take
cnh
files,
I
can't
really
know
from
the
resulting
data
files
everything
that
actually
came
out.
In
fact,
if
you
talk
to
the
folks
who
write
debuggers,
they
have
complicated
heuristics
to
try
and
figure
out
when
you're
debugging,
if
you're,
looking
at
the
right
source
guide.
A
So
you
might
say:
okay,
great,
we'll
scan
the
inputs.
I've
got
a
bunch
of
source
codes
sitting
out
on
my
repo
I'll
scan
it,
but
it
doesn't
really
explain
the
output
because,
as
I
pointed
out
with
a
linux
kernel
example,
not
everything
that's
out
there
gets
built
at
all.
So
you
don't
really
know
where
it
all
went
in
the
process.
A
A
A
The
build
tools
have
the
right
context
at
the
right
time
for
you
to
be
able
to
find
out
the
information
that
you
need,
and
so
what
git
bomb
fundamentally
does.
Is
it
advocates
for
building
these
compact
artifact
dependency
graphs,
just
out
of
the
git
object,
ids,
embedding
the
get
object
id
of
those
get
bomb
documents
into
the
output
artifact
from
a
build
tool
and
having
the
build
tool.
A
Do
it
because
the
build
tool
knows
it
in
a
language,
neutral,
environment,
your
language,
energy
needs
environment
across
all
kinds
of
packaging
formats,
with
zero
developer
effort,
involvement
or
awareness.
So
quick
question:
let's
see
if
we
have
any
engineers
in
the
room,
how
many
of
you
are
lazy
now
we
know
who
the
engineers
are.
Engineers
are
lazy,
it's
literally
what
we
pay
them
for.
A
A
A
So
really
quickly,
I'm
going
to
take
questions
here
in
a
second,
but
we
have
a
vibrant
community
going.
We
actually
have
initial
poc
work
with
llvm,
clang
and
lld,
so
we
can
actually
build
things
fulfilling
some
of
this
promise
that
work
will
be
upstreamed
over
time.
We've
got
work
being
done
in
go
rust.
We've
got
other
tools
that
are
actually
looking
at
how
to
automate
the
process
of
extracting
the
source
code
hashes
out
of
things
that
have
cves
by
looking
at
the
fixed
versus,
not
the
fix.
A
What's
the
fundamental
best
lesson
to
learn
as
an
architect
make
it
someone
else's
problem,
that's
the
very
best
trick
as
an
architect.
If
any
of
you
are
starting,
our
ambition
have
ambition,
search
architecture.
That's
the
number
one
trick,
so
we
already
have
people
signing
artifacts
that
exists
in
the
world.
There
are
whole
projects
like
sync
store
that
are
looking
at,
making
that
better
and
smoother.
A
You
can
tell
because
the
signatures
don't
match
anymore
and
so
part
of
what
kit
bomb
is
doing
is
taking
this
very
simple
idea
and
putting
it
in
a
place
where
the
entire
ecosystem
around
it
can
benefit,
but
also
can
contribute
to
solving
those
problems.
Did
I
answer
your
question?
Awesome.
It's
a
very
good
question.
We
have
another
question
over
here.
B
A
A
Those
are
the
kinds
of
metadata
that
you
would
want
to
capture
from
a
cryptographically
verifiable,
build
process
and
not
having
to
solve
that
problem
in
a
way.
That's
just
bespoke
to
this
part
of
the
problem
is
a
huge
advantage,
so
this
incrementally
enables
us
to
get
to
more
and
more
secure
places.
B
A
Right
so
cyclone
dx
we've
already
had
the
cyclodx
people
come
around
and
actually
ask
us
what
the
uri
format
should
be
used
for
for
external
identifiers,
so
should
be
fine
on
the
github
enterprise
side
at
the
guts
under
all
the
other.
Goodness
that
github
gives
you
what
you
will
find
at
the
very
base
is
get
so
all
the
source
code
files
that
you're
storing
in
github
enterprise
are
still
starting
yet,
and
that
means
that
git
has
still
computed
the
get
object
id
for
all
of
them.
A
A
A
When
you
look
at
a
thing
like
wordpress,
the
question
you
start
asking
is
what
makes
sense
there
because
wordpress.
If
I
remember
correctly-
and
please
correct
me,
if
I
don't
it's
basically
a
bunch
of
perl
scripts
that
are
being
run
and
then
you
get
plugins
that
are
bringing
also
a
bunch
of
pearl
is,
am
I
remembering
correctly
in
perl
php,
oh
so
php
of
course,
yeah
not
enormously
different,
but
a
little
bit
and
it
may
be
running
in
a
run.
Time
is
zend
still
building
runtimes
that
pre-compile
things
et
cetera,
et
cetera.
Apologies.
A
C
A
Absolutely
sorry
right
here,
I
forgot
to
go
to
my
last
slide.
So
if
you've
got
qr
code
scanning
phones,
this
takes
you
straight
to
getbob.gov
community
and
we
have
weekly
meetings
that
happen.
Tuesdays
at
11
a.m,
pacific,
which
is
1
p.m.
Central.
Where
you're
currently
sitting,
we
have
slack
channels
which
we
also
have
mailing
lists.
People
tend
to
use
the
slack
channel
more
than
the
mailing
list,
there's
a
whole
bunch
of
stuff.
You
can
see
the
mini
meeting
minutes.
A
A
That's
okay,
it's
okay!
To
be
shy!
All
right!
It's
been
super
fun.
Talking
with
you
all
you've
had
excellent
questions.
You've
been
very
engaged.
All
of
you
could
raise
your
hands,
which
is
an
anomaly
and
I'd
be
happy
to
talk
to
people
in
the
hallway
afterwards
about
get
bomb.
If
you'd
like
to
continue
the
conversation.