►
From YouTube: Securing the Software Supply Chain with in-toto - Santiago Torres-Arias & Justin Cappos, NYU
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Securing the Software Supply Chain with in-toto - Santiago Torres-Arias & Justin Cappos, NYU
The cloud native ecosystem and tooling allows for rapid development and delivery of applications using various services in different configurations in highly-automated software supply chains. Unfortunately, this supply chain has become an attractive target for attacks. An attacker that compromises any of the steps of the supply chain, compromises a dependency or alters the product in transit, can affect all users at once and with devastating consequences. In this talk, we will talk about the current integrations of in-toto in the cloud/container space. In addition, we will cover the existing in-toto toolchains and how they can be used in various scenarios, from supply CI systems like Jenkins, to providers such as GitLab, and beyond. We will showcase these in different real-world use cases with concrete examples inspire attendees on how to secure their supply chain.
https://sched.co/VGqK
B
So
yeah
I
was
introduced.
Mexican
PhD
student
I'm,
studying
at
NYU
and
I've,
been
dedicating
most
of
my
20
20
years
sold
on
sort
of
protein
security.
I
started
like
five
years
ago.
Looking
at
this
problem
space
and
what
I
want
to
you
to
have
you
guys
carry
out
on
this
company
out
of
this
presentation?
Is
this
four
things?
First,
I
want
to
not
convinced
you
show
you
that
software
supply
chain
security
is
an
up-and-coming
problem
and
it's
a
it's
causing
like
very
devastating
compromises
all
across
the
industry.
B
I
also
want
to
talk
about
the
in
todo,
which
is
I,
think
it's
a
great
solution
to
start
addressing
this
problems.
Then
I
want
to
talk
about
how
is
in
total
being
used
today.
So
just
to
give
you
a
little
bit
of
inspiration
and
how
you
can
use
in
todo
to
protect
your
software
supply
chain
and,
finally,
to
close
things
out.
B
I
want
to
make
a
public
call
on
how
you
can
contribute
if
you're,
looking
for
a
good
open
source
project
and
under
the
CN
CF
umbrella
that
you
want
to
participate
and
start
making
tickets
are
in
code.
Getting
yourself
introduced
to
the
open
source
community
then
well
in
total.
Is
the
perfect
perfect
place
to
start?
B
So
when
we
talk
about
software
supply
chain
or
like
supply
chains
in
general,
we
usually
think
about
the
metaphor
of
shipping
things
out.
The
eventual
goal
of
a
supply
chain
is
to
get
things
an
inducer
to
a
consumer.
Somebody
out
there
that's
trying
to
use
your
product
now
when
we
talk
about
software.
B
Probably
everybody
here
can
recognize
all
of
this
logos
here
and
maybe
can
I
get
a
show
of
hands
of
how
many
people
think
that
their
software
is
similar
to
this,
maybe
a
little
bit
more
convoluted,
but
you
can
recognize
that
maybe
you
have
a
version
control
system,
you
have
a
build
farm
somewhere.
You
probably
package
things
out.
Maybe
since
this
is
the
cube
current
cloud
native
con,
we
are
talking
about.
B
Instead
of
putting
a
Debian
package,
you
probably
put
a
container
out
the
container
image
out
in
docker
hub
or
you
probably
make
a
whole
cloud
native
application
bundle
and
you
ship
it
to
the
users
or
hosted
yourself.
You
also
may
have
a
CIE
CD
system,
that's
constantly
testing
and
running
different
types
of
evaluations
on
your
source
code,
maybe
on
the
resulting
binary.
B
If
you're
doing
some
sort
of
static
analysis
of
of
binaries
memory
leaks
and
whatever
you
can
do,
you
can
do
all
of
these
sorts
of
things
to
your
pipeline
to
produce
better
and
more
trustworthy
software.
Now,
even
with
this
opinionated
very
simple,
almost
cartoonish
supply
chain,
we
have
compromises
that
can
take
place.
B
People
can
hack
into
the
version
control
system
and
they
can
replace,
for
example,
the
pseudo-random
seed
of
your
of
your
VPN
or
your
of
your
IP
SEC
stack
and
suddenly
they
can't
equipped
all
of
the
conversations
that
are
happening
and,
as
you
can
see,
because
I'm
flashing,
this
things
out
quite
fast
lis.
This
is
not
an
isolated
incident.
This
happens
a
lot,
and
this
was
just
for
the
version
control
system.
People
can
also
hack
into
your
bill
box
and
they
can
introduce
backdoors.
There
was
a
very
big
event,
I
think
it's.
B
Maybe
five
years
ago,
Xcode
ghost
somebody
published
the
backdooring
version
of
the
Xcode
SDK
and
all
of
the
iOS
apps
that
were
build
using
this
backward
version
of
the
SDK
had
the
backdoor
themselves.
This
eventually
flowed
all
the
way
to
the
App,
Store
and
people
that
were
consuming
this
blackboard
version
of
the
iOS
apps
were
compromised
themselves.
This
is
a
very
big
blast
radius.
This
is
a
very
impactful
to
compromise
many
users
in
different
environments
and
well.
This
is
not
an
isolated
incident.
Either.
B
Now
we're
starting
to
see
a
trend
here
you
can
also
hack
into
packaging.
You
can
hack
it
into
docker
hub.
You
can
hack
into
Red
Hat.
You
can
have.
You
can
hack
into
pretty
much
any
package
repository
that
you
can
think
of,
and
you
can
get
things
such
as,
for
example,
PHP,
my
admin
or
the
Azure
cloud
in
which
you
compromised
certain
parts
of
the
mirroring
infrastructure
just
to
get
yourself
into
certain
specific
demographics,
in
the
case
of,
for
example,
PHP
myadmin,
they
hacked
a
South
Korean
server.
B
What
I'm
sliding
all
of,
through
these
things,
I'm
not
trying
to
shame
anybody
in
the
industry
in
saying,
like
hey,
you're,
really
a
mistake
in
your
software
supply
chain
and
you
should
be
ashamed
of
yourself.
The
point
that
I'm
trying
to
make
here
is
we're
we're
stopping
here.
There
was
a
four
node
software
supply
chain
and
I'm
sure
that
many
of
you
were
like.
Oh,
this
is
so
silly.
This
is
so
simple
and
there's
so
many
avenues
of
compromise.
B
All
of
them
have
a
very
big
impact
on
users
on
your
reputation
on
your
budget
on
your
IP,
and
if
we
make
things
a
little
bit
more
complicated,
then
worse,
things
can
happen
or
it's
easier
to
like
lose
track
of
all
of
what's
going
on.
So
this
is
why
we
want
to
address
a
problem.
This
is
why
the
problem
is
so
complicated.
This
is
why
it's
so
difficult
to
fix.
Now.
I
know
that
many
of
you
out
there
are
thinking.
B
Well,
you
can't
you
can
probably
use
get
commit
signing
and
you
can
protect
your
version
control
system.
That's
a
great
idea
and
I
think
everybody
should
be
looking
and
striving
to
like
having
integrity
checks
over
your
version
control
system.
You
can
also
have
things
such
as
reproducible
bills
or
tea
PM's,
the
verifiable
compiler,
so
you
can
have
some
higher
degree
of
assurance
in
your
build
system.
You
can
have
things
such
as
TLS
or
GPG,
or
tough
in
such
a
way
that
you
can
have
a
higher
degree
of
resiliency
and
high
assurance
case
for
your
package.
B
Delivery
and-
and
all
of
those
really
is
a
great
I-
think
that's
a
great.
That's
a
great
approach,
I
think
that's
a
great
use
of
point
solutions
to
fixing
the
problem
of
software
supply
chain,
but
this
is
an
intro
to
talk,
and
you
wouldn't
be
surprised
if
I'm
going
to
tell
you
that
this
is
not
the
end
of
the
story.
Now
I
took
the
liberty
of
leading
a
bunch
of
Devils
out
of
the
picture
that
we
have
initially
and
there's
a
couple
left.
This
raises
a
couple
of
questions.
B
One
of
them
is
well,
even
if
you
have
a
point
solution,
how
can
you
be
sure
that
this
point
solution
is
being
followed?
And
if
that
point
solution
is
being
followed
and
you
have
a
product
or
an
artifact
was
created
during
the
parallel,
for
example,
the
VCS
step
is
that
specific,
artifact,
the
one
that's
being
shipped
into
the
build
farm,
or
is
it
any
any
other?
This
raises
questions
about
the
supply
chain,
integrity,
lack
of
compliance
and
any
other
way
of
representing
this
flow
of
things
throughout
the
supply
chain.
So
well.
B
Well,
what
to
do
with
in
toto
is
we
want
to
do
three
simple
things
we
want
to
describe
what
needs
to
happen.
The
software
supply
chain
we
want
to
describe
these
steps,
there's
four
steps,
or
this
end
steps
in
any
of
your
particular
supply
chains.
In
your
pipeline.
We
want
to
also
define
who
can
partake
into
this
operations
in
the
supply
chain.
We
want
to
say,
for
example,
that
only
my
build
form
should
be
building
and
doing
nothing
else.
B
It
should
be
touching
source
code
and,
finally,
we
want
to
make
a
tight
linking
between
the
artifacts
as
they
flow
through
the
chain.
We
want
to
say
the
version
control
system
produces
sources.
Those
are
the
sources
that
should
be
input
into
the
build
farm
and
the
build
farm
builds
a
binary
foo
and
that
binary
foo
is
the
one
that
is
eventually
going
to
float
into
the
packaging
or
to
my
container
or
into
any
way
that
I'm
going
to
release
things
out
now.
B
So
how
do
we
do
this?
We're
going
to
do
this
with
two
pieces
of
information?
The
first
one
is
called
a
total
labeled.
The
internal
layout
has
precisely
what
I
was
describing
earlier.
It
has
a
series
of
steps.
You
essentially
declare
welders
needs
to
be
a
version
control
system.
There
needs
to
be
a
build
farm,
there
needs
to
be
a
packaging
step
and
there
needs
to
be
a
CI,
that's
somewhere
in
the
space.
Then
you
want
to
define
who
can
protect
the
act
into
these
activities?
B
You
can
say
well,
Aaron
is
the
one
that's
in
charge
of
packaging
and
bob
is
the
builder
Bob,
the
Builder?
No
that's
Carol
and
Carol
is
the
builder.
So
Carol
should
be
the
one
that's
building
things.
I
am
actually
surprised,
Bob's,
not
the
Builder,
and
finally,
we
have
the
third
property,
which
is
registering
artifacts,
who
can't
create
what
and
who
can
consume.
What
and
how
do
these
things
link
together?
B
If
Carol
is
the
one
that's
building
Carol
should
be
reporting
what
she's
taking
in
from
about
the
version
control
system
missed
and
and
producing
about
and
Carol
should
also
report.
What's
the
binary
that's
produced
and
finally,
when
the
binary
that
is
produced
by
Carol
is
being
packaged
or
put
into
a
container
image
or
any
type
of
distribution
mechanism.
Well,
the
errand
should
report
what
she
got
in
and
what
she
produced
out
of
this.
B
With
this
we
have
a
very
tight
linking
we're
actually
building
a
software
supply
chain,
and
let
me
emphasize
a
chain
of
things
that
flow
together.
So,
finally,
we
want
to
also
declare
an
authoritative
figure
that
says
well,
this
is
what
needs
to
happen.
I
am
the
project
owner
I
am
the
project
manager.
I
am
the
PDF
L
of
an
open
source
project.
B
I
am
I,
am
the
top
of
this
project
and
I'm
going
to
say
with
my
signature
and
my
rubber
stamp
that
this
is
what
needs
to
happen
and
whenever
you
want
to
verify
this
specific
deployment
or
specific
package,
do
you
want
to
trust
me
to
tell
you
what
needs
to
happen?
So
that's
one
part
of
the
story.
Now
we
know
what
needs
to
happen.
We
know
that
all
of
these
operations
need
to
happen
in
certain
fashion.
All
of
this
specific
point
solutions
must
be
in
place
and
things
need
to
be
linking
together.
B
Knowing
what
needs
to
happen
is
only
half
of
the
story,
so
the
other
thing
that
we
have
is
or
that
you
need
to
use
when
you're
deploying
in
toto,
is
link
metadata,
link,
metadata,
think
of
it.
As
in
the
old
school
rubber,
stamping
of
usual
supply
chain
operations,
you
take
a
you,
take
something
something
in
then
you
perform
your
steps,
you
take
a
couple
of
bolts
and
build
a
car
door,
and
then
you
pass
it
over.
B
So
you
create
a
rubber-stamp
record
of
what
you
took
in
what
you,
what
you
create
it
and
you
pass
it
on
later
down
the
chain
of
custody.
So
in
the
internal
world
you
do
this
with
a
link
metadata.
These
are
basically
records
of
all
of
the
operations
that
happened
and
while
the
rest
of
the
story
is
well,
you
want
to
make
sure
that
what
needs
to
happen
matches
what
happened.
B
So
you
take
your
deployment,
your
package,
your
anything
that
you're
really
producing
it
can
be
a
deployment
llamó
for
all
for
all
that
matters,
and
then
you
are,
you
start
walking
back
the
paper
trail
using
all
of
the
stations.
You
can
start
checking
that
actual
supply
chain
steps
were
followed,
and
then
you
take
a
look
at
the
policy
and
say
well.
Is
this
actually
what
needed
to
happen
and
if
it
did
then
everything's
good?
If
there
was
some
breakage
in
linking,
then
something
happened
and
you
can
fail
verification.
B
You
can
tell
the
system
and
you
can
get
out
the
admission.
So
this
is
all
nice
and
good.
In
theory
this
should
work,
but
we
are
an
industry
conference
and
we're
probably
wondering
well
how
can
I
make
this
deployment
work
in
my
specific
configuration,
so
in
toto
has
a
bunch
of
deployments
out
there.
We
are
actually
protecting
you,
you're,
a
user
of
data
dog.
B
Like
many
of
these
logos
here,
all
of
the
integrations
are
being
tracked
all
the
way
back
to
a
developer,
using
a
hardware
token
to
date,
at
our
offices
and
there's
other
deployments
by,
for
example,
Microsoft
is,
has
seen
AB
test
deployment.
Tina
is
the
cloud
native
application
bundles.
They
want
to
be
able
to
have
you
track
all
the
way
from
the
version.
Control
system
were
all
the
way
to
the
left
until
the
everything
gets
back
to
the
cloud
native
application
bundle.
B
Now
of
all
of
this
examples,
I
was
thinking,
probably
the
one
that
you
people
are
more
familiar
with
this
again
raise
of
hands.
Who
here
uses
a
biplane
manager
such
as
Jenkins
I'm,
actually
glad
so.
You
can't
have
Jenkins,
be
a
pipeline
manager
and
you
can
have
a
gradual
rollout
of
in
toto
in
such
a
way
that
you
tell
well
Jenkins
anything
that
you
do
in
a
stage
just
create
this
rubber-stamp
record
ship
it
up
to
a
metadata,
server
or,
and
then
finally,
before
I
omit
any
artifact
to
my
cloud.
B
I
can
get
it
and
I
can
check
that.
The
policy
that
somebody
wrote
actually
followed
everything
that
Jenkins
and
outside
of
Jenkins
was
expecting
to
happen.
So
you
have
operations
that
happen,
rubber-stamps
that
flow
into
a
metadata
server.
Then.
Finally,
an
admission
controller,
enabled
by
Toto
sitting
in
your
cloud
that
at
the
time
of
admission,
it's
checking
that
all
of
the
policies
that
we
spoke
about
are
actually
being
checked
now
to
use
the
jackets
plugin.
B
B
Now
using
the
jackets
plugin,
you
get
a
you
get
a
bunch
of
nice
deployment
benefit.
The
first
one
is
that
every
artifact
by
the
artifact,
the
manager
and
Jenkins
is
registered,
for
you
know
where
it
came
from.
You
know
which
specific
notes
produced
it.
So
if
there
is
anything
that
was
fishy,
you
can
actually
nail
it
back
down
to
a
specific
box
or
a
specific
container
that
actually
perform
this
operation.
You
can
also
have
I
am
this
is
so
small?
B
You
can
also
have
a
verification
of
mission
time,
which
saves
you
a
lot
of
overhead
in
terms
of
verifying
software
supply
chain
elements
with
a
scanner
or
something
that's
actually
sitting
on
your
box
and
may
be
missing
something
you
can
also
have
things
that
are
sitting
outside
of
your
cloud.
Some
tools,
like
usek,
can
be
scanning
your
deployment
files
and
they
can
be
contrasting
them
with
your
with
your
containers,
so
you
have
things
that
tie
very
tightly
tied
together.
B
You
have
your
container
image
supply
chain,
and
then
you
have
your
deployment
configuration
of
supply
chain
and
both
of
them
meet
meet
and
admission
time,
and
you
can
get
both
things
together.
You
can
also
save
save
yourself
time.
Instead
of
calling
HTTP
web
hooks
in
admission
time
and
waiting
for
latency
to
be
affecting
your
deployment,
you
can
preemptively
start
doing
this
checks
and
saving
this
rubber
stamps
on
the
server
as
they
are
created.
B
You
can
also
have
things
such
as
better
audit
auditing
processes,
which
is
something
that
I
spoke
about,
and
you
can.
Finally,
oh
yes,
so
when
you
finally
deploy
this
you
can
you
basically
need
to
do
this
things
and
I
think
the
this
is
a
very
good
picture
on
what
you
on
what
you
get
for
free
by
doing
this
type
of
tightly
auditing
of
your
supply
chain,
because
you
defined
everything
on
a
single
source
of
true
policy
language.
You
need
to
introspect
into
your
software
supply
chain.
B
Even
if
it's
a
gradual
rollout
and
you
just
want
to
protect
the
specific
steps,
it
doesn't
force
you,
but
it
makes
you
look
back
into
well.
If
I
need
to
update
the
Jenkins
file,
do
I
need
to
review
the
policy
on
how
things
should
be
done.
Do
I
need
to
review
whether
my
Cusick
integration
or
my
vulnerability
scanner
should
change.
B
Consequently,
when
I
change
the
Jenkins
file
or
if
I'm
rotating
personnel
should
I
be
rotating
keys
around
is
or
if
I'm,
adding
new
elements
to
my
pipeline
should
I
be
going
back
to
somebody
or
a
security
team
to
actually
gate
it
and
tell
me
hey.
This
is
good
to
go
or
it
should
be.
You
should
be
considering
changing
this
by
plant
this
way.
So
that's
a
free
bonus
bonus.
You
get
a
you,
get
a
very
tightly
defined
process
that
you
can
actually
and
reasonably
update
and
improve.
B
As
time
goes
by
now
we
have
a
we
recently
integrated
the
cube
Seck.
You
can
basically
do
that.
You
can
talk
to
cube
Seck
and
tell
it
hey,
give
me
a
rubber-stamp
version
of
in
toto
of
your
scan
using
internal
metadata,
and
you
can
use
a
cube
Seck
key
to
know
that
they
are
actually
the
ones
that
are
performing
the
scan.
B
Security
ecosystem
now,
finally,
just
to
close
out
I
wanted
to
make
a
call
to
contributing
I
think,
there's
a
lot
of
interesting
things
that
you
can
do
to
help
with
a
in
toto.
We
have
three
implementations.
We
have
a
Python
implementation
that
it's
probably
the
one,
the
most
mature
one
you
can
check
out
roadmap.
We
have
pretty
much
full
spec
compliance.
We
have.
B
We
have
the
most
of
the
features
in
and
we
have
a
bunch
of
like
production
deployments
with
it.
So
it
is
probably
the
ones
that
you
should
be
looking
at
if
you
want
to
play,
but
something
that
I
was
thinking
that
we
could
use
from
new
contributors
is
to
make
a
deployment
test.
They
you
want
to
set
at
their
environment
from
scratch
without
knowing
much
about
project,
and
it
was
surely
run
into
things
such
as
well.
B
I,
don't
think
the
docs
are
clear,
or
you
know
what
I
tried
these
things
and
they
didn't
work
in
my
specific
mac,
OS
with
brew
installation
or
I,
was
using
windows
subsystem
for
Linux
and
all
of
those
things
are
useful
because
we
want
to
make
it
usable
for
the
for
everybody
that
wants
to
supply
chain.
If
you
are
more
interested
in
other
languages,
such
as
Java
or
golang,
those
those
also
have
a
roadmap,
but
they
are
a
little
bit
behind
in
features.
B
So
if
you're
excited
a
feature
that
you
think
that
should
be
added
to
those
languages,
then
by
all
means
take
a
look
at
the
issue
tracker
or
take
a
look
at
that.
We
have
a.
We
have
a
section
in
the
readme
of
the
features
that
we
are
thinking
should
be
added
next,
if
you
want
to
just
go
and
try
that
I
think
that
would
be
very
useful.
We
have
slack
channel
in
the
CN
CF
mailing
list.
We
have
a
IRC
channel
on
freenode.
B
If
you
also
want
to
apply
there
and
we're
pretty
welcoming
to
pretty
much
anybody
in
the
echo
system
that
wants
to
either
play
with
in
toto
developing
toto
or
or
more
now,
the
implementations
of
in
toto
are
not
the
end
of
the
story.
We
also
have
a
bunch
of
tools
out
there.
I
mentioned
there
say
Jenkins
plugin
that
you
can
use.
B
You
could
work
on
that
if
you're
somebody
that's
like
very
knowledgeable
of
Jenkins
plugins,
that
wants
to
like
add
more
features
or
probably
make
it
better
integrating
to
your
type
of
pipeline,
then
that's
a
also
great
way
to
get
started.
We
have
a
cube
control,
plug-in
cube
CTL,
depending
on
who
you
ask
or
cube
Ketil,
but
that
the
plugin,
for
example,
lets
you
scan
your
deployments
on
client
side.
B
You
can
also
hack
on
that
I
think
it's
a
I
think
it's
also
a
way
a
good
way
to
start,
if
you
want
to
like
run
verification
without
like
locking
your
deployments
on
production
just
yet,
and
the
cube
control
plug-in,
as
a
matter
of
fact,
is
the
same
code
base
that
goes
into
the
admission
controller,
so
you
can
get
code
in
there
and
consequently
making
the
quality
of
the
admission
controller
better
yeah.
And
then
we
have
a
well
yeah.
We
have
a.
We
have
other
ways
to
contribute.
B
C
C
B
You
can
check
at
any
point
you'd
like
we
think
that
it's
mission-critical
to
check
before
deploying
or
as
meaning
a
container,
but
if
you'd
like
to
save
yourself
time,
save
yourself
headache
and
do
verification
earlier
on.
You
can
totally
do
that.
The
framework
is
not
precluding
you
from
doing
so.
Something
that
I
think
is
another
great
area
of
improvement.
Is
we
have
all
of
this,
like
verification
left
with
having
something
like
an
integration
with
the
surface
mesh
in
such
a
way
that
you
can
revoke?
B
For
example,
an
attestation
for
uploading,
a
village
can
or
revoke
an
attestation
for
a
sign
out
from
a
release
manager.
Things
like
this
in
such
a
way
that
you
can
spin
down
a
container
that
is
related
to
that
supply
chain.
That's
a
great
another,
great
way
to
go,
but,
as
I
said
in
Toto's
as
a
whole,
so
want
to
be
able
to
not
only
attest
but
verify
at
any
point
in
the
supply
chain
in
such
a
way,
that's
flexible
and
powerful
to
with
powerful
semantics
to
allow
you
to
do
that.
D
B
So
the
public
keys
of
anybody,
that's
related
to
an
activity,
are
stored
on
the
layout.
Now,
how
do
you
distribute
those
private
keys
to
the
specific
stakeholders?
We
consider
that
a
little
bit
out
of
scope,
we
have
a
different
key
management
support.
We
support
GPT
keys,
if
you're,
for
example,
like,
for
example,
Debian.
Does
that
so
to
do
that,
we
also
support,
like
all
the
families
of
like
pkcs
X.
So
if
you
have
a
PKI
solution
that
you
can
export
those
keys,
you
can
also
do
that.
E
B
A
great
question,
so
it
depends
you
get
the
the
tool
itself
will
basically
tell
you
something's
wrong.
What
type
of
action
do
you
take
in
I?
Am
a
security
guy,
so
I
like
yeah.
You
should
not
deploy
that,
but
I
know
that,
for
example,
Debian
the
Debian
transport
for
reproducible
builds
as
a
matter
like.
It
is
a
fact
that
there's
things
that
aren't
producible,
so
your
running
total
verification
over
those
packages
and
it's
going
to
fail
just
because
of
the
sheer
nature
of
that
being
on
reproducible.
B
So
you
can
flick
a
like
a
switch,
and
you
can
say
instead
of
just
getting
it
out,
send
me
a
warning
or
print
a
big
red
banner
that
says,
like
you,
should
be
digging
into
this
specific
package.
You
could
do
so
in
the
admission
controller.
I.
Don't
think,
there's
code
to
do
that
just
yet,
but
I
think
that
would
be,
for
example,
a
great
the
first
feature.
B
So
glad
you
asked
that
question
I'm,
so
glad
of
all
of
the
questions,
they're
very
good
in
toto
is
a
totally
said
tool.
That's
also
recursive,
so
you
can't
pull
in
internal
metadata
from
your
dependencies.
The
ecosystem
is
a
little
bit
early,
so
there's
not
a
lot
of
metadata
around,
but
you
can
actually
do
a
you
say
you
have
a
layout.
That's
that
says:
well,
I
am
going
to
pull
in
all
of
Debian,
so
let
me
pull
all
of
the
metadata
for
the
VN
and
introspect
into
their
metadata
as
well.
A
So
yeah
now
I'll
even
add
one
more
point
to
that.
So
in
the
future,
when
the
next
release
of
Debian
is
built,
you'll
be
able
to
look
at
things
like
when
this
package
was
built.
What
what
was
the
software
supply
chain
for
the
compiler
that
was
compiled
last
time
to
do
this
and
for
the
operating
system
kernel
and
so
on?
So
you
do
get
very
much
this.
You
can
imagine
even
doing
this
across
projects
where
you
know,
there's
pip
installed
packages
that
were
built
on
a
debian
environment
that
had
this
and.
E
G
E
G
B
B
Another
great
question
so
I
think
tomorrow
or
right
now,
unfortunately,
there's
a
talk
by
the
graphy
esteem
in
which
they
are
going
to
mention
that
in
toto
can
be
put
in
put
into
a
graffities
metadata
server.
So
you
could
store
all
of
this
metadata
in
a
central
location
and
and
then
you
can
query
it
on
demand
in
toto
itself
is
not
the
science
thinking
of
a
specific
transport,
because
we
knew
that
mainly
supply
chains
use
different
types
of
transport
and
oftentimes.
We
get
people
that
come
to
us
and
say
like
hey.
B
C
You
you
sure
that
I
Jenkins
integration
on
it's
kind
of
a
bit
of
magic,
what's
happening
behind
the
scenes
for
integration
with
other
CI
systems.
What
would
be
the
steps
to
be
able
to
integrate
Toto
in
in
in
stuff
like
kidnap
CI,
where
each
job
is
its
own
container?
You
can't
really
wrap
that
job
with
are
abroad
that
checks.
What's
in
the
lucky,
you
have
to
integrate
Toto
into
the
image
that
runs
the
job,
which
makes
it
more
it's
more
maintenance.
C
B
So
well,
that
is
another
good
question.
I
think
that
there's
no
technical
limitation
to
that.
As
a
matter
of
fact,
the
data
dog
integration
they
built
what
they
call
an
untrusted
CI.
They
are
running
everything
on
get
lap
runners
that
spin
containers
that
then
die.
But
you
can,
you
can
assign
them
temporary
keys
and
you
can
also
set
up
a.
We
call
this
in
total
record
and
start
and
stop.
You
can
basically
record
the
state
of
the
ecosystem
or
the
container
file
system
before
it
right.