►
From YouTube: Putting the Supply Chain Pieces together: A Deep Dive into the Secure softwar... Michael Lieberman
Description
Putting the Supply Chain Pieces together: A Deep Dive into the Secure software Factory - Michael Lieberman, Citi
In this deep dive on supply chain security Michael Lieberman will go into a deep dive on an implementation of the CNCF's Secure Software Factory reference architecture. The talk will discuss the holistic nature of the supply chain security problem space and how the reference architecture highlights the software provenance gap that many projects and organizations trying to improve their security posture have. Michael will show how cloud native tools, configured and implemented in the right ways, can help in providing reliable provenance while increasing the trustworthiness of the artifacts you build. A system built on top of tools like Kyverno, Tekton, Chains, Spire and Sigstore will be shown how they can be tied together to build software that hits high SLSA levels.
A
A
A
So
what
is
the
secure
software
factory?
Well
at
a
high
level,
the
secure
software
factory
is
a
cloud
native,
but
technology
agnostic,
reference
architecture
for
building
software,
while
tracking
provenance,
in
other
words
it's
a
reference
reference
architecture
that
takes
your
continuous
integration
and
build
systems
and
helps
fill
in
the
supply
chain.
Security
gaps
like
helping
provide
a
chain
of
custody
for
your
project
from
source
code
to
package
software.
A
A
A
A
A
A
A
A
A
A
But
what
happens
if
the
build
tool
itself,
for
example,
go
build
or
maven
turns
out
to
be
doing
something
bad?
How?
How
can
we
detect
that?
That's
where
runtime
visibility
comes
in
by
using
ebpf
and
other
tracing
tools
like
tracy
or
falco?
You
can
monitor
what
is
happening
within
the
build
itself,
so
if
a
build
is
attempting
to
reach
out
to
malware.com
or
something
your
runtime,
visibility
should
be
able
to
detect
it.
A
A
A
Now,
let's
take
a
look
at
what
an
example
build
looks
like
when
using
the
secure
software
factory
architecture,
you
shouldn't
change
your
pipelines
to
no
longer
do
things
like
security,
linting,
sas
and
das
scans
are
similar.
Keep
running
security
focused
build
steps.
The
key
thing
that
the
secure
software
factory
does
for
us
is
help.
You
generate
provenance
around
your
supply
chain
that
you
can
have
some
confidence
around,
as
this
diagram
shows.
Each
step
is
recorded
by
the
pipeline
observer.
The
pipeline
observer
signs
attestations
regarding
each
step
and
forwards
that
metadata
over
to
some
storage.
A
A
By
recording
each
of
these
steps
and
pushing
them
out,
you
can
begin
to
generate
a
chain
of
custody
around
what
is
happening
in
your
build.
If
your
build
artifact
step
reports,
the
hash
of
its
output
as
something
different
than
what
the
publish
artifact
step
does,
then
you
know
something
has
gone
wrong.
A
Its
purpose
is
to
act
as
both
a
system
for
people
to
use
to
help
secure
their
internal
builds
and
software
supply
chain,
as
well
as
being
a
project
with
a
secure
supply
chain.
We
plan
to
do
this
by
following
the
various
best
practices
and
standards
defined
in
open
source
groups
like
the
cncf
and
openssf.
A
Some
of
the
best
practices
for
supply
chain
security
today
can
be
enforced
in
various.
You
know
sas
build
tools,
however,
that
often
doesn't
necessarily
fit
the
needs
of
some
organizations
and
projects
that
might
not
be
able
to
be
allowed
to
use
sas.
This
is
also
an
issue
for
folks
who
are
required
to
enforce
different
sorts
of
policy
that
are
not
supported
by
some
of
these
other
tools.
A
Ssf
tries
to
help
out
here
by
enforcing
enforcing
policy
at
multiple
different
levels.
There
are
the
ssf
defaults,
which
are
supply
chain
best
practices
that
should
be
enforced
regardless
of
an
organization's
individual
requirements.
These
are
things
like
pinning
to
a
hash
for
a
container
image
instead
of
using
the
tag
latest
or
that
all
build
pipelines
must
contain
an
s-bomb
generation
step,
an
individual
organization,
whether
it's
a
company
or
organization
like
cncf,
might
try
to
enforce
high-level
governance
rules
on
all
teams
and
projects
that
fall
underneath
them.
A
These
are
things
like
naming
schemes,
allowed,
programming,
languages
and
versions
of
build
tools,
underneath
that
there
might
be
further
restrictions
based
on
an
individual's
team's
requirements.
An
organization
might
say
python
java
and
go
have
all
been
approved,
but
a
specific
team
might
say
that
only
go
is
allowed
for
their
project.
A
You
can
then
further
constrain
configuration
and
policy
to
individual
projects,
so
a
new
project
under
a
team
that
uses
go
might
be
might
be
required
to
use
version
1.18
or
above
these
constraints,
help
organizations,
teams
and
projects
better
enforce
rules
and
controls
and
thus
help
increase
the
covenant.
Confidence
in
what
the
providence
attestations
are
telling.
You
is,
in
fact,
true.
A
It
does
so
by
using
a
configuration
language
called
q
q,
if
you're
not
aware,
is
a
language
that
has
been
seen
as
a
successor
to
google's
internal
configuration,
language
and
similar
languages
like
jsonnet.
It
helps
us.
Instead,
it
helps
us
by
instead
of
having
to
write
individual
yaml
for
both
our
techton
pipelines
as
well
as
kiverno
policy.
A
A
A
A
A
All
right,
so
I
already
have
the
initial
configuration
set
up,
so
it
already
has
a
key
for
this
particular
build
setup
and
I'm
just
going
to
run
an
example.
Build
packs
build
here
and
to
be
clear.
This
is
mostly
just
running
techton,
but
it's
running
it
within
the
context
of
sort
of
a
secure
software,
factory
configuration
and
setup.
A
So
it's
running
with
all
the
various
best
practices
you
would
want
to
have
set
up
in
this,
and
it
also
has
all
the
other
sorts
of
associated
tools
you
might
want
to
have
running
here
and
then
you
know
there's
certain
things
that
haven't
actually
been
deployed
out
to
ssf,
yet
like
runtime
visibility,
but
it
is
one
of
the
things
on
that
are
currently
being
worked
on.
So,
while
that's
running,
I
can
show
you
the
logs
here:
oh
actually,
it
ran
and
completed
already.
A
This
is
just
sort
of
the
build
logs
here.
You
can
see
it
generated
this
image,
which
you
know
it's
using
ttl.sh,
which,
if
you're
not
aware
of
it's
just
a
free
sort
of
test
registry,
for
you
know
pushing
out
images
that
you
want
to
expire.
So,
for
the
sake
of
this
demo
very
straightforward
and
I
can
go
and
validate
that
techton
chains
here,
which
is
one
of
the
components
of
ssf,
has
come
through
and
signed.
Yes,
it
has
so
if
I
run
a
couple
of
these
other
commands
here,.
A
So
if
I
run
crane,
which
is
a
a
tool
to
just
that,
allows
me
to
manipulate
and
see
what's
inside
of
an
oci
registry,
I
can
see
that
hey.
I
have
an
image
here
and
this
image
contains
a
latest
and
it
contains
a
dot
att
which,
if
you're
not
familiar
with,
is
just
sort
of
a
cosine,
sorry
sigstor
based
at
a
station,
and
it
also
contains
a
signature
here
and
now.
If
I
want
to
go
and
validate
that
this
image
has
been
signed
with
the
appropriate
signature,
I
can
go
and
validate
that
right.
A
A
Yep
and
so
it's
able
to
say
that
as
well,
but
now
let's
go
and
actually
take
a
look
at
what
that
attestation
is,
is
telling
us.
So
I
can
download
that
at
a
station-
and
you
know
essentially
base64
decoded
and
fetch
out
the
actual
data-
that's
in
there.
So
as
you
can
see
in
here,
you
know
I
have
the
name
of
the
image.
A
I
have
a
digest
of
the
image,
and
this
is
for
those
who
aren't
familiar.
This
is
a
salsa
at
a
station,
and
what
this
tells
us
is,
it
tells
us
all
sorts
of
nice
little
bits
of
information.
This
information
is
coming
out
of
stuff
like
techton
chains,
but
in
here
I'm
able
to
do
things
like
I'm
able
to
see
what
are
the
environment
variables
right.
I'm
able
to
go
and
check
stuff
like
what
was
the
entry
point
for
the
build?
A
What
was
I
can
also
check
in
here?
What
was
the
builder
for
the
build
right
like
in
this
case?
It's
using
you
know
this
sample
builder
image
and
I
can
do
all
sorts
of
other
things
I
can
see
when
the
build
started
when
it
finished,
and
all
of
this
metadata
is
super
useful
to
me,
when
sort
of
figuring
out
you
know,
did
something
happen
to
my
build
right.
A
If,
if
I
expected,
you
know
a
particular
builder
to
be,
you
know
if
I
expected
to
use
a
different
kind
of
builder
and
it
didn't
match
this.
Well
then
I
know
something
went
wrong
right
and
I
can
use
all
of
this
metadata
coming
out
of
here
and
you
can
imagine
if
I
generated
an
s-bomb,
I
would
have
a
similar
sort
of
attestation.
That
looks
like
this.
That
has
all
the
metadata
associated
with
that
s-bomb
and
I'd
be
able
to
go
and
validate.
A
That
you
know
did
that
was
that
s-bomb
generated
by
a
build
tool
that
I
you
know
that
I
trust.
If,
yes,
then,
hey
great,
you
know
we
can
approve
this
sort
of
thing
to
go
to
the
next
level
to
be
promoted
to
production
whatever.
If
I
notice
that
you
know
it's
using
a
tool
that
hasn't
been
approved,
we
can
control
that
through
stuff,
like
policy
as
code.
A
All
right
so
just
to
kind
of
quickly
show
a
little
bit
of
what
this
configuration
looks
like
well.
The
configuration
here
is
all
in
queue
and
it
looks
very
similar
to
json,
but
what
this
actually
does
is
using
our
the
rest
of
our
tooling.
It
allows
us
to
generate
the
yaml
configuration
for
tecton
as
well
as
other
things
like
you
know.
A
And
then
you
know
those
sorts
of
things
help
provide
increased
confidence,
and
so,
when
you
go
to
production,
you
can
start
to.
You
know:
ask
via
also
policy
is
code
using
stuff.
Like
emission
controllers,
you
can
say:
does
it
have
a
valid?
You
know,
salsa
attestation?
Does
it
have
a
valid
signature?
Does
it
have
a
valid
s-bomb?
A
A
Assuming
the
answer
is
yes
for
all
those,
then
you
can
have
increased
confidence,
that
everything
looks
good,
that
your
supply
chain
is
secure
and
you
can
then
approve
it,
and
you
know
do
something
akin
to
you
know
what
google
calls
binary
authorization,
but
the
basic
idea,
just
sort
of
being.
You
know
you
can
sort
of
stamp
your
artifact
for
for
for
use
anyway.
That's
about
it
all.
I
have
right
now
and
I
wanted
to
then
open
it
up
for
questions.