►
From YouTube: Supply Chain Integrity WG Meeting (Jan 19, 2022)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
Not
where
I
am
in
new
york,
a
little
bit
further
north
and
northwestern
new
york
got
got
hit
pretty
bad.
We
just
got
a
ton
of
wind
got
the
power
got
knocked
out
for
like
half
a
day.
I.
A
B
Be
mostly
brad
on
my
side
is
gonna,
be
demoing,
I'm
gonna
we're
gonna,
throw
it
back
and
forth
between
each
other.
I.
A
And
so
we
have
michael
first
today,
michael
and
brad,
doing
a
presentation
and
then
a
discussion
on
the
working
group
charter
for
this
working
group,
because
we
we
started
off
as
a
digital
identity,
working
group
and
then
expanded
the
the
scope
to
be
the
supply
chain,
integrity,
working
group.
So
read
me,
you
could
use
some
updating
and
just
to
know
before
we
get
started
if
you're
gonna,
if
you
add
agenda
items
like
each
week,
just
make
sure
you
put
them
like
under
whoever
already
put
those
at
the
top.
A
I
think
that's
the
best
way
to
do
it
and
then,
if
things,
if
we
don't
have
enough
time,
we'll
just
bump
things
to
the
next
meeting
instead
of
moving
things
to
the
top
of
the
list,
if
you
don't
mind
cool
all
right,
well,
welcome
everyone
to
our
supply
chain,
integrity,
working
group
meeting
and
and
with
that,
I'm
going
to
hand
it
over
to
michael
and
brad
to
kick
it
off.
B
Cool
thanks,
so
I'm
gonna
just
quickly
throw
it
over
to
brad
and
while
he's
going
through
the
demo,
I'll
probably
begin
to
share
some
diagrams
to
help
walk
folks
through
this,
but
just
to
kind
of
give
a
very
quick
two
sentence.
Sort
of
thing
is
so
we're
going
to
be
showing
off
the
secure
software
factory,
which
is
a
reference
or
not
a
reference.
It
is
a
prototype
implementation
of
what
is
being
done
in
the
cncf
supply
chain,
security
working
group.
B
It
is
a
it's
it's
it's
a
set
of
tools
as
well
as
configuration
and
some
other
things
to
help
us
build
artifacts
securely,
whose
you
know
provenance
can
be
tracked
throughout
throughout
the
sort
of
build
system
and
so
on,
and-
and
I
can
go
through
some
additional
details
as
we
go
through
brad.
Do
you
want
to
show
off
what
that
looks
like.
C
Sure,
so
can
you
see
my
vs
code
here,
yep,
okay,
so
this
is
what
michael
was
just
talking
about.
So
I
have
checked
out
here
the
secure
software
factory
from
from
the
github
repository
and
what
it
includes
is
the
infrastructure
for
standing
up
the
the
build
pipeline.
So
it's
tucked
on
pipeline
tecton
chains
and
also
kyogreno
in
this
case
for
doing
the
admission
controlling
and
a
few
example
pipelines
that
we
have
built
out
the
one
I'm
going
to
show
you
today
is
called
the
the
sample
pipeline.
C
I
picked
it
because
it
it
does
a
canary
deployment
of
the
build
artifact
at
the
end,
which
comes
under
the
purview
of
the
the
admission
controller.
So
what
I
have
set
up
here
so
far
is
basically
I've
run
through
the
the
first
few
steps
of
the
the
example
here.
Basically
setting
up
a
mini,
cube
cluster
and
then
the
next
piece
that
has
already
been
done
is
basically
installing
tecton
pipeline
and
tecton
chains,
generating
some
keys.
C
That
tekton
is
going
to
use
using
cosine
and
then
setting
up
a
guy
with
an
emission
control
policy
that
actually
uses
one
of
the
keys
from
the
that
we
set
up
to
to
verify
that
anything
that
we
push
to.
In
this
case
we're
going
to
be
pushing
the
artifact
up
to
ttl.sh.
C
So
at
the
end
the
governor
is
going
to
basically
ensure
that
we
only
pull
things
from
ttl.sh
that
have
been
signed
by
by
this
key
that
we
we
generated
here.
So
what
I'm
going
to
do
is
before
we
switch
back
to
discussing
the
individual
components
is
to
basically
fire
off
the
individual
pipeline
here.
C
That
runs
through
that
and
then
we'll
basically
start
following
the
logs
for
that
as
we're
going
through
the
rest
of
the
discussion.
C
So
michael,
I
don't
know
if
you
want
to
drop
back
into
talking
about
that
or
if
we
want
to.
You
know
talk
about
how
what
what
just
happened
with
the
spinning
off
the
the
pipe
the
example
pipeline
right
here.
B
Yeah,
so
I
don't
want
to
go
too
deep
into
that,
because
I
know
we
there's
a
lot
of
demos
that
have
sort
of
shown
off
some
of
the
techcon
and
some
of
the
tecton
chains
pieces
and
we
know
kind
of
how
some
of
those
things
sort
of
work
together.
B
So
I
don't
want
to
go
too
deep
in
there
right
now,
but
I
think
I
think
it's
probably
maybe
worthwhile
just
to
kind
of
show
a
couple
of
diagrams
to
show
what
this
sort
of
thing
looks
like,
and
then
we
can
kind
of
go
back.
B
So
let
me
share
my
screen
here
in
a
second,
and
can
everybody
see
the
diagrams
okay
cool
yep?
So
the
basic
idea
here
right
is:
is
you
know
what
are
we
trying
to
do
right?
What?
What
is
this?
B
What
is
what
brad
just
showed
off?
What?
What
is
that?
Well,
so
it's
it's
the
secure
software
factory
right,
which
is
it's
a
ci
cd
system.
It's
some
policy
stuff.
It's
all
these
things
combined
to
help
out
with
helping
sort
of
build
software
securely
in
a
way
who's.
You
know,
at
least
within
the
stuff
that
we're
building
within
the
the
the
context
of
the
secure
software
factory,
its
provenance,
can
be
traced
and
so
on,
and
so
there's
a
bunch
of
different
things
here
right.
B
You
know
it's
going
to
require
access
to
your
source
code
control,
so
you
know,
as
as
brad
showed
you
know,
we're
pulling.
You
know
we're
we're
building
stuff,
it's
going
to
be
pushing
artifacts
in
this
case
images
to
ttl.h,
but
it
can
obviously
push
wherever
and
it
also
you
know
at
some
point
is
going
to
require.
You
know
you
want
to
have
a
production
emission
controller.
That
says:
hey
did
this
thing
go
through
the
secure
software
factory?
Does
it
have
valid
salsa,
attestations
and
so
on?
B
If
so,
then
let
it
into
the
production,
environment
and
so
quickly-
and
this
might
be
a
little
hard
to
sort
of
this-
is
sort
of
the
the
view
of
where
we
would
love
to
be
able
to
go
into
where
we
would
eventually
like
to
go
into
it.
I
know
this
is
probably
a
little
small.
B
Or
sure,
which
is
that
better,
much
yeah,
and
so
the
only
problem
with
this
tool,
is
they
don't
make
it
super
easy
to?
Let
me
see
if
there's
a
way
to
switch
to.
B
Okay,
yeah
yeah,
I
just
mean,
like
I
want
to
be
able
to
move
further
down
the
the
the
diagram
here,
but
I'll
deal
with
it.
Okay,
so
the
thing
here
right
is
is
so
it
the
it
consists
of
a
bunch
of
different
things:
the
security
factory.
So
it's
there's
some
build
environments
where
we're
actually
building
the
stuff
in
in
there
is
a
pipeline
observer,
a
thing
that
is
actually
recording
what
is
happening
in
the
builds.
B
So
it's
you
know
so
that
it
can
attest
to
those
things
it's
not
in
there
today,
but
eventually
we
imagine
there
to
be
a
a
pipeline
observer,
a
thing
that
can
sorry
not
a
pipeline,
sorry,
a
workload,
a
tester
and
a
noda
tester
and
sorry
that's
cut
off
at
the
bottom.
There,
let's
see,
if
I
can-
maybe
here.
Oh
this
is
probably
maybe
a
little
bit
easier
here.
So
the
the
there
is
a
workload
and
noted
tester.
B
So
these
are
the
things
that
would
essentially
be
a
testing
that
the
the
to
the
identity.
So
this
is
like
your
spiffy
spider
off,
making
sure
that
you
know
the
only
workloads
that
are
running
are
the
ones
that
are
pre-approved,
maybe
even
eventually
with
stuff.
Like
you
know,
trusted
platform
module
integration.
B
You
know
the
we
have
an
emission
controller
on
the
secure
software
factory
itself,
so
the
only
things
that
are
running
are
approved,
tasks,
approved,
build
images
and
so
on,
and
you
know
there
is,
you
know,
also
runtime
visibility,
so
this
is
stuff
like
falco
and
so
on
that
are
are
sort
of
tracing,
what's
actually
happening
in
those
build
environments,
so
we
can
detect
anomalous
behavior.
B
Some
of
this
stuff
isn't
there
today,
but
quickly,
whoops
quickly,
here
I'll,
throw
it
back
over
to
brad
is
today
what
this
looks
like
is
this
right.
We
have
tekton
chains
recording
the
builds
that
are
being
run
in
tecton
pipelines.
Tecton
chains
is
pushing
attestations
into
oci.
B
We
have
kiverno
enforcing
policy
on
tecton
pipelines
to
make
sure
that
only
approved,
build
images
and
so
on
are
running
inside
of
our
build
system,
and
then
we
have
a
bunch
of
tooling.
That
is,
you
know
essentially
deploying
all
this
stuff,
and
this
tooling
is
we.
We
help
manage
it
through
queue
which
brad
will
or
which
brad
will
show
off.
C
C
Sorry
was
that
we
basically
executed
this
build
script
here,
which,
instead
of
a
couple
of
variables
for
where
we're
going
to
push
the
images
to,
in
this
case
we're
going
to
take
the
default
of
ttl.sh,
and
then
we
give
it
a
random
repository
name.
So
if
we
have
multiple
people
running
through
the
examples,
at
the
same
time,
they
don't
try
to
push
to
the
same
image
location,
but
the
meat
of
it
is
we're
doing
an
evaluation
of
some
q
files
here
and
passing
in
some
information
using
cues
tag
capability.
C
So
what
what
this
is
doing
is
doing
it.
B
B
Sure
brad,
do
you
want
to
take
that
or
oh
you
can
go.
B
C
B
Yeah
sure
so
you
so
cue
lang
is,
is
it's
a
configuration
language
that
you
know
is
looks
it's
kind
of.
It
looks
a
little
bit
like
json
with
some
additional
stuff,
but
it
lets
us
easily
sort
of
add
some
additional
functionality
into
into
json
that
we're
writing
or,
and
it
can
output
to
yaml
and
so
on.
But
it
lets
us
sort
of
describe
a
lot
of
these
things
in
similar
sorts
of
configuration.
B
Languages,
like
you,
know
your
terraform,
hcl
or
or
json
if
you're
familiar
with
jsonnet
and
the
languages
is
developed
by
some
of
the
folks
who
worked
originally
on
the
board,
configuration
language
and
and
had
taken
some
of
the
the
the
learnings
from
that
and
kind
of
expanded
it
into
something
like
this,
and
so
it's
kind
of
just
a
a
a
language.
That's
its
intention
is
to
help
man
to
help
generate,
manage
and
validate
configuration.
C
Yep,
I
guess
the
only
thing
I
would
add
is
that
I
I
sort
of
view
it
as
a
a
way
that
you
can
define
constraints
on
on
the
data
and
the
data
itself
in
specific
values.
So
it
generates
this
lattice
of
values
that
are
both
the
constraints
and
the
concrete
data
and
the
the
key
thing
is
that
those
can't
be
conflicting
at
any
point
in
time.
So
you
can't
redefine
a
value
to
another
value
later
on
in
in
in
the
evaluation
and
it's
it's.
C
What
it
does
is
go
through
and
try
to
unify
all
the
different
definitions
in
the
same
package
and
come
up
with
whether
you
you're
you're,
adhering
to
that
that
the
the
policy
and
the
values
at
the
same
time-
and
so
we've
we've
taken
advantage
of
that
here
in
the
at
the
top
level
we
import.
C
You
can
import
some
of
the
ghost
trucks
to
allow
you
to
do
some
validation
of,
in
this
case
we're
doing
some
of
the
the
core
kubernetes
core,
our
back
and
some
of
the
car
kyverno
strucks
to
do
the
evaluation
and
generation
of
of
the
either
the
the
ammo
or
the
json
that
we
can
then
send
a
cube
pedal
to
do
to
do
the
the
creation
of
those
particular
items.
C
C
So
we
in
the
examples
we
have
further
defined,
that
we
in
all
of
the
examples
that
we
want
to
define
some
secrets
that
we're
going
to
be
using
and
then
we're
also
going
to
be
defining
some
persistent
volume
claims
that
we're
going
to
apply
across
all
of
the
pipeline
runs,
and
so
q
also
has
this
this
notion
of
doing
a
comprehension
over.
C
In
this
case,
we're
saying
all
of
the
pipeline
runs
that
we've
defined
so
far.
Let's,
let's
add
this
additional
information
to
it,
and
so,
as
we
walk
down
this
tree
from
the
ssf
level
to
the
examples,
q
is
going
to
put
those
together
and
make
sure
that
they
are
consistent
as
we
go
down
and
so
as
we
get
into
the
actual
sample.
C
This
is
where
we
get
to
the
more
concrete
data
sort
of
level.
So
q
has
this
notion
of
doing
schema
at
the
higher
levels
policy
at
the
mid
levels
and
then
the
actual
data
at
the
lower
levels,
and-
and
so
that's
where
you
can
get
this
sort
of
hierarchical
approach-
of
applying
the
policies
across
there
and
this
this
is
the
place
where
we
we've
also
introduced
the
tags
for
the
repository
that
we
saw
in
the
the
the
the
shell
script
here.
C
So
we're
doing
the
evaluation
over
the
the
data,
that's
in
the
the
sample
pipeline
tree.
So
that
includes
everything
at
the
ssf
example
and
the
the
sample
pipeline
level
doing
an
evaluation
over
that
we're
passing
in
this
tag
where
we're
defining
the
repository
and
then
we're
using
the
the
queue
command
facility
which
is
defined
in
in
this
ssf
underscore
tool
piece
and
in
here,
where
we're
we've
defined
and
apply
and
a
create
command.
C
So
those
those
correspond
to
those
commands
that
we're
using
here
so
here
we're
we're
using
the
apply
command
to
pull
out
everything
in
the
in
our
definitions.
That
will
will
be
appliable
with
cute
cuddle
apply
and
with
create
we're
pulling
out
everything
that
we
can
use
with
cute
cuddle
create.
C
F
C
One
of
these
types
pulling
all
those
values
out
and
then
we're
we're
basically
getting
the
ins
inside
definitions
of
those
looping
over
those,
and
then
we
can
pass
that
through.
This
is
kind
of
a
functional
call
semantic
to
do
a
printout
using
a
yaml.
So
it
streams
that
out
as
yaml.
So
we
pull
out
the
values
of
all
of
those
things
that
we've
defined
using
that
that
sort
of
query
and
then
we're
going
to
split
those
out
as
yaml,
and
so
what
the
the
script
does
is
it.
It
pulls
out.
C
B
So
let
I
think
it
might
be
also
worthwhile
just
to
kind
of
show
a
diagram
just
so
that
folks
kind
of
understand
the
upshot
of
some
of
that.
Let
me
just
share
that
real,
quick
and
don't
worry
I'll
set
this
to
I'll,
set
it
to
presentation
mode
once
I've
shared
it
all
right.
B
Okay
and
I'll
put
this
in
presentation
mode,
whoops
yeah!
You
can
see
the
diagram
again
right.
B
Yes,
cool
so
quickly
here
the
the
the
main
thing
right
is.
This
allows
a
couple
of
different
things
right.
What
what
brad
had
showed
off
is.
It
allows
us
to
sort
of
create
a
hierarchy
of
configurations,
so
you
can
use
to
say
like
hey
the
secure
software
factory
has
a
bunch
of
rules
that
we
believe
allows
you
to
sort
of
build
some
software
securely,
but
we're
not
going
to
have
all
the
rules
for
everybody
right.
You
know
you
might
have
a
step.
Has
you
know
one
person
using?
B
I
don't
know
black
duck
as
their
scanner,
another
person's
using
some
other.
You
know
vera
code,
as
as
you
know,
as
as
a
code
scanner
or
whatever
right,
and
so
this
hierarchy,
though,
allows
you
to
sort
of
have
you
know
the
secure
software
factory
can
have
a
set
of
things
that
it
runs
it
controls
and
then
you
can
further
constrain
that
with
your
own
policy,
your
own
configuration.
B
B
So
no
team
and
no
project
can
be
anything
other
than
a
job
pipeline
right
and
that
helps
us
constrain
there,
and
a
team
might
have
additional
rules
for
that
for
what
they
require
and
a
project
might
have
additional
rules
and
as
what
brad
showed,
is
that
hey
as
long
as
project
configuration
abides
by
the
restrictions
or
the
constraints
that
the
team
has
in
the
organization
it'll
work,
and
that
allows
us
to
do
a
couple
of
things.
B
B
It
also
lets
us
generate
a
lot
of
this
configuration,
because
a
lot
of
these
things
can
be
set
up
as
defaults.
If
you're,
following
all
the
defaults,
you
just
get
a
lot
of
the
stuff
generated
for
you.
So
if
I
go
back
to
this
diagram
here
right,
the
thing
here
is
that
this
configuration
we
have.
We
can
tie
in
the
configuration
for
our
our
kiverno
policies
for
our
techcon
pipelines
and
tasks.
All
together,
they
all
get
deployed
at
the
same
time
and
they
all
are
kind
of
considered
one
sort
of
grouping
of
resources.
B
So
you
automatically
get.
You
know
your
admission
control
policy
deployed
along
with
your
pipeline.
You
don't
have
to
think
about
generating.
Oh,
I
need
to
have
yaml
configuration
that
looks
like
this,
that
that
has
this
string
and
if
that
string
ever
changes,
I
need
to
you
know,
move
all
that
sort
of
stuff
around.
B
I
hope
that
explained
if
anybody
wasn't
sure.
C
Okay,
it
looks
like
we
finished
the
pipeline
here,
so
let's
look
real
quickly
at
what
we
defined
in
the
the
sample
pipeline,
the
queue
in
terms
of
tasks.
So
we
can
look
through
this.
This
is
sort
of
json-like
where
we
define
the
the
pipeline
that
we're
going
to
be
using
here
the
pipe
to
build
and
deploy
pipeline.
The
set
of
tasks
in
there
are
going
to
be
the
clone.
C
The
repo
build
and
push
the
image
generate,
a
an
s
bomb
for
it
to
a
vulnerability,
scan
and
then
deploy
it
to
the
cluster
during
the
canary
deploy,
and
so
you
can
see
toward
the
end
here.
We've
passed
through
the
grid
scanner
and
then
it
actually
did
the
the
deployment
to
the
cluster.
So
if
we
do
okay
get
all
here,
we
should
see
a
pike
help
yeah
pod,
that's
running,
so
that
confirms
that
it
got
through
the
the
carver
scan
and
actually
got
deployed
there.
C
So
the
the
the
key
piece
here
is
that
you
see
that
we
didn't
have
to
this
is
a
pipeline
object.
That
was
also
defined
that
so,
if
you
look
in
the
top
level,
the
pipeline
say,
pipeline
object
has
a
kind
of
pipeline
and
the
api
version
is
this:
tecton
dev,
b1
beta1
but
you'll,
see
since
we've
defined
that
at
the
higher
level
and
we've
said
that
the
the
name
of
that
is
going
to
come
from
the
the
name
that
we
assign,
when
we
actually
give
it
a
concrete
value.
C
If
we
look
back
at
the
pipeline
here,
so
it
it.
Basically
it's
going
to
inherit
all
of
that
from
from
the
upper
levels
into
this
value.
So
then,
when
we
go
and
do
the
evaluation
and
spit
it
out,
it's
going
to
have
all
of
that
data
already
pre-populated
in
there,
and
I
think
that
speaks
to
some
of
what
michael
was
was
saying.
You
can.
C
There
are
different
levels
at
which
you
can
insert
those
those
policies
or
the
set
of
values
that
you're
going
to
have
for
certain
things
and
then
at
the
the
lower
level
user
end.
You
just
need
to
know
the
the
your
unique
values
that
you're
going
to
be
using
in
that
case
and
and
the
goal
for
us
is
to
sort
of
refine
that
so
we
we
have
a
smaller
set
of
things
that
the
end
user
needs
to
define
to
do
the
particular
operation
that
that
they
want
to
do.
B
Yeah
one
thing
to
add
on
there
as
if
folks
are
familiar,
for
example,
with
with
how
some
of
the
stuff
works
in
techton
right
when
you
have
a
pipeline
run
often
you're
you're,
you
know,
between
pipelines
and
pipeline
runs,
and
you
know
you
have,
you
might
be
sharing
config
maps
between
lots
of
different
things
and,
and
you
might
be
generating
lots
of
different
persistent
volume
claims
and
yaya
q
allows
us
to
automate
a
lot
of
that
so
that
the
end
user
doesn't
really
need
to
think
about.
C
So
what
I'm?
What
I
just
did
here
is
I
pulled
out.
Some
of
the
information
from
the
the
pipeline
run
itself
for
the
image
url
and
the
tag
that
we
used
to
do
the
push
to
generate
a
docker
image
as
string
for
that,
and
then
we
can
do
crane
on
that
to
see
what
actually
got
pushed
to
the
registry
and
you'll
see
that
we
got
a
one
one
image,
that's
tagged
for
one
hour
and
then
we
have
an
attestation
and
a
signature
that
that
has
been
deployed
into
the
oci
registry.
C
For
that
that
particular
image,
and
then
we
can
go
through
and
do
a
verification
with
cosine
of
the
image
itself
that
it's
signed
and
then
also
the
attestation
and
here
again
we're
using
the
secret
that
we
we
generated
with
with
cosign
earlier
to
do
that
that
verification,
that's
this
piece
here
where
it's,
the
tecton
change
signing
secret.
C
So
if
we
go
through
and
do
those
two
pieces
we'll
see
that
we
actually
have
a
valid
signature
for
the
image
and
then
the
valid
attestation
for
that
too,
and
then
you
could,
you
could
decode
the
attestation
to
get
more
information
from
that
if
you
needed
to
so,
I
think
that's,
basically
the
gist
of
that
particular
example.
B
So
I
don't
think
that
there
are
any
current
users
right
now.
This
is
you
know
intended
to
be.
You
know.
I've
been
working,
obviously
with
the
cncf.
This
is
stuff
that
we
do
plan
to
open
source.
Oh
right,
rather
it
is
open
source,
but
we
do
plan
to
sort
of
make
a
bigger
sort
of
announcement
for
it
once
we
kind
of
get
all
the
various
approvals
for
that.
But
the
general
idea
here
right
is,
is
you
know
for
us?
B
We
are
using
it
for
our
own
sort
of
use
cases,
but
anybody
is,
you
know,
sort
of
welcome
to
participate.
You
know,
we've
been
having
some
conversations
with
folks
on
you
know.
B
How
can
we
expand
this
because
the
idea
here
right
is,
is
you
know,
there's
a
lot
of
examples
of
how
to
use
a
lot
of
the
supply
chain,
stuff
and
and
s-bomb
and
and
salsa
and
so
on
with
stuff
like
github
actions,
but
we
recognize
that
hey
github
actions
works
for
smaller
sorts
of
folks,
but
when
you're
once
you're
sort
of
a
giant
enterprise
like
we
are,
you
know
those
sorts
of
things.
You
know
you,
you
require
a
little
bit
governance
a
little
bit
more.
B
D
B
Yeah,
that's
one
key
thing:
there's
a
bunch
of
other
things
as
well.
That
I
think,
are
a
little
out
of
the
scope
of
this
particular
demo,
but
the
idea
is,
we
also
want
to
make
the
secure
software
factory
that
we've
been
building
sort
of
like
dog
fooding,
all
the
best
practices
of
supply
chain
security.
B
So
we
I
didn't
really
get
into
it
too
much
but,
for
example,
we're
validating
you
know
at
vendoring
time
and
also
at
ingestion
time
we're
we're
validating
that
the
version
of
tecton
that
we're
using
is
signed
with
the
tekton
key
and
has
valid
attestations
as
well
and
so
we're
you
know
we're
working
with
kiverno
to
make
sure
that
key
verno
is
is
up
to
date,
signed
and
tested,
and
so
all
the
tools
we
want
to
use
and
included.
B
We
also
want
to
make
sure
have
they
been
signed
and
tested,
and
we
want
to
make
sure
that
all
of
our
stuff
is
signed
and
attested,
and
you
know
so
that
we
could
start
to
sort
of
build
a
better
world
there.
So
that's
like
one
other
big
thing
and
then
another
big
thing
for
us
is.
B
We
also
are
making
this
like
the
the
secure
software
factory
itself,
which
right
now
consists
of
a
couple
of
these
different
tools,
and
we
do
want
to
make
it
eventually
pluggable
so
that,
if
you
do
say,
hey
look,
I
I
want
to
you
know,
replace
you
know
techton
with
this
other
thing,
maybe
eventually
we
could
support
that
as
well,
but
the
basic
idea
behind
it
is
by
also
using
q
to
also
configure
the
secure
software
factory
itself.
It
makes
the
management
of
all
these
different
resources
much
easier,
because
you
can
imagine
you
know.
B
Whereas
with
this
we
with
a
some
q
configuration,
it
allows
us
to
say:
hey,
while
deploying
tecton
you're,
making
sure
that
you
know
the
pipe
the
the
policies
you're
associating
with
tecton
are
sort
of
linked,
and
so
anytime
we
make
a
change.
We
don't
have
to
worry
about
like
shooting
ourselves
in
the
foot
by
like
oh,
I
updated
tech
tom
but
forgot
to
update
the
associated
policy.
B
G
Hey
michael
had
a
quick
question,
spurred
from
you
kind
of
mentioning
eating
our
own
dog
food
with
vending
and
such
you
know,
looking
at
the
signed,
you
know,
tecton
builds
or
even
caverno,
and
such
do
you
have
that
built
into
the
actual
pipeline
itself
to
evaluate
along
the
way,
or
is
that
kind
of
like
a
separate
exercise
outside
of
the
actual
pipeline?
G
B
Right
now,
it's
there's
two
things:
one
is
we
at
vendoring
time
we're
validating
what
we're
about
to
vendor,
and
so
that's
like
we're,
vendoring
the
tecton
based
configuration
and
then
we're
modifying
the
configuration
through
patch
files
so
that
it
becomes
easy
to
kind
of
see
like
oh,
you
know,
because
helm
charts
can
get
difficult
to
manage
and
so
on.
So
we
found
it
much
easier
to
just
kind
of
pull
down
the
releases
directly
from
tecton,
but
when
pulling
down
those
releases,
you
know
him
who's
on.
B
This
call
wrote
a
quick
and
dirty
tool
that
will
validate
through
right
now,
I
think,
since
they
sign
it
through
cosign,
it
validates
the
the
the
signatures
and
attestations
that
way
and
so
it'll
vendor
it
that
way,
but
then
also
one
of
the
other
things
that
we
do
do
as
well
in
the
kiverno
policies
and
we're
still
developing
some
of
these
things
out
is
that
at
runtime
as
well.
B
We
also
have
policies
that
validate
that
hey
at
vendor
time
we're
validating
to
make
sure
that
if
I'm
pulling
in
a
new
version
of
this
tool,
is
it
still
you
know.
Am
I
pulling
down
one?
That's
signed
and
attested
by
the
maintainers,
and
then
secondarily
you
know,
and
then,
when
I'm
actually
running
this
thing,
did
somebody
try
to
replace
the
image
without
you
know,
and
it's
not
a
signed
image
anymore.
Something
like
that.
So
that's
that's.
How
we're
kind
of
approaching
that
problem
cool!
Thank
you.
C
So,
basically
we're
just
generating
the
keys
using
cosine
and
then
putting
those
into
his
just
for
the
purposes
of
the
example
pipeline
runs.
So
we
we
push
the
both
the
private
and
the
public
keys
up
into
the
secrets,
and
then
we
can.
We
can
pull
them
out,
at
least
the
public
key
out
to
do
to
do
verification,
at
least
for
this
particular
example.
C
Ideally
you
probably
have
another
mechanism
for
longer
to
lift
keys
that
you
might
use
for
that
particular
piece.
We
haven't
put
a
lot
of
infrastructure
in
place
for
that,
yet.
B
Yeah
so
long
term,
what
we
do
want
to
do
is
we
want
to
have
those
be
spiffy
identities,
and
so
we
would
have
a
mechanism
and
most
likely
we'd
use
something
like
hashicorp
fault,
to
integrate
with
with
with
that,
and
then
we
would,
we
would
provide
keys
to
this
to
spiffy
and
spiffy
spire,
and
then
it
would
generate
identities,
short-lived
identities
for
us
to
then
use
and
sign
the
stuff
with.
B
Yeah
and
in
fact,
a
lot
of
that
stuff-
that's
already
in
there-
can
just
sort
of
use
any
kubernetes
secret,
we're
just
obviously
it's
much
easier
to
show
hey
we're,
generating
a
key
via
the
command
line.
This
is
you
know
and
just
show
you
that
it's
signed
with
this
key,
but
it
could
be,
you
know
hsm.
It
could
be
okay,
cool
thanks.
A
Cool,
thank
you
michael
and
brad
for
that
demo.
This
is
awesome.
I
think
we
need
to
move
on
to
the
next
agenda
item
and
so
folks
have
more
questions.
Maybe
ask
in
the
in
the
chat
or
find
us
and
find
us
in
slack
all
right.
Okay,
do
you
want
to
start.
E
Sure,
let's
see
so,
why
don't?
I
share
the
screen,
and
so
I
volunteered
in
our
last
meeting
to
to
create
a
draft
of
a
new
readme
for
our
supply
chain,
integrity,
working
group-
and
I
did
share
that
out
by
email
to
our
list.
E
I
thought
I
would
just
maybe
walk
through
the
kind
of
the
flow
that
I
have
for
it
get
people's
ideas
here
and
then
we
can
think
about
next
steps.
I
think
if
we
feel
like
it's
heading
in
the
right
direction,
if
there
aren't
too
many
comments
where
we
can
turn
it
into
a
pull
request.
E
If
there
are
lots
of
comments,
we
can
continue
iterating.
So
I
broke
it
into
kind
of
three
areas.
One
is
an
overview
of
the
sort
of
the
working
group.
E
E
We
probably
want
this
readme
to
to
be
consistent
with
other
readmes,
and
I
didn't
spend
a
lot
of
time
looking
at
other
working
group
readme,
so
that
might
be
a
pass
that
we'll
want
to
do,
and
maybe
david
wheeler.
I
think,
if
you're
here
you
can.
You
can
help
me
with
that.
E
E
Let's
see,
and
then
I
did
spend
a
little
bit
of
time
talking
about
user
stories
related
to
supply
chain
integrity,
so
policy
managers,
kind
of
you
know-
I
put
names
to
each
of
them
and
then
said
what
it
is
that
their
what
their
needs
are:
policy
managers,
producers
of
of
of
software
auditors,
procurement
managers
and
consumers-
then
I
this
is:
I
caught
mainly
copied
and
pasted
the
meetings
and
communications
and
notes
sections
from
the
previous
readme
and
then
also
from
the
previous
readme.
E
There
were
some
sections
that
talked
about
governance
chairs
of
the
working
group
and
our
antitrust
policy
blurb.
E
E
So
that's
the
state
it's
in
right
now,
one
thing
when
I
wrote
it
initially,
I
was
trying
to
be
broad
about
supply
chain
and
I
was
thinking
not
to
scope
it
intentionally
to
open
source
software.
But
think
of
you
know
what
we're
doing
is
you
know,
thinking
about
supply
chain,
all
up
that
applies
to
open
source
and
proprietary
and
potentially
even
to
things
that
are
not
not
strictly
software
like
firmware
and
cloud
services
and
dan
had
suggested.
E
Maybe
we
want
to
keep
the
scope
to
open
source
software
and
that's
totally
fine
with
me,
so
I
did
change
it
in
one
place
and
you
know
maybe
we
need
to
add
the
words
open
source
software
in
other
places
in
here.
So.
D
Yeah,
I
think
your
current
objective
says
we're
going
to
solve
it
for
bananas
and
because
it
doesn't
say
it's
even
I.t,
never
mind
software,
never
mind
open
source
software.
E
E
Yeah,
I
was
pretty
happy
with
with
what
dan
had
suggested,
which
is
focus
scoping
to
open
source,
because
that's
what
that's,
what
the
foundation
scope
is
is
on
securing
the
diverse
ecosystem.
So
I
bet
I
don't
think
that
precludes
us
from
doing
things
that
are
you
know
that
apply
to
open
source
and
other
things.
It
just
says:
well,.
E
A
Yeah
we
should
figure
out
how
to
keep
some
of
the
content
from
the
existing
readme
too.
There's
a
lot
of
good
work
early
on
like
a
threats,
diagram
and
things
that
we're
trying
to
initially
protect
against
and
different
types
of
attacks
and
goals
and
on
goals.
So
I
don't
think
it
has
to
live
here,
but
I'd
hate
to
see
that
going
away.
I
know
that
was
some
concern
that
people
had
with
even
re-scoping
this
working
group
is.
A
E
Talk
about
scope
in
terms
of,
and
that's
a
possibility.
We
didn't
talk
about
scope
in
terms
of
the
aspects
of
supply
chain
that
we're
concerned
with.
So
things
like
you
know-
and
this
is
what
the
previous
working
group
was-
was
one
aspect
which
is
developer
identity
and
so
now
we've
expanded
we're
also
thinking
about
policy
and
attestations,
and
so
so
maybe
we
can
add
a
section
for
that,
and
then
I
don't
know.
Let
me
let
me
think
about
it.
E
I
was
thinking
we
could
add
a
section
for
sort
of
areas
of
supply
chain
covered
and
then
have
a
link
to
develop
the
previous
developer
identity
attestation
from
there.
E
Maybe
let
me
play
with
that.
If
that
sounds
good
to
folks-
and
maybe
I
can
make
one
more
one
more
pass
at
this-
we
can
discuss
it
in
our
in
our
meeting
two
weeks
from
now
and
then
think
about
going
to
a
pull
request.
After
that.
D
Can
I
suggest
moving
a
little
faster
because
I
mean
currently,
I
think
the
readme
is
terribly
misleading
and
I
would
I'd
hate
for
the
best
to
be
the
enemy
of
the
good.
I
would
propose
just
turn
this
into
a
pull
request.
Now
put
the
user
stories
in
a
separate
file
linked
to.
D
We
can
still
make
you
know,
use
the
pull
request,
comments
to
comment
on
tweaks
for
it
and
then
merge
it
in
and
then
keep
making
improvements,
but
I
I'd
hate
for
it
to
linger
too
much
longer.
I
think
people
are
very
confused
by
the
current
readme.
A
Yeah,
I
think
that
sounds
good.
I
think
there
was
a
comment
in
the
chat
about
the
objective,
so
take
a
look
at
that.
Okay,
maybe
one
more
recommendation
sure,
let's
see
sorry,
I
had
my.
E
Oh
okay,
okay,
so
do
we
so
okay,
currently
the
overview
and
the
objective
read
pretty
close:
do
we
want
to
get
rid
of
them
and
just
have
yeah.
D
Yeah
yeah
I
hate
to
have
duplicates.
I
certainly
I
mean
we,
you
could
you
could
take
the
overview
and
text
the
the
objective,
mentioning
the
supply
chain,
integrity
working
group,
starting
out
with
that-
is
not
a
bad
thing
anyway,
I
guess
it's
like
the
it's
the
objective,
the
the
supply
chain.
Integrity
working
group's
objective
is
to
provide
a.
C
D
Okay,
can
you
post
the
the
url
in
the
chat,
and
maybe
we
can?
Maybe
we
can
just
quickly
offline,
beat
on
this,
get
a
rough
agreement
and
then
create
a
pull
request
from
it?
Well,.
A
Thank
you,
kay,
you're
welcome.
We
have
a
few
minutes
left
and
I
don't
think
we've
done
intros
in
a
while.
So
if
anyone
is
on
the
call
and
wants
to
say
a
quick
hello
and
what
you're
interested
in
solving
or
helping
with
that
would
be
awesome,
but
if
not
no
no
worries
and
we
can
end
a
little
early.
H
Here
I
go
hello,
my
name
is
nathan
menhorn,
I'm
from
xilinx.
One
of
my
primary
focuses
is
on
software
security.
So
I've
recently
joined
this
group
just
to
kind
of.
H
A
A
L
I'll
say
hello,
my
name's
tom
from
bloomberg,
I'm
very
interested
in
open
source
software
supply
chain,
especially
the
amount
we
integrate
with
it.
I
went
to,
I
think,
alpha
working
group
last
time
and
trying
to
see
which
groups
we
can
help
with
and
will
help
us
as
well
so
yeah
novice
on
his
way
around
at
the
moment.
F
F
M
Cool
on
the
next
one
nice
to
meet
you
folks,
I'm
miki,
I'm
from
snake's
office
of
the
cto
in
my
role,
also
I'm
working
on
the
supply
chain
strategy.
So
I'm
looking
now
to
learn
how
you
can
collaborate
with
the
open,
ssf
foundation.
D
N
I
like
it
thanks
to
whoever
called
out
the
assassin
the
assessed
verb,
I
think,
is
important.
N
You
know
it's
a
great
question.
They
then,
and
I
think
that
the
answer
is
best
left
to
the
working
group's
actual
output
rather
than
trying
to
pin
it
down
in
the
mission.
You
know
you're
right,
it's
in
the
eye
of
the
beholder.
From
my
perspective,
you
know
we
are
in
the
context
of
quality
in
so
much
as
it
affects
the
security
risks
of
a
piece
of
software
instead
of
where
my
brain
is,
but
that's
a
lot
of
words
to
try
and
mash
into
something
where
there's
a
lot
of
parent
context
anyway.
Can.
D
N
No,
no
categorically
I'll
explain
my
perspective
because
I'm
so
dogmatic
david,
you
know
to
me,
there's
three
problems
of
software
supply
chain
right,
there's,
correctness,
aka
equality
as
in
was
this
thing
well
made,
and
does
it
resist
the
kind
of
attacks
that
would
come
like?
Is
it
resistant
to
attacks
by
the
how
it
was
made?
D
N
C
N
I'm
just
looking
at
santiago's
comment:
I'm
trying
to
see
that
properly.
L
D
You
know-
maybe
maybe
I
can
just
let
I'm
going
to
put
it
in
suggestion,
confidentiality,
integrity.
O
I
hate
to
be
the
person
who
points
out
that
confidentiality
usually
implies
confidentiality,
which
is
at
odds
with
public
information
about
the
open
source
supply
chain.
N
But,
but
to
me,
like
we've
lost
my
correctness,
piece
like:
where
would
you
describe
vulnerability
here?
It's
not
an
integrity
in
my
book.
That's
sort
of
the
like
integrity
means
nobody's
messed
with
this
thing
it
hasn't
been
tampered
with.
It
is
what
we
said
it
was,
but
a
log
for
j
problem
is
not
a
confidentiality
problem
or
an
availability
problem.
It's
a
correctness
problem.
So
maybe
I'm
miss.
You
know
maligning
the
cia
triangle,
but
I
I
have
subverted
it
to
mean
correctness
in
my
context,.
J
Well,
that's
important
when
you
get
into
safety,
you
know
so
you
know
you
need
it
to
be
safe,
secure,
reliable,
resilient.
D
D
E
Can
we
just
say
security,
just
just
checking
that
again,
like
I
mean
we
could
get
into
you
know
lots
of
adjectives
to
describe
it,
but
maybe
for
purposes
of
the
overview.
Could
we
just
say,
security.
N
D
H
N
E
J
E
J
F
N
What
what
word
would
you
add
to
make
them
care
about
it
like?
Is
it
safety.
F
N
N
I
think
that
it
would
be
worthy
of
a
conversation
and
then
moving
it
up
as
parenthesis
sort
of
you
know
under
behind
security.
After
we've
had
that
conversation,
but-
and
I
I
mean
this
with
like
I'd
like
to
learn
more
and
understand
more,
but
what
would
we
do
towards
safety?
And
somebody
asked
about?
What's
you
know?
What
does
correctness
mean
right.
D
The
issue
isn't
that
the
issue
is
this:
group
historically,
has
not
been
focusing
on,
say
safety,
but
instead
on
the
security.
J
E
Let's
so
we
are
at
the
top
of
the
hour,
people
are
bouncing.
Let's
you
know
it
feels
like
this
is
a
an
okay
starting
point.
Let
me
let
me
put
in
the
pull
request
and
I
think
we
we
should
keep
you
know,
refining.
I
think
we
can
refine
in
a
couple
ways
we
can
have.
What
we
talked
about
is
the
bike
shedding
document,
but
we
can
also,
you
know,
add
more
user
stories
to
to
cover
different
scenarios
and
be
clear
about.
E
Let's,
let's
try
to
make
the
readme
better
than
it
is
today
as
a
starting
point
and
and
and
we
can
keep
refining.