►
From YouTube: CNCF Security TAG Supply Chain WG 2021-06-10
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
B
C
A
C
A
A
There
are
people
like
dan
and
priya
on
the
call
I
actually
yeah
prius
here,
who
are
down
a
a
good
road
and
we
thought
it'd
be
beneficial
to
compare
notes,
see
what
they've
been
working
on
hear
from
them.
How
far
along
are
they?
What
areas
are
they
they
needing
help
with
and
for
us
to
evaluate,
collaborating
and
contributing
with
them?
So
we
can
accelerate
this
work
with
that
priya.
I
believe
you
have
prepared
some
material
and
want
to
give
us
an
overview
I'll
pass.
D
D
D
So
a
lot
of
this,
these
slides,
are
based
off
this
dock.
That
dan
wrote
called
zero
trust
supply
chains
which
I
have
linked
in
the
bottom
I'll
share
the
slides
after,
and
so,
if
you
haven't
read
the
doc
already,
I
would
definitely
recommend
reading
it
because
it'll
go
into
a
lot
more
detail
about
all
the
stuff
I'm
going
to
talk
about
today,
but
I'll
just
give
a
quick
overview
of
the
doc
through
the
next
few
slides.
D
So,
basically,
the
dock
covers
how
we
use
a
few
different
tools
to
create
a
secure
supply
chain
and
the
tools
we're
focusing
on
are
spiffy,
inspire
six
store
and
techton,
so
spiffy
inspire
will
use
to
perform
node
and
workload
at
a
station.
Six
store
is
a
project
that
I've
been
working
on
for
months
actually
consists
of
three
different
tools,
so
full
co
is
our
root
certificate
authority.
Recore
is
a
transparency.
D
Log
and
cosign
is
a
container
signing
tool
which
basically
makes
it
easier
to
assign
and
verify
containers
and
we're
using
tekton
as
our
example
build
system.
Today,
tactile
pipelines
is
just
a
cic,
just
cd
system
based
in
kubernetes
and
techton
chains
as
well,
which
basically
provides
supply
chain
security
for
text
on
pipelines.
D
I'll
discuss
each
of
these
more
in
more
detail
as
we
go
through
the
presentation,
so
quick
caveat
before
I
get
into
it.
There
are
a
lot
of
different
options
for
each
of
the
tools
that
I'm
going
to
be
talking
about
and
a
lot
of
different
things
can
be
plugged
in
and
we're
definitely
not
set
on
these.
This
is
kind
of
more
just
an
example
of
one
way
this
could
be
done,
but
if
anyone
has
other
opinions
or
ideas,
we're
super
welcome
to
hearing
them
cool.
So
I'll
start
just
by
talking
about
tecton
chains.
D
So
why
is
this
useful?
So
how
do
we
really
know
what
has
happened
in
a
build
a
lot
of
times?
We
don't
really
like.
We
have
a
build
process.
That
does
something,
and
it
tells
us
that
it
happened
and
we're
like
okay,
like
that
sounds
legit,
and
we
kind
of
just
have
to
take
take
its
word
for
it,
and
so
change
makes
this
a
little
bit
better,
because
chains
is
actually
watching
the
build
process.
D
D
The
problem
is
that
we're
not
really
watching
the
bill
process
itself,
we're
watching
kubernetes,
where
the
build
process
is
running
and
the
thing
about
kubernetes
is
that
the
problem
with
this
is
that
in
kubernetes,
anyone
with
the
correct
our
back
permissions
can
actually
go
in
and
edit
your
pod
or
edit
your
task
run,
and
so
before
chains.
Since
chains
relies
on
observing
these
things
to
finish
and
tell
change
what
happened?
It's
not
actually
that
secure
a
person
could
go
in
change.
D
D
Cool
so
now
I
kind
of
have
like
this
process
this
system,
where
everything
is
verified
kind
of
from
the
beginning
to
end.
So
we
have
spire
verifying
the
workload
on
the
pod,
and
then
we
have
chains
verifying
what
spire
did
and
then
signing
it
again
and
then,
as
a
human,
you
can
go
ahead
and
you
can
verify
that
chain's
actually
signed
whatever
image
or
task.
You
were
trying
to
build.
D
Cool
and
then
the
final
tool
that
we
have
kind
of
integrated
into
this
is
six
store,
so
we
use
full
co
to
provide
certificates
to
help
sign
and
verify
code.
We
use
cosign
to
assign
container
images
when
they're,
if
they're
built
in
tactile
pipelines
and
we
have
record
as
well,
which
is
a
transparency
log
where
all
activity
is
stored,
so
it
can
be
monitored
and
checked
later
if
it
needs
to
be
so.
I
mentioned
a
lot
of
tools
just
now,
so
we
have
this
like
diagram
to
kind
of
see
how
they
all
fit
together.
D
D
D
So
basically,
I'm
going
to
build
an
image
and
tucked
on
it
should
be
signed
and
validated
with
spire,
and
then
techton
will
validate
that
spire
actually
sign
the
workload
and
then
text
on
chains
will
again
sign
sign.
The
image
will
verify
that
the
image
was
signed
locally
with
cosine
and
show
overall
provenance
as
well.
D
Okay,
let's
switch
to
my
my
id.
Can
everyone
see
this
okay
cool?
So
the
first
thing
I'm
going
to
do
is
generate
some
keys
that
we're
going
to
use
that
the
tecton
chains
controller
is
going
to
use
for
signing.
So
this
is
going
to
generate
an
encrypted
private
key,
so
I'm
going
to
enter
in
a
password
and
we
have
a
public
key
which
we're
going
to
use
for
verification
at
the
end
as
well.
D
D
Run
and
it's
going
to
take
a
few
seconds
just
for
everything
to
come
up,
but
hopefully
in
the
logs
we
should
cool.
We
can
see
the
three
different
steps
that
we
had.
Actually
it
looks
like
the
second
one
is
still
continuing,
but
first
we
create
the
docker
file
and
you
can
see
that
so
so
you
can
see
that
we
actually
did
reach
out
to
spire
when
generating
this
workload,
and
we
kind
of
have
one
for
each
container.
D
D
But
if
this
all
worked,
then
the
first
thing
it'll
do
is,
it
will
have
seen
that
attached
was
complete.
So
it
found
this
task
run,
which
is
like
this
big
long,
awful
chunk
of
text,
scroll
past
that
and
it'll
sign
it
and
store
the
payload
on
the
task
run
itself
as
an
annotation,
and
then
next
it'll
see
that
we
actually
it'll.
D
This
annotation
basically
means
that
that
spire
signed
the
workload
and
it
was
validated.
This
is
actually
not
supposed
to
happen
in
tecton
pipelines.
We
plan
on
moving
this
to
chains
and
have
chains
actually
doing
the
validation
itself,
but
it's
kind
of
just
here
for
now
definitely
still
a
work
in
progress,
and
so
we,
basically
we
take
the
payload
and
the
signature
decode
them
with
base
64..
D
So
we
have
our
payload
here
and
then
verify
with
cosine
against
the
same
public
key
and
it
looks
like
it
worked,
which
is
nice,
so
yeah,
that's
pretty
much
the
demo.
So
there's
a
lot
of
different
things.
I
think
we
can
do
with
this.
I
think
it
would
be
really
cool
if
we
could
use
different
build
systems,
not
just
techton,
but
maybe
jenkins.
D
D
D
C
A
D
C
We're
thinking
about
having
multiple
steps
in
the
supply
chain
and
so
like
and
trying
to
have
one
artifact
at
the
end
of
those
things.
So
if
you're
chaining
together
like
unit
tests
or
integration
tests
with
the
build
process
itself,
you
might
want
to
have
all
of
those
represented
as
a
broader
in
total
layout.
But
this
is
all
unknown
to
me
as
well
too.
So
I
don't
know
if
that
makes
sense
or
not,
but
that
was
how
I
was
thinking
about
it.
D
Got
you
yeah
right
now?
We
definitely
do
it
one
per
taskran.
I
don't
know
I.
I
don't
really
know
enough
about
antodo
to
know
if
it
is
like
meant
to
if
one
attestation
can
be
used
to
kind
of
like
cover
an
entire
chain
of
things
or
if
you're
meant
to
have
one
adaptation
for
everything,
but
I
could
look
into
it.
E
So
there's
also
one
thing
on
terminology
thing:
we
might
not
be
saying
the
same
word:
entoto
has
a
concept
of
links
and
a
concept
of
layouts
and
then
there's
also
a
third
concept
called
attestations
which
are
supposed
to
replace
links.
So
it's
kind
of
confusing
yeah.
I
think
you
were
talking
about
layouts
john,
which
are
like
chain
links
together
and
then
enforce.
Policy
on
them
is
my
understanding
of
it
and
then
yeah.
E
E
A
F
A
C
C
A
C
C
G
A
B
Yeah
sure
yeah
so
yeah
great
demo.
I
think
the
things
that
we'd
like
to
know
more
about,
if
folks
have
thoughts
on
is
one
is
how
sort
of
humans
get
involved
somewhat
in
throughout
the
sort
of
chain
of
things
right.
You
might
have
out-of-band
security
reviews
and
you
want
people
to
attest
to
a
security
review
or
also
you
know,
even
something
like
a
manager
approval
for
deployment
like
yeah
we're
good
for
deployment.
You
want
to
kind
of
have
that
also
be
part
of
the
set
of
attestations.
B
So
that's
something
that
I
think
we're
interested
in
along
with
we'd
love
to
be
able
to
see
you
know
in
the
future.
You
know
somewhat
more
of
the
okay
now
that
it's
gone
through
these
attestations.
Here's
how
we're
enforcing
it
in
production
to
ensure
that
the
only
things
that
are
running
are
the
artifacts
that
have
you
know:
we've
the
artifacts,
whose
provenance
has
been
sort
of
validated.
E
Yeah,
maybe
I'll
answer
the
human
one.
I
think
it's
a
great
use
case.
If
you
take
a
look
at
the
in
toto
out
of
state
and
I'll
drop.
The
link
in
here
it's
in
hyphen,
total
slash
attestation,
repo
you'll,
see,
there's
some
early
work
and
showing
how
that
could
happen.
There
there's
a
really
good
layering
system
in
here
that
I
like,
where
there's
it's
called
the
subject
and
then
the
statement,
and
so
what
pre-show
is
actually
not
an
attestation.
E
It's
a
provenance
statement
as
part
of
like
a
larger
attestation,
and
there
are
different
types
of
statements
that
can
be
made.
So,
instead
of
just
what
build
steps
ran,
you
could
have
a
statement.
I
think,
there's
an
example
here,
showing
a
code
review
or
something
like
that
where
a
human
can
make
a
statement
and
then
the
subject
is
actually
what
it
references.
E
So
if
you
think
of
just
containers
or
something
simple,
where
there's
a
shot,
256
hash,
you
can
start
to
join
and
build
up
like
a
giant
graph
of
all
the
statements
made
about
an
artifact
and
reference
things
that
way:
there's
all
sorts
of
cool,
giant,
graphql
style,
graph
database
things
where,
if
everybody
was
speaking
the
same
language
and
referring
to
things
by
digesting
the
same
way
and
making
statements
about
it,
you
can
start
to
imagine
some
really
cool
queries.
You
can
make.
A
Curious,
how
are
you
folks
thinking
around
packaging
this
as
a
solution
rather
than
hey
here's
a
reference
architecture,
we've
opinionately
picked
this
parts
and
leave
it
to
people
to
bring
up
versus.
Are
you
are
you
considering
instrumenting
the
deployment
of
this
and,
if
so,
what
would
be
the
order
of
operations
like?
Yes,
you
have
like
a
full
co
publicly
available,
like
presumably
you
have
to
bring
spire
first
like?
Are
you
taking
care
of
that?
Are
you
bootstrapping
that
spire
deployment
then
running
tecton
upon
it?.
D
That's
a
good
question.
I
guess
like
I
I
was
thinking
more
like
it
would
be
useful
if
we
had
like
one
central
repository,
maybe
where
we
have
like
a
few
different
examples
of
like
actual
like
real
world
ways.
People
would
want
to
use
this
and
maybe
just
have
all
the
config
in
there
and
then
people
can
kind
of
like
pick
and
choose
like
what
they
want
to
do
and
how
they
want
to
do
it.
I
don't
really.
E
A
E
Path
forward,
I
saw
it
would
be
like
just
throwing
this
out
as
an
idea,
like
just
kind
of
start,
with
what
priya
had
and
just
kind
of
nerd
out
on
it.
Like
turn,
we've
got
a
cluster
set
up
and
running,
people
can
come
play
with
it
and
just
like
geek
out
and
make
it
as
secure
and
crazy
over
the
top
as
possible
and
document
all
the
protections
you
get
and
everything
like
that,
and
then
step
back
and
see.
E
If
there
are
other
ways
you
know,
instead
of
picking
one
we're
just
kind
of
choosing
one
to
start
with
documenting
all
the
cool
stuff,
we
can
do
and
protections
we've
made
and
guarantees
we
can
make
and
then
figure
out.
You
know
make
all
that
pluggable
and
have
people
jump
in
and
show
other
ways
to
do
the
same
thing,
because
the
more
things
we
pick
here,
the
harder
it's
going
to
be
to
say.
Obviously
these
are
three
things
you
can
do
to
make
a
secure
supply
chain.
E
F
A
The
risk
with
that
is
today
a
lot
of
these
knobs
are
in
configuration.
Files
are
not
things
instead
of
programmatically,
say:
oh
idc
inspire,
so
it's
it's
error.
Prone
people
are
going
to
flip
on
the
wrong
thing
or
or
they're
going
to
stumble
on
it
like
they're,
going
to
have
followed
the
steps,
but
maybe
they
touch
the
wrong
field
or
the
wrong
ammo
somewhere
and
then
they're
gonna
be
blocked
in
that.
So
I'd
be
curious,
like
around
help
wanted.
A
F
Should
be
a
getting
started
of
some
sort
where
it
has,
you
know
again
these
examples
that
are
out
of
the
box
right,
but
yeah.
It
should
be
where
that's
again
the
getting
started
where
people
can
add
their
own
kind
of
you
know
two
cents
to
it,
but
we
have
to
have
a
line
in
the
sand
of
just
example
like
a
one
through
two
or
three
or
whatever,
because
if
it's,
if
it's
something
that's
so
nebulous,
it's
just
not
going
to
get
adoption
is
my
it's
my
take.
E
E
So
like
we're
kind
of
drawing
one
line
through
that,
like
a
map
of
like,
if
you
pick
these
things,
then
you
then
configure
it
this
way
following
this
tutorial,
you've
got
an
awesome
supply
chain
and
then
for
each
of
those
you
know,
there's
30
other
things
you
can
pick
in
the
cncf
landscape
and
we
can
open
it
up
and
let
people
show
how
to
swap
out.
You
know
if
you
can't
use
tekton
for
some
reason.
F
Exactly
and
then
have
issues
be
where,
if
somebody
needs
to
integrate
with
a
another
solution
or
something
of
that
elk,
then
we
should
have
those
projects
kind
of
help
to
you
know
if
something
rises
to
the
top,
then
we
can
go
to
other
other
people
do,
but
you
agreed
having
that
kind
of
initial
kind
of
rosetta
stone.
I
guess
right
so
of
the
cncf
landscape.
That's
the
word!
That's
the
word.
E
A
So
in
the
process
we
might
be
able
to
create
first-class
support
and
first-class
integrations
between
those
different
projects
getting
apis
for
the
different
things
now.
The
other
thing
to
get
super
crisp
on
is
going
to
be
the
ontology
of
it,
because
spire
has
a
concept
of
attestation
that
is
different
from
the
entodo
concept
of
at
the
station
as
the
same
person
in
charge
of
both
like
once,
you
got
the
stuff
running.
A
A
That
may
may
do
a
job
and
like
they
have
to
go
through,
like
this
machine
must
possess
a
a
virtual
tpm
and
it
must
have
been
deployed
in
this
availability
zone
and
this
namespace
and,
like
all
the
all
the
linux
introspection,
do
we
expect
the
person
to
know
these
things
to
be
the
same
person
to
to
do
inputs
and
layout
files,
or
these
are
typically
different
people
and
we
we
want
to
create
a
model
of
like
well.
You
give
this
to
this
person,
and
this
thing
to
this
other
person.
E
I
don't
think
there's
any
canonical
or
shape
of
like
who
wears
witch
hats.
It's
like
the
personas
question
we
always
face
of
like
what
are
the
all
the
possible
unique
personas
and
then
each
organization
is
going
to
map
them
on
to
people
differently
like
a
one-person
company.
You
got
everyone
with
that
same
hat,
and
you
know
two
big
companies
have
different
dotted
lines
around
who
wears
which
hat
so
yeah,
maybe
getting
crisp
on
the
personas
first
and
then
figuring
out
how
to
map
them
into
an
org
chart
would
help.
A
As
you
say,
like
those
those
are
blurry
and
and
often
broken
like
in
one
place,
it
may
be
a
one-person
army
in
other
places.
It
may
be
different
teams
like
whoever
ends
up
running
it.
It
would
be
good
if
we,
if
we
separate
distinctions-
and
we
don't
conflate
terms-
and
we
just
say
like
these-
are
different
layers
of
abstraction.
You
have
at
the
station
at
this
level,
which
is
not
like
conceptually.
It's
it's
accomplishing
the
same
thing,
but
it's
mechanically
done
very
different.
C
Yeah,
I
have
one
question
on
the
provenance
in
the
demo
right.
We
are,
what
is
sure
so,
once
the
image
is
produced,
the
artifact
is
produced,
the
provenance
is,
can
be
verified
only
for
the
image
or
it.
We
can
verify
that
this
image
was
produced
by
this
particular
task,
and
you
can
verify
that
right
or
this
pipeline
yeah.
D
So
the
providence
that
I
showed
actually
verifies
the
entire
task
run,
so
the
payload
is
actually
like
everything
in
the
task
run.
So
one
of
the
image
itself
is
like
an
output
or
a
result
in
the
task
screen
itself.
So
you
can
verify
that
the
image
came
from
that
task
run
because
it
is
part
of
the
payload
yeah.
D
G
C
Okay,
yeah,
I
think
I
think
we
had
that
early
disc
earlier
today.
The
discussion
right
that,
if
that
particular
image
had
basically
gone
through
some
of
the
tests
like
unit
tests
and
what
are
all
those
things,
is
there
a
way
to
also
provide
that
attestation
that
okay,
this
image
was
produced?
It
was
run
not
at
the
task,
but
at
the
pipeline
level
right
that
it
has
gone
through
this
pipeline
with
series
of
tasks.
D
Yeah
so
right
now
we
have,
we
can
generate
like
stations
for
an
entire
task
run,
and
so
you
could
have
out
of
stations
for
each
one
and
I'm
sure
we
could
add
support
for
like
creating
it
at
the
pipeline
level.
But
right
now
we
just
don't.
Have
it
like
that's
something
that
would
probably
be
really
cool.
D
D
F
A
A
D
I
feel
like
well
for
me,
I'm
I
guess.
I'm
focused
more
on
like
the
the
smaller
things
day-to-day,
like
I'm,
just
like
focused
on
actually
trying
to
get
like
aspire
to
work
with
chains
and
like
trying
to
make.
Oh,
the
demo
itself
was
like
a
little
bit
hacky
right
and
trying
to
like
clean
it.
All
up
is
like
more
what
I
focus
on.
I
feel,
like
the
I
think,
the
group
it's
cool,
because
then
we
can
kind
of
like
start
attacking
other
areas.
F
Yeah
and
let's
also
define
like
a
an
mvp
right
like
just
because
we
can,
we
can
attack
this
as
we
are
as
engineers
literally
for
months,
but
we
just
got
to
figure
out
okay.
What
is
it
this
is
our
line
in
the
sand,
everyone.
This
is
where
we
want
to
kind
of
get
out
there
as
a
basis,
and
then
let
you
know
let
it
out
in
the
wild
and
let
people
do
do
their
thing.
C
D
D
C
All
right,
it
looks
like
there's
a
few
other
external
projects
that
are
in
different
states
as
well
like
the
the
internal
attestation.
Stuff
is
like
0.1
is
it
like?
Maybe
we
can
also
help
push
these
other
projects
over
the
finish
line
as
well
too,
to
to
get
everything
kind
of
to
that-
probably
not
envy
for
mvp,
but
should
like
reiterate
the
importance
of
moving
these
other
projects
in
the
right
direction,
because
some
of
them
have
moved
historically
kind
of
slow,
but.
A
Yeah
that
would
be
dope
yeah
priya,
I
I
know
people
didn't
get
a
chance
to
introduce
themselves
and
you
might
not
not
know
who
you're
talking
to,
but
we
have
a
pretty
broad
representation
from
different
projects,
different
different
companies.
It's
it's
a
really
good
bench
of
expertise
for
folks
to
pitch
in
and
contribute
possibly
plug-ins
or
extensions.
A
I
think
the
ultimate
goal
here
is
bootstrap
an
ecosystem
and
like
people
being
able
to
sure
they
read
the
reference,
but
maybe
we
make
this
a
modular
thing
and
people
can
swap
it
for
something
else
or
the
apis
for
the
automation
and
the
instrumentation
of
the
bring
up
of
the
of
the
entire
supply
chain.
Definitely.
G
Are
you
not
too
bad?
Sorry,
I
feel
like
I've
been
on
vacation,
but
it's
like
a
vacation
in
hell.
I
just
haven't
really
surfaced
from
from
other
work,
but
as
I've
been
tidying
and
not
been
able
to
join
these
calls,
but
under
your
conversations,
what
city's
perspective
on
supply
chain
or
working
with
the
projects.
A
From
the
angle
of
software
factories,
so
priya
shared
the
work
that
she's
been
doing
working
with
dan
and
laurent
on
the
call
around
taking
tecton
taking
spire
taking
six
door
actually
like
it.
It
does
is
not
like
quite
glued,
but
it's
it's
like
nicely
interoperating
with
with
each
other.
I
believe,
you've
been
following
the
paper
and
we're
discussing
well,
there's
there's
some
areas,
they're
looking
for
help,
there's
also
areas
of
opportunity
to
extend
the
solution
or
like
take
the
solution
as
the
reference
architecture.
A
G
Oh
totally
right
so
so,
unfortunately,
I'm
gonna
have
to
rebind
and
see
the
demo.
I
apologize.
I
missed
it
here,
but
I
have
been
following
a
lot
of
this
work
right
and-
and
I
think
it's
absolutely
spot
on
right-
the
the
way
that
I
you
know,
I
suggest
we
look
at.
It
is
looking
at
that
high
level
architecture
figure
out
how
it
fits
in
and
see
where
any
of
the
gaps
are.
But
I
think
the
technologies
you're
looking
at
and
using
are
just
tremendous
right.
G
I
mean
it's
great,
open
source
work
that
I'd
be
interested
in
getting
involved
in
you
know
and-
and
you
know,
seeing
how
we
can,
how
can
make
it
work
at
a
larger
level,
but
also
you
know
start
with
that
architecture
and
figure
out
literally
from
the
beginning.
You
know
where
are
the
gaps?
I
I
think
that
the
whole
combo,
though,
between
techdon
spot
aspire
and
six
door,
is
a
really
compelling
one
though
awesome.
A
A
Through
it
one
one
other
dimension
that
comes
up
is
thinking
of
failure
modes
say
your
dark.
Fiber
gets
severed
to
focio.
What
is
the
expected?
Behavior
then
say:
tacton
loses
connectivity
to
spire,
like
what
did
you
set
up
your
time
to
lifts
or
your
route
got
compromised?
Whatever
you
want
to
force
rotate
your
route,
we
might
want
to
start
thinking
around
help
wanted
for
people
to
think
around
failure
modes
and
how
to
make
it
like
anti-fragile
just
in
resilient.
A
G
That
that's
a
great
point
and
we've
been
thinking
about
that
too.
Is
that
what
happens
if
we,
we
can't
get
access
to
some
of
the
those
trusted
stores
or
we
can't
validate
some
of
those
signatures,
and
how
do
you
there's
some
other
way
around
it
and
what
are
the
security
implications
of
the
mitigations
for
that
too
right,
and
then
I
guess
also
in
as
well
as
the
sort
of
failure
modes
is
anyone
threat
modeled
it
and
look
it
looked
at
it
that
it
may
have
already
happened.
G
I'm
not
aware
no,
but
because
I
I
think
that's
something
I'd
be
keen
on
doing
is
looking
at
the
full
end-to-end
architecture
in
the
very
next
stage
is
go
in
and
threat
model
that,
within
an
inch
of
its
life
and
then
figure
out
right.
Where
are
the
controls
we
can
start
to
embed
on
it
or
change?
Maybe
some
of
the
engineering
assumptions
and
such
just
based
on
that
threat
model
and
that.
F
G
G
B
Is
you
know
just
sort
of
I
don't
know
java
jar
go
binary
and
then
also
you
know:
how
does
that
get
published
to
an
actual
artifact
repository
and
then
how
would
that
get
deployed
in
production,
with
a
sort
of
validation
that
you
know?
Yes,
we
have
validated
the
provenance
supply
chain
and
you
know
so:
that's
okay
to
be
now
run
in
in
production,
environments.
D
Yeah
definitely
and
that's
kind
of
what
I
meant
by
like
kind
of
expanding
beyond
this
and
like
where
I
think
I
could
use.
We
could
all
use
a
little
bit
of
help
because
it's
definitely
possible
to
like
use
the
same
flow
to
sign
like
other
artifacts
like
jars
or
binaries,
but
it's
not
like
built
in
in
the
same
way
that
the
support
for
the
containers
is
so
that
could
be.
It
could
be
interesting
to
add
that
in
because
it's
possible
right
now,
but
it's
not
as
convenient
to
do.
I
guess.
B
Yeah
and
and
one
other
thing
that
I
think
I
I'm
sure
this
will
come
out
in
the
threat,
modeling
that
we
do.
But
I
know
one
of
the
biggest
sort
of
attack
vectors
is
like
the
build
itself
like
if,
if
it's
not
necessarily
that
somebody's
coming
in
from
the
outside
and
compromising
the
container,
but
the
code
that
you're
running,
like
the
actual
build
itself,
is
written
in
such
a
way
that
it
is
building
a
compromised
artifact.
B
Maybe
we
pulled
in
source
code
that
source
code
wasn't
vetted
the
right
way
and
then
now
you
have
an
artifact.
That's
been
signed
all
the
right
ways,
because
it's
still
gone
through
all
the
right
build
steps
and
whatnot.
But
you
know
that's
been
compromised
and
to
be
clear,
I
think,
there's
steps
you
know
whether
it's
sas
or
das
scans
or
whatever
can
can
do
that.
But
I
think
it's
worthwhile
kind
of
you
know
also
really
looking
at
like
what
is
the
build
step
actually
doing.
A
So
yeah,
I'm
sure
plenty
more
of
ideas
are
going
to
come
up
and
you
might
already
feel
overwhelmed
with
everything
we've
we've
said,
since
you
concluded
your
demo
priya,
but
we're
very
interested
and
eager
of
working
with
you
and
collaborating
and,
as
nan
pointed
out,
we
might
want
to
get
like
super
crisp
and
focused
and
just
like
do
a
project
board
and
pick
well.
We
could
do
50
things,
but
we're
gonna.
Do
this
three
before
kubecon,
I'm
sure
you're
already
doing
that
yourself,
like
you,
might
want
to
pick
how?
F
D
F
D
F
D
F
A
D
D
F
A
Yeah
for
since
we're
using
oidc
federation,
I
don't
know
that
spire
and
gcpoidc
work
together
today
because
of
the
ciphers
that
are
supported
when
we
implemented
this
for
aws
aws
didn't
have
support
for
elliptic
curve
and
jots
and
aspire
didn't
support.
Acne
starts.
We
did
added
acne
certs
and
we
had
to
like
fall
back
on
whatever
other
cypher,
like.
I
think
it's
just
using
narsay
right
now,
but
yeah.
I
think,
jk
support
doesn't
support
like
one
of
the
flavors
of
the
dcs,
so
yeah
we
might
need
to
get
a
little
bit
creative.
A
A
F
I
would
say
I
would
assume
would
be
a
full-time
media.
I
just
the
action
items
I'm
putting
here
is
digest
pre-a
demo
and
test
test.
It
crisp
crisp
up
what
what
we
want
to
do
and
I
think
next
meeting
we
should
probably
divvy
up
tasks
since
people
will
be
able
to
play
with
it
a
little
bit
and
kind
of
give
their.
You
know
I
it's
hard
being
in
this
nebulous
thing,
without
playing
with
something
and
understanding
where
you
can
fit
in
this
is
my
take.