►
From YouTube: Software Supply Chain SIG Meeting - Mar 24, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
D
B
B
So
maybe
we
can
slowly
start
while
others
join
so
welcome
everyone
for
our
second
meeting
for
the
special
interest
of
software
supply
chain.
Last
week,
two
weeks
ago
we
had
the
cop
meeting
for
our
sick,
discussing
about
how
we
can
work
on
contributing
to
overall
efforts
to
improve
sacred
posture
of
open
source
projects
from
cicd
perspective,
and
that
was
a
mainly
brainstorming
discussion
and
what
we
can
do
and
how
we
can.
B
You
know,
work
within
the
sick
and
we
had
some
slides
to
kick
off
discussion
during
that
meeting.
So
if
you
are
wondering
what
we
discussed,
you
can
take
a
look
at
the
meeting
presentation
that
is
linked
on
the
meeting
minutes
of
the
previous
meeting,
and
we
took
some
notes
on
the
slice
directly
and
if
you
have
you
know
any
additional
comments
or
ideas,
you
can
bring
them
to.
B
You
know
agenda
for
upcoming
meetings
and
I
see
quite
few
new
faces,
and
that
is
the
other
thing
we
did
during
the
previous
meeting.
We
simply
introduced
ourselves
and
what
we
expected
to
achieve
within
the
sequel.
What
we
want
to
do
with
the
seek.
Maybe
if
I
can,
you
know,
call
out
some
of
you
who
joined
first
time
today
to
introduce
yourselves,
I
hope,
that's
okay.
E
F
F
F
G
I
Hi,
I'm
mike
lieberman.
I
do
supply
chain
security
over
at
city
and
I'm
also
one
of
the
leads
on
the
supply
chain.
Security
working
group
over
at
the
cncf
and
also
we
have
recently
contributed
a
sort
of
a
a
system
that
is
sort
of
a
implementation
of
the
cncf's
reference
architecture.
On
what
we're
calling
the
secure
software
factory,
which
I'll
be
giving
a
demo
in
a
little
bit.
I
K
B
B
So
we
have
a
very
limited
agenda
today
because
we
want
to
spend
most
of
the
meeting
time
for
presentation
from
mike,
as
well
as
a
follow-up
conversation,
because,
like
the
secure
software
factory,
looks
pretty
awesome,
I've
been
playing
with
it
for
last
couple
of
weeks,
so
it
would
be
great
to
spend
the
remainder
of
meeting
for
any
questions,
comments
or
ideas
about
sacred
software
factory
and
perhaps
the
you
know,
possibility
of
using
secure
software
factory
as
one
of
the
projects
as
part
of
the
poc.
We
intend
to
bring
up
under
this
sick.
B
B
The
regular
meeting
time
is
one
hour
later
for
the
participants
from
north
america
and
for
european
participants.
We
are
meeting
at
the
you
know
usual
time,
but
europe
is
moving
summertime
this
weekend.
I
believe
so
because
of
that
we
will
change
the
meeting
time
to
3
p.m,
utc,
starting
from
next
meeting
on
april
14th,
which
will
bring
the
meeting
times
their
usual
times
for
everybody
like
for,
I
think,
8
a.m
for
west
coast,
us
and
5
pm
for
europe
and
vice
versa.
B
B
B
The
cdf
comment
has
such
as
other
six
and
technical
side
committee
to
make
sure
you
join
at
right
time
after
this
summertime
change
happens.
So
that
is
a
reminder
and
the
other
reminder
is
about
the
presentations.
As
we
discussed
during
the
previous
meetings.
We
will
invite
contributors
from
other
communities
to
come
and
join
to
our
stick
to
present
the
projects
initiatives
they
have
there
in
their
communities
and
the
first
one
of
such
presentations
will
be
given
by
mike
today,
but
we
have
few
more
presentations
scheduled
for
upcoming
meetings
and
those
presentations.
B
What
is
the
topic?
Who
is
presenting
date
and
time?
They
are
listed
on
our
presentations
document,
which
is
linked
on
the
meeting
agenda
document,
so
this
week
you'll
have
the
presentation
from
mike
and
during
our
next
vitic,
which
will
happen
on
14th
of
april.
We
will
have
priya
visiting
us
talking
about
tecton
cd
chains
28th
of
april.
We
will
have
thomas
streets
from
diner
trace
joining
us
talking
about
cncf
talk,
abdullahi
and
potato
head,
and
then
james
rollins
will
join
us
may
12th
to
talk
about
cartographer
and
we
will
probably
add
more.
B
You
know
presentations
to
upcoming
meetings,
and
this
means
that
if
you
have
something
to
present,
it
doesn't
have
to
be
a
project.
It
could
be
a
topic.
You
can
simply.
You
know,
list
your
presentation
on
this
document
and
just
say:
well,
hey.
I
want
to
talk
about
this
topic.
Can
I
you
know,
get
30
minutes
of
the
meeting
time
and
then
we
will
make
sure
you'll
get
thirteen's
in
the
upcoming
meeting
for
that.
I
D
I
It's
just
currently
going
through
cncf
talk
approval,
but
to
kind
of
give
you
just
sort
of
a
highlight
of
all
the
of
what
it
is,
is
it's
a
reference
architecture
that's
intended
to
help
with
building
of
software
artifacts
securely
right
in
a
way
that
we
can
also
begin
to
bring.
You
know
some
reasonability
about
around
our
supply
chain
and
the
core
of
it
is
mostly.
Let
me
see
if
I
can
find
this.
I
So
the
the
core
of
of
the
purpose
of
the
secure
software
factory
is
around
three
sort
of
critical
concerns.
One
is
provenance,
verification,
the
other
is
trustworthiness,
and
then
the
third
is
sort
of
recursively
doing
that
for
all
of
your
dependencies,
and
so
the
the
key
thing
that
has
sort
of
been
missing
from
a
lot
of
the
stuff
in
the
sort
of
cid
cicd
space
has
been
whoops
a
lot
of
stuff.
In
the
cicd
space
has
been
around
sort
of
provenance
right,
you
know,
yes,
we're
doing
security
scans.
I
Yes,
we're
doing.
You
know
linting
and
security,
linting
and
sas
and
das
and
all
those
sorts
of
things.
The
problem
that
has
come
up
time
and
again
is
how
do
I
know
that
I
ran
the
scan
on
the
right
artifact.
How
do
I
know
that
somebody
didn't
replace
that
artifact?
How
do
I
know
that
what
I
built
was
actually
the
source
code?
I
thought
I
was
building.
How
do
I
know
that?
I
you
know
something
didn't
come
in
in
the
middle.
I
I
So
let
me
go
up
here,
so
these
are
some
diagrams.
Is
it
readable
for
everybody?
Do
I
need
to
make
anything
larger,
all
right
cool,
so
the
secure
software
factory
sort
of
exists
in
the
same
space
that
you
would
imagine
a
lot
of
other
sort
of
ci
cd
and
build
tools
would
live
in
right.
So
you
have
your
developer.
I
Your
developer
gets
feedback
from
you
know:
ci
cd,
your
developer
pushes
code
to
source
code
control,
and
then
you
know
your
ci
cd
system
in
this
case
we're
calling
it
the
secure
software
factory,
pulls
code
from
source
code
control
and
then
builds
it
and
does
a
bunch
of
you
know
does
whatever
you
need
it
to
do
and
then
pushes
those
artifacts
to
artifact
storage.
It
also
pulls
dependencies,
it
needs
from
artifact
storage
and
then,
as
you
can
probably
imagine
you
know
in
production,
you
want
to
sort
of
validate
that
hey.
I
I
want
to
validate
that
the
signatures
and
attestations
that
are
coming
out
of
the
secure
software
factory
right
that
I'm
only
running
artifacts
in
production
that
have
those
signatures
and
attestations
quickly.
Here.
This
is
just
sort
of
a
level
down
deeper,
more
zoomed
in
look
there,
but
if
I
now
kind
of
go
in
here,
you
can
see-
and
let
me
make
this
larger
there's
a
couple
things
here.
I
So,
ideally
right
in
the
middle
here,
is
you
have
your
build
environments
right?
So
these
are
the
actual
build
containers
that
are
running
your
builds,
and
so
how
do
we
make
sure
that
you
know
they're
running
the
right
things
that
they're
running
the
right
things
in
the
right
order?
That
things
are
not
you
know,
things
are
not
being
skipped
and
that
you
know
you're
not
trying
to
pull
stuff
from.
You
know
you're
not
trying
to
pull
things
from
inappropriate
places
right.
I
I
I
Sure
and
I'll
I'll
zoom
out
and
move
over
to
some
of
the
other
places
when
when
it's
when
we
need
to
get
there,
okay
cool
so
so
the
pipeline
observer
in
this
case
is
something
like
techton
chains.
So
right
so
techton
is
running
the
builds,
but
you
need
something
to
actually
record
what
is
happening
in
those
builds.
What
is
tecton
reporting
back
out
right?
One
of
the
big
things
that
has
kind
of
come
out
there
right
is.
I
We
don't
want,
builds
themselves
as
in
like
what's
happening
inside,
of
a
build
to
self-report,
because
you
know
a
build
because
it's
arbitrary
code
written
by
who
knows
you
know
written
by
who
knows
right,
like
they
can
misreport
a
lot
of
information.
So
that's
why
you
need
something
like
techton
chains
and
so
with
that
right,
techton
chains
needs
to
validate.
You
know
the
identities
of
what
is
actually
running,
those
builds
and
that's
where
the
workload
of
tester
and
node
attesters
come
into
play,
and
this
is
sort
of
for
folks
who
are
familiar
with
it.
I
This
is
where
sort
of
spiffy
spire
comes
into
play.
Where
you
know,
when
I
spill
up
spin
up
a
build
container,
we
want
to
validate
that
both
you
know
hey
when
I'm
spinning
up
this
techton
build.
Is
it
running
on
a
kubernetes
node
that
I
own
right?
How
do
I
know
that
it's
not
running
on
some?
You
know
compromise
node.
Well,
you
can
use
a
noda
tester
for
that
and
the
same
thing
goes
with
workloads
right.
I
How
do
I
know
that,
when
I'm
spinning
up
the
container
that
I'm
actually
spinning
up
a
container
that
you
know
says
hey
look,
this
is
where
you
know
the
code
lives
and
you
know
here's
here's
the
parameters
to
the
build.
Well,
that's
where
the
workload
attester
comes
in,
so
that
you
can
actually
validate
hey.
I
Am
I
actually
pulling
the
code
from
the
right
place,
those
sorts
of
things
because
then,
if
the
eventually,
if
you
know
the
workload
when,
when
the
container
first
gets
spun
up
it
sort
of
generates
almost
like
a
hash
of
all
of
that
metadata
regarding
the
spinning
up
of
the
container,
and
if
that,
if
that
hash
does
not
match
the
hash
at
the
end,
well,
techton
will
not
sign
it
right
because
they'll
say
wait
a
second.
These
hashes
don't
match.
Something
might
must
have
changed
in
the
middle,
where
you
know
hey.
I
I
So
next
up
right
is
then:
okay,
well,
that's
sort
of
recording
the
build
and
all
that
sort
of
stuff.
So
what
are
we
doing
regarding
making
sure
that
only
approved
bills
are
running?
Well,
that's
where
policy
sort
of
management
and
the
emission
controller
comes
into
play.
So
not
only
you
know,
not
only
do
we
need
a
mission
controller
for
production
workloads
to
make
sure
that
only
things
that
are
signed
by
you
know
your
secure
software
factory
are
allowed
in
production,
but
you
also
need
to
do
the
same
thing
for
your
build
environments
themselves.
I
Right,
you
need
to
make
sure
hey
is
the
build
image
that
I'm
using
signed
by
our
key
or
signed
by.
You
know
a
key
that
we
trust
or
identity,
that
we
trust,
and
so
this
is,
you
know
another
thing
that
comes
into
play
right.
You
know
when
I'm
running
techton,
how
do
I
know
that
I'm
running
actual
tecton?
How
do
I
know
somebody
hasn't
replaced
the
tecton
images
with
something
else
right?
I
want
to
make
sure
that
the
tecton
images
that
I'm
using
are
signed
by
you
know
the
techton
maintainers.
I
You
know
if
I
trust
them,
and
so
this
is
kind
of
where
a
lot
of
that
sort
of
stuff
comes
in
now.
Finally,
right,
one
of
the
things
that
that
the
other
piece
of
the
puzzle
is
runtime
visibility,
so
you
also
need
to
be
able
to
say
how
can
I
look
at?
What's
happening
in
a
build
so
that
I
can
detect
anomalous
behavior
right,
so
this
is
stuff
like
hey
I'm
running
a
build,
even
though
I
didn't
give
that
build
network
access
right.
I
I
Hey
it's
trying
to
reach
out
to
the
internet,
to
malware.com
or
whatever
right,
oh,
okay!
Well,
I
want
to
know
that
right.
So
not
only
do
I
want
to
lock
down
the
build,
but
I
still
want
to
detect
anomalous
behavior
like
it's
trying
to
go
out
and
do
something
it's
not
supposed
to
hey.
You
know
this
is
in
one
of
the
demos
we
gave
tim
and
I
had
given
at
supply
chain
security
con
last
year
at
kubecon
was
we
showed
off?
I
So
you
know
this
sort
of
looks
like
your
average
pipeline,
but
you
know
where
you're
sort
of
fetching
some
code
and
some
dependencies
you're.
You
know
linting
it
or
whatever
in
your
pre-build
tasks
and
so
on
you're
building
the
the
artifact
you
know,
you're
building
the
artifact,
then
you're
pushing
out
those
artifacts.
I
Sorry
I
should
say
then
you're
scanning
those
artifacts
or
whatever,
and
then
you're
publishing,
let's
say
the
artifact
at
the
end.
And
obviously
this
is
just
a
a.
This.
Is
not
what
happens
all
the
time
you
know
you
can
have
stuff
that
happens
after
publishing
or
or
whatever,
but
you
know
just
to
keep
it
sort
of
simple
here
and
so
the
the
key
pieces
here
is
just
once
again.
The
pipeline
observer
is
recording
all
of
this
information
and
pushing
the
attestations
and
signatures
to
metadata
storage.
I
So
these
might
be
things
like
hey
I,
you
know
this
is
some
sort
of
sass
scan,
that's
sascan
ran
and
then
it
sort
of
says:
hey,
I'm
gonna
sign
off
on
that
scan
with
you
know
my
identity
and
also
pushes
it
to
metadata
storage.
So
you
know
at
the
end,
hey
does
this
have
an
approved.
You
know
you
know
sas
or
das
scan.
I
The
configuration
is
sort
of
generating
the
actual
yaml
configuration
for
us,
but
allows
us
to
sort
of
tie,
tecton
pipelines
and
chains,
definitions
to
other
components
in
there
as
well
like
kiverno
policies.
So,
instead
of
saying
hey,
techton
chains,
here's
the
key
you
should
be
looking
at
and
then
having
to
write
up
a
separate
policy
that
says:
hey
keeverno,
now
look
at
this
key.
We
have
one
configuration
file
in
queue
that
tells
it
says.
Okay
now,
general
generate
me.
I
A
key
verdo
policy
and
a
techton
chains
configuration
that
points
to
this
key
right,
so
we
can
have
it
all
in
one
place.
So
if
the
key
ever
changes,
it's
just
one
thing
that
we
can
kind
of
push
out
there,
because
one
of
the
big
things
right
is
is,
as
you
know,
this,
as
our
sort
of
cicd
setup
becomes
more
and
more
complicated,
you
want
to
kind
of
still
have
all
that
configuration
live
as
much
as
possible
in
one
place
have
stuff
like
inheritance
and
and
sorry.
I
I
should
say
more,
like
composition,
where
you
know,
one
configuration
file
can
sort
of
generate
everything
we
need,
and
so,
if
I
go
back
up
here,
what
that
allows
us
to
do
is
say:
hey
we
can
generate
configuration
that
is
secure
right.
That's
where
this
ssf
defaults
come
in
to
play,
then
you
can
say
well,
individual
organizations
might
have
specific
things
they
want
to
have
right.
Maybe
they
want
to
have
naming
constraints,
maybe
they
want
to
have
yeah.
Maybe
they
want
to
have
like
a
name
policy.
I
Maybe
they
want
to
have
you
know:
hey
we're
only
a
java
shop
right,
so
we
only
allow
java
builds.
You
can
sort
of
constrain
it
at
at
the
queue
level.
That
says:
okay,
great.
If
somebody
tries
to
build
something
that
isn't
java.
Sorry,
you
just
it
won't
work
and
the
same
thing
goes
with
stuff.
Like
individual
teams
maybe
have
their
own
naming
policy.
I
I
You
know
it
won't
actually
deploy,
and
then
we
can
also
validate
it
as
well
against
you
know,
eventually
against
stuff,
like
kiverno
and
so
so
at
runtime
it'll
also
validate
it,
but
at
deploy
time
it
will
also
do
that
same
sort
of
validation
cool.
So
let
me
stop
sharing
so
before
I
give
go
into
to
more
of
a
hands-on
demo
of
a
hands-on
keyboard
demo,
any
questions
about
anything
I
showed
off
so
far.
I
L
Say
we
want
to
do
this?
Do
you
know
like
the
same
thing
with
you
know,
like
some
other
tool
say
we
want
to
use?
You
know
like
jenkins,
x
and
not
use.
You
know
like
techton.
How
hard
would
it
be
to
implement
that?
So
you
know
like
jenkins
x
uses,
you
know
like
techton,
but
we
don't
use
chains.
So
that's
one.
You
know
like
project
that
we
want
to
add.
You
know
like
very
soon
that
so
and
like
maybe
even
build.
L
I
Sure
so
the
secure
software
factory
reference
architecture
so
most
of
those
diagrams
at
the
top
there
yeah
use
whatever
you
know,
use
whatever
you
see
fit
that
that
sort
of
matches
that
general
flow-
and
you
know
once
again.
I
didn't
go
too
deep
into
the
actual
reference
architecture
itself,
which
will
be
published
in
the
next
couple
of
weeks.
But
let
me
actually
just
send
the
link
you
should
have
read
access
to
it.
I
But
the
thing
there
that's
what
it
describes
in
in
sort
of
detail,
and
it
literally
does
not
talk
about
what
tools
or
anything
right.
It
just
says
you
should
have
a
tool
that
does
that
that
performs
this
sort
of
action,
and
so,
if
jenkins
x
and
whatever
else
can
hit
that
great
as
far
as
ssf
our
reference
sort
of
our
reference
implementation
here
or
or
you
know
what
we've
built
at
city
and
contributed
to
open
ssf,
so
ssf
right
now
supports
chains
and
pipelines
and
kiberno
and
whatever.
I
But
you
know
we
are
more
than
open
to
sort
of
supporting
additional
tools
as
well,
because
the
once
again,
the
other
thing
that's
really
nice
about
q
is
q,
allows
us
to
sort
of
abstract
a
lot
of
that
sort
of
stuff
away.
Obviously,
there's
going
to
be
a
lot
of
practical
things
where
you
know
you
might
end
up
needing
to
redo
a
lot
of
things.
I
I
You
know
some
concerns
there,
but
as
long
as
you've
sort
of
defined
that
interface
at
top-
and
you
have
the
individual
implementations
underneath
yeah
you-
I
don't
see
why
not
outside
of
just
you
know
the
practical
concerns
of
potentially
supporting
you
know
if
we
were
to
say:
hey
will
ssf
support
jenkins
x,
let's
say
ssf
the
code
right.
You
know
it's
just
more
of
a
hey.
If
there's
somebody
who's
gonna
manage
it
and
maintain
it
then
sure,
okay,.
I
B
I
Yeah
and
to
be
clear,
a
lot
of
this
is
just
it
was.
We
originally
were
calling
it
the
secure
software
factory
as
well,
and
then
that
obviously
led
to
confusion
where
people
thought
that
the
the
code
was
actually
also
written
by
the
cncf,
and
given
that
this
got
donated
to
open
ssf,
we
want
to
make
sure
that
it
was
a
clear
distinction
and
then
the
other
thing
that
had
come
up
was
because
the
secure
software
factory
coming
from
cncf
was
the
reference
architecture,
and
the
has
a
very
specific
meeting.
I
People
were
thinking.
Oh,
this
is
the
only
secure
software
factory,
and
so
we
wanted
to
sort
of
separate
it
out
and
because
enough
people
were
already
calling
the
code
ssf,
we've
just
sort
of
said:
hey
we
and
the
acronym
is
ssf.
You
know,
ssf
is
a
secure
factory,
so,
like
that's,
we've
kind
of
reworded
it.
If
folks
still
are
confused,
we
can
always
rename
it
but
yeah.
Sorry
for
the
confusion.
B
N
I
It's
the
general
case
for
all
forms
of
software,
there's
obviously
going
to
be
specific
constraints
that
you
know
might
hit
closed
source
versus
open
source,
but
generally
you
know
this
should
be
applicable
across
the
board.
The
practices,
at
least,
should
be
applicable
across
the
board
and
in
fact,
the
way
we've
structured.
I
The
code
is
such
that,
if
you're
an
open
source
group
that
has
a
specific
policy,
you
can
implement
that
specific
policy
in
you
know
something
like
this
and
then
the
same
thing
is:
if
you're,
you
know
a
closed
source,
you
know
you.
Can
you
can
implement
that
same
sort
of
policy
right?
You
know,
hey.
We
only
pull
artifacts
from
our
approved
artifact
repository
great.
This
sort
of
thing
can
support
sort
of
keying.
You
know
just
saying
great
no
builds
are
allowed
to
download
from
you
know
anywhere
other
than
here.
That
kind
of
thing.
I
No,
so
it's
still
the
same
sort
of
thing
right
where
you
can
validate
based
on
attestation
signatures
as
well
as
sort
of
pinning
to
hashes
as
well.
So
as
long
as
vendors
are
using
sort
of
right
now
we're
supporting
the
sig
store
model,
but
as
long
as
vendors
are
signing
their
stuff
with
sigstor
right-
and
you
say
great-
I
trust
that
identity.
A
I
Okay,
so
just
to
kind
of
run
through
a
little
bit,
and
it
might
be
a
little
hard
for
some
folks
to
read,
but
don't
worry
about
it
too
much
is.
I
am
a
sort
of
spun
up
a
mini
cube,
installed,
ssf,
which
consists
of
tacton
tecton
chains
generated
some
keys,
set
up
kiverno
and
some
example
policies,
and
let
me
just
show
you
what.
D
D
I
Okay,
so
this
is
sort
of
an
example
pipeline.
It's
running
some
stuff
in
there.
If
I
and
all
of
the
everything
I'm
about
to
show
you
here
is
stuff
that
is
already
in
the
code
where
you
can
follow
along
if
you
wanted
to
run
the
same
sort
of
thing,
so
this
is
just
sort
of
going
out,
building
and
and
so
on,
and
while
that's
doing
that,
let
me
just
switch
over
to
the
dashboard,
so
you
can
kind
of
maybe
get
a
bit
of
a
better
look
here.
I
So
just
to
kind
of
go
through
what
is
it
doing
right?
It's
doing
a
normal
sort
of
tecton
thing.
It's
cloning,
a
repo
and
once
again
a
lot
of
these.
You
know
pipelines
right
now
are
very
much
simplified
in
reality,
you'd
probably
do
a
lot
of
like
you'd
have
a
scanning
step.
You'd
have
all
that
those
sorts
of
things
and
whatnot,
and
so
you
know
here
we
have
something
we're
building
an
image,
I'm
pushing
it
out,
we're
generating
an
s
bomb
for
that
image
as
as
well.
I
And
then
you
know
if
the
image
that
gets
pushed
out
is
over
here
and
whatever,
and
then
we're
going
and
deploying
the
image
you
know.
Ideally,
we
probably
wouldn't
deploy
it
as
part
of
the
same
pipeline.
We'd
have
some
approval
steps,
but
just
for
the
sake
of
the
demo,
that's
some
stuff
we're
doing
there,
and
so
just
to
kind
of
go
back
to
the
code.
D
I
All
right,
okay,
so
I'm
just
gonna
fetch
information
about
the
image
and
the
task
run
just
so
that
we
can
go
in
and
and
just
to
show
you
what's
actually
there
right.
So
the
image
right,
there's
we're
using
a
sort
of
free.
What's
it
called
the
registry
here
that
expires
after
an
hour.
Don't
worry
about
it
too
much,
but
the
main
thing
is
hey
my
image:
it
has
an
attestation,
it
has
a
signature,
and
so
you
know
techton
as
your
where,
like
you
know,
goes
and
signs
those
things.
I
Right,
and
so
here
is
the
actual
attestation
that
came
out
of
it.
So
this
is
a
salsa
provenance
statement.
Sorry
it's!
It
was
an
in
toto,
it's
an
entota
statement
with
salsa
providence,
predicate
format
inside
and
you
know
it
has
all
this
information
about.
You
know
what
was
the
builder
images
that
were
used
and
and
so
on
and
so
forth,
and
then,
in
addition
to
that,
if
you
know
so,
that's
all
the
stuff.
That's
in
there
we're
also
using
some
techton
internal
internal
storage.
I
This
is
now
running
inside
of
my
environment
and
just
to
kind
of
show
you
that
something
would
not
like
some.
If
I
did
not,
if
I
was
using
something
that
wasn't
built
by
the
thing
it
would
not
run,
I
can
show
you
that
here
right,
where
hey
I'm
trying
to
run
this
image
right
in
you
know
the
theoretical
production
namespace
here
and
hey
the
ki
verno
says
well
hold
on
you,
don't
have
the
right,
attestations
and
yeah.
So
any
any
questions
about
anything
I
showed
off
here.
I
I
We
are
validating
that
we're
using
valid
tecton
images
signed
by
tecton
keys
or
we're
using
other
sort
of
approved
images
signed
by
folks.
We
trust-
and
so
if
somebody
came
in
with
a
different
type
of
builder
and
they
didn't
have
the
right
sorts
of
keys,
just
wouldn't
run,
and
then
you
know,
by
going
through
all
that
we
can
start
to
sort
of
build
provenance
throughout
that
sort
of
process.
I
Where
you
know,
we
have
at
least
some
level
of
guarantees
that
we
pulled
code
from
the
right
spots
that
if
we
pull
down
dependencies
that
we
pull
down
dependencies
from
the
right
spots,
that
and
then,
when
you
know
we
build
it,
hey
we
think
generally
hey.
Maybe
this
thing
you
know
wasn't
compromised
or
whatever
there's
obviously
a
lot
more
work.
That
needs
to
be
done
on
that
that
space
as
well
and
then,
when
we
sort
of
build
everything,
we're
now
sort
of
saying
great.
I
You'd
probably
have
something
like
a
google
style,
binary
authorization
sort
of
setup,
but
you
know
for
now
for
the
simple
case:
you
can
probably
do
something
like
kiverno
and
then
obviously
a
lot
more
stuff
is
going
to
be
built
out
over
time
and
if
folks
want
to
see
the
code
real,
quick
of
what
that
of
that
looks
like
so.
This
is
what
the
sample
pipeline
looks
like,
and
this
is
a
queue
and
I'm
not
going
to
get
too
deep
into
q.
I
But
a
lot
of
this
stuff
is
actually
pretty
easy
to
convert
from
the
yaml
config
to
queue,
but
it
allows
us
to
easily
parameterize
stuff.
It
allows
us
to
eventually
begin
to
abstract
a
lot
of
things,
so
you
can
say
you
know
a
develop.
You
know
a
development
team
might
say
here
are
my
list
of
trusted
keys
right
and
you
know
those
trusted
keys.
I
If
anything
falls
outside
of
that
list
of
trusted
keys,
you
know
it
will
not
pull
in
those
dependencies,
and
you
know
here's
my
signing
key
and
it
will
automatically
pull
in
that
signing
key
and
do
all
that
sort
of
stuff
and
yeah
so
that
that's
really
all
I
had
for
for
this
sort
of
demo,
there's
some
other
demos
that
you
know
if
folks
were
interested
in
in
the
future
that
we
can
show
off.
You
know
we
can
show
off
a
bit
more
sort
of
end
to
end.
I
We
can
show
off
stuff
like
what,
if
somebody
does
try
to
compromise,
let's
say
a
build:
how
would
this
system
sort
of
catch
that
sort
of
thing
you
know
at
different
levels?
Like
you
know,
if
somebody
tried
to
replace
your
source
code,
what
would
that
look
like
and
how
would
this
be
able
to
sort
of
catch
that
sort
of
problem?
And
and
you
know
what,
if
you
try
to
download
a
dependency,
you
know
a
bad
dependency.
What
does
that
look
like.
B
So
what
is
your
thinking
about
like
extending
that?
A
bit
further
productions,
for
example?
Sometimes
some
of
the
stuff
you
are
running
in
production
you
have
running
in
production,
may
have
vulnerabilities
disclosed
like
do
you
consider
those
things
running
production
as
part
of
the
supply
chain
like
concerns,
or
things
are
done
once
we
deployed
there
and
someone
else's
problem.
I
No,
no,
I
think
it's
still
part
of
the
same
problem.
I
think
the
thing
that
secure
software
factory
was
trying
to
solve
was
was
the
build
piece,
there's
still
pieces
around
the
production
sort
of
binary
authorization
piece.
So
this
is
where
stuff
like
you
know,
and
we
can
go
on
for
for
a
long
time
here
about
all
the
different
things
we
might
want
to
include
as
part
of
that
authorization.
I
But
it's
it's
my
opinion
at
least
that
the
way
that
it
should
work
is
you
generate
all
these
attestations
they're
all
stored
in
some
place
that
that
you
can
access
and
a
binary
authorization
sort
of
piece
which
to
be
clear,
I
don't
think
there's
really
many
of
them
besides,
maybe
critics
and
graphics
that
kind
of
thing,
but
I
think
that
the
way
that
things
are
moving,
is
you
say,
okay
great,
I
have
let's
say
I
have
a
scanning
attestation.
I
have
a
build
attestation.
I
have
a
linting
attestation.
I
I
have
all
these
different
things.
Maybe
I
have
an
attestation
that
the
product
manager
approved
or
whatever,
and
I
have
all
these
attestations
now
you
could
code
all
of
that
as
policy
in
something
like
kiverno.
The
problem
is,
you
have
a
lot
of
those
policies,
things
will
start
to
get
slow
and
it
also
becomes
difficult
to
sort
of
easily
reason
about.
But
if
you
have
something
like
a
binary
authorization
process,
you
go,
and
you
say
great
once
a
day
once
a
week
whatever,
once
an
hour
doesn't
matter,
I
go
through.
I
I
scan
all
of
those
things
and
maybe,
as
part
of
that
I
go
and
the
as
part
of
the
binary
authorization
is
hey.
Maybe
I
go
back
through
the
s-bomb
and
say:
are
there
any
new
vulnerabilities
that
have
come
up?
If,
yes,
I'm
going
to
alert
on
it
right?
Maybe
I
revoke
access
to
qa
or
dev,
let's
say,
but
I
don't,
let's
say,
revoke
access
to
production,
because
we
still
want
to
keep
things
running,
but
we
don't,
let's
say,
allow
new
deployments
in
production
until
that
sort
of
thing
has
been
pushed
out.
I
That
includes
you
know
essentially,
is
the
binary
authorizator
to
say:
hey,
I
checked
everything
and
it
looks
good
and
I'm
gonna
stamp
it
for
one
week,
one
day
one
month
whatever
and
I
think
obviously
a
lot
of
that's
going
to
be
up
to
the
individual
organization
or
whatever
that
that
feels
comfortable
with
and
then
from
there.
You
know
you
might
constantly
be
going
back
and
validating
like
hey.
I
B
Yeah
yeah,
that's
exactly
the
reason
because,
like
I'm
not
saying
like
all
the
things
that
happen
on
the
left-hand
side,
closer
developers
or
you
know,
production
environments
are
not
important
but
like
more,
like
majority
of
focus
is
on
that
side
and
the
right
side
or
production
side
is
a
bit
like
yeah.
It's
not
taught
much
about
I'm
not
saying
we
have
to
fix
everything
at
once,
but
just
was
wondering
your
opinion
about
it.
Yeah.
I
I
I
think
that's
what
it's
called
and
beyond
prod
has
a
bunch
of
really
interesting
ideas
around
how
they
do
borg
authorization
and
and
whatnot,
and
their
thing
was
like
yeah.
We
have
all
of
this
metadata
associated
with
the
stuff
we're
building,
and
then
we
have
a
final
process.
That
kind
of
says,
hey
great,
on
a
regular
cadence,
I'm
essentially
renewing
that
authorization
and
if
something
new
comes
in
right,
I
now
need
to
require
that
thing
either
be
rebuilt
based
on
the
new
requirement
or
rescan
based
on
the
new
requirement
or
whatever.
I
I
Do
we
go
recursively
all
the
way
back
to
the
kernel
right
or
even
just
the
compiler
of
the
kernel
you
know.
Do
we
start
to
build
some
of
this
stuff
for
for
hardware
and
and
so
on,
and
so
I
think,
there's
a
bunch
of
big
questions
about
also.
You
know
when
we
start
to
run
these
things
like
how
do
we?
How
deep
do
we
go
or
as
like,
some
of
the
other
folks
who
wrote
the
book?
Was
it
the
bottom
turtle
right
like
what
is
that
bottom
turtle?
B
B
I
B
I
Yep
and
in
the
in
the
coming
weeks,
I'll
definitely
update
this
group
on
we
do
once
the
open,
ssf
stuff
begins
rolling,
we'll
probably
start
to
have
our
own
sort
of
working
group
meetings.
If
folks
want
to
actually
contribute
to
the
code
and
and
build
out
whether
it's
you
know
contributing
something
like
hey,
you
know:
here's
maybe
how
we
could
hook
in
something
like
a
jenkins
x
or
it
could
be.
I
I
B
Yeah,
as
I
mentioned
like
this,
like
secret
software
factory
and
ssf,
is
one
of
the
things
we
may
look
as
part
of
our
proof
of
concept.
We
intend
to
establish
under
this
specialties
group
and
if
that
happens,
we
will
probably
hear
from
us
and
we
will
probably
come
back
and
contribute
to
the
work
you
are
doing
there.
B
So
thanks
again
mike
for
taking
time
to
join
our
meeting
and
presentation,
the
background
information
and
the
demo-
and
I
hope
you
could
continue
joining
to
our
meetings,
because
we
will
be
discussing
similar
topics
as
you
have
been
summarizing
over
the
past
hour
and
for
all
of
you.
Our
next
meeting
will
be
on
14th
of
april
and
please
not
to
leave
time.