►
From YouTube: CNCF SIG Security: Supply Chain Security WG 2021-02-19
Description
CNCF SIG Security: Supply Chain Security WG 2021-02-19
A
C
D
E
F
F
Now
sorry
that
document
now
cool,
so
what
I
was
going
to
suggest
was
kind
of
go
through
top
to
bottom,
because
now
I
think
we've
got
a
lot
of
feedback
in
it
now
and
figure
out
and
go
through
the
scope
and
then
work
from
that
point
down,
but
certainly
open
to
any
other
suggestions
for
the
agenda.
One
one,
but
I
did
want
to
pick
out
was
I
don't
know
if
cole
have
you
been
able
to
add
your
trunk
in
or
is
that
still
in
development
up
your
mute.
F
F
G
F
H
I
know
most
of
the
commentary
comes
from
emily,
so
I
don't
know
if
she
she
wants
to
direct
her
attention
to
something
in
particular
or
like.
I
know
you
jumped
in
yesterday
that
done
a
ton
of
work.
Well,
maybe
past
couple
of
days
would
be
better
representative
of
of
the
amount
of
work
you've
you've
done
there
so
curious
what
your
takeaways
are.
You
left
some
notes
in
slack,
but
I
wonder
if
you
want
to
like
race
that
out.
A
So
what
one
of
the
things
that
will
end
up
happening
is
the
paper
is
going
to
end
up
going
to
a
community
review,
but
prior
to
that,
there's
this
single
voice,
narrative
pass
that
happens
and
anything
that
we
can
do
to
help
make
sure
that
the
person
that's
doing
that
single
voice.
Narrative
pass
has
an
easier
time
of
it
is
going
to
be
super
beneficial
and
making
this
go
much
quicker.
A
So
any
kind
of
consistency
and
format
for
like
recommendations
and
best
practices
in
particular,
whether
or
not
the
recommendation
is
before
the
justification
for
why
we're
recommending
that,
whether
or
not
we
use
terminology
as
that
we
recommend
to
this,
or
if
we
call
it
a
best
practice-
and
this
is
what
the
best
practices
is.
So,
just
trying
to
make
sure
that
we
have
consistency
across
the
breadth
of
the
document
for
what
we're
calling
particular
things.
A
The
other
part
is
some
of
the
acronyms
that
are
in
use,
so
it's
generally
best
practice
to
anytime
you're,
introducing
an
acronym
for
the
first
time.
To
spell
it
out,
then
shorten
it
later
on
and
typically
add
that
back
into
a
glossary
towards
the
end,
it
makes
it
a
lot
easier
for
reviewers
that
may
be
unfamiliar
with
the
concepts.
So,
for
instance,
one
of
the
sections
had
a
recommendation
of
ssh
over
pat
and
I'm
familiar
with
ssh,
but
not
pat,
and
I
couldn't
couldn't
google
anything
on
it.
A
A
F
Yeah,
that's
that's
awesome.
I
I
think
that.
Definitely
we
need
to
run
through
to
make
sure
it's.
It
confirms
that
same
sort
of
standard
right
at
the
minute
we've
got
five
or
six
people
contributing
with
totally
different
voices,
and
we
haven't
got
any
standardization.
So
so
you
definitely
should
do
that
as
an
editorial
pass,
but
that
last
point
you
you're
referring
to
right
so
and
actually
you
made
a
different
point
about
other
material
coming
in
but
effectively
as
we're
referencing
other
documents.
F
A
F
A
That,
when
and
if
we're,
introducing
a
concept
that
has
some
reinforcement
or
like
for
more
information,
go
here,
sometimes
those
work
better
as
footnotes
so
that
the
user
doesn't
lose
track
of
where
they
are.
If
they
see
the
footnote,
they
drop
down
to
the
section
read
it
go
back
up
and
move
on,
instead
of
scrolling
all
the
way
down
to
the
bottom
of
the
document.
A
In
other
cases
where
there
is
a
particular
content
element
from
an
external
source
where
we
really,
when
I
drive
reinforcement
home,
we
talk
a
little
bit
about
why.
That
thing
is
important,
so,
like
the
nist
appendix
I
think
c,
is
what
it
was
or
appendix
2.
Something
like
that.
I
made
the
reference
in
there
that
we
talk
a
little
bit
about
why
that
particular
area
is
important
and
how
we
expect
the
reader
to
use
that
or
leverage
that
as
they
go
through
the
document.
F
That
makes
sense,
but
one
of
the
other
things
that
I
think
it
might
have
been
on
the
slack
channel
that
you
pulled
out,
which
I
think
is
really
kind
of
poignant,
is,
is
now
everyone's
a
fan
of
supply
chain
and
there's
actually
a
reasonable
amount
of
you
know.
Now
it's
cool
and
there's
lots
of
documents
talking
about
it.
I
think
we
need
to
differentiate.
You
know,
what's
our
differentiator,
why
are
we
writing
this
document?
Now
everyone
else
has
written
stuff.
I
mean
I've
got
my
view
in
that.
F
G
A
It's
confusing
for
a
lot
of
people
and
when
they're
tasked
by
their
organizational
leadership
to
start
a
supply
chain
working
group.
So
how
do
we
fix
our
supply
chain?
So
we
don't
become
another
solarwinds
they're,
looking
to
the
community
to
provide
a
singular
document
that
kind
of
executes
like
a
playbook
and
whether
or
not
that's
a
high
level
for
as
an
architect
that
I
would
want
to
read
through
and
then
I
can
provide
a
reference
implementation
schema
to
my
development
team
based
off
of
that.
So
I
have
a
foundational
understanding.
F
And
that's
the
thing
that
I
wanted
to
do
whilst
kicking
this
off
right
at
the
start.
Right
is
that
this
is
a
best
practices
document
that
then
maps
directly
to
a
best
practices,
architecture
with
the
cncf
tools
and
then,
as
a
best
practices,
implementation
using
those
tools
that
you
can
take
and
that's
the
bit,
although
we
kind
of
need
those
second
and
third
bits
to
to
prove
out
to
be
truly
useful.
I
think
that's
the
differentiator
to
me,
because
I
just
haven't
seen
that
still
right.
H
I
think
we're
starting
to
arrive
at,
I
think
we're
starting
to
arrive,
who
who
our
intended
audience
is
for
good
part.
Those
of
us
who
are
gathered
here
in
the
scholar,
people
who
have
time
to
think
and
question
the
status
quo,
the
question
supply
chain
today,
but
the
industry
is
at
large.
They
often
have
to
go
with
well,
what's
seen
as
the
accepted
solution
and
they
follow
the
dogs
and
they
don't
question
why
they
don't
question.
Is
this
the
right
tool?
Is
this
the
right
framework?
H
They
just
go
with
things:
they're,
not
questioning!
Well,
are
there
better
ways
to
do
signing
and
verifications?
Are
there
better
ways
to
do
this?
Other
things
so
emily?
I
know
I
know
you
you
put
an
intended
audience
in
there.
Maybe
we
can
like
fill
it
in
with
a
straw.
Man
or
like
are
these
practitioners
or
these
operators
who
these
people
are
the
other
thing?
Well,
I
see
a
a
number
of
people
joining
the
group
for
the
first
time.
H
I
want
to
make
sure
that
everyone
feels
like
well.
They
they
can
come
up
to
speed,
know
what
we're
doing
and
they
can
like
find
a
place
to
insert
themselves
there's.
There's
areas
we're
looking
for
help
blake
good
to
see
you
again
amazing
to
have
you
here.
Blake
is
doing
some
really
really
cool
things
in
his
work
so
good
to
have
a
practitioner
in
the
group
tiffany
jordan
tiffany
is
product
manager
for
a
lot
of
the
app
delivery
efforts
over
at
vmware.
H
A
So
andres,
that's
a
good
point.
Do
we
have
a
kind
of
guidelines
or
north
star
for
new
folks
that
are
interested
in
doing
this?
One
of
the
problems
that
we
had
with
the
cloud
native
security
white
paper
when
we
opened
it
up
for
community
comment
was
either
we
didn't,
define
our
scope,
our
our
intent.
Clearly
enough
that
we
had
a
lot
of
feedback
that
we're
trying
to
like
shift
what
the
focus
of
the
paperwork
was.
Do
we
have
something
like
that.
F
No,
I
think,
that's
a
fair
comment.
We
don't
right
and
when
we
were
trying
to
define
that
at
the
front
it
was
still
a
little
vague.
So
I
think
maybe
that
is
something
we
can
add.
As
you
know,
this
is
the
not
only
the
scope,
that's
number
one,
but
number
two
would
be
the
okay.
If
you
want
to
contribute
this
is
how
so
I
think
that
would
be
beneficial.
H
Yeah,
the
the
one
guidance
is
perhaps
we're
we're
really
biased
towards
action
and
getting
things
in
writing.
We
don't
want
to
like
make
this
a
a
discussion
forum
there.
There
are
a
lot
of
good
discussions
that
have
happened,
but
if
you
have,
if
you
see
something
you
see,
it's
not
covered
the
right
way
or,
like
you
feel
certain
ideas
would
be
represented
better
or
there
are
some
ideas
that
haven't
been
captured,
write
them
down,
yeah.
F
Absolutely
the
way
we
usually
maybe
we
need
somewhere
actually
within
the
paper
to
identify
that
what
we
would
do
initially
when
we
went
through
it
is
putting
out
placeholders
for
the
sections
that
we're
going
to
discuss.
Maybe
there's
some.
You
know
we
need
to
mark
out
some
of
the
placeholders.
If
you,
if
you're,
creating
a
completely
new
section,
you
know.
Okay,
we
put
it
in
bold,
like
text
two.
Maybe
you
know
somehow
put
a
comment
next
next
new
section
or
such
and
then
fill
it
out.
Maybe.
H
Thing
bring
those
in
once
once
they're,
like
sort
of
fleshed
out
and
same
with.
If,
if
you
see
an
existing
section
that
you
feel
the
ideas
can
be
elaborated
further
and
you
like
that's
what
you
feel
inclined
and
have
the
most
energy
to
work
on
jump
right
in
there,
no
one
is
really
too
attached
to
the
words
we
put
in
place.
So
if
you
feel
you
want
to
rewrite
something
or
you
want
to
add
on
to
it,
that's
for
a
game
too
right.
Jonathan.
F
Absolutely
we
need
to
figure
out
how
we're
going
to
do
that.
Actually,
that
was
one
of
the
questions.
One
of
my
questions
in
that,
if,
if
we
are
going
to
suggest
rewriting-
and
I
think
when
we
get
to
the
point
where
we're
going
to
do
some
fairly
heavy
editorial
across
it,
we
are
going
to
need
to
change
the
document
quite
heavily,
probably
need
some
form
of
versioning
and
be
interesting
to
see
how
people
collaborated
on
that
with
the
other
white
paper.
A
This
is
going
to
be
our
starting
point.
It's
a
very
rough
draft.
We
kind
of
like
snapshotted
that
and
then
moved
the
content
into
a
separate
document,
and
that's
that's
where
we
did
our
working
editorial.
We
did
a
little
bit
more
writing
moving
and
shifting
things
around
that
were
redundant
in
other
areas.
F
That
makes
I
mean
that's
kind
of
what
we
followed
in
that
we
started
with
those
high-level
straw.
Man
of
you
know
these
the
different
sections,
and
then
we
separated
out
into
right
who's
going
to
take
that
section
call
took
one
rich
julian
took
one.
I
think
another
two
took
one.
I
took
one.
I
think
we're
probably
beyond
that
at
this
point,
we've
got
chunks
of
it
filled
in,
and
I'm
just
trying
to
think
at
this
point.
A
F
A
E
Yes,
so
this
is
vessel,
so
there
is
one
section
called
securing
source
code.
That
is
the
section
I
mean
I
I
do
not
know
where,
where
we
have
defined
the
ownership
of
of
a
section,
but
that
is
a
section
that
I
would
want
to
take
kind
of
ownership
for
or
work
collaboratively
with
somebody,
because
I
have
a
few
ideas
around
it.
I
work
days
in
I
mean
this
is
something
that
I
do
today.
E
F
So
richard
richard
julian
took
that
one
but
and
definitely
worked
with
him
to
to
update
her
absolutely
and
pile
in
there
right
I
mean,
maybe
I
take
it
back
if
people
think
that
there's
still
huge
chunky
sections
that
we
that
they
could
adopt,
let's
go
for
it.
I
don't
think
there's
any
reason
to
say
no
right.
H
A
All
right
good,
examining
s-bombs,
so
that
was
one
of
the
sections
that
was
seemed
a
little
bit
late
and
how
it
mapped
to
the
particular
relevance
of
the
paper
from
a
flow
perspective.
There
was
also-
and
I
think
I
had
a
comment
to
that
effect.
We
also
had
like
this
trailing
section
for
record
traceability,
tracking
dependencies,
oaus
dependency
tracker,
which
was
covered
higher
up.
D
E
And,
and
if
you
guys
want
I,
I
can
explain
that
what
I'm
thinking
about
on
this
call
as
well,
so
that
I
bring
everybody
on
board
that
okay,
why?
I
want
to
structure
information
in
a
particular
way,
and
then
you
guys
can
give
me
comments
right.
Okay,
this
is
wrong.
This
is
right
so
that
we
move
for
I
mean,
because
I
want
to
establish
the
structure
first
for
that
section
and
then
fill
in
all
the
details
for
securing
source
code
and,
of
course
there.
E
I'm
not
sure
this
is
the
right
call
for
it
or
we
need
to
establish
another
call
or
something
like
that,
but
yeah.
At
least
that
section
is
something
that
I
want
to
go
through
today,
so
that
people
can
give
comment
that
okay
and
then
we'll
I'll,
try
to
fill
up
every
detail
and,
of
course,
working
with
others
as
well,
so
that
we
know.
H
Faiso
thanks
for
thanks
for
taking
the
initiative.
I
think
it's
it's
great.
If
you
take
that
on,
if
you
could
give
us
a
quick
rundown
of
what
is
it
that
you
want
to
discuss,
we
can
try
to
discuss
this
right
here
right
now,
like
for
five
minutes
or
so
or
if
you
feel
like
you
want
to
start
on
the
outline
we
can.
I
don't
know
if
we
want
to
put
people's
names
downs
to
know
like
oh
faisal
and
richard,
and
maybe
someone
else-
and
this
call
wants
to
jump
on
that.
H
You
want
to
have
a
breakout
discussion
with
those
people
first
and
bring
it
and
bring
it
back.
Emily
and
I
recently
participated
in
writing
a
whole
book
over
two
weeks
with
other
15
people
on
a
call
and
we'll
learn
a
few
things
on
on
what
should
be
group
discussions,
what
should
be
breakout
discussions,
but
I
think
we
like
emily.
What
do
you
think
we
should
do.
I
A
A
F
H
B
No,
I
think
that
sounds
good
to
me.
I
need
to
take
a
closer
read
through
this
before
you
know,
signing
up
for
anything
and
kind
of
collect
my
own
thoughts,
but
andres
I'll,
probably
reach
out
to
you
just
because
I'm
new
to
to
joining
sessions
like
this
with
some
of
my
initial
feedback,
because
I'm
not
too
sure
where
to
put
it
up
front.
H
J
K
K
L
K
L
A
L
K
The
things
that's
going
to
bring
up
the
software
factory
I'll
quickly
mention
it
is
one
of
the
things
we
do
is
typically
standardizing
build
processes
when
possible
and
also
introducing
more
oversight
to
it
and
moving
it
out
of
individual
developer
control.
You
can't
change
your
your
your
code
inside
the
repo
to
change
your
build
process.
You
have
to
go
to
something
external,
so
that's
a
topic,
that's
not
showing
up
here,
and
I
didn't
know
where
to
best
mark
that
no
it's
a
good
one.
Just
I
guess
just
add
that.
F
F
K
H
Then,
mike
lieberman,
last
time
we
were
on
the
call,
you
had
some
great
ideas
of
well
all
the
other
aspects
around.
Well
how?
How
do
you
in
order
to
trust
the
machines
that
are
building
your
software?
You
should
have
secured
these
things
using
like
defense
and
depth.
I
don't
think
that
has
quite
been
captured.
F
A
A
F
F
F
F
A
G
A
Production
of
software
artifact
and
associated
metadata
s-bomb,
this
one
will
likely
need
an
introduction
further
up
because
we
introduced
s-bomb
and
d-bombs
further
up
within
the
paper.
So,
if
you're
working
on
this
one,
I
would
recommend
also
tackling
that
one
and
making
sure
that
it
works
within
the
flow.
G
F
It
would
have
been
useful
right.
I
think
this
was
when
we
were
looking
about
how,
when
we
go
through
when
we've
collated,
the
in
total
data,
how
do
we
distribute
that
to
other
people
further
up
the
chain,
because
the
reality
is
this
is
for,
and
this
goes
back
to
the
you
know
the
use
cases
right.
The
reality
is
you're,
probably
in
the
middle
of
the
supply
chain:
you're,
not
the
you're,
not
the
end
user.
So
you
need
to
send
your
data
and
your
metadata
to
the
next
person
in
the
chain.
G
K
Yeah
a
little
bit
yeah,
so
we
put
some
a
lot
of
other
data
that
way
that's
appropriate,
it's
key
value
and
container
metadata,
but
we
have
not
actually
established
something.
That's
standardized
or
something
general
purpose
like
I'd
be
interested
there.
I
want
to
say,
like
oci,
has
good
answers
here,
but
oca
too,
but
yeah
it's
not
done
yet,
and
the
integration
isn't
ready
yeah.
K
F
K
A
So
that's
actually
a
good
question,
and
this
is
something
that
I
struggled
with
throughout.
The
document
was
that
we
had
the
raw
suppliers.
We
have
the
software
producers
and
then
we
have
the
software
consumers
and
I
started
that
lexicon
earlier
up.
I
didn't
add
the
software
consumers,
but
ultimately,
if.
F
A
K
G
Out
how
to
explain
it
better,
go
ahead
for
distribution
and
metadata.
I
think
there's
two
things:
we
need
to
concern
ourselves
right,
right,
the
actual
metadata
and
then
the
the
signatures
of
the
hashes
of
the
metadata
right.
So
we
need
that
transparency
and
the
actual
metadata.
I
think
those
are
two
separate
things.
J
K
K
J
B
H
K
Attacker
one
of
the
practical
challenges
I
think
I've
run
into
over
and
over
is
when
hashing
happens
and
turning
something
into
an
idea.
Digest
is
your
metadata
on
the
inside
or
the
outside
of
that
signature,
if
you
will,
in
other
words,
like
a
doctor,
digest
effectively
includes
all
of
its
labels,
because
they're
inside
the
manifest
of
doctor
images,
which
means
you
can't
change
your
metadata
post
signature
without
invalidating
things.
K
I
think
things
are
what's
one
of
the
many
improvements
to
the
notary,
v2
oci,
stuff,
that,
after
building
an
artifact,
you
can
add
additional
metadata
to
it
on
the
outside.
This
is
a
practical
detail,
but
it's
as
you
consider
tools.
It's
one
of
the
many
problems.
I've
frequently
run
into
that
made
sense.
H
H
So
if
you
don't
know
about
signing
software
artifacts,
but
have
questions
around,
how
should
software
artifacts
be
signed
and
questions
that,
like
just
following
that
thought
process
that
would
be
really
beneficial
here
and
then,
as
you
disengage
from
that
section,
someone
else
can
take
ownership
start
to
fill
those
out.
That's
going
to
help
us
accelerate
a
lot
of
the
work.
A
K
So
good,
no,
no
blake
go
ahead.
Yeah!
Sorry,
sorry!
I
keep
I'm
really
bad
at
talking
over
people.
Sorry
I
was
going
to
mention.
Is
yes,
software
artifact?
This
generally
probably
looks
like
standard
industry
code.
Signing,
I
think,
is
my
expectation
of
our
output.
This
is
signing
of
artifacts
delivered
to
users.
That's
one
thing
I
want
to
highlight:
this
is
not
science
or
maybe
it
is
you
there
you
have
just.
K
You
can
distinguish
between
artifacts
produced
in
the
middle
of
your
pipeline
and
your
final
artifact
at
the
end,
and
I
think
that
may
be
worth
mentioning
here.
You
have
automated
signatures
for
sure
inside
your
system.
That's
what
intel's
doing,
but
you
might
have
some
different
kind
of
signature
at
the
very
end
like
say
notary,
for
your
signature
delivered
to
an
end
user.
So
it
may
be
worth
mentioning
that
these
are
not
always
the
same.
K
One
of
the
things
like
I'm
very
confused
by
is
how
do
I
actually
connect
meaningfully
cryptographically
those
two
chains
of
trust
together?
I
I
don't
have
good
answers
and
it's
yeah.
So
it's
one
of
the
end
of
your
software
build
process
and
the
delivery
to
the
user
might
be
different
signature
mechanisms.
K
K
J
E
Yeah,
so
in
the
past
on
this
on
this
section
as
well,
I
had
communicated
this
thing
before
as
well
somewhere
that
first
we
need
to
identify
what
different
software
artifacts.
We
are
talking
about
right,
because
s
bombs
are
one
manifests.
Are
there
there
are
executables
now
now
there,
the
landscape
is
very
big
right
and
many
of
the
things
are
in
enterprise.
Today
they
work
for
people.
E
They
do
this
thing
day
in
and
day
out,
right
and
then
some
things
are
exploratory
like
in
total
or
something
like
that
right,
their
exploratory
in
a
sense
because
they
are
not
prevalent
in
the
enterprise
right.
So
we
need
to
identify
that,
okay,
what
kind
of
sort
assigning
artifacts
we
are
talking
about
right
and
then
base
once
we
have
identified
those
artifacts,
then,
based
on
each
of
them,
we
can
kind
of
give
recommendation
that
okay.
E
This
is
the
way
we
sign
okay,
or
this
is
something
that
you
should
do
or
look
into
it
right,
because
because
right
now,
I
I
think
signing
of
the
software
artifacts
it's
in
itself
could
would
be
a
very
giant
white
paper
right
because
there
are
so
many
techniques
out
there.
There
are
so
many
interfaces
out
there.
There
are
csps
ksps
pkcs11,
then
there
are
gbg
signing
in
toto.
Is
there
no
tree?
Is
there?
E
A
F
A
A
I
do
have
one
question
that
kind
of
triggered
in
my
mind,
as
we
were
having
the
software
artifact
discussion
is.
I
have
not
seen
anywhere
in
the
document
an
explanation
of
the
components
of
the
supply
chain
as
they
relate
specifically
to
software,
so
we've
talked
a
little
bit
around
the
code
itself,
that's
being
written
whether
or
not
you're
a
raw
supplier,
a
producer
or
consumer.
K
I
think
yeah,
I
fired
a
release,
I
think,
adding
at
least
an
extremely
simplified
flowchart
pipeline
diagram
might
be
meaningful
at
the
beginning,
yeah
because
it
would
identify
the
stages,
the
identities
of
people
at
each
stage,
with
the
names
you
mentioned,
and
what
artifacts
are,
what
what
stuff
is
at
each
stage
inputs
or
outputs
yeah,
which
basically
it's?
What
are
the
inputs,
one
or
more
intermediate,
and
an
output
like
an
extremely
simple
pipeline,
not
but
just
showing
that
the
existence
of
those
yeah.
G
K
Yes,
no
mostly
like
all
these
nate,
all
these
things.
We
keep
talking
about
our
glossary.
If
you
will
just
something
that
includes
the
same
exact
names,
we're
going
to
use
throughout
the
paper
and
introduces
them
a
diagram.
Yes,
we
probably
could
copy
the
diagram.
I
haven't
seen
it
mentioning,
but
we
probably
could
copy
it
for
reference,
but
just
making
sure
it
matches
the
terminology
we're
going
to
use
the
rest
of
it.
Just.
K
K
A
A
H
Another
thought
that
elicited
would
be
really
need
to
be
on
a
reference
architecture
to
provide
a
reference
environment
and
give
configuration
files
to
stand
something
up.
I
know
we
talked
with
andrew
martin
to
do
something
possibly
supply
chain-ish
or
capture
the
flag
for
a
security
day.
Maybe
we
can
tap
into
those
folks,
but
if
someone
is
feeling
eager
to
like
write
some
code
or
do
some
configs,
it
would
be.
It
would
be
like
a
great.
F
G
H
K
K
K
A
So
I
that
was
actually
something
that
I
had
also
learned
was
that
some
of
the
content
of
the
paper
appears
to
be
more
expansive
into
a
reference
implementation
area
and,
if
you're
doing
a
review
and
you
you
feel
that
particular
section
that
you're
looking
at
has
more
reference
implementation.
Specific
information
highlight
it
and
tag
it
as
reference
implementation.
F
Thing
because
I'm
trying
to
figure
out
because
the
differences
between
that
and
the
the
actual
reference
implementation,
because
the
expectation
would
be
that
that
reference
implementation
is
literally
pres.
Well,
it
would
be
great
press
a
button.
We
instantiate
the
whole
shooting
match,
and
now
you
can
start
building
out
your
code,
so
it
would
have
the
configuration
the
environment
with
it.
Everything
that
someone
would
need
to
be
able
to
instantiate
this
thing,
that's
kind
of
where
I
think
we
were
going
initially
with
that
reference
implementation.
I
mean
it's
a
long
way
off
right.
F
M
John
for
something
like
that,
if
we
just
go
back,
I
think
to
what
I
think
was
an
earlier
comment
as
well.
We
would
need
to
make
sure
that
the
artifacts
are
clearly
defined
and
the
any
translation
between
the
artifacts
across
the
supply
chain
and
stuff,
but
bang
on.
If
we
end
up
with
a
software
factory
on
this,
it's
golden.
G
B
J
M
Much
better,
okay,
sorry
about
that
looks
like
zoom
just
reset
something
for
me
here,
but
no.
I
was
just
going
to
say
that
I
think
that
the
conversation
is
spot
on
if
we
just
tie
in
what
was
stated
earlier,
if
we
can
work
on
the
artifacts
themselves
and
then
look
at
the
integration
of
these
artifacts
and
possibly
translations
and
then
the
sort
of
click
button.
M
Software
factory
model,
which
starts
to
talk
about
a
software
supply
chain
that
we
can
instantiate
becomes
a
starting
point
for
people
to
go
in
and
they
can
kind
of
configure
it
for
their
environments.
But
so
there's
some
really
interesting
work.
That's
being
discussed
here.
If
we
systematically
take
it
from
the
the
the
concept
of
first
of
all,
just
to
highlight
sort
of
the
areas
that
we're
looking
at
in
this
document,
then,
let's
get
down
to
the
artifacts.
J
H
Yeah,
there's
there's
a
point
that
that's
that's
pretty
tight
and
so,
if
like
it
will
be
largely
informed
by
the
the
previous
sections
but
I'll
tell
us,
you
were
the
last
one
on
the
microphone.
I
don't
know
that
you've
yet
been
assigned
to
anything.
If
you
could
jump
in
there.
That
would
be
great
yeah.
M
N
N
N
A
Okay,
so
if
you
have
not
yet
been
assigned
and
you're
just
going
through
and
reviewing,
we
would
like
you
to
become
a
contributor
to
the
paper.
Please
feel
free
to
assign
yourself
a
section
or
just
start
jotting
down
some
of
your
notes
or
thoughts
and
opinions
that
you
have
on
a
particular
area
oftentimes.
Once
somebody
sees
something
written
down,
it
jogs
their
memory
to
add
on
to
it
and
expand
it,
and
then,
sooner
or
later
you
take
a
paper,
that's
20
pages
and
turn
it
into
41..
A
A
I
do
have
a
question
associated
with
timeline,
so
originally
we
were
targeting
this
for
a
kubecon
cloud
native
security
release
for
europe,
which
is
may
beginning
of
may,
and
it
usually
takes
about
a
month
to
get
through
the
community
review
and
adjudication
portion
of
that.
So
that
brings
to
beginning
of
april.
So
we
really
need
to
have
draft
content
with
our
initial
passive
review
sometime
in
mid
march.
F
I
gotta
think
that's
achievable.
We
we've
still
got
like
four
weeks
or
so
to
really
crack
on
right.
I
think
we've
got
a
lot
of
tech
content
in
here
already
there's
some
of
the
areas
we've
picked
out
there
that
we
can
add
on
to
it.
Four
weeks
set
up,
I
thought
we'd
be
in
decent
shape,
but
it
would
mean
you
know:
we'd
spend
a
week
doing
that
review,
maybe
two,
so
we
really
do
have
to.
I
guess
start
implementing
some
of
these
content
areas.
I
F
H
Yeah,
that's
a
great
point:
if
you
feel
you've
hit
a
wall,
be
it
writer's
block
or
you
don't
know
something
just
raise
your
hand
in
the
slack
channel
for
others
to
jump
in
and
and
discuss
that
with
you
to
see.
If
you
can
progress
or
if
you're
ready
to
tap
out
and
move
on
to
something
else,
we
can.
We
can
discuss
that
as
well.
B
F
D
A
I
think,
some
of
that,
if
you
do
get
really
detailed
or
into
the
weeds,
I
think
we
can
do
a
review
and
determine
whether
or
not
it's
it's
too
intense
for
that
particular
section
or
needs
to
be
put
out
into
a
reference
implementation
for
further
explanation.
We
can
do
that
as
part
of
the
review
oftentimes.
What
will
end
up
happening
is
when
we
do
that.
A
First
draft
content
pass
it's
not
going
to
be
consistent
at
the
level
of
depth
and
we
might
find
some
areas
that
need
to
go
a
little
bit
deeper
and
other
areas
that
need
to
be
raised
up.
But
it's
always
better
to
have
some
of
that
information
so
that
we
can
make
more
informed
decisions
when
we're
doing
those
reviews.