►
From YouTube: CNCF Security Tag Supply Chain WG 2021-08-12
Description
CNCF Security Tag Supply Chain WG 2021-08-12
A
Agenda
really
is
gonna
mainly
go
through
so
michael
and
I
got
together
and
tried
to
kind
of
put
the
outline
together.
We
are
discussing
about
basically
based
on
everyone's
input.
We
think
we
have
a
good
foundation
to
start
writing
up
what
the
reference
architecture
would
look
like,
and
you
know
we
the
best
way.
We
think
that
to
go
forward
with
this
is
just
like.
Have
a
couple
of
folks.
A
I
put
out
a
message
earlier
this
week
to
to
ask
volunteers
and
thanks
for
all
those
that
volunteered
to
put
in
your
time
so
we'll
be
going
through
a
little
bit
about
this
and
how
we're
gonna
do
it.
There
are
some
discussion
points
that
we
still
want
some
feedback
on
from
all
the
folks
on
the
call,
so
that
will
be
the
main
agenda
for
today,
but
before
we
get
into
that,
I
want
to
spend
just
a
quick
five
minutes.
B
C
Real
quick,
so
an
update
from
my
end,
so
the
so
salsa
the
framework
that
google
originally
spearheaded,
but
now
it's
part
of
the
open
ssf,
so
they
had
their
first
sort
of
community
meeting
yesterday
went
well,
there's
pretty
reasonable
representation
across
the
board.
Folks,
like
david
wheeler
from
the
linux
foundation,
a
few
you
know
various
other
companies
and
then
also
we
now
also
have
representation
on
the
on
the
steering
committee
as
well.
C
B
Just
wanted
to
introduce
myself,
I'm
pars
patel,
I'm
part
of
box
boats
technology,
so
I'm
working
just
trying
to
learn
on
the
you
know:
okay,
get
involved
with
the
open
source,
and
you
know
I'm
interested
in
the
supply
to
secure
supply
chain,
and
I
was
looking
into
in
toto
and
tecton
change
and
all
that
kind
of
stuff
so
happy
to
be
here
and
help
out
any
way.
I
can.
A
D
B
Yeah,
I
can
introduce
myself
so
I'm
remy,
I
just
joined
michael's
team
at
city
two
weeks
ago
and
I
also
started
to
play
with
tecton
tecton
chains
input.
So
I
use
the
demo
that
priya
created
to
start
playing
with
chain
stuff,
like
that,
so
I'm
still
discovering
the
technologies,
and
I
hope
that
soon
I
could
have
a
meaningful
input.
A
So,
based
on
all
the
previous
weeks,
discussions
and
all
the
brainstormings
and
all
the
presentations
we've
had,
which
have
been
really
helpful,
you
know
we
were
just
discussing
and
we
think
that
we
have
enough
to
kind
of
put
something
together
and
we
figured
one
way
to
do.
This
is
let's
just
write
something,
and
then
you
will
see
the
responses
we
will
review
it
and
refine
it
as
we
go,
and
a
lot
of
a
lot
of
this
is
really
what's
a
scoping
exercise.
You
know
we.
A
C
Sure
yeah
so
based
on
sort
of
the
previous
discussions,
I
just
started
sort
of
outlining
a
lot
of
it
and
just
sort
of
dumping.
The
sort
of
thoughts
to
page-
I
think
largely
you
know
this
is
all
based
on
what
we've
already
written
in
the
various
best
practices
documents
and
the
the
other
sort
of
breakout
brainstorming
sessions,
but
a
little
bit
more
sort
of
okay.
You
know
this
is
what
it
should
all
look
like.
C
Like
you
know
stage,
one
should
be
this
and
stage
two
and
so
on
should
be
those
sorts
of
things.
I
think
you
know
there's
a
lot
of
areas
where
I
am
not
an
expert
in
you
know,
especially
when
it
comes
to
the
sorts
of
things
like
you
know:
identity,
attestation,
sorts
of
pieces,
like
you,
know
the
no
data
station
and
workload
attestation,
so
I'm
mostly
just
been
following
the
documentation
of
things
we
have
been
looking
at
like
spire
and
just
kind
of
trying
to
see
like
hey.
C
You
might
not
use
those
terms.
That's
okay,
like
let's.
Let's
have
that
discussion
and
let's
figure
that
out,
because
in
certain
cases
like
as
an
example,
you
know
if
we
are
looking
at,
let's
say
tecton
chains
for
some
of
this
stuff.
There
currently
isn't
really
a
well.
You
know
widely
sort
of
accepted
term,
for
what
tecton
chains
is
doing.
Right.
Priya
has
brought
up
like
something
like
maybe
supply,
chain,
security
manager
or
pipeline
supply
chain
security
manager.
Something
like
that,
but
there's
lots
of
other
stuff.
You
know
we
should.
C
You
know
talk
some
of
that
over
and
also
make
sure
that
you
know
all
these
pieces
kind
of
all
sort
of
make
sense,
because
I
think,
as
we're
building
this
document
out,
the
other
things
that
are
going
to
come
out
of
this
are:
what
are
the
gaps
right?
What
are
the
things
that,
when
sort
of
writing
up
this
flow,
that
all
of
a
sudden,
we
start
having
questions
like?
C
A
A
A
A
What
is
included
as
part
of
this
reference
architecture?
Specifically,
we
talked
a
little
bit
about
you
know.
This
is
still
at
the
very
conceptual
level,
so
inputs
and
outputs
of
the
circular
software
factory.
So
this
is
like
inputs
are
dependencies.
The
inputs
are
the
different
tasks
that
you
run
within
the
software.
Secure
software
factory
I'll
put
the
artifact,
so
nothing
like
technology,
specific
or
conceptual
we
describe
what
these
inputs
are.
You
know
what
what
are
the
assumptions
we
make
about
these
inputs
and
outputs?
A
We
talk
about
the
different
components
of
the
sf,
so,
as
usual
again
see
like
nothing.
Technology
is
specific,
already
everything
so
at
the
conceptual
level,
so
control,
plane,
pipeline
framework
and
tooling
don't
test
several
tests.
Again.
We
have
a
discussion
more
on
this
data
as
well,
and
then
we
go
on
mapping
entities
to
project
technologies,
so
this
will
be
like
okay
for
all
these
different
components
and
offer
all
these
different
inputs
and
outputs.
A
What
are
some
examples
of
the
projects
and
also
what
are
which
technologies
and
which
projects
will
we
be
using
in
the
reference
architecture
that
we
want
to
build?
So
this
will
come
a
little
bit
later
as
we
are
building
it.
Obviously,
we
will
also
explain
how
we
end
up
picking
these
technologies
and
why
we
did
that
and
then
we
go
to
action,
actions
and
capabilities
of
the
ssf.
So
this
is
what
other
actions
you
can
do
in
the
secure
software
factory.
A
So
you
know
attaching
the
nodes
triggering
a
pipeline
configuring
a
pipeline.
I
don't
think
this
is
fully
updated.
There's
a
lot
more
over
here,
but
still
everything
in
this
section.
Actually,
the
mapping
probably
should
be
in
appendix
everything
in
this
section
really
is
on
the
conceptual
level.
You
know
we
don't
talk
about
specific
technologies.
It's
just
like
you
have
a
component,
that's
known
to
test
the
test
nodes,
and
this
is
how
you
use
it
within
this
process
of
running
a
circuit
build.
A
So
that's
the
idea.
Unfortunately,
we
don't
have
that,
so
we
get
the
part
which
is
prototyping
the
the
secure
software
fracture.
So
this
is
really
for
all
these
different
stages
of
you
know
triggering
the
pipeline
configuring
the
pipeline.
What
are
the
different
components
that
needed
for
them
and
how
do
they
interact
with
each
other?
A
Still
talking
about
technologies,
but
not
talking
about
specific
implementation
of
specific
projects
for
each
of
the
stages
of
things
that
it
can
carry
out
in
this
the
the
reference
architecture,
they
will
have
the
related
appendix
sections
which
will
describe
the
actual
implementation
and
the
actual,
like
gallery
implementation
details
of
how
it's
done.
What
technologies
are
used,
can't
caveats
and
all
these
things
and
as
you
go
towards
the
end,
it's
just
like
additional
notes
about
the
reference
architecture,
something
sad.
A
You
know
good
information
to
know
and
maybe
how
this,
how
this
releases
elsa
things
like
that
and
then
another
important
part
which
is
future
work,
which
is
augmenting
the
reference
architecture.
So
this
really
talks
about
like
what
are
certain
things
that
we've
not
really
addressed
within
the
secure
software
factory
reference
architecture,
so
other
use
cases.
For
example,
you
know
aggat
use
cases,
we
we
don't
talk
about
that
technology
improvements.
A
A
This
is
the
sql
software
factory?
What
are
other
parts
of
the
software
supply
chain
that
we
need
to
start
building
reference
architectures
for
right.
So
this
is
like
we
talk
about
securing
the
the
build
pipelines
and
build,
but
we
don't
really
talk
about
what
exactly
are
the
things
that
are
running
within
right.
We
provide
some
guidelines,
but
we
don't
provide
as
much
detail
so
we'll
say
you
know.
A
C
C
C
So
just
because
you
know,
obviously
we
can,
you
know,
go
as
deep
with
the
you
know,
the
we
can
keep
going
deeper
with
the
turtles
as
as
far
as
we
need
to
in
the
reference
architecture
as
well,
and
so
we
do
need
to
kind
of
figure
out
like
hey.
What
are
we
saying
is
maybe
out
of
scope,
and
maybe
we
just
cite-
and
we
say
hey,
you
know
you
should
be
using
sort
of
secure
keys.
E
I
actually
kind
of
disagree.
I
think
that
without
the
secured
distribution
and
establishing
of
identity,
you
don't
really
gain
much
from
having
an
entire
secure
software
factory
that
you
can't
trust
to
actually
verify
and
you're
up
you're
anything
because
you
don't
know
who's
actually
running
this
software
factory.
I
just
really
think
that's
a
key
component
that
we
have
to
cover
in
this
document,
for
it
to
be
valuable.
C
I
I
would
sort
of
disagree
just
because
I
I
think
that
there
is
a
level
that
we
might
say.
Yes,
we
are
establishing
the
you
know
as
long
as
you're
establishing
the
identity
at
this
level.
We're
largely
saying
these
things,
but
the
same
thing
can
be
said
about:
are
we
establishing
the
identity
up
and
down
the
chain
of
the
operating
systems?
We're
running
for
this?
Are
we.
E
Establishing
different
layers
of
hardware,
I
just
mean
that,
like
you,
you
need
to
know
who's
actually
doing
these
actions
and
and
why
you
trust
them
to
do
these
actions.
Otherwise
you
don't,
have
you
know
security?
You
just
have
some
kind
of
stuff
that
happened
and
somebody
did
it
and
you
don't
know
why
you
should
trust
that.
D
It
looks
like
the
document
you
have
here
is
really
only
concerned
with
the
sort
of
bottom
right
going
from
build
artifacts
to
verify
artifacts
and
that's
sort
of
the
the
key
of
my
question.
There's
a
lot
more
about
this
whole
thing.
Now,
if
it's,
it
may
be
valuable
to
have
a
document
focused
narrowly
on
that.
I
think
it's
just
worth
calling
out
what
the
scope
is,
and
that
may
be
the
marina
and
my
concern
here
like
is
it
the
whole
thing
you're
trying
to
cover
in
this
document
or
a
narrow
part
of
the
pipeline?
D
F
Interestingly,
sorry,
I
I
had
more
of
a
feeling
that
it
was
the
central
part
of
the
diagram
that
we're
just
looking
at
that
was
covered
by
this,
or
maybe
you
know
up
to
the
verification
part.
So
I
mean
I
could
just
be
wrong
or
we
could
just
you
know,
or
maybe
it's
interesting
to
talk
about
it
because
we
just
don't
have
quite
the
same
perspective
on
it.
F
One
small
thing
to
try
and
answer
marina's
point
which
I
I
would
tend
to
agree
with
that,
if
you
don't
know
who's
sort
of
putting
your
inputs
into
the
system,
you
can't
really
trust
the
outputs.
It's
fundamentally
it's
true.
I
mean
it's,
it's
there's
nothing,
it's
absolutely
true,
but
the
thing
is,
you
may
still
gain
something
valuable
from
making
the
box
into
which
you're
putting
stuff
harder
to
tamper.
With
I
mean,
if
you
go
back
to
say,
like
I
don't
know
much
more
real
world
example.
F
Like
you
know,
water
treatment
fact
plant,
I
mean
sure
if
people
poison
it
before
the
water
goes
in,
it's
it's
bad,
but
the
fact
that
then
the
the
plant
is
itself
secure
against
people
coming
in
and
tampering
with
the
machinery
inside.
That's
still
a
win
in
itself.
It
just
removes
some
places
where
you
know
stuff
bad
stuff
can
happen.
F
I
I
see
it
in
the
same
way
that
sure
it
doesn't
solve
the
problem,
but
it's
a
good
incremental
improvement
to
already
having
that
bit
of
the
of
the
supply
chain
more
secure,
and
so
I'm
not
sure
we
we
don't
gain
anything
because
we
don't
have
the
identity
part
covered,
not
necessarily
I'm
not
saying
we
shouldn't
work
on
it
or
anything.
I'm
just
saying
I
think
we
can.
We
maybe
gain
more
from
even
just
this
bit
than
we
might
think.
C
C
I
think,
if
you
sort
of
look
at
salsa
and
some
of
the
other
things
that
are
sort
of
coming
out,
the
way
that
a
lot
of
people
have
been
approaching,
the
initial
work
is
more
at
an
establishing
provenance
piece
and
recognizing
that
we
might
be
ingesting,
as
as
you
ment,
as
axel
mentioned,
you
know
we
might
be
ingesting
bad
code.
We
might
be
ingesting.
You
know
some
of
that
sort
of
stuff
that
is
going
to
take
a
lot
of
time.
C
C
I
think
that's
definitely
important
there,
but
I
just
don't
want
us
to
kind
of
also
talk
to
I'm
a
little
worried
if
we
start
to
say
okay
now
we're
going
to
include
how
you
know,
how
does
the
secure
software
factory
trust
the
the
source
code,
repository
and,
and
so
on,
like
that,
could
get
quite
complicated,
at
least
for
the
initial
pass?
I'm,
but
but
that's
just
my
my
two
cents,
any
thoughts.
E
Yeah
I
mean,
I
think
that
there's
a
couple
of
different
problems-
and
I
agree
that
you
know
making
source
code
secure
is
a
big
problem.
We
don't
want
to.
You
know,
try
and
tackle
here,
but
I
think
we
can
at
very
least
at
the
very
least,
make
sure
that
the
right
people
are
sending
the
code
to
the
software
factory
or
at
least
people
within
the
right
teams
or
whatever.
I
don't
think
that
I
think
that's
a
fairly
simple,
first
step
that
would
be
you
know
it's
an
easy
addition
and
then
you
know.
E
Obviously
we
can
keep
things
like
static
and
dynamic
analysis
of
that
code.
That's
a
whole
different
problem
right
whether
the
code
is
good
but
like
you
know
who
actually
wrote
it
and
where
they
trusted
to
write
the
code
and
wasn't
it
wasn't
just
randomly
injected
by
an
attacker
or
some
other
person.
I
think
that
that's
the
piece
that
I
think
is
an
easier
first
step
that
we
could
include
so.
B
B
Ahead,
I'm
sorry
one
thing
I
would
like
to
add:
I
think
what
so,
what
is
the
root
of
trust
here
like
we
are
saying
there
has
to
be
one
root
of
trust
that
we
can
agree
upon
that
this
is
what
is
basically
verifying
all
the
code
that
is
coming
in
the
subject.
The
pipeline
that
suffers
this
software
supply.
A
A
You
know
in
the
future,
so
I
think
all
the
points
are
valid
and
we
want
to
include
all
this
information
and
therefore
we
have
these
sections
in
the
in
the
in
this
particular
document
to
say
here
all
the
important
other
factors
and
the
other
components
that
are
essential
to
the
software
supply
chain.
These
are
important
you
should
you
know
we
need
a
reference
architecture
for
this.
We
need
to
build
this
picture,
but
you
know
this
is
not
done
yet
it'll
be
done
in
the
future,
so
baby
steps.
G
G
Is
change
communicating
to
the
source
code
repository?
If
so,
can
we
tell
apart
these
two
systems
and
do
mtls
between
them
same
with
a
metadata
store,
and
given
that
we
are
putting
spire
as
a
building
block,
we
can
use
spire
in
many
different
ways,
some
of
them
more
advanced
than
others.
We
can
do
federation
where
there's
different
inspired
appointments.
We
can
say
it's
all
part
of
a
single
trust.
To
me,
we
brandon
when
we
wrote
the
spiffy
book
with
ian
hock
and
they
were
on
it.
G
He
shared
his
prototype
with
how
they
do
user
svits
at
netflix.
We
could
bring
that
up
here
and
leverage
there,
but
we
really
want
to
make
it.
What
I
heard
from
eva
was
like
well
first
off:
let's,
let's
call:
what
is
it
that,
like?
How
big
is
this
picture,
and
then
I
heard
marina
said
no
matter
how
big
the
picture
is.
There
should
be
strong
identity
all
across.
D
I
think
a
lot
of
this
discussion
gets
resolved
if
the
document
opens
with
a
clear
description
of
the
intent
of
the
document.
What's
in
scope,
what's
going
to
be
talked
about
here
and
what
are
the
things
that
are
out
of
scope?
Maybe
even
what
are
the
foundational
principles
that
this
document
simply
assumes,
but
does
not
go
into
like
that
you're?
You
know
you
have
identity
in
key
management.
A
Yeah
and-
and
I
think
that's
like
one
initiative-
what
these
two
sections,
I
think
we
want
to
detail-
is
that
we're
not
claiming
to
to
be
the
entire
picture,
and
then
this
is
a
small
part
of
like
everything
else.
That's
it.
I
think
the
feedback
that
we're
getting
is
we've
put
a
lot
of
these
things
in
like
the
future
work,
and
maybe
the
thing
to
do
here
is
to
kind
of
bring
it
up
in
the
document.
A
G
I
still
think
we're
talking
past
each
other,
and
that
goes
back
to
like
establishing
true
knowledge.
Based
of
what
I
see
in
chat
like
yes,
there's
people
who
are
here
because
their
field
of
expertise
is
image.
Verification
and
signing,
but
like
search
distribution,
is
very
different
from
that,
but,
like
there's
key
distribution
for
this
other
abstraction
layer
of
things,
so.
A
I
I
do
think
I'm
seeing
a
bit
of
pieces
where
I
think
is
rather
than
particularly
for
this
in
the
case
where
okay,
here,
what
are
some
things
that
are
related,
that
we
can't
just
abstract
away
from
just
secure
software
factory
outside
our
scope
and
say
that
okay,
you
can
do
this
separately.
We
can
create
a
nice
interface
that
says
that
this
is
the
interface
that
you
do
with
key
management.
You
know
you
can
detach
it
from
there.
A
A
A
The
issue
of
tasks
in
a
separate
document:
now,
if
it's
something
that
can
be
kind
of
encapsulated
as
like
an
input
of
our
output
of
the
the
ssf
reference
architecture,
then
it's
fine.
We
can
put
it
in
our
document,
but
if
it's
something
that's
like
really
intertwined
in
the
implementation-
and
we
can't
just
put
it
as
an
input
and
output,
then
I
agree
that
we
we
need
to.
G
G
F
Well,
I
think
one
of
the
problems
we're
touching
on
is
that
as
we're
saying,
there's
like
multiple
opinions
in
the
group,
but
also
there's,
there's
two
ways
of
approaching
it.
One
of
it
is
to
say
here's
the
optimum
thing
that
we
can
figure
out
and
the
other
one
is
to
say
here's
a
bunch
of
steps
you
can
follow
to
get
closer
and
closer
to
something
that
is
good,
and
so
are
we.
I
think
my
understanding
was
that
we
were
aiming
more
to
say
right.
F
You
can't
do
the
whole
thing
in
one
go
so
we're
gonna
start
with
this
bit
and
try
and
give
you
a
good,
a
good
view
of
what
a
good
version
of
this
bit
is,
while
being
very
clear
that
it's
only
a
bit.
It's
only
a
part
of
a
whole
and
you
would
need
to
do
more,
and
I,
of
course
I
think
all
of
us
I
mean
I
have
a
feeling.
F
I
don't
haven't
known
this
group
for
very
long,
but
I
have
feeling
a
lot
of
us
are
actually
quite
aligned
in
the
way
we
approach
things
and
would
be
great
to
be
able
to
say
this
is
the
optimum
overall
vision
thinking
taking
everything
into
account
where
people
with
many
different.
You
know
specializations
here
that
bring
in
a
lot
of
interesting
points.
F
I
mean
marina
was
just
saying
you
know
if
you
don't
have
secure
key
distribution,
you
can't
even
trust
your
key,
so
you
can't
trust
who's
signed
whatever
it
is,
so
your
signatures
are
just
basically
worthless.
All
of
that
is
is
absolutely
true,
but
just
how
much
can
we
actually
do
in
in
this
amount
of
time
before
and
if
we
want
to
publish
this
in
a
timely
fashion?
So
I
think
that's
why
we
sort
of
have
to
concentrate
on
a
smaller
part
and
be
very
clear
about
the
limitations
of
what
we're
doing.
G
If,
like
we
open
up
with
like
hey
here's,
the
ideal
end
state,
you
should
arrive
and
hear
all
the
things
you
should
be
working
towards
now,
let's
get
let
us
break
some
of
that
apart
and
and
tell
you
where
to
start
where
the
scope
of
this
is
not
all
of
it,
but
your
ambition
and
your
aspiration
should
be
to
get
to
all
of
these
things
we're
talking
about
rather
than
hey.
Our
scope
is
just
this
tiny
thing,
oh
and
for
the
future
think
about
these
things
down
the
line.
I
think
that's
very
risky.
D
D
The
scope
of
this
is
so
vast
that
every
group
and
I've
been
trying
to
tag
into
as
many
different
groups
outside
the
cncf
everywhere.
I
can
find
it
in
the
open
source
ecosystem
that
are
looking
at
this
problem
space.
Every
group
has
a
different
perspective
of
what
that
overall
scope
is,
so
I
do
not
think
given
the
constraints
that
this
group
is
operating
under
both
your
scopes
to
the
cncf
and
you
have
a
time
deadline.
D
I
don't
think
trying
to
open
a
paper
with
here
is
a
total
vision
is
a
reasonable
goal
right
now.
I
think
it
needs
to
start
with
the
scope,
because
the
problem
space
is
both
very
vast
and
nebulously
undefined.
There
is
not
yet
industry
consensus
on
how
to
do
this
so
pick
your
scope
make
a
recommendation
within
that
scope
and
call
out
what
you're
not
addressing
that
makes
this
an
achievable
goal.
D
A
G
Think
I
think
folks
are
really
risk
averse
and
there's
a
component
of
bystander
effect.
And
yes,
it's
it's
hard
to
be
like
absolutely
right
or
like
absolutely
certain,
but
we
could
make
a
bet
or
we
could
make
a
claim
and
stake
that
claim
and
really
advance
the
space,
but
like
not
describing
not
by
like
manifesting
the
future.
G
Everyone
else
has
described,
but
the
the
one
that
we're
defining
ourselves
from
knowing
like
yeah,
we
haven't
seen
any
any
measure
of
improvement
and
and
how
people
run
their
pipelines
and
how
they
harden
their
pipelines
and
really
questioning
up
up
front.
I
think
it's
going
to
be
an
accelerator.
We
can
do
things
a
little
non-conventionally
here
right.
We
don't.
We
don't
have
to
be
super
lawyerly
or
super
prescriptive
of
like
we
have
to
follow
pre-structure
formats
and
doing
papers
like
but
again
I'll
defer
to
the
broader
group.
A
I
I
just
want
to
also
remind
folks
that
we've
had
this
conversation
before
and
it
ends
up
so
so
just
some
context,
I'm
not
sure
if
everyone
has
been
here
for
that
so
like
initially
this,
this
entire
group
started
with
jonathan
meadows
wanting
to
do
the
reference
architecture
and
then
we're
like
oh,
but
let's
define
the
entire
space
first.
So
that's.
We
did
the
supply
chain
paper
and
I
think
like
based
on
the
collective
knowledge
of
the
group.
A
G
Yeah,
just
just
for
full
background
there
once
we
were
done
with
the
paper,
the
majority
of
the
group
said:
okay,
we're
done.
We
did
a
great
job.
This
is
awesome,
as
we
were
preparing
to
present
that
paper,
whoever
we
delegated
to
do
it.
I
was
amongst
them.
I
said
like
wait,
a
second
we're
not
done
like
we.
A
G
Need
to
we
need
to
give
people
a
like
code,
templates
and
examples,
and
probably
those
should
be
informed,
form
a
larger
architecture
and
we
need
like
cookbooks
and
people
really
don't
piece
all
the
things
together,
so
not
not
like
to
minimize
the
work
of
anyone,
but
a
lot
of
the
desire
and
energy
and
going
back
to
people
said
like
hey.
Remember
we're
not
done.
Let's
actually
put
the
meetings
back
on
the
calendar
because
we're
going
to
work
on
this
thing,
but
it
should
be
from
the
like.
G
I
don't
want
to
go
back
in
circles
if
we
want
to
say
that
the
consensus
from
the
majority
is
like
no
that's
too
much
to
cover
here.
Let's
just
cover
the
existing
outline
as
this,
but
I
am
hearing
concern
from
folks
that,
like
let's
not
cut
off
identity
and
if
we're
doing
spire,
let's
do
spire
and
fool
not
just
like
know
that
station,
let's
do
or
not
just
within
the
system.
Let's
also
impose
that
things
calling
into
the
system
should
be
spiffy
identified
as
well.
C
You
know,
I
think,
that's
that's
big
there
and
then,
whatever
kind
of
is
needed
to
hit
that,
I
think
might
be
a
reasonable
thing,
because
I
do
think
we
could
constantly
take
sort
of
echo
brandon
there.
We
can
kind
of
go
around
in
circles
on
exactly
you
know
how
deep
you
know
what
turtle
do
we
want
to
address
first,
and
I
think,
over
time
we
can
kind
of
continue
to
increase
the
scope,
but
maybe
even
just
for,
like
the
initial
work,
we're
working
on
the
next
couple
of
weeks.
C
Keep
it
limited
and
see
where
the
gaps
are
and
then
expand
it
as
as
we
see
fit.
I
just
I
just
worried
that,
like
yeah,
I
think
we
have
had
the
sort
of
identity
conversation
before
and
there
were
some
conversations
on
yeah.
How
deep
should
the
identity
go?
Should
we
be
essentially
identifying
the
the
users
who
are
you
know,
writing
the
code,
but
then
there's
an
element
of
well.
A
A
To
commenting
now
that
everyone
has
like
is
kind
of
on
the
same
page
of
what
this
document
is,
is
going
to
be
the
goal
of
this
document,
so
we'll
open
up
this
document
of
commenting,
but
I
think
there
are
some
aspects
that
we
think
would
be
good
for
group
discussion.
I
think
mainly
being
the
the
main
architecture
diagram
that
we
have
here.
It's
a
little
bit
tiny.
C
You
know
part
of
this,
but
it's
coming
from
outside
and
coming
in,
but
the
the
yeah,
the
basic
idea
right
is
is
we
should
be
doing
something
at
least
for
the
initial
sort
of
pass?
I
would
hope
the
the
sort
of
pipeline
we
are
running
right
is
is
a
fairly
sort
of
simple
and
straightforward
thing,
where
I
would
say
at
least
for
now
stuff
like
sas
and
das
scans
are
out
of
scope
and
yaya.
I
think
right
now
the
initial
work
is
just
hey.
C
So
on
that
front.
You
know
this
sort
of
just
shows
a
very,
very
simple,
build
here
right
where
hey
you're
fetching
the
code
independencies
right.
That
task
should
have
an
identity
associated
with
it.
I'm
making
an
assumption
that
that
identity
is,
you
know,
however,
the
keys
get
there.
You
know
that's
sorted
out,
that's
sort
of
out
of
my
wheelhouse,
but
the
the
basic
idea
there
right
is
is
assuming
that
sort
of
task
is
there.
You
know
the
identity
is
attested
to
sorry.
C
The
node
is
attested
to
that
is
running
the
thing
the
workload
identity
is
attested
to
and
then
something
like
you
know,
the
pipeline
security
manager,
something
like
chains
would
go
in
and
sign
you
know,
would
would
capture
the
metadata
and
sign
the
outputs
and
sign
the
inputs
and
outputs,
and
then
that
would
all
get
published
to
a
metadata
store.
So
just
to
be
clear
here.
I
realized
that,
though
I
kind
of
combined
the
workload
of
tester
with
that
pipeline
security
stuff.
C
That
should
probably
be
kept
separate,
but
that's
really
the
only
thing
that
I
was.
I
was
trying
to
kind
of
write
up
here,
just
to
kind
of
keep
it
simple
of
like
what
should
the
the
expectations
here
be
and
once
again,
I'm
open
to
changing
the
scope,
but
my
thought
is
just
at
least
for
now
we
should
be
looking
at.
You
know.
C
There
is
some
source
code
that
comes
in
and
that
source
code
gets
built
and
we
should
be
establishing
a
provenance
that
the
source
code
and
the
dependencies
we
downloaded
are
the
source
code
independencies
that
ended
up
throughout
the
build,
and
that
already,
I
think,
helps
with
some
of
these
sort
of
you
know
if
you
want
to
say:
okay
well
what
what
is
the
what's,
the
so
what
to
the
end
user.
So
what
to
the
end
user
is
well
now.
You
know.
C
G
C
Sure
so
I
mostly
like,
given
that
I'm
still
relatively
new
to
all
the
different
things
there.
I
mostly
just
sort
of
followed
the
spiffy
spire
stuff,
where
the
way
that
they're,
the
way
that
they're
setting
it
up
is
that
the
workload
of
tester
is
essentially
just
a
process.
Sorry,
it's
a
testing
to
the
identity
of
a
process,
that's
running,
and
so
that
process
that
could
be
running
is
something
inside
of
a
container
that
that's
kind
of
all.
A
Workload
out
of
station,
I
got
into
jackpot
a
little
bit.
I
I
for
this
reference
architecture,
like
I
know
like
it's
difficult
to
have
technologies,
try
and
like
to
prevent
technologies
for
influencing
the
conceptual
view,
but
I
think
the
the
idea
is
that
this
view
should
be
in
the
ideal
world
where
you
can
just
get
a
technology
for
the
specific
component.
A
G
Me,
let
me
finish
what
I
was
going
to
say,
which
is
conceptually
there's
one
a
tester,
so
if
we
collapse
or
if
we
remove,
or
we
shift
left
the
attesters
and
make
them
out
of
band
and
draw
a
big
box
around
them
to
the
little
box,
it'll
be
more
representative
of
of
like
the
function
or
the
logical
component
that
performs
at
the
station.
Logically,
these
are
well
logically
on
implementation.
These
are
one
and
the
same.
It
was
just
my
piece
of
feedback.
D
In
terms
of
implementation,
attestation
is
backed
by
things
which
are
really
conceptually
and
business-wise.
In
my
experience,
outside
of
the
software
factory
right,
the
attestation
service
might
be
fundamentally
a
third
party
like
intel,
providing
something
that's
not
part
of
your
software
factory.
It's
a
resource
you
rely
on.
I
think
that's
your
point,
andre.
G
C
So
I
I
recognize
that
you
know
in
in
this
specific
case,
like
if
you're
looking
at
something
like
spire
spire
handles
both
of
them
and
to
be
clear.
I
think
this
kind
of
highlights,
I
think,
one
of
the
big
gaps
that
that
should
be
addressed,
which
is
it's
sort
of
a
the
what
ava's
brought
up
multiple
times
the
taxonomy
gap.
You
know,
spire
calls
it
certain
things.
Chains
calls
certain.
You
know,
chains
also
talks
about
attestations
and
it's
unclear.
C
You
know,
and
in
toto
talks
about
attestations
and
are
those
attestations
do
they
all
have
this
carry
the
same,
meaning,
I
would
argue,
probably
not
so
we're
we're,
definitely
at
a
in
a
place
where
we
should,
in
the
very
least
yeah.
Let's
you
know
if
these
things
are
unclear
in
the
community
and
nobody
else's
is
doing
this
work
either
we
should
participate
or
make
a
call
on
on
what
these
things
should
be.
You
know
the
more
generic
terms
on
these
things
that
that's
that's
my
pitch.
At
least.
D
I'll
add
that
I've
seen
just
looking
at
this
document
attestation
used
in
four
different
ways:
human
identity,
hardware,
identity
or
node
identity,
workload,
identity
and
artifact,
identity
and
attestation
can
be
performed
on
each
of
those
in
different
ways
or
in
similar
ways.
I've
seen
proposals
for
a
lot
of
spectrum
here.
C
So
I'm
curious,
like
you
know,
anybody
have
thoughts
on
on
sort
of
the
the
wording
that's
used
like,
because
I
see
a
lot
of
folks
talking
about
assertion
versus
attestation
versus
claim
versus
just
signing
it
right.
So
so
I
I'm
curious
if,
if
other
people
are
seeing
this
problem
or
if
they
think
no,
no,
like
like
it's
okay,.
B
F
F
F
D
I
think
that's
a
very
pertinent
thing
to
do,
and
folks
I'm
chatting
with
and
other
groups
are
beginning
to
do
the
same
thing.
We
do
have
some
references
from
the
itf
for
the
meaning
of
words
like
claim
and
attestation
that
are
not
dissimilar,
where
the
itf
is
so
persnickety
about
their
wording.
They'll
often
say
a
hardware-based
attestation
and
this
group
might
say
we're
using
the
same
definition,
but
we're
not
requiring
the
hardware
base.
D
A
So
I
know
we
asked
for
a
couple
of
folks
to
do
to
volunteer
to
help
out
so
we'll
be
scheduling
something
separate
for
that.
You
know
it'll
be
kind
of
like
a
writing
session
just
to
get
more
of
these
parts
of
the
document
flashed
out
and
obviously,
once
we
get
more
comments,
we
can
start
building
onto
the
main
content
of
the
document.