►
From YouTube: CNCF SIG Security - Supply Chain Security 2021-03-12
Description
CNCF SIG Security - Supply Chain Security 2021-03-12
A
C
B
Yeah
I'll
actually
have
some
time
this
weekend,
so
I
I
do
a
lot
of
volunteering,
so
I
tutor
a
lot
of
folks
in
in
programming,
so
the
past
they
they
have
a
big
project
coming
up.
So
I
haven't
had
a
lot
of
time
to
focus
on
this
thing,
but
this
weekend,
that's
over
so
should
have
more
time
to
to
go
back
over.
A
I'm
open
to
suggestions
here,
but
I
was
thinking
of
just
going
top
to
bottom
see
how
far
we
get
it's
like
a
joint
edit.
I
know
multiple
people
are
then
going
to
take
separate
sections
and
I
for
one
I'm
gonna
take
another
sort
of
run
from
top
to
bottom
tonight,
if
not
saturday,
again
any
other
suggestions
or
efficiency,
I'm
going
to
somewhat
stir
crazy
at
this
point
reading
the
same
document
over
and
over
again,
it's
good
stuff,
there's
some
really
good
stuff
in
here.
I'm
just.
A
D
D
E
F
A
A
G
A
A
A
A
E
H
F
I
think
yeah,
I
think
it's
definitely
not
just
containers
right.
It's
we
we
can,
we
can
solidly
say
it's
not
focused
on
containers,
but
I
do
think
containers
are
a
big
part
of
it
and-
and
we
do
mention-
I
believe
in
in
the
actual
document-
how
the
the
I
think
on
the
signing
side,
specifically
how
that
can
apply
to
containers
and
and
built
deployed
artifacts.
I
think
when
we
say
artifacts
a
lot
of
times.
This
group
means
containers.
A
H
Keeping
track
of
those,
I
suppose
signing
is
I
mean
this
sign
assigning
the
container
image
is
what
it
is
it's
the
best
we
can
do
for
now
and
then
probably
some
best
practices
around
docker
files,
because
it
seems
well
best
practices
around.
You
know
pulling
using
a
mutable
tag
versus
pulling
by
digest
to
keep
building
reproducibility
using
yeah.
So
I
am,
I
am
just
pouring
all
of
this
out,
so
that's
why
I'm
asking
whether.
A
H
A
That's
the
thing
from
my
view:
I
think
it's
difficult
because
it
is
kind
of
intertwined
right
and
the
reality
is.
We
are
the
cncf
and-
and
I
wonder
if,
if
we
start
to
start
to
expand
upon
that,
and
if
we
get
to
the
point
that
look,
it
kind
of
gets
in
the
way
of
the
general
flow
of
content.
Maybe
it
is
kind
of
an
appendix
or
it's
a
reference
to
material
already
exists,
but
at
least
we
reference
it
inside
the
document.
It
would
that
be
an
approach
right.
A
I
I
did
for
my
paper
on
my
site.
Is
I
mean
containers
are
kind
of
a
part,
part
and
parcel
of
the
entire
thing
it's
pervasive
throughout
the
entire
supply
chain,
because
ultimately,
that's
in
a
lot
of
ways
that
you're
deliverable
right
and
so
you're
acting
upon
them
and
all
of
the
points
you
made
are
absolutely
spot
on.
I
think
they
need
to
be
mentioned,
but
there
are
other
documents
you
can
reference
out
to.
So
you
don't
have
to
explain.
Okay,
let's
talk
about
multi
multi-stage
builds,
and
you
know
you
hear
some
pros
and
cons.
I
You
know
we
don't
have
to
do
all
that.
You
can
point
to
different
things,
but
say
you
definitely
need
to
focus
on
that
and
make
sure
you
have
the
most
minimally
smallest
container.
You
know
to
give
yourself
the
smaller
security
risk
at
the
end
stuff
like
we
can
give
those
recommendations
but
based
off
of
other
documents
and
articles
that
already
exist,
yeah,
and
I
definitely
think
it
should
be
a
part
of
it.
H
So
the
reason
why
I
am
advocating
for
writing
out
all
of
those
recommendations
specifically
here
is
because
the
existing
recommendations
around
building
container
images
actually
contradict
all
of
the
stuff
that
I've
said
over
here.
For
example,
you
know
oh
use
use
you.
Can
you
can
just
pull
from
an
image
from
docker
hub?
H
H
A
So
it's
like,
I
think
it
makes
sense
to
add
this
and-
and
I
I
think,
there's
a
valid
points
as
well
right
in
the
week
we-
but
I
I
guess
my
my
mouth
concern
here
is-
is
on
the
the
size
of
that
scope
in
increase
in
certain
timelines
right
and
frankly,
who's
going
to
write
that
so.
But
but
I
think
I
think
it's
an
appropriate
statement
right.
So
I
think
a
way
forward.
A
C
I
have
added
some
wording
around
hardening
containers
based
upon
upon
the
department
of
defense
approaches,
it's
more
focused
on
the
abstract
of
taking
scratch
and
adding
stuff
or
digitalis,
or
the
inverse
just
reducing
or
copying
into
a
multi-stage
stock
file.
So
it's
it's
there
at
a
high
level,
but
there's
no
there's
no
detail
on
the
actual
docker
file
hardening
steps.
I'd
be
happy
to
add
a
few
more
bits
to
that.
If,
if
you
want
to
just
collaborate
on
that
or
or
I'll
follow
your
lead
or
whichever.
A
So
nature
and
andy:
do
you
want
to
maybe
on
that
comment
and
add
your
names
in
there
that
you'd
take
that,
and
is
it
reasonable
to
add?
That
initially,
is
that
appendix
and
depending
on
the
the
speed
and
detail,
we
can
look
to
integrate
that
because
I
do
think
it
makes
a
lot
of
sense
to
add
it
in
you
know
it's
just
annoying
that
it's
additional
scope,
but
actually
it's
the
right
team,
the
right
place
to
add
it.
It's
the
right
scope.
I
A
No
now
that
that
is,
I
I
I
don't
recall
whether
it's
actually
in
there,
but
that's
what
I
was
referring
to
last
week
when
we
were
talking
about
you
know
having
the
pipeline
to
create
those
really
hard
and
build
containers
for
those
workers,
and
that
absolutely
has
to
be
in
the
middle
of
the
document.
In
my
view,
because
there's
a
lot
of
I
can,
I
can
take
that
one.
If
it's
maybe
a
science,
I
can
have
a
shot
at
writing.
That
part.
I
I
A
I
Yeah,
basically,
the
way
I
read
that
is
like
the
only
attacks
are
coming
when
it's
from
an
outside
entity,
and
so
and
I
think
the
the
side
comments
are
probably
pretty
pretty
important
like
what
exactly
do
we
want
to
determine
is
the
what
is
the
supply
chain?
I
always
consider
the
software
and
my
own
internal
teams
to
be
a
part
of
that
whole
software
supply
chain,
it's
not
just
from
outside,
but
I
could
write
pretty
poor
software
that
exposes
vulnerabilities
pretty
easily
that
have
no
dependencies
on
outside
resources.
I
D
A
B
A
A
A
J
F
A
F
F
C
F
H
H
H
A
I
I
guess,
if
we
think
about
the
the
the
sort
of
actors
we're
looking
at
moderate
security,
whatever
that
means
in
high
security.
So
if
we
were
to
say
to
someone
look
whatever
that
most
moderate
posture
is
and
we're
going
to
have
to
make
up
what
a
moderate
posture
is,
you
know
what
would
be
the
reasonable
assumption
if
you
were,
you
know
doing
it
at
that
moderate
level
of
a
risk
assessment.
A
C
I
That's
that's
what
I
did
in
my
papers.
I
literally,
I
basically
said
that
there's
going
to
be
a
hardening
process,
you're
going
to
do
in
order
to
build
your
software
and
run
your
software,
like
the
scope
of
this
paper,
doesn't
include
that
I
can
say
there's
a
few
things
that
we
can
do
like
minor
things.
We
do,
but
really
it's
picking
up
from
the
responsibilities
of
a
developer
in
a
platform
admin
and
then
running
that
through
the
completion
up
to
the
point
where
it
goes
into
a
production.
I
A
B
A
I
Yeah,
so
it's
the
shared
responsibility
model.
You
need
to
make
some
assumptions
somewhere
and
you
know-
and
maybe
that
spawns
another
paper
in
the
future
that
talks
about.
How
do
you
go
further
down
to
the
hardware
level?
And
you
know
that's
that
part
of
the
supply
chain.
You
know
the
physical
supply
chain,
but
one
paper
is
not
going
to
handle
all
that.
I
H
I
So
because
that
that's
kind
of
like
I
I
looked
at
that
as
well,
and
I
kind
of
left
it
off
my
side
of
the
paper
because
it
introduced
more
scope
that
it
wasn't.
You
know
that
yeah,
if
you
think
about
it
from
a
developer's
perspective,
you
don't
have
a
lot
of
control
over
that
it's
kind
of
what's
there,
and
so
I
assumed
that
was
a
or
I
made
the
assumption
that
that
was
the
part
of
scope
that
was
out
just
because
of
the
you
know:
it's
it's.
I
How
much
scope
do
you
want
to
put
in
and-
and
you
could
make
an
argument
for
both
sides
to
say
yeah
could
totally
be
a
part
of
it
could
also
make
you
know
an
equal
argument,
saying
that
who
has
the
ability
to
make
the
decisions
or
changes
within
that,
and
it's
probably
not
necessarily
the
platform
game,
but
maybe
it's
you
know
operations
or
something.
So
I
I
just
kind
of
I.
I
left
it
out
of
mind
I'm
for
that
reason,
but
I
couldn't.
E
B
I
think
it's
also
worthwhile
to
to
make
the
distinction
between,
obviously
some
of
it's
going
to
be
like
the
hardening
of
your
software
factory
and
all
the
things
that
are
sort
of
all
the
components
of
that.
Like
your
build
systems,
your
ci
cd
and
whatnot,
and
the
hardening
of
the
os
and
separate
from
you
know,
building
of
a
an
end
user
sort
of
application.
B
C
I
I
wonder
if
we
would
say
that
we
are
forced
to
trust
a
couple
of
vendors.
One
is
the
infrastructure
provider
or
cloud
provider.
Another
is
probably
the
vendor
that
ships
the
operator
or
the
linux
distribution
that
we're
using
under
the
hood,
and
so
we
say
that
we
trust
those
not
to
be
compromised,
but
then
another
vendor
who
might
be
shipping
us
binaries,
and
it's
just
that
one,
my
magic
binary.
That
does
everything
kind
of
thing.
C
A
A
A
K
I
I
I
I
A
J
C
C
A
A
A
E
A
A
A
F
The
only
thing
I
would
say
here,
john
on
this
is
along
the
lines
of
like
this
should
be
you
know
in
the
abstract.
It
should
be
the
very
first
thing
somebody
sees
when
they
get
into
the
paper
right
like
if
I
don't
know
in
the
first
that
first
paragraph
what
this
is
going
to
do
for
me,
I'm
going
to
click
x
on
the
the
win,
the
tab,
so
I
the
I,
if
we're
already
putting
it
there,
I
would
say,
let's
hope,
not
to
repeat
ourselves.
A
F
I'm
sorry
right
a
section
that
that
that's
going
to
say
what
you're
supposed
to
get
out
of
reading
this
paper.
I
would
expect
that
to
be.
You
know
the
very
first
thing
that
you
see
when
you
open
the
paper,
one
of
the
first
probably
two
paragraphs
it
would
be
in
an
abstract
if
this
was
like
a
scientific
paper
right.
G
F
J
F
I
L
A
E
J
So
I
think
these
terms
under
software
sources
are
all
good.
I
would
it
doesn't
strike
me,
though,
that
we've
really
used
them
very
much
throughout
the
paper.
So
I
wonder
if
that's
something
that
we
should
go
back
through
with
an
eye
towards
sort
of
having
a
common
vocabulary
that
we're
using
throughout
the
rest
of
the
paper,
if
we're
defining
these
terms
up
at
the
top.
A
I
They
kind
of
also
align
a
little
bit
with
like
a
bit
of
a
persona
in
a
glossary.
Do
you
want
to
also
define
that?
Because
we
don't
have
things
like
admin
or
platform,
admins
or
stuff
like
that?
That
might
be
able
to
be
used
within
the
like
for
ownership
and
responsibilities
within
the
different
phases
of
the
life
cycle?
I
I
I
So
if
you
want
to
tag
me,
I
can
put
the
ones
that
we
typically
use
on
our
side.
It's
it's
abstracted,
so
it's
not
specific
to
any
vendor
of
any
type.
It's
just
it's
more
just
interesting,
but
I
can
throw
in
a
few
of
them.
You've
got
a
couple
already
for,
like
the
raw
source,
like
you've
got
a
couple
areas
in
there.
So
I'm
more
than
happy
to
take
that
on
awesome.
Thanks
blink.
B
K
A
A
A
A
A
A
A
A
A
A
I
I
J
A
A
H
E
E
K
A
A
L
So
just
a
small
comment
on
the
secure
authentication
part
under
general
guidance
right.
I
I
just
need
to
in
the
secure
authentication
section
I
want
that
we
put
multi-factor
auth
first
and
when,
when
we
generally
talk
about
public
key
infrastructure,
generally
people
tend
to
move
towards
certificates
right
and
not
ssh
keys.
L
So
so,
let's
just
put
it
like:
okay,
multi-factor,
authentication,
a
and
then
b
should
be
like
okay,
well,
ssh
keys
and
that's
c.
We
then
discussed.
I
don't
know
this
big,
explicit,
limiting
of
an
authentication
mechanism
to
particular
activities
through
app
passwords
or
personal
access
tokens.
I
think
we
just
need
to
kind
of
give
examples
here:
okay,
like
establish
multi-factor,
authentication,
bssh,
key
c
personal
access,
tokens
or
application
app
passwords.
L
No,
no,
it
doesn't,
it
doesn't
fall
under
multifactors.
Multifactor
has
a
very
different
definition
and
you
have
to
basically
these
fall
into
only
one
category.
Okay,
when
you
explain
multi-factor,
there
are
different
factors.
Like
I
mean
you
can
give
thumb
print
and
there
is
a
particular
definition
for
multi-factor
it.
They
all
doesn't
fall
into
that
right.
So
yeah.
K
I
I
tend
to
agree
with
with
reina
there
like,
I
think
like
they.
They
are
multiple
factors
and-
and
I
agree
like
if
we,
if
we
want
to
like,
be
strict
to
the
word-
I
think
I
can't
remember
it
on
top
of
my
head
right
now,
but
it's
like
multifactor
is
like
a
who
you
are
what
you
know
where
what
you
are
like.
I
There's
there's
a
that
definition
right,
so
we
can
probably
get
a
little
more
pedantic
about
it,
but
I
do
I
do
agree
that
those
are
one
of
the
components
of
a
multi-factor
so
and
also
aren't
we
explaining
that
further
down
somewhere.
So
we
don't
have
to
like
this.
This
section
right
here
doesn't
have
to
be
highly
specific.
It
can
be.
You
will
be
reading
about
this,
so
we
don't
have
to
at
this
moment.
We
don't
have
to
define
it
yet.
L
Yeah,
so
let's
make
it
generic
then
right,
but
but,
as
I
said,
it's
fine
but
multifa
this
all
these
examples
that
we
have.
It
is
only
one
factor
of
multi-factor.
Okay.
This
is
technically
the
how
the
things
is.
So
if
we
we
are
mentioning
this
thing
at
the
other
sections
like
securing
source
code
so
yeah
we
can
keep
it
generic
and
we
just
don't
give
examples
here
right,
but
but
yeah
there
are
few
terms
which
are
used
which
have
particular
meaning
in
the
security
community.
A
Yeah,
I
I
think
when
we
go
through
and
do
like
another
sweep,
we
want
to
make
sure
that
any
of
those
terms
we
we
do
refer
to
are
accurate
and
then
perhaps
add
that,
as
the
glossary
to
the
end
to
make
sure
we're
keeping
ourselves
hold
ourselves
to
account
yeah,
okay,
so
moving
down
below
the
general
guidance
as
mr
martin
and
I
clash
on
updates
and
and
ours.
Secondly,
those
are
they
and
what
happened
there.
B
J
Yeah,
so
I
just
from
the
perspective
of
how
we're
laying
out
the
paper
do
we
want
those
to
be
treated
in
two
separate
sections.
We
have
a
section
on
you
know
on
the
attestation
and
then
a
separate
section
on
verification,
or
do
we
want
to
kind
of
merge
those
together
under
the
same
heading
is
what
I'm
asking
there
and
you
know
at
the
sort
of
like
heading
one
level.
I
guess
in
terms
of
our
our
major
sections.
A
F
Can
I
make
one
comment
about
this:
this
block
of
text
right
here
we're
essentially
reiterating
the
heading
titles
that
are
on
the
left.
If
you
have
the
the
google
docs
windows,
I
know
we
have
an
anti-checklist
block
amongst
us,
but
I
I
think
that
maybe
it
would
be
pretty
straightforward
to
take
the
heading
titles
and
then
the
definition
because
reading
through
that
that
comma,
the
list
of
of
the
sections
here,
I'm
like
reading
definitions
and
I'm
just
sitting
here
going
like
it,
looks
like
a
really
long
run
on
right.
F
I'll,
be
honest.
So
if
we
break
it
up
into
that
here,
this-
the
header,
the
section
titles
that
you
can
see
when
you,
when
you
go
to
the
abstract
or
whatever
the
table
of
contents,
is
going
to
look
like
for
this,
and
this
is
what
they
mean,
which
is,
I
think,
what
somebody
did
here.
They
extrapolated
out.
They,
they
mapped
from
the
heading
title
to
a
definition
of
that,
or
at
least
an
explanation.
It
might
just
be
cleaner
and
I
can
do
that
recommendation.
L
Yep,
so
so,
on
the
slack
channel,
there
were
two
points
that
I
still
have
to
edit
I
mean
there
was
a
consensus
reached.
I
think
we
all
discussed
our
points.
So
those
two
aspects
I
do
have
to
change.
I
couldn't
change
it
last
week.
I'm
sorry
about
that.
It's
just
I
got
busy
in
something
else,
but
I'll
make
those
changes
right.
Those
two
aspects,
one
was
related
to
define
a
list
of
allowed
files
right
this
recommendation,
so
we
need
to
kind
of
I
mean
we.
L
We
have
different
opinion
here
on
the
group.
So
so
right
now
my
point
of
view
is
we
keep
this
thing
and
we'll
just
try
to
make
it
more
smoother
or
softer
right.
So
I
I
have
to
think
about
the
con
content.
What
to
put
here
right,
but
yeah.
These
one
thing
that
I
do
like
here
is
that
we
have
a
lot
of
recommendations
and-
and
this
is
something
that
I
do
want
to
keep
explicitly.
I
do
not
want
to
write
paragraphs
we
I
just
want.
L
If
somebody
wants
to
secure
source
code,
they
they
go
into
this
page
and
they
say
okay,
these
are
the
recommendations
and
they
are
out
of
it
right
and
similar
should
be
the
pattern
for
other
sections
if
we
are
doing
image
hardening.
Somebody
goes
to
that
section.
Reads
the
recommendation
and
then
go
out
right,
because
the
paper
will
be
long.
No,
I
don't
think
super
people
are
going
to
read
a
lot
so
yeah.
A
A
You
know
almost
if
we
have
like
a
we're
loading
up
on
summary
sections,
but
maybe,
like
literally
the
summary
section
that
lists
all
the
actual
recommendations
or
a
checklist.
I
think
the
owasp
sbcs
standard
is
written
in
that
sort
of
way.
So
it's
easy
to
pick
up
and
just
get
a
general
idea
of
what
people
are
looking
at
doing.
L
I
I
A
J
Yeah
there
was
some
talk,
I
think,
of
doing
something
like
that
of
creating
just
sort
of
a
you
know
not
to
use
the
word
checklist,
but
something
that
resembled
a
checklist
in
the
in
the
executive
summary
and
or
I
guess
it
could
also
be
an
appendix.
There
was
some
talk
of
that
on
slack
just
to
throw
that
out.
L
Yeah,
I'm
in
favor
of
that
blog
thing
right
eventually,
when
the
paper
comes
out
or
even
before
that
we
can
write
a
blog
on
each
of
the
big
sections
and
we
can
then
really
have
a
very
short
blog
and
in
which
we
iterate
the
context.
These
are
our
recommendations
for
more
detail,
go
to
the
white
paper,
best
practices
and
stuff
like
that,
but
but
yeah
I
I'm
I'm
not
attached
to
anything
whatever
the
group
decides.
L
A
A
A
L
A
That's
part
of
it
we're
trying
to
add
at
the
bottom,
I
think
for
sale
all
right.
I
appreciate
we're
sort
of
at
the
end
of
our
our
time
there.
I
think
we've
got
through
a
fair
chunk
to
be
fair,
it's
only
about
a
third
of
the
paper,
but
I
know
that
we're
multiple
people
are
gonna,
go
through
it
over
the
next
couple
of
days.
I'm
gonna
have
another
go
tonight.
A
H
L
Okay,
just
a
small
comment,
so
so
I'm
also
start
going
to
review
the
paper.
There
are
a
couple
of
comments
in
the
bottom
of
the
section
where
technically
some
things
we
are
referring
to,
they
are
not.
They
are
not
correct.
Like
somebody
referred
like
long-lived
certificates.
This
is
this
is
not
a
thing
of
today.
Today,
people
are
moving
towards
short-lived
certificates.
L
There
is
crypto
policies
around
it
right,
so
we
cannot
recommend
long-lived
certificates,
okay,
that
that
cannot
that
shouldn't
happen,
okay,
yeah,
so
so
I
will
point
those
things
out
in
the
paper,
because
there
are
a
couple
of
technical
aspects
which
which
we
should
completely
avoid
right.
That's
not
the
way
how
things
are
so.
A
Yeah
I
mean,
I
think,
any
of
any
other
sort
of
commentaries
or
or
things
we
need
to
discuss.
I
think
I
think,
there's
a
group,
maybe
if
we
use
the
slack
channel
a
lot
more
over
the
next
week
or
so
any
of
the
issues
that
you
know
are
a
little
bit
sticky
and
it's
probably
one
for
comment
and
and
feedback,
maybe
raise
that
in
the
slack
and
yeah.
A
I
think
I'm
just
going
to
go
top
to
bottom
and
then
do
all
of
the
all
the
appropriate
edits
and
I'll
post
something
in
the
chat
that
yep
I've
had
to
go
and
over
to
someone
else,
sort
of
thing,
any
other
bits
of
logistics.
We
need
to
cover,
because
I
think
a
couple
of
people
are
going
to
be
going
through
it
over
the
next
couple
of
days.