►
From YouTube: TAG Security Supply Chain WG 2021-11-04
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
D
We
wanted
to
start
really
getting
just
like.
You
know
stuff,
like
just
just
comments
and-
and
you
know
tweaks
here
and
there
at
least
for
this
initial
v1
and
then
the
idea
was
to
allow
folks
to
quickly
we
can
work
on
like
a
v,
1.1
or
whatever,
and
all
that.
C
I
can
hear
I
can
hear
you
fine
michael.
Can
you
hear
me.
D
B
D
I
inappropriately
had
myself
viewed
there.
I
I
think
I
think
some
folks.
I
know
there
was
something
last
week
that
we
had
pushed
it
back
an
hour
this
week.
I
thought
it
went
back
to
the
normal
time.
D
C
D
Because
I
know
priya
is
out
brendan's
out,
I
I
wonder
if
andres
might
well,
so
I
know
andres
is,
is
on
vaca
like
on
on
leave
paternity
leave,
but
I
don't
know
well
either
way
we
can
get
started
either
way
we
can
get
started
and
if
it
needs
to
go
two
hours
it
can
go
two
hours
like
the
last
couple
times
and
because
I
have
you
know
time
to
do
that
so
I'll
start
off.
D
I
always
get
the
spiel
wrong,
but
you
know
just
as
a
reminder.
You
know
the
meeting
is
is
recorded
as
well.
As
you
know,
attending
this
meeting
and
participating
you
are
abiding
by
you
know.
You
need
to
abide
by
the
cncs
code
of
conduct
all
right
cool,
so
there
wasn't
really
anything
too
big
from
my
end
that
I
felt
any
big
topics
for
my
end,
so
I'm
gonna
mostly
defer
to
the
other
folks
on
the
call
on
anything
they
wanted
to
bring
up.
D
Last
week
we
went
over
the
diagrams.
I
added
some
additional
diagrams.
D
Yeah
I
I
added
some
additional
diagrams.
I
added
some
a
few
things
here
and
there
we
tweaked
a
couple
of
sentences
here
and
there,
but
besides
that,
I
think
we're
we're
pretty
much
ready.
D
For
you
know
a
sort
of
more
of
a
broader
community
review
as
well
as
I
believe
andres
has
said
over
the
dock
earlier
in
the
week
over
to
the
technical
writers
at
the
cncf
to
start
doing,
proofreading
and-
and
you
know,
making
sure
that
we're
consistent
and
pointing
out
any
areas
that
don't
make
sense.
That
kind
of
thing.
B
D
I
I
think
it
makes
sense
from
what
I
saw
right.
You
know,
I
think
that
that's
largely
like
yeah
we're
validating
you
know
everything
from
identity
to
the
actual
dependencies
and
images,
and
all
these
things
and
like
the
idea
is
you
know
as
long
as
you
pas
pass
all
of
these
policy
requirements,
then
your
stuff
goes
into
production.
You
know.
B
D
Oh
right,
actually
billy
do
you
want
to
introduce
yourself
since
I
think
you're
new
to
the
to
the
to
this
particular
group.
I
know
some
of
your
teammates
have
been
on
here.
C
Yeah
yeah
yeah
john
vele,
I've
been
around
kubernetes
for
for
forever
and
most
recently
been
working
on,
k
native
and
then
and
most
recently,
I'm
working
with
matt,
scott
kim
and
dan
over
at
the
chain
card.
So
I
just
wanted
to
go
ahead
and
say
hi.
I
met
michael
in
person
over
in
cube
current,
but
I
don't
think
I'm
met
all
you
all.
So,
thanks
for
having
me.
D
Yeah
cool
so
yeah,
just
as
to
catch
you
up
real
quick,
you
know
both
dan
and
matt
have
provided
a
lot
of
input.
A
few
other
folks
have
provided
you
know
a
lot
of
input.
We've
been
working
on
the
sort
of
reference
architecture
which
is
sort
of
intended
to
build
off
of
what
we
had
as
a
best
practices
white
paper,
those
things,
and
so
the
reference
architecture
is
intended
to
actually
be
a
hey.
What
tools?
D
And
how
do
you
use
those
tools
in
what
ways
in
order
to
get
something
that
you
can
kind
of
say,
hey,
I
believe
we're
building,
artifacts
that
to
sort
of
use
the
terms
that
that
salsa
is
really
pushing
is
we
believe
that
they
haven't
been
tampered
with.
We
believe
that
they're
authentic.
We
believe
that
they
also
have
integrity,
and
you
know,
assuming
those
you
know,
and
at
some
level
right
and
so
we're
obviously
focused
around.
D
You
know
the
cloud
native
piece
on
you
know
mostly,
but
just
to
kind
of
give
you
the
quick
thing,
john
and
alex
posted
some
docs
there,
or,
I
guess
the
one
doc
here.
I
also
post
the
meeting
notes
and
in
fact
actually
I
realized
I
forgot
to
post
a
meeting
notes.
I
will
add
the
thing
here
for
I
will
update
one
second
here.
I
will
update
this
so
that
we
can
start
having
we
can
put
down
attendance
and
everything
give
me
one.
Second.
B
A
D
All
right
so
feel
free
to
just
add
your
name
to
the
attendance
list
and
if
there's
anything
else,
you'd
want
to
update
or
whatever
else.
D
All
right,
okay,
so
other
topics,
because
I
know
once
again
you
know
we
can.
We
could
do
this
all
to
death
the
the
actual
document
itself,
I
think
largely
it
is
in
a
good
spot.
There
are
some
areas
that
are
a
little
inconsistent
and,
I
think,
alex
you
said
you.
You
had
kind
of
done
some
stuff
to
clean
up
some
of
the
mission
controller
stuff,
because
I
do
agree.
I
think
there
was
a
few.
We
had
the
emission
controller
stuff
in
like
three
or
four
different
places.
D
We
were
more
or
less
saying
the
same
thing
in
slightly
different
ways.
In
those
three
or
four
places
I
took
a
look,
it
seems
pretty
good.
I
just
wanna.
D
You
know
at
some
point
very
soon,
I'm
going
to
do
a
full
sort
of
read
over
the
entire
dock
again
and
and
double
check
some
of
those
pieces
yeah
but
alex
did
you
want
to
talk
anything
about
that
piece?.
C
No,
I
mean,
I
think,
I
I
basically
said
what
I
needed
to
say
in
the
in
the
chat
but
basically
yeah.
I
looked
at
the
actually
right
where,
where
that
that
new
diagram
came
in
that
and
mission
controller
section,
which
is
still,
I
think,
kind
of
long,
but
but
we
I
think,
I
think
this
was
one
of
those
things
where
we
had
for
several
weeks
in
a
row
we
had.
C
We
had
rehashed
this
particular
section
and
written
like
four
different
drafts
of
it
in
the
same
place,
and
so
I
tried
to
just
pull
those
together
into
a
consolidated
form
that
that
incorporated
all
the
the
ideas
that
we
were
trying
to
convey
there.
So
I
think
I
don't
know
that
we
need
to
go
through
it
line
by
line
in
this
meeting.
But
you
know
if
anybody
wants
to
take
a
few
minutes
and
read
through
that
and
make
sure
that
it
does
in
fact
capture
what
we've
been
talking
about.
C
But
I
haven't
in
my
in
my
consolidation.
I
didn't
delete
anything
that
really
needs
to
be
there
or
anything
like
that.
That
would
be
great,
but
that's
that's
where
that
is.
B
B
That
that
looks
great
alex.
Thank
you.
D
John
or
gary
do
you
have
any
other
sort
of
big
ticket
items
from
the
paper
or
anything
other
than
I
know
a
lot
of
like
little
a
lot
lots
of
little
comments.
People
have
been
making.
You
know
replace
physical
with
human
replace
manual
with
this
you
know,
like.
I
think
that
that's
just
gonna
keep
popping
in
for
until
we're
completely
done,
but
just
wanted
to
see
if
there
was
any
sort
of
other
big
things
that
that
need
to
get
addressed.
A
I
don't
think
so.
I
was
just
taking
a
look
at
appendix
c,
which
I
think
is
a
really
great
reference,
and
it
looks
like
there's
a
comment
about
like
whether
or
not
we
should
include
this.
I
think
it.
I
think
it
would
be
good
to
include
that
longer
term
in
terms
of
like
hey,
these
are
the
set
of
practices
or
recommendations
from
the
white
paper
or
the
best
practices
paper.
How
does
the
reference
architecture,
as
of
today
stack
up
against
that?
I
think,
is
important,
because
we
made
a
lot
of
recommendations.
D
So
that
is
my
next
big
topic
for
the
meeting,
so
so
we
can
talk
about
that
once
I
want
to
get
everybody
else's
feedback
first,
I
was
literally
typing
it
down
as
on
the
agenda,
as
you
were
saying
it
so,
but
first
gary
do
you
have
any
other
sort
of
questions
comments.
C
B
It
is
really
interesting
and
excited
to
see
this
this
all
coming
together,
cool.
D
All
right
so
there's
two
topics
I
want
to
bring
up.
One
is
the
reference
implementation
and
we
can
get.
We
can
get
a
little
later
in
the
meeting,
but
I
will
post
the
link
to
it
again
in
both
here
and
the.
D
So
once
again
recognize
that
the
code
is
very,
very,
very
gross,
it
was
originally
intended
as
a
quick
demo
and
then
people
liked
it
enough
they're
like
hey,
can
we
make
something
real
out
of
this,
and
so
that's
probably
going
to
be
where
we
start
off
with
some
of
the
sort
of
reference,
implementation
or
sorry.
The
prototype
implementation
for
what
we're
doing
in
the
reference
architecture
can
go
into
some
details
on
that
a
little
later,
but
the
next
steps
are
okay.
D
D
Sorry,
my
mouse
just
died
because
I
need
to
plug
it
back
in
so
the
the
the
things
that
we
want
to
do
is
work
the
broader
community
to
see
how
the
reference
architecture
sort
of
lines
up
with
some
of
the
standards
and
the
frameworks
and
the
specifications
that
people
have
in
the
community
and
a
big
one
is
salsa.
D
So
had
a
little
bit
of
a
discussion
about
that
yesterday,
going
to
be
sending
a
lot
more
emails
about
it,
some
of
the
folks
on
salsa
side,
kind
of
seemed
really
keen
on
working
with.
You
know
the
python
folks
and
working
with
some
other
open
source
communities
to
get
some
of
that
sort
of
stuff
done
around
like
hey.
Can
we
get
python
things
in
pi
pi
at
like
a
salsa
level,
two
or
something
like
that?
All
of
them?
D
You
know
and
have
that
sort
of
thing,
and
one
of
the
things
that
I
I
still
am
also
pushing
is
soon
is.
Can
we
also
start
to
talk
with
them
about
hey
what
level
salsa
do
you
think
this
is?
What
sort
of
proof
do
you
think
we
can
put
in
here?
What
sorts
of
attestations
do
you
think
can
make,
and
and
how
can
we
collaborate
so
that
we
can
start
to
show?
You
know
the
out?
D
The
artifacts
that
are
outputs
of
the
secure
software
factory
are
salsa
level,
two
or
salsa
level,
three
or
whatever,
and
I
think
that
you
know
my
cursory
glance
of
the
thing
is.
I
think
we
are
like
salsa
level
2.5.
You
know
we
are
very
close
to
salsa
level
3..
In
fact,
actually
we
even
have
some
components
of
salsa
level
4
as
long
as
your
projects
are
doing
the
right
thing,
but
I
do
want
to
work
with
the
community
on
this
to
sort
of.
D
To
to
figure
that
out
and
to
work
with
you
know
them
on
any
sort
of
issues
we
might
have
like
salsa
is
still
relatively
new.
The
attestation
spec,
I
believe
we
are
releasing
version
2
on
monday,
sorry
version
0.2
of
the
attestation
spec
on
monday,
as
long
as
everything
goes
goes
as
planned,
but
yeah.
D
I
think
we
want
to
make
sure
that
you
know
so
that's
just
one
thing
with
the
salsa
thing,
but
I
think
we're
also
curious
as
to
how
we
can
also
integrate
with
other
groups
like
the
cartographos
working
group
for
the
cncf,
so
that
we
can
start
to
guide
lot.
We
can
start
to
guide
people
and
saying
yeah.
This
is
not
you
know.
D
The
secure
software
factory
is
probably
not
a
day
one
for
an
enterprise
when
they're
switching
when
they're
starting
to
look
at
cloud
native
and
kubernetes,
probably
secure
software
factory
is
not
a
day.
One
thing:
it's
maybe
a
day,
two
a
day
three,
you
know
further
down
the
line
sort
of
thing,
because
we
recognize
that
it
could
be
quite
complicated.
It
requires
you
to
have
admission
control,
or
it
requires
you
to
have
a
good
idea
of
how
you're
managing
identities
and
secrets-
and
it's
you
know
it
also
requires
you
know
everything.
D
Almost
everything
is
code
right.
You
know,
and
also
git
ops,
all
over
the
place
and
so
on
and
so
forth.
So
just
want
to
kind
of
throw
some
of
those
general
things
that
we've
been
talking
with
a
few
different
groups
on
but
want
to
get
other
folks
thoughts.
B
So
one
question
I
had
is
michael:
do
we
need
to
do
that
in
phase
one,
or
can
we
do
it
in
phase
two.
D
Oh
no
yeah,
so
a
lot
of
this,
I
believe,
is
probably
a
phase
two
sort
of
thing,
but
we,
but
given
the
only
reason
why
I
think
some
of
it
we
want
to
start
poking
around
now
is
a
lot
of
teams
and
groups
are
starting
to
plan
2022
and
so
yeah.
We
do
want
to
make
sure
that
that
at
least
we
get
on
the
radar.
I
guess
for
some
of
the
folks.
C
I
think
I
agree
with
you,
michael
that
my
my
cursory
glance
at
what
we've
done
so
far,
I
think
also
is,
is
somewhere
between
two
and
three
on
the
salsa
scale,
and
I
think
I
don't
know
I
mean
probably
you
know.
Obviously
we
should
we
should
consult
with
the
salsa
people,
but
I
think
that
if
we,
you
know,
put
this
out
and
say:
okay,
so
here's
version
one
of
this
reference
architecture
and
we
think
that
if
you
implement
a
reference,
if
you
implement
a
secure
software
factory,
that
follows
these
recommendations.
C
You'll
be
at
salsa
2.
Out
of
the
out
of
the
gate
that
you
know
and
then
in
future
work
we
hope
to
attain
higher
levels
or
help
you
attain
higher
levels
or
whatever,
like.
I
think,
that's
a
reasonable
statement
that
we
could
make
somewhere
in
the
in
the
introduction
of
this
document.
D
Yeah
and
like
I
will
probably
for
various
reasons,
have
to
at
least
take
a
step
back
from
some
of
it.
Just
because
I
am
a
voting
member
of
the
steering
committee,
and
I
don't
want
there
to
be
a
conflict
of
of
interest
of
like
oh
yeah,
the
other
project,
I'm
working
on.
It's
also
for
it's
perfect
and
I'm
I'm
attesting
to
it.
But
but
I
do
think
you
know
it
could
be.
D
I
do
think
it's
it's
it's
going
to
be
very
close
to
yeah,
salsa
3,
and
especially
with
some
changes
and
whatever
we
could
probably
get
it.
Salsa
3.
it.
Actually,
you
know
the
funny
thing
is:
if
all
the
stuff
was
there
today,
we
could
easily
get
salsa
4
for
things
that
are
reproducible
as
long
as
you're
using
certain
technologies.
D
Like
you
know
certain
things
like
you
know,
if
you're
using
build
kit
and
you're
using
you
know,
you
have
reproducible
bill,
build
pack,
sorry,
if
you're,
using
build
packs
and
you're
using
reproducible,
builds
or
nicks
and
reproducibles
and
similar
sorts
of
things
like
bazel
or
whatever,
and
you
are
using
spiffy
spire
in
the
right
ways,
and
I
recognize
that
the
spiffy
spire
stuff
hasn't
been
integrated
in
all
the
tools
yet.
D
But
assuming
you
were
doing
all
those
things,
you
would
pretty
much
have
salsa
4
at
that
point,
but
there's
a
few
things,
obviously
that
that
still
need
to
be
done
in
the
community
to
kind
of
get
those
features
in
the
tools
in
order
to
yeah
done.
Oh,
okay,
yeah.
So
it
looks
like
what
the
reason
why
a
lot
of
folks
aren't
on
the
call
is
because,
once
again,
I
guess
because
of
europe
changing
their
time
zone.
I
guess
it
was
part.
I
guess
the
meeting
was
still
scheduled
in
europe.
D
It
doesn't
doesn't
matter,
I'm
gonna
be
on
for
a
while.
So
yeah
just
wanted
to
kind
of
throw
that
out
there.
The
reference
implementation
right
now,
I
believe,
is
salsa.
2.
once
again,
it's
just
a
demo,
it's
the
demo
that
I
showed
off
at
kubecon
and
a
few
other
places,
but
that,
but
that
is
giving
salsa
level
two
level
attestations
out
of
chains.
D
A
Can
we
make
it
any
easier
to
achieve
salsa
level,
two
or
more
easy
to
understand
like
if
we
really
want
to
get
people
to
salsa
level?
Four
like
how
much
time
and
effort
is
reasonable
to
expect
them
to
put
into
understanding
that
and
the
scope
of
this
problem
is
it
going
to
be?
You
have
to
read
the
100
pages
combination
of
the
you
know
the
best
practices
guide
and
the
reference
architecture
and
read
all
of
this
code
and
understand,
salsa
and
like
like
how
do
is
there
a
separate
effort
around
making
it
easier
to
consume?.
D
Yeah,
so
so
you
bring
up
a
good
point.
Let
me
actually
add
that
as
oh,
let's
actually
just
let
me
just.
D
Yeah
there
is
a
big
thing
there
around.
How
do
we
make
this
easier
to
consume?.
D
So
the
my
my
thing
is
yes,
that
is
definitely
also
a
phase.
Two
thing
there's
a
couple
of
things.
One
is,
as
I
kind
of
mentioned
before,
some
of
the
features
that
allow
us
to
do
some
of
the
things
we've
even
described
in
the
reference
architecture.
Some
of
those
things
like
right
like
when
we
wrote
them.
The
feature
was
still
being
written
right.
You
know
it
is
so
when
it
comes
to
a
lot
of
this
stuff.
D
A
lot
you
know,
especially
I'm
going
to
say,
there's,
there's
certain
tech
companies
like
your
googles
and
whatever
that
that
have
written
a
lot
of
this
sort
of
stuff
internally,
and
it's
also
a
little
bit.
You
know
when
you
have
thousands
of
engineers
working
on
on
the
problem.
You
you
you,
can
you
can
solve
it
right,
you
know
or
you
can
you
can
do
what
you
need
to
do
and
so
not
once
again
like.
D
This
is
the
sort
of
thing
where,
when,
when
you
can
sort
of
compile
a
lot
of
things
from
source,
you
can
do
a
lot
of
those
things
now
when
it
comes
to,
you
know,
hey,
how
do
we
beat
this?
To
sort
of
somebody
who's
like
yeah,
I
don't
have
a
thousand
engineers
who
can
work
on
this.
I
have
two
guys
or
you
know,
two
people.
How
do
you?
D
D
This
is
not
the
sort
of
thing
that
we
just
expect
somebody
to
be
able
to
pick
up
the
same
way
that,
like
you
know
in
2016
right,
you
know,
kubernetes
was
not
the
easiest
thing
to
just
sort
of
spin
up
and
use
and
just
kind
of,
and
then
use
securely
and
yaya
right.
It
took
a
lot
of
effort.
You
know,
I
think
what
was
the
the
thing
that
people
keep
using
is.
Is
you
know
how
do
we
make
it
boring?
You
know,
how
do
you
make
it
boring
and
it's
gonna
take
time.
D
I
think
that's
the
that's
really
the
big
thing
here
now
with
that
said,
I
think
we
can
do
certain
things
with
the
secure
software
factory.
Oh,
let
me
actually
copy
the
whole
thing
here,
the
the
actual
that
github.
So
one
of
the
things
I
want
to
be
able
to
do
is
say:
hey
look
from
a
prototype
implementation
perspective.
We
can
show
you
what
it
looks
like
now.
This
is
not
going
to
this
is
not
a
one.
Size
fits
all.
D
You're
gonna
need
to
do
a
lot
of
effort
on
that,
but
just
this
is
sort
of
where
we're
starting
to
push
and
whatnot
now
the
thing
that
I
think
we
also
need
to
sort
of,
but
while
going
through
this,
I
think
it
really
just
comes
back
to.
D
We
really
need
to
acknowledge
that
this
is
going
to
be
a
hard
thing
to
to
begin
with,
because
something
that
came
out
of
supply
chain
security
con
one
of
the
things
we
noticed
in,
especially
in
the
slack
chat
for
it
was
lots
of
folks
saying
this
seems
hard
you're
telling
me
that
I
need
to
validate
and
sign
everything
and
have
these
attestations
and
blah
blah
blah.
D
D
Some
of
that
is,
you
know
it's
a
different
pattern.
The
same
way
that
we've
moved
away
from
as
much
as
possible.
We
moved
away
from,
like
you
know,
complete
monoliths
right,
we've,
deconstructed
applications
and
whatever
not
everything
has
to
be
a
microservice,
but
we've,
you
know
gotten
more
reasonable
there
and
we
said:
hey
look.
You
can't
do
these
sorts
of
things
anymore,
it's
just
not
gonna
work
and
then,
at
the
same
time,
how
do
we
also
still
make
it
easier
right?
A
Yeah-
and
I
think
that
all
makes
sense-
maybe
one
of
my
concerns
to
be
a
little
more
explicit
is
like,
given
the
constituencies
of
this
group
and
salsa
are
do
we?
Is
there
a
fine
line,
we're
walking
between
this
being
the
reference
architecture
or
implementation
of
a
salsa
supply
chain?
A
Or
is
this
the
cncf
reference
architecture,
or
does
that
matter
and
like
like
it
doesn't
end
up
being
both
and
does
it
send
them
a
signal
or
message
on
behalf
of
salsa
that,
like
maybe
salsa,
is
too
complicated
or
the
standards
are
set
too
high
for
salsa
that
we
don't
want
to
like?
We
don't
want
to
get
involved
in
that
or
like
or
like
do
we
need
to
separate
these
things
in
any
way
and
are
there?
Is
there
any
implicit
like
assumptions
made
about
the
relationships
there.
D
So
I'll
give
well,
so
let
me
just
give
my
two
cents
and
then
I
want
to
defer
to
other
people.
My
two
cents
is
just.
I
think
it
is
going
to
be
a
symbiotic
relationship.
I
think
weird
helping
push
salsa
to
be
a
bit
more
clear
about
some
of
the
requirements
and
how
we
do
that
and
then
I
think
salsa
is
pushing
on
us
to
be
a
bit
more
aspirational
and
I
think
just
the
the
other
thing
that
should
be
clear
about
salsa.
D
Is
we
want
to
make
sure
that
that
salsa
level
4
is
clearly
an
aspirational
goal?
Very
few
people
are
going
to
be
able
to
achieve
it
and
in
many
cases,
you're
probably
not
going
to
have
salsa
across
the
board.
You
might
have
for
my
crown
jewels.
That's
salsa,
4
right,
you
know
for
our
core.
You
know
like
just
as
an
example
here,
like
maybe
you
work
at
a
hedge
fund.
You
know,
oh
okay,
our
logic
on
how
we
look
at
you
know.
D
The
markets
is,
is
salsa
level
four,
but
our
marketing
website
all
needs
to
be
salsa
level.
Two
right
like
we
don't
you
know
you,
you
can
see
that
there
might
be
a
balance
between
those
those
different
things
and
and
yeah.
So
I
think
it's
going
to
be
we're
both
going
to
be
pushing
on
each
other
to
to
to
figure
this
out,
but
want
to
get
other
folks
on
this
calls
thought
on
it.
C
Yeah,
I
think
that's
that
kind
of
fits
with.
My
sense
too,
like
my
my
impression
of
salsa,
is
that
the
like,
like
salsa
level,
four
to
me,
sounds
like
this
is
critical
infrastructure.
This
is
national
security
level
stuff.
This
is
stuff
that,
like
probably
your
average
everyday
developer,
doesn't
actually
need
to
be
trying
to
build
salsa
level.
4
artifacts.
C
You
know
somewhere
in
that
range
anyway
and
that
you
know
what
we
want
is
for
people
to
improve
the
security,
because
we
currently
have
a
whole
bunch
of
stuff
that
doesn't
fit
any
of
these
categories
of
salsa
at
all,
and
it's
wreaking
havoc
but
wha,
you
know,
but
we
don't
necessarily
need
to
say,
and
now
everyone
needs
to
be
salsa
4
because,
like
that's
just
unrealistic,
and
so
we're
probably
trying
to
push
people
to
say
like
somewhere
in
that
two
to
three
range
is
the
target
for
most
application
stacks.
Does
that.
C
I
think
that
makes
a
lot
of
sense.
My
only
it's
not
even
a
concern,
but
thought
is
that
there
is
so
much
code.
That
starts
off
very
much
with
the
oh,
hey,
I'm
going
to
start
pro
thing
and
all
of
a
sudden
you
realize
that
the
entire
company
is
depending
on
that
kind
of
a
thing
right.
C
So
as
long
as
being
able
to
go
ahead
or
or
what
I
think
it'd
be
super
nice,
I
mean
obviously
it's
not
exactly
comparable
but
like
pearl
used
to
have
the
tank
flag
right
if
you've
ever
used,
pearl
and
you're
like
okay.
Well,
now
I'm
secure
right,
but
it
was
like
you
could
at
least
get
to
a
point
where
you
could
go
ahead
and
start
with
the
you
know,
rolling
the
knuckles
on
the
keyboard
and
you
get
a
valid
pearl
program
and
you're
like
well.
C
That
was
fun
and
then
eventually,
as
as
it
gets
used.
So
as
long
as
there's
a
pathway
that
that
allows
you
to
grow
with
the
salsa,
if
you
will
so
that
you
can
go
ahead
and,
for
example,
start
with
something
like
that-
and
you
know
obviously
I'm
super
simplifying
this,
but
you
know
by
by
adding
more
check
boxes
and
and
flags
and
everything
else.
You
have
a
pathway
where
it
isn't
like.
Okay.
Well
now
I
gotta
redo
everything
that
that's
my
only
thought
on
that
matter.
D
Yeah
and-
and
that's
definitely
what
one
of
our
concerns
with
whatever
we
bring
up
as
like
a
prototype
implementation
or
whatever,
I
think
the
thing
that
we're
even
saying
with
some
of
the
stuff,
even
with
the
the
reference
architecture
document,
it's
going
to
be
a
long
journey
before
a
lot
of
this
really
gets
hearted
and
consolidated
around
you
know
this,
isn't
you
know
the
the
thing
that's
come
up
and
in
some
conversations
is
this?
Isn't
like?
Oh,
the
iso
standard,
this
isn't
the
nist
standard.
D
D
We
are
even
acknowledging
in
the
document
that
some
of
the
stuff
that
we
stayed
in
there
might
be
out
of
date
by
the
time
it's
been
published
because
of
how
quickly
things
have
been
moving,
but
I
I
agree
with
you
on
on
the
point,
though,
of
of
like
once
we
do
consolidating
around
tooling
and
yaya
that
becomes
much
harder
to
that
becomes
a
much
harder
decision
to
reverse,
because
once
you
have
folks
like
as
an
example
like,
oh
everybody
installed,
techton
or
everybody
installed
jenkins
x
or
everybody
installed
whatever,
and
then
you
say:
oh
maybe
that
wasn't
the
best
decision.
D
Everybody
goes
well,
you
know
we
we
made
that
decision.
Now,
it's
it's
yeah.
D
It's
gonna
be
an
interesting
challenge.
D
Cool
okay,
so
any
other
questions
comments
on
like
sort
of
the
the
next
steps
feel
free
to
also
like.
If
are
there
other
next
steps
that
people
is,
it
is
there
another
thing
that
people
want
to
was
like.
I
say
like
any
other
next
steps
that
people
wanted
us
to
get
involved
with
other
groups.
Other
initiatives,
those
sorts
of
things.
B
Only
thinking
of
the
confidential
compute
for
the
root
of
trust
I
saw
in
the
beginning
of
the
software
factory
that
we
need
to
establish
a
clear
route
of
trust,
not
sure
if
we
can
leverage
the
confidential
compute
available
from
all
the
csps
right.
B
Hardware
rooted
trust,
just
the
just
the
software
factory
should
it
be
built
in
a
confidential
computer.
I
don't
know
underlying.
D
Yeah,
so
I
I
do
think
that
that's
going
to
be
probably
another
set
of
next
steps.
I
think
one
of
the
things
that
we
had
sort
of
briefly
sort
of
discussed
because
of
all
the
work
in
the
tpm
space
and
the
confidential
compute
space
and
trusted
execution
environment
space
is
that
a
lot
of
that
sort
of
stuff
is
still
being
developed
and
one
of
the
problems
I
think
we
had
was
also
a
lot
of
the
things
today.
D
Don't
just
don't
work
in
containers,
yet
there
is
effort
to
get
like
vtpm
working
better
in
containers
and
some
of
these
other
sorts
of
confidential
compute
sorts
of
things
working
inside
of
containers
in
a
better
way.
There's
actually
some
work
on
the
spiffy
spire
side
that
should
get
merged
in
in
the
coming
weeks,
but
that
would
only
work
at
the
sort
of
kubernetes
node
level.
D
It
wouldn't
work
for
the
workloads
themselves,
but
yeah,
that's
still
worth
some
additional
conversations,
and
actually
I
I
do
think
that
we
should
be
working
with
the
other
working
groups
that
are
focused
on
the
hardware
stuff
to
kind
of
figure.
Some
of
that
out,
I
think
today,
the
way
we've
sort
of
stated
it
right
now
is
we've
deferred
to
the
best
practices
white
paper
around
some
of
these
things.
That
do
say
you
should.
You
know,
root
your
trust
in
hardware,
if
possible,
right
for
a
lot
of
these
things.
D
Now,
with
all
of
that
said,
I
think
it
would
be
really
really
worthwhile
if
we
are
building
out
that
reference
implementation
as
an
actual
piece
of
code.
I
want
us
to
sort
of
you
know
practice
what
we
preach
and,
if
possible,
like
you,
know,
enforce
the
same
sorts
of
rules,
maybe
do
something
like
yeah.
We
have
a
key
signing
ceremony
or
whatever,
with
you
know,
here's
the
reference,
implementation
or
prototype
implementation
and
we're
following
all
the
rules
that
we
stated.
B
A
I
think
one
one
other
area,
I've
seen
and
just
came
to
mind
when
you
mentioned
the
like
mandating
use
of
specific
tools.
You
know
like
you,
you
have
to
use
jenkins
or
tekton
or
something
else's.
Some
of
the
most
prevalent
tools
are
not
open
source
like
I
don't
know
how
much
of
jenkins
is
open
source
or
how
much
of
like
the
I
saw
a
tweet
from
miranda
this
week
about
something
artifactory
was
doing
with
with
some
jfrog
stuff
for
secure
supply
chain
like
it
would.
D
Yeah,
I
I
I
so
we
have
been
having
some
chats
on
that
front.
D
Just
a
few
of
us
just
sort
of
like
just
just
I'm
trying
to
remember,
if
there's
any
specific
vendors
as
much
as
just
it
was
a
big
topic
of
conversation
at
kubecon,
I
will
say
that,
like
a
lot
of
vendors
are
kind
of
like
hey,
we
would
love,
for
you
know
salsa
to
become
a
bigger
thing,
because
then
we
can
say
you
know,
like
an
average
vendor
will
say:
oh
yeah,
we
have
the
sauce.
D
We
have
a
salsa
level,
two
badge
right,
you
know,
and
so
people
kind
of
say,
ooh,
nice
and
and
the
same
way
as
well
right
like
are
they
doing
anything
that
we
should
know
about
really
interesting,
that
we
should
include
obviously
we're
still
running
into
some
issues
right
with
stuff
like
vendors
want
to
you
know
we
all
just
got
to
make
money,
so
they
are
very
much
like
saying
how
much
do
we
want
to
talk
about
what
we're
actually
doing
right,
because
we
don't
want
to
you
know,
say
too
much
and
get
you
know,
and,
and
now
it's
just
like
our
secret
sauce
is
now
just
open
source.
D
D
But,
but
are
you
actually
following
it
or
you
just
yeah
we're
following
something
like
it
and
you're
like
so
so
that
just
means
you're
not
following
it
and
and
you're
kind
of
you
either
took
what
we
did
and
forked
it
and
kind
of
doing
your
own
thing
and
trying
to
make
it
more
proprietary,
which
fine,
you're
you're
able
to
do
that,
but
recognize
that
a
lot
of
other
people.
You
know
if
the
community
goes
this
way.
You're
gonna
be
stuck.
A
Yeah-
and
I
think
it
brings
another
interesting
perspective
and-
and
I
don't
know
the
company
representation
of
everyone
here,
but
I
think
if
I
can
generalize
and
and
maybe
I'm
not
raised
like
we've-
had
more
participation
from
a
lot
of
the
large
platform
providers.
You
know
that
I
mean
rather
than
security
companies
or
the
smaller
vendors
that
are
like
actively
developing
technology
in
this
space,
and
it
may
be
influencing
the
perspective
that
we
offer
and
I
think
that's
another
good
reason
to
involve
more
people.
D
Yeah
and-
and
so
a
thing
I
had
heard-
and
this
is
another
thing
which
is
once
again-
I
don't
want
to
get
too
deep
into
rumor
and
speculation,
but
I
did
hear
some
gossip
that
there
are
vendors
who
seem
to
be
very
interested
in
seeing
us
publish
this
thing
and
then
them
saying:
oh,
we
follow
the
cncf,
you
know
ref
arc,
but
I
think
a
lot
of
vendors
are
just
you
know
I
get
it.
I
used
to
work
at
a
vendor.
D
You
know
they
often
a
lot
of
vendors
do
not
want
to
work
with
open
source
because
they
have
enough
things
going
on
and
they're
just
like.
We
would
much
rather
just
consume,
it
contribute
back,
yeah
yeah,
I
get
it,
but
I
do
we
as
much
as
we
can.
D
I
think
we
should
work
with
vendors
who
do
want
to
work
with
us
and-
and
we
do
want
to
you
know-
have
reach
out
to
to
vendors
around
this
now
now,
with
a
lot
of
that
said,
I
think
I
don't
know
about
everybody
else
where,
where
exactly
everybody
else
works
ahead,
but
I
know
a
lot
of
folks
on
the
school
are
working
at
vendors,
just
maybe
very
large
vendors
who
do
have
broad
open
source.
You
know,
or
you
know,
orgs
under
it.
D
I
I
I'm
working
for
an
end
user.
So
that's
where
I'm
coming
from.
A
D
Yeah
and-
and
I
think
you
know
it's
one
of
those
things
as
well
when
it
like,
we
want
to
make
sure
that
we're
also
clear
when
I
can't
you
know-
and
this
is
something
we
made
sure
it
was
clear
in
a
lot
of
this-
is
that
if
there
is
a
tool
that
is
listed
in
the
ref
arc,
if
there
is
a
thing
it's
just
because
the
authors
of
the
ref
arc
were
familiar
with
it,
it's
not
or
it's
specifically
because
it
matches
the
cncf's
policies
around
hey.
D
Look
if
there's
a
cncf
tool
that
does
this
thing.
We
should
be
pushing
obviously
that
cncf
tool
unless
it
lacks
the
the
features
that
that
are
required
for
whatever
we're
talking
about,
but
at
the
same
time
you
know,
there's
we
want
to
make
sure
that
it's
also
clear
that
you
know
there's
nothing.
Nothing
in
there
is
left
out
specifically
because
we
hate
that
tool.
It's
like
well,
one
is
we're
an
open
source
thing,
we're
not
going
to
specifically
call
out
vendors
and
be
like.
D
Oh,
this
vendor
is
great
and
at
the
same
time
it
might
just
be
because
you
know
the
people
who
contributed
the
most
to
the
paper,
just
weren't
familiar
with
those
tools
and
if
somebody
else
comes
in
and
says
oh,
I
would
write
up
a
whole
blurb
about
this
other
tool.
Go
ahead
for
the
next
version
or
whatever,
but.
A
Yeah
yeah,
and
I
think
that
the
other
encouraging
part
is
the
the
idea
that
a
vendor
would
prefer
to
reference
the
reference
architecture
and
say:
hey
we're
in
compliance
with
this.
Rather
than
shoot
it
down
and
say:
hey,
we
don't
know
who
these
people
are.
We
completely
disagree
with
everything
they've
proposed
and
you
shouldn't
listen
to
them.
Here's
our
proprietary
solution.
A
D
And
I'm
sure
there's
going
to
be
some
big
vendors
that
will
most
likely
just
say.
Well,
we've
locked
you
into
our
walled
garden,
so
you
have
to
apply
our
best
practices
or
go
find
another
vendor.
I'm
sure.
That's
also
going
to
happen.
That's
just
what
we
have
to
deal
with,
but
yeah
the
more
folks
we
can
get
involved
the
better.
D
C
Think
we've
made
a
little
bit
of
space
for
this
in
the
way
we've
structured.
The
paper
too,
where
we
have.
We
have
like
a
a
prototype
implementation
that
is
built
entirely
around
open
source
tooling.
Basically,
but
then
we
go
into
sort
of
a
theoretical
description
of
what
a
secure
software
factory
looks
like
and
there's
nothing
about
that
theoretical
description
that
would
preclude
you
from
building
your
own
proprietary
tools.
That
did
all
of
those
things
if
you
really
wanted
to
as
a
vendor
do
all
of
that
in-house
right.
C
So
so
I
think,
like
we've,
we
sort
of
have
like,
given
you
two
paths
forward
right,
like
here's,
a
model
if
you're
in
the
open
source
world-
or
you
want
to
do
all
of
your
stuff
with
open
source
tools.
Here's
a
great
way
to
do
it
because
we've
built
it
out
and
you
can
just
kind
of
follow
along
with
the
way
that
this
has
been
built
right
and
then,
but
if
you
really
are
not
gonna
do
that
you
can
like
here's
the
theory
and
you
can
build
it
yourself.
D
Yep,
yeah
and-
and
I
think
that's
actually
it's
something
that
that
was
already
brought
up
with
some
of
the
the
the
the
secure
software
factory
ssf
stuff,
it
does
look
like
somebody
from
white
source
is
poking
around
with
some
of
the
reference
implementation
code,
we've
written
and
saying
like
hey.
How
can
we
start
to
adopt
some
of
these
things
and
how
can
we,
you
know
yeah
yeah
and
it's
like,
and
I
think
you
know
that
person
even
mentioned
that
they
want
to
like
do
this
the
hard
way
right?
D
They
they
don't
just
want
something.
That's
just
you
know,
because
they're
gonna,
you
know
they
recognize
just
as
well
as
everybody
else
that
people
are
gonna,
have
a
diverse
set
of
tools
that
they're
gonna
use.
They
just
need
to
know
what
what
are
the
features
that
they
need
in
those
tools
and
how
do
those
tools
need
to
be
sort
of
tied
together
to
get
that
reference
architecture,
and
I
think
we
do
a
pretty
good
job
at
saying
hey.
This
is
what
the
reference
architecture
requires.
D
Okay,
if
not,
I
did
wanna
quickly
shift
to
some
of
the
demo
stuff
just
to
as
there's
not
the
demo,
the
the
secure
software
factory
code
once
again,
the
the
code
here
at
some
point.
The
idea
is
to
go
through
all
the
correct
cncf
best
practices.
Sorry,
the
all
the
correct,
cncf
bureaucracy
practices
in
order
to
get
this
potentially
included
as
an
actual
project
in
the
cncf
or
as
a
repo
under
the
cncf
there's
a
lot
of
paperwork
that
needs
to
get
done
for
that.
D
So
that's
why
we
have
it
here
for
now,
because
otherwise
we
would
just
have
to
be
stuck
just
not
being
able
to
do
anything,
and
I
wanted
it
off
of
my
personal
repo
because
I
just
didn't
want
it
to
seem
like.
Oh,
this
is
mike's.
You
know
we
didn't
want
to
just
seem
like.
Oh,
this
is
just
what
mike
is
doing
on
the
side
and
it's
like
no.
No.
This
is
what
a
bunch
of
us
are
all
doing
and
working
on
just
a
couple
of
things
here
is.
D
This
is
very
obviously
intended
for
just
purely
a
demo
right.
I
have
some
stuff
in
here.
It's
all
just
intended
for
the
demo.
We
are
in
the
next
day
or
two
we
plan
on
restructuring
it
all
so
that
it's
more
like
this
is
what
needs
to
get
installed,
and
then
this
is
what
and
then
like
under,
like
something
like
a
demo,
folder
or
an
examples.
Folder
are
the
things
you
can
run
to
show
it
off
and
then
we're
looking
at.
You
know,
potentially
a
lot
of
just
different
tools
and
technologies.
D
Obviously
we're
you
know
since
right
now,
it's
just
all
of
us
working
on
it
like
the
more
the
merrier.
I
have
a
bunch
of
issues
in
here.
The
biggest
one
that
we're
working
on
right
now
is
is
sort
of
this
re-architecture
piece,
which
is
just
how
do
we
just
create
a
very
simple
baseline
like
where
we
are
in
you
know,
instead
of
having
the
scripts
all
over
the
place,
we
have
the
scripts
in
all
one
place.
We
have
the
installation
all
one
place.
D
If
we're
using
helm,
we
have
the
helm,
charts
in
a
consistent
sort
of
helm,
charts
set
up
and
that
we
have
the
mechanisms
right
where
hey,
if
you're
doing
stuff,
with,
for
example,
we
are
using
tekton
for
the
reference
implementation
and
we're
using
chains.
You
know
if
you
want
to
include
a
new
pipeline.
D
Hey
here
is
the
structure
for
what
that
looks
like,
so
that
you
could
just
sort
of
easily
you
know
sort
all
that
out.
So
we're
looking
at
tools
also
like
q
and
some
other
things
to
kind
of
get
all
of
that
stuff
organized.
We
are
very
much
you
know,
since
this
is
all
part
of
this.
The
same
group
we're
very
much
you
know,
feel
free
to
open
up
issues,
feel
free
to
test
it
out,
feel
free
to.
D
D
As
close
to
salsa
4
as
possible
for
the
software
factory
itself
right
because
we
want
to
say
hey,
I
don't
want
like-
I
am
making
sure
that
everything
goes
through
a
two-person
code
review
right,
even
though
technically
I'm
an
admin
on
this
thing
I
don't
want
to
like,
but
I
want
to
have
and
to
be
clear.
I
haven't
used
github
too
much
recently
to
know
how
to
enforce
all
these
things.
D
I'm
working
with
a
few
folks
on
that,
but
to
make
sure
that
we
are
following
all
the
best
practices,
all
the
rules
and
yayada
right,
because
we
want
to
make
sure
that
this
is
something
that
we
can
point
to
folks
and
say:
hey
the
supply
chain
of
the
secure
supply
chain
thing
is
secure
right.
We
don't
want
to
end
up
in
a
situation
where
it's
like.
D
Oh
we,
the
the
secure
software
factory,
like
the
canonical
example
of
this
thing,
got
supply
chain
attacked,
and
now
we
all
look
like
idiots
right
like
we
don't
want
that.
D
On
project,
I
think
the
most
helpful
thing-
and
this
is
where
it
is
kind
of
a
it's
one
of
those
catch-22s
is
like
I'm
going
to
say
if
you
want
to
jump
in,
and
you
have
the
time
to
jump
in
today,
start
working
inside
of
the
the
actual
like
read
through
sort
of
how
we
run
the
demo
and
start
poking
around
with
the
demo
tell
us
what
doesn't
work,
what
works?
D
Well,
what
doesn't
work
so
on
if
you're
like
hey,
if
you
can
wait
a
week
in
the
next
couple
of
days,
we
are
restructuring
the
repo
such
that
it
should
look
like
a
normal
thing
where
we're
going
to
have
more
of
like
an
automated
test.
So
it's
like
hey
you
run
this
make
file,
you
run
something
like
make
setup
or
whatever
or
make
dev,
and
you
know
we'll
will
automatically
install
like
this
is
how
a
lot
of
this
works
today
right
you
install
a
mini
cube.
D
You
install
a
techcon,
you
install
change,
you
install
spire,
those
spire
actually
isn't
required
right
now.
At
least
you
install
kyverno,
you
install
gatekeeper
and
those
things
combined
then
allow
you
to
run
this
sort
of
demo
here,
where
this
demo
pushes
out
some
helm
charts
that
are
like
the
configuration
for
the
tools
it
that
you
know
it
pushes
out
our
policy
as
code
stuff.
D
It
pushes
out
a
an
example
pipeline
and
so
on
and
so
forth,
but
some
of
that
sort
of
stuff
is
going
to
be
refactored
really
quickly,
because
we
recognize
that
it's
just
not
like
we've
conflated
a
few
pieces
for
the
demo
and
we're
gonna
kind
of
make
it
harder,
but,
like
I
think,
the
the
big
things
are
poke
around
with
the
demo.
D
Look
through
the
github
issues
and
start.
You
know
if
there
are
things
that
you
think
are
missing
from
there
feel
free
to
add
new
tickets
if
you've
or
new
issues.
If
you
think
that
you,
you
know,
you
want
to
take
a
particular
thing,
feel
free
to
kind
of
say:
hey.
Can
I
take
this
if
you
run
into
bugs
feel
free
to
add
bug
tickets?
If
you
find
interesting
things
that
you
think
you
know,
you
want
to
just
have
a
discussion
on
feel
free
to
say:
hey,
look
like,
for
example,
governance
right.
D
But
if,
if
the
idea
is
hey,
you
want
something
a
little
bit
more
hard
like
hey:
is
there
a
specific
ticket
or
something
that
I
would
say,
wait
probably
about
a
week
we'll
have
a
little
bit
more,
we'll
have
swapped
around
a
lot
of
the
stuff
we'll
have
it
in
a
reasonable
spot
and
most
likely
the
next
steps
starting
next
week
are
going
to
be.
D
We
want
folks
to
use
the
thing
test
out
it
via
demos.
We
also
are
starting
to
talk
to
folks,
like
google,
who
have
offered
potentially
a
a
like
an
actual
kubernetes
cluster
that
we
could
test
this
stuff
out
on.
Like
an
actual,
you
know
some
gcp
compute
for
automated
tests.
D
I
know
that
some
of
the
stuff
we
might
be
able
to
run
via
github
actions,
but
I
am
a
little
worried
about
how
much
git
up
have
actions
can
support
if
we're
running
github
actions
that
installs
a
local
kubernetes
cluster,
whether
it's
kind
or
mini,
cube
or
whatever,
and
then
these
12
other
large.
You
know
we're
installing
chains,
we're
installing
all
these
things,
I'm
just
a
little
worried
of
like.
Will
it
take
a
really
long
time?
D
Is
it
going
to
cause
issues
yeah
yeah,
but
I
think
the
the
next
steps
starting
next
week
are
going
to
be
a
lot
of
like
how
do
we
start
writing
up
tests
for
this
thing,
and
then
we
can
go
back
and
start
adding
additional
features
start
tying
things
together,
because
I
think
the
big
thing
is
going
to
be
hey.
I
spun
this
all
up.
I
don't
know
how
it
works
and
the
test.
D
Slash
example:
slash
demos
are
gonna,
be
the
good
way
of
showing
how
how
it
works
and
also
making
sure
that
if
we
make
a
change
which
we're
running
into
now-
and
I
know,
is
a
big
issue
with
infras
code
stuff
is
every
time
I
make
a
change,
I'm
testing
it
locally
and
then
my
person
on
an
m1.
You
know
my
my
colleague
on
an
m1
mac
is
saying
it
doesn't
work
for
me
and
then
we
discover,
oh
there's,
a
weird
quirk
with
m1
max
with
this
thing,
and
that.
D
Well,
I
am
going
to
prep
for
the
next
the
next
hour,
because
I
think,
because
of
the
time
zone
shift,
some
people
are
joining
in
a
few
minutes.
D
Yeah,
this
is
the
second
one.
Again
it
it's
okay,
I
think
it's
between
it
getting
rescheduled
the
past
two
weeks
for
like
because
of
some
conflicts
with
some
some
people
had
and
then
the
europe
switching
their
clocks.
B
D
Oh
yeah,
I
guess
I'll
poke,
whoever
it
is
on
that.
D
D
Yeah,
I'm
sure
we'll
talk
to
somebody
to
make
sure
it
gets
figured
out
for
next
week.
I
get
okay,
I
guess
we
can
get
started.
I'm
sure
other
folks
will
will
hop
on
as
they
need.
So
just
as
a
reminder,
this
meeting
is
being
recorded
and
will
be
uploaded
to
youtube
shortly
after
this,
and
then
your
participation
is
meeting
means
you
are
agreeing
to
the
cncf
code
of
conduct
cool
all
right.
So
let
me
share
a
couple
things.
D
One
is:
let
me
share
the
document,
the
the
the
working
group
notes
document,
that's
what
I
just
shared
right
now
and
then
I'm
gonna
share
the
cncf.
That's
our
software
factory
document.
D
Cool
okay,
so
we
talked
about
a
few
topics
in
the
last
half
meeting
thing
feel
free
to
add
your
name
to
the
attendance.
Add
anything
that
you
want
in
the
discussion
or
any
other
updates
anything
that
you
think
that
needs
to
be
added
in
there,
but
first
before
kind
of
getting
into
general
updates.
Does
anybody
want
to
introduce
themselves
if
they're
they're
new
to.
B
Sorry,
I'm,
I
guess
kind
of
new
I've
been
in
a
couple
meetings
before
just
not
this
one,
I'm
working
at
plume.
We
do
wi-fi
routers
for
a
lot
of
companies
like
comcast
and
some
things
like
that.
So
we're
looking
into
supply
chain
security
for
our
devices,
cool.
B
And
next
and
michael
or
possessory,
at
red
hat,
I'm
just
interested
in
the
topic.
D
Awesome
all
right
cool,
so,
okay,
axel,
has
joined
cool,
so
we
can
get
started
here.
I
guess
so
so
for
the
folks
who
are
new
just
so
so
you're
aware
of
like
where
we're
at
you
know
previously,
we
had
released
a
best
practices
white
paper.
I
believe
this
back
in
may
around
that
time
frame
april
may
time
frame
around
kubecon
europe
and
then,
after
that,
we
started
building
out
a
secure
software
factory
reference
architecture.
D
So
we're
what
we're
calling
the
secure
software
factory
is
just
essentially
what
tools
and-
and
you
know,
ci
tools,
plus
security
tools,
all
those
those
things
combined
do
we
feel,
can
help
us
better,
secure
our
supply
chains
for
artifacts
we're
building,
and
so
we
built
out
reference
architecture
that
reference
architecture
is
at
least
the
v1
of
the
paper
is
more
or
less
done
at
this
point,
and
let
me
just
make
sure
that
I
just
post
it
again
in
case
anybody
missed
it
in
the
chat.
So
this
is
the
stuff
there.
D
So
what
the
the
reference
architecture
is
is
sort
of
a
large
description
of
you
know:
how
do
you
approach
the
problem
from
a
tools
perspective?
What
do
what
features
do
the
tools
need?
How
do
those
tools
need
to
be
configured
and
working
together
with
each
other
and
how
does
all
of
that
sort
of
come
together?
And
why
does
that
produce?
D
You
know
artifacts
that
we
believe
are
safer
right.
You
know,
have
higher
level
of
integrity
have
a
you
know,
we
can
prove
authenticity
and
and
those
sorts
of
things.
D
So
that's
the
part
of
the
the
reference
architecture,
and
so
that
thing
as
of
this
week,
is
more
or
less
done
from
a
draft
perspective.
We
are
reaching
out
to
the
community
for
additional
comments
from
the
community.
D
We
are
also
sending
this
over
to
our
cncf
technical
writers
to
help
clean
it
up,
and
you
know,
do
a
little
bit
of
work
on
you
know,
making
certain
the
way
we
say
certain
things
a
little
bit
more,
consistent
and
and
that
sort
of
thing,
and
then
one
of
the
things
that
that's
also
part
of
this,
which
is
sort
of
a
next
step,
is
sort
of
the
reference
implementation
or
the
prototype
implementation,
which
is
based
off
of
some
demo
code.
D
My
my
team
and
I
had
written
and
that
we're
now
looking
to
get
as
part
of
the
official
cntf
they
will
eventually
be
pulled
into
the
cncf
once
we
go
through
some
bureaucratic
sort
of
processes
to
get
it
officially
adopted.
But
for
now
this
is
you
know
it's
it's
living
there
to
be
clear.
It's
very
much
demo
code
that
we
are
rewriting
to
become
an
actual
thing,
but
just
throwing
that
out
there
for
any
of
the
new
folks.
Are
there
any
sort
of
questions
on
that
front?
D
Yeah,
so
it
is
cloud
native
at
this
point,
so
most
of
the
stuff
there
is
is
around
the
cloud
native
space.
Now
there
are
discussion
around
stuff
like
hey
like
from
an
internet
things
perspective
or
from
you
know,
a
hardware
perspective.
Where
else
does
this
fit
in
at
least
for
the
v1
document
we
have
been
pushing
on,
like
mostly
focused
around
the
sort
of
cloud
native
stuff,
so
you
know
kubernetes
containers.
D
You
know
service
mesh,
those
sorts
of
things
now
with
that
said,
like
another
thing,
is
you
know
we
didn't
have
previously?
You
know
anybody
who
was
very
well
aware
of
of
hardware
and
stuff
related
to
that.
So
we
a
lot
of
the
document
just
didn't
really
get
into
that.
B
Okay,
yeah
I've
been
reading
up
on
some
of
the
issues
with
the
attaching
the
prominence
information
to
like
the
artifacts,
and
it
sounds
like
there's
like
two
different
options:
the
one
that
dan
was
suggesting
to
what
the
cosine
was
doing
and
we're
I
was
just
trying
to
figure
out-
is
that
you've
looked
at
using
the
cosine
flow
right,
yep.
D
Yeah
yeah,
so
so
that's
what
we're
doing
so
right
now,
so
for
the
way
that
we've
been
doing
stuff
in
real
quickly.
The
reference
architecture
does
say:
hey
look,
even
if
you're
not
using
containers.
If
you
have
access
to
oci,
it
is
very
easy
for
you
to
push
artifacts
into
oci
itself.
Sign
those
artifacts
provide
attestations
in
those
artifacts
that
they
live
along
the
actual
thing
in
oci.
So
you
could
have
you
know
an
arbitrary
blob.
It
could
be.
D
You
know
whatever
it
is,
it
could
be
a
tarball,
it
could
be
an
executable,
it
doesn't
matter,
and
then
you
could
have
a
signature
that
refers
to
that
executable
or
whatever
inside
of
oci.
You
could
also
add
a
stations
that
are
all
in
there
and
you
could
use
oci
to
kind
of
hold
on
to
that,
and
so
in
the
reference
implementation
in
particular
we're
doing
a
lot
of
that.
You
know
outside
of
the
scope
of
this
meeting,
but
I
I
do
have
some
examples
of
hey.
D
I
have
a
a
what's
referred
to
as
a
bundle
and
that
bundle
has
literally
the
entire
list
of
transitive
dependencies
for
a
particular
thing
that
I
want
to
run.
I
could
just
run
it
on
any
linux
machine.
It
doesn't
have
to
have
anything
on
it
other
than
I
think,
like
a
shell
and
a
couple
other
things,
and
it
will
just
sort
of
expand
out
and
it
will
validate
signatures.
It'll
do
all
that
good
stuff.
B
Okay
yeah,
so
we
had
feedback
on
the
document.
How
would
you
want
us
to
submit
that.
D
Just
there
should
be
comments
going
out
if
there's,
if
it
hasn't
been
opened
up
to
comments
to
everybody,
I
believe
that
might
be
happening
after
an
email
gets
sent
out.
I
think,
either
later
this
week
or
early
next
week,.
D
Yeah
yeah,
no,
no
problem
cool
okay.
So
now
we
can
kind
of
switch
to
the
next
thing,
which
is
just
for
for
the
other
folks
who
have
been
working
on
on
this.
Are
there
any
updates?
Any
questions
concerns.
D
I
know
we're
kind
of
like
been
more
or
less
tying
it
up
tying
up
the
last
few
things
for
the
secure
software
factory
outside
of
opening
it
up
to
to
other
folks
to
comment
on,
but
anybody
else
have
any
sort
of
big
things
that
that
either
they
they
updated
and
they
want
folks
to
review
or
any
other
things
that
that
they
want
to
talk
about
on
that
front.
E
C
D
Yep
yep,
okay,
cool,
so
okay,
so
for
so
the
the
next
topic
that
I
wanted
to
just
talk
about
was
give
folks
thoughts
on
next
steps.
So
once
we
sort
of
release
this
as
a
v1,
I
think,
as
we
kind
of
all,
had
sort
of
discussed
previous
in
previous
meetings,
that
we
recognize
that
even
the
v1
is
going
to
be
out
of
date.
By
the
time
we
publish
it
because
of
how
quickly
the
supply
chain
security
space
is
moving.
D
You
know,
I
know
with
some
of
the
stuff
like,
for
example,
when
we
were
writing
this,
like
the
notary,
v2
stuff
was
still
being.
You
know,
thought
out,
and
now
there's
like
a
an
alpha
for
it
and
a
lot
of
the
things
when
it
came
to
you
know.
Oh
this
thing
doesn't
exist
in
chains.
You
know
as
of
last
week,
some
of
those
features
have
now
been
added
to
chains
and
and
so
on.
So
I
think
that
there's
some
next
steps
regarding
making
it
a.
D
Making
it
a
a
reference,
doc
and
and
so
on,
sorry,
I'm
making
it
a
sorry,
a
living
doc
and
so
that
we
can
update
it
as
time
goes
on,
so
we
can
do
something.
I
think
one
thing
you
know
once
we're
done
with
the
v1,
we
should
probably
have
the
broader
discussion,
but
just
what
folks
thoughts
on
what
do
people
think
about
taking
kind
of
that
that
salsa
approach
of
like?
D
Oh,
we
have
a
v1
of
the
document.
We
could
have
a
v
1.1
two
months
later
and
that's
okay,
because
of
the
the
nature
of
the
space
we
recognize.
As
long
as
we
were
clear
to
everybody
who
is
looking
at
this
thing
that
hey
look,
this
isn't
well
the
supply
chain,
security
space,
isn't
a
very
mature
space
and
a
lot
of
these
tools,
a
lot
of
the
patterns
they're
still
being
developed
as
we're
writing
the
best
practices
for
them,
but
just
wanted
to
get
folks
thoughts
on
that.
B
That
was
my
question
earlier
about
the
cosine
and
the
notary.
I
guess
I
haven't
dived
into
all
the
issues
there,
but
there
seems
to
be
a
little
bit
of
difference
of
opinion
on
some
of
that
stuff.
So
I
was
just
trying
to
figure
out
where
that
was
going,
so
I
don't
have
an
opinion
on
either
one
so.
C
There's
there's
still
some
people
saying
that
they're
going
in
different
directions,
I
think
there's
still
some
possibility
for
conversion
or
at
least
compatibility
between
those,
so
as
I
think
they
figure
that
out,
we
can
then
iterate
on
the
best
practices
here,
which
is
kind
of
cool
yeah.
I
generally
agree.
I
think
that
this
is
a
fast-moving
space,
and
so
we
really
want
to
make
sure
that
to
keep
this
document
relevant,
I
think
we'll
have
to
update
it
pretty
frequently.
E
You
know,
10
minutes
after
they've
been
published
good
laws
about
technology
talks
about
talk
about
principles
and
talk
about
what
we
want
to
achieve,
and
I
think
it's
the
same
idea
here
we're
talking
and
we
want
to
talk
more
about.
You
know
general
principles
in
general.
You
know
sort
of
building
blocks
we
want
to.
We
want
to
have
to
guarantee
certain
properties
versus
specific
tools.
The
tools
may
change
and,
as
you
were
saying
you
know,
chains
doesn't
do
something
one
weekend
and
it
does
it
the
next
week.
D
Yeah
yeah
yeah,
so
I
I
totally
agree
with
that
and
in
fact
I
think
we've
done
a
pretty
good
job
in
the
document
of
going
through
some
of
those
things
and
and
by
that
I
meant
actually,
I
was
kind
of
more
talking
the
the
prototype
implementation
of
the
thing,
but
yeah
to
your
point.
D
Yes,
we
are
trying
to
talk
about
more
about
how
you
do
things
like
certain
things
like
hey,
we
expect
things
to
be
signed
and
to
be
attested
and
yayada
now
exact
model
for
how
they
do
that
we're
a
little
bit
more
flexible
about
as
long
as
it
follows
the
good
you
know,
as
long
as
it
follows
the
right
principles
and
so
on.
E
B
D
Yeah,
and
and
so
for
for
alan
and
some
of
the
other
newer
folks,
just
so
that
they
recognize
like
yeah,
like
the
the
reference
architecture,
might
refer
to
certain
tools,
but
throughout
the
architecture
we
do
say,
hey,
we
are
trying
to
take
a
tool,
agnostic
approach.
D
D
You
know,
identities
the
same
way
that,
like
a
spiffy
spire,
does,
and
so
that's
kind
of
what
we'd
like
it's
more
or
less.
We
took
what
they're
doing
from
their
model
and
said
hey.
D
This
seems
like
a
really
good
practice
and
more
things
take
that
model
yeah
you
can
just
you
know
you
can
do
that
sort
of
thing,
but
you
know
we're
not
really
necessarily
tying
to
any
specific
tool,
at
least
as
far
as
the
reference
architecture
is
concerned,
there
is
something
which
I'll
talk
about
a
little
later,
which
is
what
we're
calling
like
the
prototype
implementation
or
the
reference
implementation
where
we
are
taking.
D
I
don't
I
don't
wanna
say
we're,
not
we're
not
necessarily
making
a
lot
of
opinions
taking
a
we're,
not
being
we
are
being
opinionated
based
on
our
document
and
we
are
taking
certain
things
based
on
just
from
the
group
who
knows
what
tools
best
and
how
can
we
tie
it
together
today
to
show
off?
This
is
what
this
could
look
like,
and
this
is
like
you
know.
If
you
run
a
pipeline
in
this
thing,
we
would
expect
you
to
get.
D
B
Yeah
and
that's
from
our
device
side,
the
spire
model
we
have
x,
509
certificates
for
device
identity,
but
linking
inspire
is
a
complicated
piece
that
I
you
know
have
to
kind
of
give
it
give
everybody
up
to
speed
on,
and
it
really
only
probably
solved
a
little
bit
of
our
problems.
But
I'd
like
to
use
the
salsa
framework,
but
maybe
not
replace
everything
if
possible.
D
So
so
I
will
say
that
there's
going
to
be,
you
know
one
of
the
things
that
that
that
was
also
something
that
came
up
in
the
previous
discussion
was
so
next
steps
is.
We
do
want
to
make
this
easier
to
consume
and
want
to
get
obviously
folks
thoughts
on
how
to
make
this
easier
to
consume,
but
at
least
for
the
time
being,
we
are
recognizing
that
the
supply
chain
security
space
is
very
much
evolving
and
it
isn't
easy
to
do
the
the
one
of
the
things
I've
seen
people
talk
about.
D
A
lot
is
like
you
know,
I
keep
hearing,
people
say
how
do
we
make
kubernetes
boring
right?
Because
that's
that's
a
you
know.
A
key
principle
is
like
hey
once
it's
boring,
then
it
just
you
know
everything
just
sort
of
comes
together
because
it
just
becomes
oh
yeah.
I
just
do
this.
This
is
just
another
one
of
these
and
and
becomes
much
easier
to
kind
of
manage.
D
I
think
the
supply
chain
security
space
is
not
boring,
yet
you
know
it
is
going
to
take
a
lot
to
do
and
also
to
some
extent
we
recognize
that.
Maybe
not
everybody
can
just
sort
of
get
it
out
of
you
know.
It's
gonna
take
a
lot
of
time
and
effort,
and
you
know
it's
not
the
sort
of
thing
that
you
can
just
sort
of
buy
a
vendor
tool
off
the
shelf
and
just
be
like
cool.
We,
you
know
we
have
supply
chain
security.
Now
it's
like
no.
D
It's
going
to
require
a
lot
of
at
least
right
now,
a
lot
of
custom
work
on
individual
companies
based
on
their
needs
and
so
on
and
so
forth
down
the
line.
Yeah
it
might
be
boring.
It
might
be
something
that
you
know.
We
just
point
to
you
know
an
open
source
tool,
a
vendor
product
or
whatever
and
say
yep.
That
thing
can
can
can
build
tools.
You
know,
can
build
your
your
software
securely.
B
E
D
Right,
so
a
couple
of
next
steps
that
I
want
to
go
over
was
one
is
and
want
to
get
other
folks.
Thoughts
on
this
feel
free
to
add
your
you
know
attend
once
again
feel
free
to
add
your
attendance
to
the
to
the
google
doc
or
whatever
else
any
other
feedback
you
might
have.
The
the
things
for
next
steps
are
beyond.
Obviously,
we
are
reaching
out
to
the
community
for
for
for
comment.
D
We
are
reaching
out
to
the
you
know
we're
going
to
be
publishing
this
this
white
paper
soon
after
you
know,
we
finish
up
some
tight.
You
know
going
through
typos
and
all
that
sort
of
stuff,
but
the
next
steps
are.
We
do
want
to
start
collaborating
with
other
groups
so
that
when
it
comes
to
these
things
right,
we
can
point
to
industry
standards,
industry
frameworks
and
say
hey.
We
follow
this
thing
as
an
example.
D
Also,
we
would
love
to
be
able
to
point
to
salsa
and
say:
hey
our
if
you
go
through
this
thing.
You
are
salsa
level
two
or
your
salsa
level
three
and
for
those
who
aren't
aware,
because
I'm
not
sure,
michael
or
allen,
if
you're
familiar
with
salsa
but
salsa
is
the
the
new
framework.
D
That's
coming
out
of
the
open,
ssf
and
originally
sort
of
put
out
there
by
google
as
a
way
to
sort
of
say:
hey
here
are
some
properties,
or
here
are
some
things
that
you
should
be
doing
inside
of
your
supply
chain
when
building
an
artifact
in
order
to
kind
of
validate
that
it
hasn't
been
tampered
with,
or
that
you
know
you
know.
Yes,
the
code
that
we
expected
to
be
compiled
is
the
code
that
actually
got
compiled
and
we
don't
have
like
a
solar
wing
type
thing.
D
D
And
so
myself,
you
know
for
the
new
folks
for
transparency,
I'm
on
the
steering
committee
for
salsa,
but
we
have
been
talking
with
salsa
for
a
little
while
on.
How
can
we
show
off,
like
you
know
this,
this
cncf
tool
or
sorry
the
reference
architecture
and
then
eventually
the
reference
implementation?
D
But
for
the
group
are
there
other
things
that
you
think
that
you
know
other
standards
that
we
should
be?
You
know
getting
involved
with?
Are
there
other
groups
we
should
start
talking
with?
Are
there
other
people?
We
should
be
talking
to
about
these
sorts
of
things.
B
I
know
there's
some
some
movement
towards,
like
you
know,
not
even
any
containers,
so
you
know
those
like
serverless
frameworks
like
open
fans,
especially
like
those
I
iot
devices.
So
I'm
not
I'm
not
familiar
with
enough
with
the
landscape
to
suggest
like
a
group.
D
Yeah,
so
on
that
front,
what
I
will
say
there's
nothing
in
here
that
specifically
says
we
can
only
build
containers.
What
we're
saying
here
is
actually
just
that.
What
we
are
describing
is
something
that,
as
long
as
you're
building
in
a
kubernetes
environment
yeah,
it
should
work.
So
if
you
have
an
artifact
that
is
a
serverless
artifact,
that's
fine.
The
secure
software
factory
should
be
able
to
build
those
things.
D
D
This
document,
if
folks,
want
to
kind
of
describe
out,
you
know
here's
how
this
might
work
for
a
little
bit
more
clearly
for
internet
of
things,
devices
network
devices
hardware,
whatever
more
than
more
than
welcome
to
kind
of
you
know
we
can
add
additional
addendums
and
you
know
whatever
to
there
in
in
a
1.1
1.2
or
whatever.
But
the
the
main
thing
here
is
is
what
I
would
say
is
actually
that
we're
focused
on
cloud
native
in
two
ways.
D
You
know
the
first
way
is
just
like,
obviously,
for
the
output
artifacts,
we're
focused
on
you,
know,
cloud
native
things
like
we're
not
so
focused
on,
just
as
an
example
like
j2
double
e
right,
you
could
still
j2e
inside
of
this
environment
as
long
as
you're
following
the
right
patterns
and
practices.
But
we
are
saying:
hey
look
if
you're
kind
of
using
you
know
modern,
tooling.
D
It
makes
this
sort
of
thing
a
lot
easier,
but
secondarily
we're
saying
hey
when
you
are
building
this
secure
software
factory,
that
we're
saying
we
are
expecting
that
secure
software
factory
to
be
running
kubernetes.
We're
expecting
that
secure
software
factory
to
be
using
cloud
native,
especially
those
tools
that
are
falling
under
the
cncf
right.
D
You
know
you're
using
those
sorts
of
projects,
so
you're
using
you
know
an
especially
open
source
project,
so
you're
using
all
you
know
the
ci
cd
tools
that
fall
under
stuff
like
the
linux
foundation,
like
as
an
example
tecton,
is
a
cd
foundation
tool
which,
where
we
all
follow
under
the
umbrella
of
the
linux
foundation,
you
know
we're
using
kubernetes
right
to
to
orchestrate
a
lot
of
these
things
and
necessarily
saying
you
have
long
running
servers.
D
There's
lots
of
practical
reasons
for
that
as
well,
but,
like
that's
kind
of
the
approach
we're
taking
as
well,
which
is
like
from
the
actual
reference
architecture,
we're
not
going
to
tell
you
how
to
you
know
hey.
How
is
this?
How
do
I
secure
this?
Using
my
you
know
my
my
my
old
jenkins
setup.
That's
all
manual
running
in
a
data
center.
Like
sorry
we're
not
you
know
we're
the
native
computing
foundation,
we're
not
going
to
describe
that.
D
Building
of
you
know
things
that
would
fit
into
oci
whether
you
know
any
sort
of
blob
things
that
can
fit
into
you
know.
Cloud
native
use
cases.
B
Oh
yeah,
I
get
that
that's
the
cloud
native
focus,
but
you
keep
bringing
up
solar
winds
and
I
would
say
solarwinds
is
not
a
cloud
native
pattern
so
well.
B
B
D
Yeah,
so
it
should
be
worth
noting
we
don't
get
into
distribution
that
much
in
the
document.
We
are
focused
more
on
the
building
of
the
thing.
Now
we
do
have
a
couple
of
notes
about
distribution
of
artifacts
to
production
environments,
using
emission
control
in
order
to
validate
the
attestations
and
signatures
and
those
sorts
of
things,
but
we're
actually
saying
at
least
for
now
we're
not
really
focused
on
that.
D
You
know
we
are
not
going
to
get
into
too
much
around
how
you
do
that
today,
because
a
lot
of
the
tooling
outside
the
cloud
data
space
just
doesn't
exist,
and
so
that
we're
saying
hey,
look
you'll
have
to
figure
out
that
on
your
your
own.
For
now,
as
time
goes
on
and
more
tools
come
out
more
vendor
things
come
out.
We
might
be
able
to
make
separate
suggestions,
but
that's
kind
of
the
the
the
way
we've
been
kind
of
looking
at
it
right,
which
is
just
like
the
way.
D
I
would
argue
is
like
the
solar
wind
stuff
is
building
it
in
a
cloud-native
way
right
where
they're
building
it
on
tecton,
which
lives
on
kubernetes
they're,
doing
all
these
different
things,
and
then
outside
of
that
they
have
these
artifacts
that
they
can
say,
hey
look.
I
have
all
this
sort
of
stuff.
D
Now,
when
I
go
and
distribute
that
artifact,
I
still
need
to
do
certain
things
in
order
to
make
sure
that
it's
distributed
securely,
that
yes,
the
thing
that
I
that
that
is
now
on
my
customer
servers
has
the
same
hash
as
the
thing
I
actually
built,
there's
still
stuff
that
you
need
to
do
on
that
front,
it's
a
little
easier
in
cloud
native,
but
there's
probably
patterns
and
practices
you
could
use
outside
of
that.
But
at
least
for
now
it's
outside
the
scope
of
what
we
were
doing.
B
Okay,
yeah,
I
I
think
that's
a
difficult
concept
for
to
understand
when
you're
talking.
I
think
the
thing
that
I
grapple
with
is
the
using
kubernetes
for
running
workloads
right
and
then
you
have
kubernetes
for
building
software
with
ephemeral
nodes
and
things
like
that.
So
maybe
that's
where
it
gets
a
little
confusing
on
what
the
factor
software
secure
software
factory
pattern
is
trying
to
cover.
D
Sure
so
we
can,
we
can
go
into
that.
I
think
a
little
bit
more
offline.
If
you
want
I'm
available,
I
think
the
main
thing
is
you
know
the
this
is
sort
of
an
evolution
of
multiple
sort
of
documents
throughout
the
cncf
as
well
from
like
the
cl.
You
know
the
cloud
native
security
best
practices
and
then
the
cloud
native
supply
chain,
security,
white
paper,
best
practices,
white
paper,
and
then
this
is
sort
of
an
evolution
of
all
those
things
to
what
is
the
reference
architecture?
D
D
Internet
of
things
you
know
includes
you
know
whether
it's
wasm
or
whatever,
as
well
as
containers
and
those
sorts
of
stuff,
and
so
now
with
that
said,
the
other
thing
that
actually
ties
into
another
topic
that
we're
we're
with
another
group
that
we're
starting
to
work
with
is
the
cardographos
working
group
and
the
cartographers
working
group
we're
trying
to
kind
of
explain
the
cloud
native
journey
right.
D
You
know
something
like
if
you
are
like
a
giant
enterprise
and
you're
starting
off
in
your
cloud
native
journey
you're,
probably
not
installing
service
service
mesh
on
day
one
right,
that's
probably
not
what
you're
doing
you're
doing
these.
You
know
it's
a
crawl
run
kind
of
thing
and
we're
trying
to.
We
are
saying
most
likely
this.
D
The
secure
software
factory
is
very
much
also
along
the
lines
in
that
journey
that,
like,
if
you're
you
know
a
massive
enterprise
and-
and
you
know
you
have
you're
using
you-
know
right
now-
you're
using
manually,
set
up
jenkins
and
yaya
you're,
not
gonna,
just
be
able
to
take
the
secure
software
factory
and
just
say
cool.
Two
weeks
later
we
have
a
secure
software
factory.
D
No,
like
there's
a
lot
more
things
in
your
you
know,
you'll
have
to
handle
in
your
own
internal
enterprises
and
the
culture
and
the
processes
and
the
policy
in
order
to
eventually
then
get
to
the
point
where
you
can
have
both
the
the
cultural
maturity,
as
well
as
the
actual
technological
maturity
to
sort
of
deploy,
something
like
a
secure
software
factory.
So
that's
definitely
something
that
I
think
is.
Is
up
for
discussion
and
we
do
want
to
make
to
be
clear-
we
do
want
to
make
this
easier
over
time.
D
The
problem
is
that
it
just
doesn't
like
these
things
are
hard
today,
and
it's
just
something
that
we
have
to.
We
do
have
to
really
drive
this
like
at
the
end
of
the
day
when
it
comes
to
a
lot
of
these
tools
like
co-signing
yeah.
It's
like
these
things
are
not
like
they're
getting
easier
every
day
to
use,
but
this
is
a
lot
of
these.
Things
are
not
something
that
you
can
sort
of
pick
up
and
just
start
using
tomorrow.
D
D
And
so
yeah
I,
like
the
the
I
guess
the
tldr
of
a
lot
of
this
is
this
stuff
is
still
going
to
take
a
while
there's
a
lot
of
environments
today
that
it's
just
it
is
hard
to
set
up
it's
going
to
be
hard
to
manage
and
you're
going
to
have
to
do
a
lot
to
sort
of
drive
it
to
sort
of
a
completion
there
right
like
so.
D
I
spoke
to
some
of
the
you
know,
solarwinds
folks
about
hey
how
many
people
you
know
how
hard
was
this
and
yeah,
and
they
said
well
when
this
was
the
number
one
priority
for
six
months,
and
you
know
you've
you've
testified
before
congress
that
you're
gonna
do
the
thing.
You
know
you
do
whatever
you
need
to
do
to
get
it
done.
I
recognize
for
a
lot
of
other
companies.
That's
maybe
not
going
to
be
the
case
so
yeah.
So
so
there's
there's
a
lot
of
stuff.
D
D
Yeah
and
it
to
be
clear,
I
think
this
is
a
thing
that
that
came
out
of
the
the
supply
chain
security
con
day
as
well,
which
was
this,
is
a
hard
problem
that
a
lot
of
folks
do
want
that
sort
of
thing
like
hey.
I
have
a
jenkins.
How
do
I
just
feed
this
into
my
jenkins
and
you're
like
well?
Actually
you
just
you
can't
this
is.
D
This
is
very
much
like
a
shift
like
before
we
were
doing
a
lot
of
stuff
with
monoliths
we're
saying:
monoliths
aren't
going
to
cut
it
anymore,
so
we're
we've,
you
know
not
saying
everything
is,
is
microservices
but
we've
broken
stuff
down
the
same
thing.
It
goes
with
a
lot
of
different
things
like
you
know,
there's
a
lot
of
old
patterns
that
have
gone
away,
because
the
new
way
we
do
things
is
just
it's
incompatible
is
the
same
way
here
like
a
lot
of
the
supply
chain.
Security
stuff
is
gonna.
D
Take
it's
gonna
take
some
time.
It's
gonna
take
a
lot
of
effort
to
make
boring,
but
the
plan
is
to
spend
that
time
to
try
and
make
it
boring.
D
D
The
next
thing,
so
that
was
one
of
the
topics
there
right
so
next
steps
right.
If
there's
other
folks
who
have
other
ideas
of
who
else,
we
should
be
talking
to
we'd
love
to
know.
I
have
listed
the
open,
ssf
scorecard
folks,
because
we
can
probably
integrate
some
of
those
things
together.
D
D
D
E
Just
briefly,
I
mean
I
fully
agree
with
the
confidential
confusing
consortium.
I
think
it's,
it's
really
good
to
start
working
with
them,
just
just
to
remind
everybody
that
there
is
a
cncf
project
that
roots
hardware,
that
roots
trust
in
hardware
tpms.
It's
key
lime,
it's
currently
in
sandbox,
hopefully
soon
in
incubation,
well
one
of
these
days
but
yeah.
E
This
is
already
something
we
have
inside
the
cncf
so
but
not
saying
that
at
all
to
say:
let's
not
talk
to
the
to
the
confidential
community
consortium,
because
I
think
that's
a
great
idea
too.
D
Oh
yeah,
yeah
and
and
to
be
clear,
yeah,
I
think
key
lime
is
great.
I
know
that
a
couple
of
months
since
I've
had
to
talk
to
any
of
those
folks,
do
you
know
if
there's
any
movement
on
the
vtpm
space,
because
I
know
there
was
some
concerns
about
like
hey,
we
can
run
tpm
on
the
nodes
and
do
some
stuff
on
end,
but
we're
having
some
issues
getting
them
to
run
in
actually
the
workload
containers
themselves.
E
Yeah
I
nested
nested
quotes
tpm
quotes
were
tr
were
hard.
I
don't
think
it's
sold
yet
I
think
it's
it's
a
bit
further
down
the
track
on
the
on
the
roadmap.
I'm
I
mean
I'm
work
with
michael
actually,
michael
peters,
who's,
currently
the
project
leader
for
the
thing
on
their
annual
review.
So
that's
the
latest
news.
As
far
as
I
know,
I
will
double
check
with
him,
joe
those.
I
will
double
check
with
him,
just
to
make
sure.
B
The
spire
has
that
tpm
node
attestation
plug-in.
How
is
this
keyline
component
different.
E
So
I
don't
know
this
the
spiffy
inspire
stuff
very
well
with
regards
to
tpm,
but
on
the
key
lime
side,
what
it
does
is,
essentially
it
it.
It
has
a
third.
It
uses
a
third
party
to
basically
at
a
test,
so
you
have
a
you.
Have
basically
sorry,
not
explain
it
very
well.
E
You
have
a
verifier
that
will
check
nodes
by
requesting
that
they
send
quotes
that
are
signed
by
the
tpm
to
show
that
basically,
they
went
through
the
boot
process
without
any
issues,
and
one
of
the
nice
things
that
key
lime
does.
Is
that
once
all
of
that's
happened,
there
are
mechanisms
to
conditionally
release.
E
You
know
payloads
to
good
nodes,
so
once
a
node
has
been
brought
up
properly,
for
instance,
you
can
give
them
a
decryption
key
to
decrypt,
something
that
is
in
their
their
image
of
the
os
they
loaded,
and
then
they
can
have
access
to
further
secrets
that
will,
you
know,
enable
them
to
join
a
group
or
something,
and
and
on
the
other
hand
it
does
another
nice
thing
which
is
to
to
use
the
the
linux
subsystem.
E
The
ima
subsystem
the
integrity
management,
so
it'll
check
a
list
of
good
files
that
is
known,
like
you
know,
in
a
in
an
allow
list,
and
any
of
these
files
that
would
change
hash
essentially
on
on
disk,
would
then
automatically
make
the
node
go
to
failed
and
the
node
could
be
removed
from
the
pool
stuff
like
that.
E
B
D
D
All
of
our
code
is
sort
of
based
on
obviously
a
lot
of
the
work
that
other
folks
have
done,
and
now
that
enough
people
had
sort
of
seen
and
said,
oh
wow,
you,
you
actually
took
the
reference
architecture
and
just
sort
of
started
moving.
You
know
actually
getting
all
the
pieces
together
and
so
on.
D
I
think
the
next
step
is
going
to
be
okay,
we're
we're
already
in
discussions
on
getting
this
brought
into
the
cncf,
either
as
a
project
or
as
a
repo
or
the
the
security
working
group
or
whatever
it
is,
but
we
do
want
to
make.
We
do
want
to
turn
this
into
an
actual
project.
That
is
tying
those
things
together
to
you
know
the
idea
being
that
at
some
point
in
the
future,
we
would
love
to
have
a
one
click.
D
You
know
we
have
deployed
you
a
secure
software
factory
that
you
can
feed
in
your
code
and
the
output
is,
you
know,
artifacts
that
have
a
salsa
attestation
and,
and
we
believe
to
be,
you
know
authentic.
We
believe
to
have
higher
level
of
integrity
and
all
that
good
stuff.
Now
with
that
said
right,
this
is
very
much
demo
code.
It
was
very
much
poc
code
specifically
for
the
supply
chain
security
talk
that
we
had
given,
but
moving
forward.
D
We
want
to
now
main
make
this
into
an
actual
thing,
so
in
the
next
days
we're
sort
of
reorganizing
a
lot
of
this
sort
of
stuff,
but
we
want
folks
to
kind
of
come
in.
We
want
folks
to
we
want
folks
to
come
in,
you
know,
add
issues
test
it
out,
yaya
feel
free
to
kind
of
poke
around
with
it.
D
D
We're
going
to
have
something
that
you
know
stalls
all
the
tools
that
would
we
would
consider
part
of
this
reference
implementation,
we're
going
to
start
having
tests
to
show
that,
like
yo,
here's
an
automated
test
pipeline
that
shows
what
a
bad
example
looks
like
right
and
here's
how
here's
the
pipeline
and
how
you
would
have
to
structure
in
order
to
do
the
right
things
and
here's
a
pipeline
that
shows
you
know
here's
an
artifact
that
it
would
build,
but,
like
you
can
sign
it,
why
does
it
not
sign
it
because
well
it
tried
to
do
something
bad
and
you
know
the
system
caught
it,
those
sorts
of
things
and
then,
after
that,
we'll
obviously
create
new
features
and
so
on
and
so
forth.
D
Now
I
think
you
know
just
to
be
clear
here
is
that
you
know
a
lot
of
the
tools
and
whatever
that's
used
in
here
are
just
the
tools
that
we
were
just
most
familiar
with
in
already
so
this
is
not
saying
like
this
is
an
endorsement
of
like
these
specific
tools
in
these
specific
ways.
This
is
just
like:
hey
we
worked
on
this
stuff.
D
We
were
able
to
get
it
working
with
these
tools
if
there
are
other
tools
that
we
want
to
use,
we
can
definitely
include
those
as
sort
of
options
in
the
secure
software
factory,
the
idea
being
that
you
know
there
could
be
multiple
different.
You
know
pipelines
and
pipeline
frameworks,
there's
multiple
different.
B
Yeah,
that's
that's
fine.
I
saw
that
at
the
top
of
the
document
it
meant
it
mentions
alternative,
ci
cd
pipelines,
but
you
in
the
discussion
today,
you
were
mentioning
those
are
all
outdated.
How
is
that?
I
guess
approach
if,
if
jenkins
github
circle
ci,
all
those
other
pipelines
are
outdated.
D
D
The
cloud
native
thing
right
is:
is
just
what
we're
kind
of
a
little
bit
more
focused
on,
but
if
you're,
if
you
can
build
a
supply
chain,
that
includes
like
let's
say
using
jenkins,
that
uses
ephemeral
infrastructure
that
everything
that
pipelines
are
100
defined
as
code
and
all
those
sort
of
other
things
that
we
sort
of
define
in
this
document,
then
you
could
use
whatever
it
doesn't
matter.
D
The
thing
that
we've,
the
the
reason
why
we're
focusing
on
some
of
the
stuff,
like
let's
say
tecton,
for
example,
is
because
one
two
a
couple
reasons.
One
is
that
it's
part
of
the
group
that
you
know
we
are
associated
with
and
then
the
other
reason
is
it
just
so
happens
to
make
it
easy,
at
least
from
our
perspective,
the
authors
of
the
paper.
B
D
Well,
so
so
salsa
is
just
a
it's
a
framework
that
says:
if
you
do
certain
things
and
you
can
attest
to
those
things,
then
you
have
a
certain
like
level
of
purity
right.
So
as
an
example
right,
if
you
are,
are
following
and
to
be
clear,
this
is
the
the
conversation
we're
going
to
be
having
with
the
salsa
team
to
say:
hey
what
level
does
the
reference
architecture
sort
of
do
because,
because,
at
the
end
of
the
day,
once
again,
it's
not
a
specific
tool.
That's
the
thing!
D
It's
what
you're
doing
with
the
tools
that
allows
you
to
do
this
sort
of
thing
right.
So
as
an
example,
I
believe
that
there's
a
thing
in
there
around
two-person
code
review
right,
so
lots
of
what
I
would
say
is
most
git
repos
out
there,
whether
it's
github
or
whatever,
can
support
two-person
code
reviews.
It's
actually
a
config
level
requirement
right
that
that
forces.
You
know
that
that
does
that.
D
So,
if
you
are
following
the
best
practices
around,
yes,
we
have
two-person
code
review
and
here
is
the
configuration
showing
that
we
have
two-person
code
review
right.
We
are
testing
that
that
configuration
is
good
enough
as
proof
or
whatever.
Then
you
know
that
hits
that
saw
self
requirement,
but
there's
nothing
in
the
specific
tools
per
se
that
stop
you
from
hitting
any
particular
salsa
requirement,
just
that
it's
certain
tools
just
make
it
easier
right
like
if
you
have
a
manual
jenkins
and
yaya,
it's
just
not
going
to
work.
D
B
I
think
you
guys
have
covered
most
of
what
I
was
thinking
of,
but
but
one
thing
I
think
that
would
help
is
like
calling
out
where
things
are
kind
of
like
very
tightly
integrated
like
currently
like
in
total
and
tech
time
chains
are
kind
of
like
one
to
one
like
I'm,
I'm
not
personally,
I'm
not
aware
of
like
alternatives
there,
so
that
may
have
been
it
might
be
where
you
were
going,
alan,
we're
like
using
toto
and
then
without
tech
time
chains.
B
D
So
a
lot
of
this
is
is
called
out
in
in
the
document.
So
so
I
recommend,
reading
through
the
reference
architecture,
also
as
well
as
the
the
the
the
best
practices
white
paper.
B
D
B
But
you
know,
as
as
you
know,
as
someone's
trying
to
spin
up
the
software
factory
right
and
then
they
want
to
try
to
you
know,
switch
out
one
part
or
another.
It
would
be
helpful
for
that
to
be
explicit.
D
Yep,
so
it
should
be
called
that
out,
at
least
in
the
reference
implementation
or
the
prototype
implementation,
part
of
the
secure
software
factory
document,
but
yeah,
you
know,
and
also
you
know
once
again
looking
for
contributors
to
it.
So
if
you
have
thoughts
around,
it
feel
free
to
open
up
a
github
issue
or
open
up
a
pr,
and
we
can
start
taking
a
look
at
it.
D
Well,
is
there
any
other
questions,
comments,
thoughts
about
anything
moving
forward
with
you
know
the
work
on
the
final.
You
know
finalizing
the
draft
or
anything
regarding
the
reference,
implementation
or
sorry,
the
you
know,
prototype
implementation
or
anything
regarding
just
any
of
the
the
work
moving
forward
for
the
supply
chain.
Working
group.
B
So,
there's
just
this
concept
that
we
have
the
os
platform.
We
got
the
applications
that
are
running
on
it
for
iot
products
and
maybe
keyline
can
attest
to
the
node.
But
when
you're,
when
you're
developing
the
os
that's
running
on
your
hardware,
we're
we're
mostly
hard,
I'm
on
the
hardware
side
when
you're
developing
the
os
and
you
have
to
make
sure
the
os
is
not
compromised.
B
I'm
just
trying
to
get
my
head
around
how
the
salsa
framework
can
help,
because
you
know
you
have
all
the
components
in
that
os
that
you're
you're
pulling
in
from
other
areas,
some
of
them
you're
custom
making-
and
I
think
that's
a
little
bit
hard
for
me
to
see
the
the
vision
yet,
but
I'm
still
learning.
I
just
started
in
like
july
so
like
trying
to
absorb
as
much
as
I
can
so
sometimes
I
talk
wrong
about
the
components,
but
that's.
D
B
D
Yeah
and
so
on
that
front,
we
do
get
a
little
bit
into,
for
example,
how
you
look
at
the
os
right,
because,
because
at
the
end
of
the
day-
and
this
is
where
some
of
the
other
sort
of
books
and
papers
come
into
play
as
well
just
in
in
the
community
of
like
you
know,
what
is
your
bottom
turtle
right?
You
know
because
also
at
the
same
time,
you
could
just
as
easily
say
how
are
we
guaranteeing
that
the
literal
pcbs
in
your
hardware
have
not
been
compromised
and
that
you
know
like
that?
There
aren't.
D
You
know
somebody
hasn't
come
in
to
you,
know
the
chip
fab
and
they're
putting
back
doors
in
the
hardware.
I
mean
there's
a
lot
of
stuff
across
the
board
that
that
needs
to
be
thought
of
we're
focused
on
a
certain
layer,
but
I
think
the
same
sort
of
practices
probably
sort
of
make
sense
and
then
also
sort
of
moving
forward.
We
would
love
to
get
you
know
additional
limit
from
folks
like
yourself
on,
like
hey
here,
we're
very
much
focused
on
software
and
these
sorts
of
things.
D
Here's
how
you
think
about
it
from
an
iot
perspective
or
here's,
how
you
think
about
it
from
a
serverless
perspective-
and
you
know
here
are
some
things
and
we
can
sort
of
kind
of
continue
to
sort
of
evolve.
The
document
as
time
goes
on
as
well
now
from
salsa
perspective,
just
real
quickly.
The
only
real
thing
that
that
salsa,
you
know
salsa
is
just
any
sort
of
artifact.
D
So
if
you're
talking
about
the
software
that's
running
on
that
system,
all
it's
saying
is
the
that
this
artifact
has
gone
through
these
sorts
of
things
against
it.
So
as
an
example,
we
have
validated
that
it's
a
reproducible
artifact
by
running
it
on
two
separate
machines
and
getting
the
same
hashes
and
those
two
machines
have
attested
to
that
right.
You
know,
and
and
those
sorts
of
things
then
get
associated
with
that
artifact
and
you
can
say:
okay
cool.
D
B
D
E
C
E
Know
it's
we
we,
it
helps
say
you
know,
we
think
it's
at
at
least
this
this
good
state,
but
there's
still
a
lot
of
other
questions
that
come
in
and
you
know,
for
instance,
you
were
saying
you
know,
you're
pulling
in
code
from
from
elsewhere,
like
keyling
will
do
very
little
about
that.
It'll.
Just
tell
you
the
node
on
which
you're
running
is
extremely
likely
to
be
running
the
os.
You
think
it's
running,
but
you
know,
and
if
files
change
on
that
node
we
can
detect
it
and
then,
but
you
you
know.
E
For
instance,
you
can't
do
something
like
fix
the
fixture
node
if
you
detect
a
change
because
as
soon
as
you
can
see,
there's
something
that's
been
compromised
on
the
node.
You
have
to
assume
the
whole
node
is
compromised
and
all
that
qm
can
do
is
tell,
for
instance,
all
the
other
machines.
Don't
trust
that
node
or
don't
talk
to
that
node
anymore.
We
don't
send
that
node
any
data.
You
know
that
sort
of
stuff.
E
So
even
that
you
know
it's
not
it's
not
as
nice
as
being
able
to
sort
of
go
back
and
fix
it.
For
instance,
you
sort
of
have
to
assume
the
node
is
is
out,
but
anyway
yeah,
it's
it's
the
more
I'm
seeing
you
were
saying.
E
You
know
you've
been
looking
at
this
since
july
and
it's
probably
about
the
same
time,
maybe
a
few
months
longer
for
me,
but
you
know
really
similar,
and
it
looks
a
lot
to
me
like
the
answer
is
going
to
lie
in
combining
various
projects
and
approaches
and
tools,
and
it
goes
to
what
you
know.
Michael
was
saying
which
is
you
know
this
is
complicated.
It's
not
like
a
turnkey
solution.
We
there
are
a
lot
of
things
to
put
together
so.
B
I
do
like
the
pattern,
the
the
femoral
nodes
and
everything,
so
it's
pretty
exciting
stuff.
So
I
definitely
appreciate
all
the
work
just
trying
to
put
my
head
around
it.
D
Yeah
and
yeah,
I
think,
once
again
to
just
sort
of
sum
up.
Some
of
this
is
we
recognize
it's
hard
and
it's
the
sort
of
thing
like
you
know,
it's
not
like
behind
me
right.
The
gang
of
four
software
architecture
book
right,
which
is
like
there
are
very
clearly
you
know,
there's
a
bunch
of
different
patterns,
there's
very
rarely
a
new
sort
of
like
big
software
architecture,
pattern
that
comes
out,
but
when
it
comes
to
you
know,
secure
supply
chain
stuff.
This
is
not
exactly
new.
D
There
have
been
issues
about
this
in
the
past,
but
it
hasn't
been
as
big
of
a
deal
until
recently
where
the
number
of
attacks
has
increased
and
the
complexity
of
our
environments
continues
to
increase
where
it's
like.
You
know
what
used
to
be.
Oh
yeah,
I
have
a
few
dependencies
is
now
I
have
my
list
of
transitive
dependencies
is
potentially
hundreds,
if
not
thousands,
of
things
and
okay.
How
do
we
reason
about
it?
How
do
we
secure
around
it?
It's
gonna
be
a.
D
It
is
a
hard
thing
to
to
manage
and
because
of
that,
it's
like
even
this,
this
reference
architecture
we're
talking
about
you
know
we
want
to
make
sure
that
we
caveat
it
with
look.
This
is
still
a
very,
very
evolving
space.
This
is
what
we
think
should
get
done.
We
think
this
sort
of
thing
helps
us
secure
it
and
so
on
and
so
forth,
but
recognize
that
this
isn't.
As
was
mentioned,
this
isn't
a
turnkey
solution
and
it
probably
won't
be
a
turnkey
solution
for
a
while.
D
But
also
down
to
you
know,
chat,
you
know,
feel
free
to
ping
me
also
in
the
slack
there's
a
lot
of
other
folks
in
the
slack
for
the
working
group,
who
probably
have
additional
thoughts
and
and
whatnot
and
and
I'm
sure,
sort
of
in
moving
forward.
We
would
love
with
you
and
anybody
else.
You
think
who
can
help
us
out
from
the
sort
of
internet
of
things
hardware
sort
of
space
on
you
know,
hey.
D
How
do
we
secure
stuff
that's
running
in
firmware
or
how
do
we,
you
know,
secure
stuff,
that's
running
the
software
on
these
individual
devices.
I'm
sure
like
moving
forward
we'd
love
to
have
some
of
those
conversations
as
well,
because
that's
a
space
that
at
least
for
myself,
outside
of
just
the
generic
here's,
how
you
secure
an
artifact,
I'm
not
sure
how
we
would
approach
that
problem
for
hardware.
I'm
not
an
expert
in
any
of
that.
B
Yeah
I
like
to
know,
I
think
I
like
to
try
to
know
as
much
as
possible,
but
there's
just
so
much
moving.
So
it's
a
software
secure
software
factory
github
site
is
that
meant
to
be
then
like
a
drop
in
place
like
implementation
of
the
document.
D
So
this
so
once
again,
this
will
probably
become
a
cncf
repo.
At
some
point,
the
idea
right
now
is
to
show
a
prototype
implementation
like
it
will
work
on
very
trivial
sorts
of
use
cases
and
show
you
like
this
is
the
sort
of
thing
you'll
probably
have
to
do,
there's
a
whole
lot
of
stuff
that
needs
to
be
sorted
out
and
once
again,
you're
not
gonna
get
anything
at
least
out
of
the
box
for
for
a
while
right,
because
a
lot
of
this
is
coming
down
to
things
like
you
know
this.
D
The
everything
we're
talking
about,
even
in
the
document,
certain
assumptions
that
are
sort
of
outlined
in
the
document
like
your
kubernetes,
is
following
the
hardening
best
practices
that
the
cncf
has
described,
and
that
is
a
list
of
things
that
you'll
have
to
consider
as
well.
Right
like
we're,
assuming
right
that
you
know,
based
in
what
we've
described
in
the
document,
you
are
not
going
to
have
you're
gonna
have
a
like
you're,
not
just
gonna,
give
developers
admin
access
to
your
kubernetes.
D
If
you
are,
this,
isn't
gonna
work,
so
there's
a
lot
of
those
things
that
are
described
as
well,
and
it
is
a
very
complicated
space.
So
it's
not
the
sort
of
thing.
That's
just
super
simple
and
super
easy
to
just
kind
of
throw
in
there,
so
it
is
going
to
take
a
while
and
it's
going
to
take
a
long
time
to
sort
of
grok
now.
D
The
idea
here
is
that
this
prototype
implementation
is
still
something
that
you
can
just
kind
of
spin
up,
see
how
it
works
like
the
prototype
implementation
will
do
things
like
it
will
validate
that
the
secure
software
factory
itself
is
using
signed
images
right
so
that
you
know,
if
somebody
were
to
replace
the
tecton
image
with
a
bad
tecton
image,
it'll
block
it.
It
will
validate
that
you
know
it
will
sign
your
artifacts
so
assuming
you've
gone
through,
you
know,
you've
developed,
developed
a
pipeline
that
matches
the
standard.
D
It
will
sign
the
artifact
as
the
the
resultant
argument.
It
will
do
a
few
other
things
like
it
has
a
poc
element
of
hey:
here's,
a
prod
namespace,
where
we're
doing
admission,
control
that
validates
salsa
attestations.
D
Now,
once
again,
that
doesn't
necessarily
work
for
you,
deploying
it
to
internet
of
things
devices,
but
it's
still
just
sort
of
you
know.
Once
again,
it's
it's
the
sort
of
poc
that
demo
thing
long
term.
This
might
be
one
day
an
open
source
tool
that
would
be
a
drop-in
replacement.
That
would
be
production,
but
the
same
way
that
a
lot
of
these
cncf
tools
would
be
sandbox
and
incubating,
and
so
on
and
so
forth.
I
imagine
it
would
probably
take
you
know
over
a
year
to
get
it
to
a
point
where
we
would
say.