►
From YouTube: State of the Art Supply Chain Security- Trishank Karthik Kuppusamy, Asra Ali & Santiago Torres-Arias
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
State of the Art Supply Chain Security (in-toto, TUF, and SigStore) - Trishank Karthik Kuppusamy, Datadog; Asra Ali, Google & Santiago Torres-Arias, Purdue University
In this talk, we’ll explore the complementary roles that TUF, in-toto, and SigStore play in creating a transparent hack-proof software supply chain that thwarts man-in-the-middle attacks anywhere between developers and end-users. The talk will build off the basics of using in-toto and TUF together to deliver hack-proof updates, especially how it was done for the first time in the industry at Datadog, and then going the extra mile with SigStore. We’ll see how SigStore’s transparent and auditable model holds publishers accountable in this system. Finally, we’ll see a real example of the whole stack in action for the first time with Datadog’s integration, and show just how easy it is to adopt yourself!
A
A
So
at
datadog
we
have
the
agent
which
some
of
you
may
have
installed.
It
monitors
your
infrastructure,
your
abs,
your
logs
and
so
on
and
there's
there's
hundreds
of
integrations
that
come
out
of
the
box
right.
It
gives
the
agent
extra
superpowers,
as
it
were,
to
measure
even
more
stuff,
and
the
problem
we
had
was
that
we
needed
to
decouple
releasing
the
agent
separately
from
the
agent
because
we
wanted
to
be.
A
We
want
the
customers
to
be
able
to
try
new
versions
of
the
integrations,
try,
bug
fixes
and
so
on,
and
so
how
do
you?
How
do
you
normally
do
this?
Well,
you
use
ci
cd,
as
many
of
us
do
here.
I
suspect,
and
so
there's
a
lot
of
benefits
to
using
ci
cd,
it's
much
less
error
prone
than
human
beings
in
building
packaging
and
and
and
signing
your
software
reliably
and
trusting
this
robot.
A
A
The
problem
is
that
a
million
little
different
things
can
go
wrong.
So,
for
example,
your
developer
could
have
a
key
compromise
or
your
vcs
could
get
compromised.
The
source
control
system
or
your
ci
cd
itself
could
get
compromised
or
the
image
registry
you
use
to
run
your
ci
cd
jobs
or
your
key
and
file
service
that
you
use
to
store
your
artifacts
and
and
your
signing
keys.
I
think
you
get
the
idea.
A
The
point
is
that,
like
I
said,
a
million
little
different
things
can
go
wrong
and
the
problem
with
this
previous
day
at
the
I
is
you
know,
good
old-fashioned,
ci
cd
by
itself-
is
that
there's
no
compromise
resilience.
One
single
attack
and
the
whole
game
is
over
it's
an
all-or-nothing
proposition
proposition.
A
So
what
we
want
to
do
is
that
we
want
compromise
resilience,
so
you
know
it's
probably
impossible
to
build
an
impenetrable
fortress,
but
what
you
can
do
is
build
layers
of
defense
around
the
difference
in
depth.
As
some
of
us
call
it,
and
so,
for
example,
you
could
think
of
building
your
your
medieval
castle
here
with
layers
of
mode
surrounded
by
alligators
and
guys
who
flame
progress
just
for
extra
measure.
A
The
second
piece
of
technology
is
called
tough
and
it
is
the
compromise,
resilient
distribution
of
the
your
software
supply
chains,
as
well
as
the
associated
artifacts,
and
the
third
piece
of
technology
is
six
store,
which
then
gives
you
transparent,
compromise
resilience.
So
you
can,
you
can
see
the
history
of
every
single
little
thing,
how
every
single
little
artifact
you
ever
released
was
produced
from
end
to
end,
and
people
can
even
audit
this
stuff.
For
you,
and
so
the
metaphor
that
we
like
to
use,
I
hear
vaccines
are
very
popular
these
days.
A
How
much
mrna
is
in
my
vaccine,
how
much
lipids
I
use
what
sort
of
adjunct
and
who
I
bought
it
from
how
it
was
all
composed
together,
and
so
you
know
that
you
know
how
this
vaccine
is
produced
right,
and
so
the
tough
is
a
bit
like
the
fda.
Saying
why
you
should
trust
pfizer
or
moderna
or
jnga,
or
whoever
else
you
have
tomorrow
in
the
first
place,
and
finally,
six
store
is
kind
of
like
the
cdc,
the
record
registry
keeping
the
history
of
how
every
single
little
vaccine
was
produced.
B
Trishak,
so
mr
shank
was
talking
about
there's
three
components
with
in
total
we're
able
to
track
everything
with
top
variable
to
distribute
what
we're
tracking,
as
well
as
the
artifacts
that
we're
protecting
and
finally
with
sector
we're
able
to
transparently
collect
this
vertical
information
about
everything
that
was
produced
in
an
ecosystem,
so
to
take
it
from
the
top.
Imagine
that
you're
maintaining
a
project
and
you're
developing
your
application
at
home
and
you
need
to
put
it
somewhere.
B
So
all
the
people
can
collaborate
with
you,
so
you
would
want
to
put
the
source
code
but
also
information
about
the
source
code
and
how
it
was
written
and
who
wrote
it
into
a
place.
That's
discoverable
by
people
with
this
you're
able
to
prevent
attackers
from
breaking
in
or
modifying
the
source
code
or
or
targeting
particular
pieces
of
of
your
distribution
to
to
introduce
malaysia's
code.
B
Now.
Imagine
that
beyond
that,
you
also
wanted
to
include
a
cicd
system
to
continuously
build
all
of
the
source
code
that
had
been
written
writing.
So
what
total
takes
care
of
is
to
creating
evidence
that
tightly
links
together
every
single
operation
that
you
did
in
your
pipeline.
So
that
when
consumers
are
about
to
consume
your
software,
they
know
that
nothing
was
performed
outside
of
the
specification
and
that
everything
has
been
performed
to
the
letter
by
the
right
party
and
there
hasn't
hasn't
been
any
tampering
in
between.
B
So
going
back
to
the
metaphor
of
of
vaccine
distribution.
Now
imagine
a
pipeline
that
we
may
be
very
more
familiar
with
a
physical
pipeline.
That's
producing,
I
don't
know
a
little
go
file
mrna.go
that
is
taken
into
a
manufacturer,
cit
system
in
the
cloud.
Maybe
in
gitlab
it
will
be
constantly
constantly
updated
and
remanufactured
as
new
ingredients
come
available.
B
B
B
A
Thank
you.
Thank
you,
santiago
yeah.
So
so,
let's
talk
about
the
second
piece
of
the
puzzle,
which
is
compromise.
Resilient
distribution
of
the
of
the
software
supply
chains.
That
santiago
was
talking
about
in
total
supply
chains
and
and
and
so
so
tough
is
the
toughest
you
can
think
of
it
as
a
secure
transfer
protocol
that
distributes
all
of
the
supply
chains,
as
well
as
the
artifacts
and
so
going
back
to
the
metaphor
of
vaccines.
A
Again
and
tough
is
like
the
fda
telling
you
hey.
Why
should
you
trust
fizer,
moderna
or
jnj
in
the
first
place,
and
then
you
can
go
off
and
figure
out
their
separate
rules
for
the
supply
chain
and
so
on
right.
But
you
have
this
one
central
route
of
trust
and
from
there
you
can
bootstrap
and
and
figure
out
your
way
through
the
rest
of
the
system.
A
So
you
can
think
of
tough.
We
don't
have
time
to
go
into
all
the
details,
but
to
give
you
a
rough
idea,
how
tough
works?
Basically,
we
listen
to
grandma.
She
told
us,
we
told
grandma.
We
have
this
very
tough
problem
of
trying
to
solve
software
updates
from
nation
state
attackers,
and
so
we
asked
grandma
for
advice.
She
gave
us
a
few
different
design
principles
that
we
then
put
together
and
call
it
the
update
framework
and
one
of
them
is
separation
of
duties.
Basically,
don't
put
all
your
eggs
in
one
basket.
A
A
A
I
I
think,
that's
what
the
crypto
kids
call
it
these
days,
so
you
can
use
things
like
keeping
your
keys
in
like
nuclear-proof
bunkers
somewhere
in
the
swiss
underground
somewhere,
so
that
attackers
can't
get
to
it
when
they
get
your
infrastructure
use.
Two
main
rules,
grandma
said
always
use.
You
know,
separation
of
keys.
In
fact,
it's
very
interesting
what
they
do.
The
key
is
a
physically
situated
far
enough
that
you
you
can't
one
person
cannot
launch
the
nuke
at
the
same
time,
so
we
use
the
same
principle
here.
A
You
need
two
different
keys
at
least
cryptographic
agility
use,
different
hashing
and
signing
algorithms
at
the
same
time.
So
you
head
your
bets,
so
even
if
one
of
them
is
broken,
you're
still,
okay,
hopefully
the
rest
have
a
different
design
with
apologies
to
the
nintendo
corporation,
tough.
Basically,
in
a
nutshell,
it's
a
bit
like
playing
pokemon.
You
got
to
catch
them
all
right,
okay,
so
yeah,
that's
basically
how
it
works,
and
now
azra
will
talk
to
us
about
six
storm.
C
All
right,
so
six
star
plays
like
a
couple
different
roles
in
this
whole
ecosystem.
So
I'm
going
to
talk
a
little
bit
about
what
it
does
in
general
and
then
we'll
talk
how
it
works
in
the
data
dog
pipeline.
So
six
store's
main
goal
is
to
basically
make
a
transparent
and
easy
to
use
way
of
supply
securing
supply
chain.
C
So
in
the
analogy
that
we
have
laid
out
before
within
toto
tuff
and
sigstor,
what
it
kind
of
plays
in
this
whole
pipeline
is
that
it
provides
a
place
of
discoverability
on
the
end
user
for
finding
when
those
artifacts
have
been
signed
and
sort
of
providing
a
like
immutable
history
of
signing
events.
So,
let's
say,
like
you
know,
for
example,
you
might
spin
up
a
monitor
and
say:
okay,
I
want
to
make
sure
and
double
check
really
just
to
keep
myself.
C
C
C
So
this
is
kind
of
the
role
of
that,
and
so
I
really
find
is
that
this
you
know,
brings
things
from,
like
you
know,
90
to
100
and
more
so
you're
able
to
kind
of
see
that
history
you're
able
to
you
know
it
provides
people
with
accountability,
and
so
that's
the
kind
of
role
that
I
see
this
playing
in
the
in
toto
and
tough
complementary
realm.
So
let's
talk
a
little
bit
about
what
six
star
does
in
general
and.
C
There
we
go
so
what
we're
going
to
do
is
kind
of
start
from
like
a
basic
principles
and
I'll
talk
a
little
bit
about
how
it
can
be
used
in
like
the
in
different.
You
know
more
complex
ways,
so
there's
three
main
components
of
the
ecosystem
that
I'm
kind
of
gonna
walk
through
from
just
starting
from
an
artifact
which
is
this.
C
You
know
like
notebook
like
thing
on
the
on
the
left
here
and
how
you
might
distribute
that
in
a
way
that
the
end
user
at
the
bottom
over
there
can
check
for
integrity.
So,
let's
start
with
that
artifact.
The
first
step
is
the
actual
signing
piece
of
that.
So
that's
going
to
happen
with
a
tool
called
cosine
and
again
all
of
these
components
that
I'm
talking
about
are
totally
modular
and,
like
you
know,
it's
pick
and
choose
do
what
you
want.
C
So
cosign
is
a
part
of
the
secret,
a
sig
store
ecosystem
that
provides
that
signing
and
verification.
So
it's
a
really
easy
signing
tool
that
tries
to
makes
you
know
most
of
the
process
as
automated
as
possible.
So
everything
you're
going
to
hear
about
from
you
know
here
on
is
happening
under
the
hood.
No
one
needs
to
know
if
they
don't
want
to
so
you
can
use
it
to
generate
keys.
C
You
can,
you
know,
bring
your
own
keys,
you
can
use
hardware
keys
and
what
you
can
do
is
you
know
with
that
public
and
private
key?
You
can,
you
know,
sign
a
container
or
really
co-sign
us
for
container
signing,
but
in
the
whole
sector
ecosystem
you
could
really
sign
any
kind
of
artifact.
So
all
right,
that's
good
and
well.
You
can
generate
that
signature
and
you
can
give
it
to
the
end
user
and
then
user
can
use
the
public
key
and
signature
to
do
a
verification.
C
But
now
building
on
top
of
that
part
of
the
difficulty
in
signing
artifacts
is
managing
keys.
Like
key
management
is
a
very,
very
hard
problem.
We
all
know
that
keys,
get
stolen,
keys,
get
leaked,
keys,
get
published
on
websites
keys,
get
compromised.
We
know
it's
just
like
kind
of
a
fact
of
nature.
So
if
it's
going
to
happen,
some
ways
that
sigster
kind
of
tries
to
mitigate
this
problem
and
make
it
something
that
developers
don't
even
have
to
think
about
is
with
this
automated
key
management
piece
called
full
co.
C
So
full
co
is
this
pki
system,
it's
a
root
certificate
authority
that
is
going
to
live
also
in
the
six
star
ecosystem
and
what
it
does
is
it's,
it's
totally
free,
also
totally
public.
Is
it
generates
code
signing
certificates
based
on
an
authorized
identity
provided
through
like
an
open
id
connect
flow?
So
what
you
end
up
with
is
maintainers
or
distributors
can
generate
a
one-time
or
like
ephemeral,
use
key
pair.
C
So
these
public
and
private
key
pairs
use
that
to
create
a
signature
and
then
send
their
public
key
up
to
full
co,
which
full
co
will
sign
off
on,
generate
a
certificate
for
and
provide
that
back
to
you.
After
that
code,
signing
is
done.
The
distributors
or
maintainers
can
just
throw
away
their
keys.
There
is
no
need
for
key
management
at
all,
and
what
this
results
in
is
that
verifiers
can
just
simply
verify
based
on
that
identity
and
as
long
as
they
check
the
full
co
piece
of
this.
C
So
that's
awesome.
We
don't
have
to
deal
with
private
keys,
but
now
there's
one
more
piece
that
exists
also
in
conjunction
and
it's
kind
of
necessary
with
the
full
seo
piece
and
that's
called
recore.
So
recore
is
a
transparency
log
you
may
be.
You
know
familiar
with
this
as
like
a
type
of
ledger,
but
it's
also
a
time
stamping
service.
So
what
this
log
contains
is
basically
storage
mechanisms,
for
any
type
of
you
know
signing
artifacts
so
like
maybe
this
includes
just
general
like
container
signatures
that
we
have
on
cosine.
Maybe
this
includes
jar.
C
Maybe
this
includes
rfc3161,
timestamps
or
or
maybe
this
includes
in
total
and
tough
metadata.
So
what
this
allows
is
anyone
can
go
and
upload
signing
artifacts
onto
this
with
a
totally
immutable
history,
which
is
you
know
by
nature
of
this
transparency
log
and
it's
searchable.
So
what
you
basically
have
provided
is
a
searchable
and
totally
immutable
record.
C
Keeping
of
all
the
signing
that's
going
on,
which
is
awesome
in
case
someone
ever
wants
to
monitor
or
trace
down
exactly
what
happened
and
when
and
also
like
you
know
in
the
future,
like
you
know,
you
can
think
of
just
kind
of
expanding
this
out
as
giving
you
this
whole.
You
know
global
view
of
the
ecosystem
and
that
you
can
kind
of
use
to
build
connections
between
different
things,
so
this
entire
piece
is
kind
of
how
the
spacecraft's
just
ecosystem
works
in
conjunction.
C
But
again
we
can
kind
of
pick
and
choose
components
as
we
want.
So
the
great
part
is
that,
like
you
know,
everything
could
happen
under
the
hood,
starting
from
the
cosine
flow,
using
all
three
of
these
components:
keyless
signing
with
full
co
and
verification
on
transparency
log,
but
you
can
also
just
use
you
know.
For
example,
the
transparency
log
to
you
know
provide
end
users
that
you
have
with
like
a
transparent
way
of
you
know
saying.
C
Yes,
you
did
sign
things
when
you
wanted
to
and
that's
exactly
what
trishank
is
going
to
talk
about
like
next
with
this
data
dog
integration
is
using
recore
as
a
way
of
hosting
their
tough
and
in
total
metadata,
as
just
a
way
of
saying,
hey,
we're,
definitely
signing
things
transparently,
so
I'll
hand.
This
off
to
you,
trishank.
C
A
A
A
It
checks,
for
example,
that
the
python
wheel
was
produced
by
the
ci
cd,
but
on
top
of
that
it
actually
unzips
it
and
checks.
The
source
code
was
literally
signed
by
one
of
our
developers
using
the
ub
keys.
That's
what
gives
us
compromised
resiliency,
even
if
someone
tampers
with
a
ci
cd,
they
can't
forgive
developer
signatures,
and-
and
this
is
the
tough
distribution
model
again,
we
don't
need
to
get
into
the
details.
It
looks
complicated,
but
really
it's
really
just
trying
to
load
balance
metadata
here.
We've
been
collecting.
A
A
And
and
now
we're
I'm
also
pleased
to
say
we're
the
first
in
the
industry.
Sorry,
as
far
as
I
can
tell
to
do
transparent,
compromised
resilience
to
take
it
to
the
next
level
as
azero
was
talking
about.
So
we
have
our
developers
sitting
some
of
them
sitting
in
the
new
york
times.
Building
must,
of
course,
and
and
releasing
new
python,
wheels
right
using
the
ub
keys.
A
So
our
developers
release
a
new
new
source
code
that
needs
to
be
sent
out
to
our
users
and
our
ci
cd
packages
them
using
in
doto
sending
attestations
about
it,
and
then
everything
gets
packed
together
in
in
tough
using
tough
to
securely
deliver
both
to
our
end
users
and
then,
finally,
now
we're
beginning
to
record
every
single
artifact,
every
new
integration
that
was
released
on
sigtor
on
our
own
record,
so
that
everyone
can
query
it
and
see
exactly
how
every
single
little
integration
was
was
produced.
End-To-End
from
our
developers
to
you.
C
All
right
so
yeah,
the
purpose
of
this
demo
is
to
talk
a
little
bit
about.
You
know:
trishank
mentioned
three
years
of
history,
of
putting
tough
metadata
and
publicly
verifying
it,
but
the
question
is
like:
did
he
really
do
it
for
three
years?
So
the
question
is:
can
we
actually,
like
you
know,
find
a
history
of
those
three
years
of
metadata?
So
what
I'm
going
to
kind
of
show?
You
is
a
little
demo
of
how
a
verification
on
an
user
would
work
using
entota,
tuff
and
sixter
components
so
to
do.
C
C
We
verified
that
they
currently
exist
in
the
log
just
because
we
don't
necessarily
trust
the
indus
indexing
service
and
we
actually
pull
that
entry
from
the
log
find
out
its
metadata
content
and
we
find
out
a
you
know:
tough,
looking
piece
of
metadata
of
a
timestamp
roll
with
a
version
3000
which
matches
before
and
just
to
make
sure
that
it
really
truly
does
match.
We
can
take
the
hash
of
that
f25c6d
as
you
can
see
printed
below,
and
it
totally
matches
the
one
that
we
downloaded
from
the
verifier.
C
So
that's
kind
of
a
speed
run
demo
of
how
this
entire
process
works.
But
the
main
idea
is
that
we
did
it
with
speed,
because
it
should
be
easy
to
do
so.
There's
not
too
much
going
on
for
you
to
deal
with,
but
all
these
pieces
are
there
for
verification
and
are
totally
transparent
for
you
to
kind
of
check
and
click
through.
So
we
kind
of
hope
that
people
start
integrating
this
into
their
system
and
making
it
like.
C
You
know
an
immutable
history
for
people
to
kind
of
search,
query,
monitor
and
also
for
your
own
benefit,
making
sure
that
you
know
no
one's
signing
things
on
your
behalf
that
shouldn't
be
there.
So
you
know
you
can
make
sure
that
no
one's
signing
with
my
email
id
token
by
checking
my
record
logs
so
recore
is
a
really
cool
tool
to
kind
of
search
and
verify
and
pull
things
and
investigate.
So
now,
I'm
going
to
hand
it
off
back
again
for
some
security
analysis.
A
C
A
C
C
A
Exactly
cool,
so
yes,
let's,
let's,
let's
next,
take
a
look
at
the
security
analysis.
What's
the
bottom
line,
what
do
I
get
for
my
money
here?
Well,
let's
take
a
look,
a
new
state
of
dr.
What
can
go
wrong?
Well,
nothing
has
obviously
gone
wrong,
like
life
is
good,
but
when
you
have
a
developing
key
compromise
in
theory,
yes,
malicious
source
code
could
be
billed
automatically
and
distributed,
but
there's
there's
an
important
thing
here.
A
A
A
You
know
denial
of
service
attacks
here
where
it
looked
like
an
attack,
but
it
wasn't
it's
a
bug
in
like,
for
example,
not
not
a
bug,
but
a
feature
and
git
rewriting
new
lines
on
from
windows,
for
example,
and
then
there's
cicd
compromise
again
don't
lose
sleep
because
we
always
always
always
double
check
the
cicd.
We
never
blindly
trust
we
always.
The
root
of
trust
is
basically
our
developers.
A
What
happens
if
the
image
registry
get
compromised
again,
no
sleep
lost
or
the
key
or
file
server.
I
think
you
get
the
idea
by
this
point,
and
so
some
conclusions
too
long
didn't
read.
Just
use
in
total,
tough
and
sick
store,
okay
to
get
transparent,
compromised
resilience.
That's
all
you
need
to
remember
you
don't
need
to
you,
don't
need
to
worry
yet
about
how
it
works,
but
this
is
the
basic
idea
we
won
transparent
compromise
resilience
for
all
right,
and
this
is
how
you
do
it.
A
This
is
our
claim
and
again
going
back
to
the
metaphor
of
vaccines.
Just
to
make
things
a
bit
more
concrete
in
toto
is
like
pfizer,
moderna
or
jnj,
telling
you
exactly
how
how
every
one
of
the
vaccine
was
produced.
Tough
is
like
the
fda
telling
you
why
you
should
trust
each
of
these
vaccine
makers
in
the
first
place
right
so
the
bootstrapping
and
trust
and
secure
distribution
of
these
vaccines.
And
finally,
six
store
is
like
the
cdc
keeping
a
permanent,
transparent
record
for
everybody
wants
to
walk
in
and
check.
A
C
Yeah,
so
I'm
going
to
talk
about
this
exciting
new
development,
which
might
not
be
as
new
when
everyone
is
actually
watching
this.
But
what
we
are
trying
to
do
is
bring
the
benefits
of
tough
trust
routes
to
everyone.
So
transparent
compromise
resilience
for
all.
So
what
we
intend
to
do
is
sort
of
integrate
tough
routes
that
you
can
kind
of,
make
yourself
on
github
and
have
our
trust
root
like
by
bootstrapping
our
own
trust
rate.
C
You
can
build
your
own
trust
route
through
this
github
approval
process
and
that
will,
like
naturally,
integrate
with
sig
store
tools.
So,
for
example,
let's
say
you
had
a
project
like,
for
example,
distrolus,
and
they
wanted
to
use
tough
or
maybe
use
in
toto
too
for
their
supply
chain
and
publish
metadata
based
on
you
know
their
their
current
layout
and
have
people
in
cosine
actually
verify
the
entire
thing
end
to
end.
So
what
they
can
simply
do
is
just
do
a
cosine
like
if
I
was
an
end
user.
C
I
would
just
use
cosine
to
use
a
verification
and
then
point
that
and
pin
that
at
a
certain
type
of
delegate,
which
is
a
delegation
from
our
own
sig
store
root
to
the
disturbances
route
and
that
way
as
an
end
user.
I
don't
have
to
deal
with
finding
the
right
metadata.
I
don't
have
to
deal
with.
You
know
pulling
the
current
metadata.
C
I
just
know
that
I'm
going
to
pin
on
this
delegate
that
is
trusted
by
six
store,
which
in
turn,
I
trust
and
then
are
am
I,
like
you
know
single
line
able
to
verify
an
image.
So
that's
the
kind
of
idea
there.
We
basically
want
to
bring
trust
roots
to
everyone
and
make
it
so
that
projects
can
transparently
and
openly
utilize
all
of
these
tools
in
conjunction
without
having
to
set
everything
up
themselves.
B
So,
lastly,
the
research
front
and
like
the
north
star
front,
we
want
to
do
three
major
thrusts.
Three
major
pushes
one
of
them
is
to
integrate
projects
such
as
keyline
to
have
a
hardware
rule
of
thrust
semantics
into
the
tracking
of
supply
chain
metadata,
so
that
you
can
know
every
single
thing
that
was
used
in
the
operation
of
a
supply
chain
action
now.
The
second
one
is
to
actually
start
discovering
these
complex
interrelationships
between
software
as
it
is
used
to
produce
more
software.