►
From YouTube: Lightning Talk: Repurposed Purpose: Using Git's DAG for Supply Chain Artifact Resolution- Aeva Black
Description
Lightning Talk: Repurposed Purpose: Using Git's DAG for Supply Chain Artifact Resolution - Aeva Black, Microsoft
What if we could know the complete and reproducible artifact tree for every binary executable, shared object, container, &etc – including all its dependencies – and you could efficiently cross-reference that against a database of known vulnerabilities? If you had had that information, could you have remediated Log4Shell faster? Might it even help open source maintainers identify at-risk dependencies sooner? If you're thinking, "this sounds too good to be true - what's it going to cost?", then we really hope you’ll join us because we believe this should be an automatic part of open source build tools. 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.
A
If
you
didn't
write
it
yourself
and
you
probably
shouldn't
trust
code,
anybody
else
wrote,
and
that
goes
not
just
for
software
in
our
clouds,
but
all
the
way
down
to
the
firmware
in
our
systems
that
you
can't
really
know.
What's
in
it.
If
you
didn't
build
it
yourself
since
then,
so
much
of
the
work
we've
been
doing
and
all
of
the
work
in
cloud
native
security
and
supply
chain,
security
is
focused
on
solving
that
question
a
decade
or
so
later.
Dorothy
denning
pointed
out
that
trust
is
a
declaration
made
by
an
observer.
A
It
is
not
a
property
inherent
in
the
thing
found
a
property
in
the
observed,
so
when
we
are
signing
things
or
creating
attestations
with
sgx
or
things
like
that,
this
is
transitive
trust.
Someone
else
is
making
an
observation
and
then
a
declaration.
Then
we
are
trusting
their
observation
because
we
trust
that
person.
The
trust,
is
not
an
inherent
property
in
the
thing.
So,
with
all
of
with
that
long
history
in
mind,
jumping
into
the
specifics
about
a
year
ago,
I
stepped
squarely
into
supply
chain
security
and
tried
to
take
a
beginner's
mind
approach.
A
Just
listen,
learn
see.
What's
out
there
understand
what
architectures
other
people
have
been
building
in
this
space
and
if
you
feel
lost
like
this,
is
just
a
tingled
web
there's
so
much
stuff
going
on.
Don't
worry,
you're
really,
not
alone.
A
lot
of
people
feel
that
way
and
at
the
heart
of
this
tapestry
of
projects.
What
we're
all
trying
to
answer
is
the
question:
am
I
safe?
A
Can
I
download
this
open
source
package?
Can
I
use
this
thing
in
a
way
that
does
not
compromise
my
safety
and
well,
if
it's
that
complex,
sometimes
complex
models
can
be
made
simpler
simply
by
changing
our
perspective,
just
like
in
physics,
you
look
at
it
from
a
different
angle
and
you
reduce
the
number
of
variables
and
it
gets
easier
to
solve.
So
I
began
asking
a
few
simple
questions.
As
I
looked
at
this
domain,
this
crazy
tapestry
of
stuff
and
three
simple
questions,
really
what
it
boils
down
to
identity.
What
is
the
software
artifact
dependency?
A
A
So
digging
in
an
artifact
in
this
definition
is
any
software
object
of
interest
and
all
artifacts
are
representable
as
an
array
of
bytes,
because
computers,
this
could
be
a
source
code
file,
it
could
be
in
python,
it
could
be
in
java
could
be
pre-compiled.
It
could
be
a
shared
object
file.
It
could
be
an
rpm
or
debian
package.
These
are
all
software,
artifacts
and
they're
all
represented
in
computers
as
an
array
of
bytes.
Therefore,
two
artifacts
are
equivalent
only
if
the
byte
array
representations
of
those
artifacts
are
equivalent
right.
A
It
should
therefore
be
possible
to
identify
these
with
some
sort
of
a
unique
id
like
a
hash.
So
artifact
ids
should
have
these
three
characteristics.
They
are
canonical
unique
and
immutable,
by
which
I
mean
independent
parties
presented
with
the
same
byte.
Arrays
can
derive
the
same
identity,
they
are
unique,
non-equivalent
artifacts
have
different
identities
and
they
are
immutable
and
identified
artifacts.
A
A
The
url
or
the
perl
also
doesn't
work
because
you
can
change
what's
on
the
other
end
of
that
or
use
multiple
urls
to
refer
to
the
same
bytes
late.
Last
year,
the
ntia
in
the
u.s
issued
a
set
of
requirements
called
the
minimum
elements
of
an
s-bomb,
a
software
bill
of
materials.
Those
minimum
elements
are
component
name
version
and
supplier
also
not
unique,
doesn't
work.
So
that's
kind
of
sad.
What
does
work
it
turns
out.
Git
already
solved
this
problem.
A
A
If
you
don't
know-
and
most
people
use
git,
never
look
under
the
hood?
It's
actually
a
merkle
tree
masquerading
as
a
version
control
system
and
a
merkle
tree
is
just
a
tree
structure
and
data
data
structure,
where
a
leaf
node
is
labeled
with
the
cryptographic
hash
of
the
data
and
every
non-leaf
node
is
labeled
with
the
hashes
of
the
tree
underneath
it.
This
has
some
really
fun
properties
like
if
you
and
I
have
huge
storage
arrays
of
data.
We
can
just
compare
the
merkle
trees
and
we
know
it's
the
same
data.
A
A
We
should
just
use
the
git
oid
they
get
oid
to
identify
our
software
artifacts.
Second
simplifying
question-
and
I
hope
I
don't
run
over
time
too
much
dependencies.
What's
in
it
from
source
code
to
executable
the
nice
things
about
a
merkle
tree
is
you
can
link
them
together
even
across
languages,
and
we
can
abstract
that
or
generalize
it
to
just
a
tree
metadata?
What
else
is
known
about
it?
A
All
the
other
stuff,
so
we've
been
working
with
the
spdx
community
to
make
sure
that
metadata
and
spdxs
bonds
can
refer
to
objects
by
their
get
oid,
and
you
can
refer
to
a
leaf
node
or
the
end
artifact
or
any
intermediate
artifact.
It
all
works,
so
you
have
your
s-bombs
for
metadata
and
your
git
bomb
for
the
artifact
tree.
Why
is
this
so
cool?
A
Because
when
there's
a
cbe
like
log4j,
if
you
associate
it
to
the
software
id
the
gitoid,
that
has
those
three
properties,
you
can
then
find
it
in
any
tree
of
software
anywhere
with
different
s-bonds,
because
I
might
give
you
a
jvm
and
someone
else
might
give
you
a
jpm.
They
both
have
log4j
somewhere
deep
in
that
tree,
get
bomb
would
help.
A
Our
approach
is
to
focus
on
a
small
bounded
set
of
projects
that
already
have
large
communities
and
often
funding
behind
them.
The
language
ecosystems
like
python
and
java
and
go
and
rust,
and
the
build
tools
like
gcc
and
llvm
add
a
small
change
there
and
everybody
in
the
world
benefits,
and
this
happens
automatically.
A
So
we
already
have
four
proof
concepts
running
for
this:
we've
done
it
for
llvm,
gcc
and
ld
we've
added
some
stuff
in
go
this
isn't
upstream.
Yet
these
are
just
our
proof
of
concepts
on
github.
You
can
grab
them
from
those
urls.
You
should
definitely
trust
my
qr
codes
and
the
fourth
one
bom
sh
is
a
really
cool
set
of
python
and
bash
scripts
that
use
s
trace.
That,
in
theory,
should
be
able
to
instrument
any
build
process.
B
A
To
use
it
for
searching
for
artifacts,
how
do
you?
The
question,
I
think,
is:
how
do
you
use
it
for
searching
for
artifacts
if
a
build
process
is
or
is
instrumented
with
this,
the
produced
git
bomb
trees
would
then
need
to
be
uploaded
somewhere,
whether
it's
git
hub
or
some
sort
of
a
universal
shared
file
system.
We
have
some.
We
have
actually
proof
of
concept
right
now
about
using
global
fs
for
this,
and
then
you
can
search
that.