►
From YouTube: CNCF Security TAG Supply Chain WG - 2021-07-08
Description
CNCF Security TAG Supply Chain WG - 2021-07-08
A
B
C
C
C
C
That
being
said
today,
I
I
think
you
know
emily
did
a
great
job
of
kind
of
just
cutting
everything
into
the
trello
board.
Have
you
all
been
able
to
see
the
the
trello
board
to
see
the
some
of
the
user
stories
and
that
aspect
that's
been
created
there?
I
don't
know
if
you
emily
want
to
provide
a
little
bit
more
context
there.
I
know
you
want
to
be
background
noise,
but
I
just
need
a
little
opener
there.
A
Of
course,
so
one
of
the
issues
that
we
had
within
the
project
within
the
cncf
security
project
is,
we
have
limitations
on
permission
sets
due
to
how
we're
set
up
as
a
security
tag.
So
what
we've
done
is
gone
ahead
and
created
a
trello
board.
It
provides
us
with
a
little
bit
more
flexibility
in
managing
this
project
and
allows
anybody
part
of
the
supply
team
working
group
to
be
able
to
be
more
active
contributors
to
the
content
and
kind
of
own
it
for
themselves
and
create
new
cards
new
issues.
A
All
of
that,
so
what
I've
done
is
I've
created
a
kanban
template
under
trello.
We
have
our
own
workspace
for
this
supply
chain
security,
reference
architecture
as
folks
join
the
board,
I'm
adding
them
in
as
workspace
admins.
So
I
don't
have
to
be
the
administrator
controlling
access
currently
we're
in
designs
of
the
design
column.
That's
extracted
all
of
the
user
stories
that
we've
worked
on
to
date
into
individual
cards.
They've
been
numbered
and
there's
a
new
task
list
or
a
checklist.
That's
been
started
for
them
within
that
checklist.
C
Project
and
props
to
michael
lieberman,
looks
like
you
took
taken
some
of
these
out
on
that.
So
that's
that's
awesome.
So
if
anybody
can
like
look
at
this
list,
if
there's
anything
that
that
comes
out
to
them
in
their
expertise
that
they
want
to
kind
of
tackle,
it's
right
there,
we'll
we'll,
we
kind
of.
I
think
we
what
we
say
emily
like
the
next
two
weeks,
I
think
we're
voting
on
is,
is
when
we
want
to
try
to
get
this
done
and
then
start
implementing
from
the
canva.
A
Yep
and
ideally,
if
we
don't
get
to
all
of
the
user
stories
that
have
enough
of
a
checklist,
that's
fine,
but
we
need
to
have
a
little
bit
more
context
for
determining
which
items
need
to
be
done
before
others.
That
way,
on
the
off
chance
that
we
forgot
to
enumerate
a
user
story
and
it
has
to
be
done
first,
we
can
go
ahead
and
spend
some
more
focus
time
on
that.
C
C
C
All
righty,
that
being
said,
I
you
know
I
kind
of
wanted
anyone
to
go
around
the
horn.
Has
anybody
had
any
kind
of
thoughts
after
the
last
time
and
ryan?
Thank
you
for
for
volunteering
like
in
terms
of
that
like,
if,
if
you
want
to
kind
of
tag
yourself
in
the
kanban
that'd,
be
awesome
ecstatic
to
have
you
involved
yeah.
C
Of
course
I
kind
of
want
to
kind
of
go
around
the
horn
and,
seeing
from
the
last
meeting
that
we
had
in
terms
of
you,
know,
nick's
and
basil,
we
talked
about
some
distroless
stuff
that
we
were
thinking
about.
Having
somebody
play
around
with.
Has
anybody
kind
of
had
any
thoughts
on
that?
If
maybe
that's
something
we
can
try
to
incorporate
in
this
ref
architecture,.
E
E
I
think
the
main
things
I
would
like
to
like
from
my
perspective
I
want
to
see,
is
compared
to
things
like
nyx
and
gwix,
and
some
of
the
other
sort
of
tools
that
are
out
there
that
can
do
the
deterministic
builds
with
packages
and
whatnot
I
want
to
see
you
know,
can
distrolus
do
the
same
thing
based
on
just
my
initial
research,
and
once
again
I
don't
like.
I
don't
want
to
say
I
I
completely
understand
everything.
That's
going
in
there.
E
B
Well,
I'm
not
like
super
familiar
with
this
dress,
but
I
could
definitely
find
out
more.
I
know
the
things
I
know
about
digitalis
right
now
is:
they
are
meant
to
be
like
minimal
base
images
that
you
can
then
build
your
build
whatever
you're
trying
to
do
on
top
of,
and
then
they're
reproducible
built
with
basil,
and,
I
think,
like
they
include
a
few
debian
packages
which
are
also
reproducible.
A
C
You're
putting
me
on
the
spot
here,
but
I
think
last
time
we
were
talking
about
it
was
more
of
I
mean
you
know
the
the
benefits
because
of
not
having
you
know
some
of
the
underlying
junk
that
we
normally
do
like
you
know,
even
with
like
things
like
alpine
or
something
like
this
there's
still
some
underlying
things
that
can
be
addressed
from
a
software
supply
chain
perspective
and
again
I
am
not
an
overall
expert
in
it,
but
I
just
know
that
that's
that's
where
I
think
folks
are
leaning
to.
I
don't
know.
E
E
Yeah
yeah
yeah,
so
I
do
have
some
background
in
this
I
mean
the
there's
a
couple
of
different
things.
It
gets
you
one
is:
if
you
have
it,
if
you
can
get
reproducible
container
builds,
it
does
allow
you
to
do
stuff,
like
you,
can
rebuild
that
container
across
multiple
build
infrastructure
and
be
able
to
say
hey
as
long
as
all
of
my
build
infrastructure
wasn't
compromised.
E
I
can
at
least
you
know,
determine
whether
or
not
a
particular
build
node.
You
know
if
it,
because
it
should
have
literally
the
same
hash
at
the
end,
the
same
checksum
and
so
same
input
should
always
create
same
outputs,
so
that
that's
one
big
thing.
The
other
big
thing
is
that
you
should
be
able
to
then
get
the
traceability
aspect
of
being
able
to
truly
determine
that
hey
these
inputs
led
to
these
outputs
and
we
can
kind
of
trace
back,
which
is
super
useful
from
a
you
know,
bill
of
materials
perspective.
E
You
could
always
go
back
and
know
exactly
what
version
of
a
piece
of
software
was
installed
on
a
container
and
then
some
of
the
other
things
from
the
sort
of
minimal
container
perspective-
and
this
is
kind
of
you
know
some
of
the
stuff
that
distro
list
nick
squix
can
do.
Is
you
know
the
literally?
The
only
thing
in
the
container
is,
maybe
just
you
know
two
binaries,
you
know
and
your
source
right.
E
A
So
I
want
to
just
verify,
because
I
heard
two
different
things,
and
this
has
an
impact
on
our
reference
architecture.
So
we're
talking
about
distro-less
images
as
part
of
the
build
infrastructure
to
reduce
the
likelihood
of
compromise
or
influence
within
the
reproducibility,
but
as
well
as
a
recommendation
for
organizations
that
are
looking
to
build
artifacts.
E
Yeah,
so
that's
actually
an
open
question
is,
is,
can
can
distrolus
be
used
to
just
also
build
the
artifact
itself
because
it
could
be
used
to
potentially
build
the
container
down
the
line
of
hey.
I
have
my
rust
or
go
binary
on
top
of
my
distro
list
container
and
that's
how
I'm
running
it,
but
it
would
also
be
useful
to
know
like
if
I'm
building
a
go
binary
right.
You
know
the
good
cicd
practice
is
to
build
the
binary
once
so.
C
C
You
know
I
just
don't
know
of
anybody,
then
we
can
understand
how
it
fits
in
our
reference
architecture
and
that's
what
like
again
like
I,
I
started
seeing
so
many
things
when
you
were
showing,
like
the
your
example
right
and
so
thoughts
on
how
we
can
kind
of
architect
stuff,
but
I
think
that's
what
the
group
needs
is
for
us
to
kind
of
see
that
I
just
don't
know
of
anybody.
Do
you
all
know
of
anybody
that
kind
of
isn't
has
an
expertise
in
this.
I'm.
B
F
If
I
can
speak
a
bit
from
from
my
experience
on
this
show-
as
I
I
felt,
this
release
in
the
reference
architecture
might
actually
fit
more
on
the
defensive
management
ford
deployable
rather
than
for
the
build.
Also,
some
of
the
distro
best
images
have
been
built
with
recipes
which
are
not
public,
some
of
the
old
ones
which
are
quite
hacky
right,
so
you
could
use
them
for
the
build,
but
somebody
would
need
to
certify
inside
their
company
that
this
particular
this
image
is
okay
for
to
build
their
things
around
this
topic.
F
F
C
Can
we
in
maybe
I'm
sorry
just
a
real
real
quick
thought?
Can
we
have
somebody
demonstrate
build
packs
in
the
in
the
way?
You
know
what
I
mean
like
how
michael
did
because
then
again
it
provides
us
this
contact.
Is
that
something
a
video
you
that's
something
you
would
do?
Do
you
think,
or
should
we
talk
to
somebody
else
or
like
I'm
just
trying
to
figure
out
how
like
who
would
be
a
somebody.
F
C
Right,
yeah
and
that's
something
if
you
have
it,
doesn't
have
to
be
you
creating
it's
just
you
demonstrating
it
for
the
group
on
how
it
works,
and
then
we
can
figure
that,
because,
if
that's
the
path,
we
go
for
the
for
the
architecture
or
we
go,
you
know
the
knicks
basil
or
we
go
to
the
distribution.
Just
I
think
again,
we
just
need
to
have
that
common
place
for
everybody
to
see.
What's
going
on,
so
we
can
figure
out.
Okay,
all
we
picked
this
and
here's
the
reasons
why
we
picked.
This
makes
sense.
F
Yes,
I
think
it's
important,
which
aspects
do
we
want
to
cover
from
this
perspective,
this
is
about
the
reproducibility
of
the
build.
Is
it
about
the
the
bill
of
material
which
one
of
the
tour,
the
certification
of
the
builder
images
right,
because
that
are
three
different
concerns
for
for
this,
like,
in
my
view,
to
consider
something
secure
for
a
builder.
C
Anyway,
and
that's
where
I
think
we
have
to
be
pretty,
you
know
we
have
to
just
basically
define
that
we
have
to
say
this
is
what
we
did
here
and
in
the
basically.
So
you
can
go
other
routes,
there's
other
tools
you
can
use
and
we
can
list
them
out
very
similar
to
the
you
know
the
dock
right.
We
don't
call
out,
you
know
specific
things
in
the
docs
we
write,
we
say:
here's
what
you
know,
we've
done
in
the
specific
reference
architecture.
C
A
C
B
I
just
want
to
add
right.
I
think
I
agree
with
emily's
opinion
like
maybe
we
need
to
give
multiple
options,
not
just
this
or
less.
I
think
we
need
to
think
practicality,
not
every
companies
are
using
golang
or
generating
or
native
binaries,
and
deploying
that
in
a
distorted
image.
Right
like
so,
you
know
there
are
companies
still
heavily
using
java
and
other
programming
languages.
B
F
In
this
topic,
I
think,
if
you
ingrain
about
the
reference
architecture,
how
fat
or
small
the
images
doesn't
matter
so
much
as
long
as
you
have
the
data
stations
and
the
machinery
of
the
framework
to
actually
say
that
something
has
happened
secure.
So
we
need
to
achieve
the
same
thing
with
ubuntu
as
we
would
achieve
this
device
for
for
deployable
to
production
in
the
end
right.
C
I
did
the
vulnerability.
I
helped
on
the
vulnerability
assessment
for
build
packs
and
I
know
there's
some
underlying
osos.
That's
being
used,
that's
being
deployed
as
kind
of
the
aspects
of
this
so
like
yeah,
I
mean
that
again.
If
we
have
the
juxtaposition
between
the
two,
where
there's
like
one
where
it's
somewhat,
if
you
use
the
term
fatter
like
os,
then
we
you
know,
we
need
to.
C
You
know,
think
think
in
terms
of
that,
because,
like
I
totally
agree
with
the
node
like,
we
need
to
do
this
in
such
a
way
that,
like
the
populace
out
there
majority
aren't,
you
know,
go
doing
all
ghost
stuff
they're
not
doing
all
like
you
know,
state
of
the
art.
We
need
something
that's
going
to
be
a
very
easily
adoptable.
I
think.
A
Well,
so
that
all
brings
up
a
really
good
point
about
container
bloat
and
how
we
handle
that
in
the
reference
architecture,
because
not
everybody
is
going
to
be
running
a
slimmed
down
single
purpose,
single
use
and
like
doing
it
over
and
over
again.
So
we
have
the
opportunity
to
be
opinionated
and
as
security
practitioners
like
recommending
you
slim
down
significantly
and
avoid
container
possible.
But
we
also
need
to
be
realistic
and
we
want
people
to
be
able
to
use
this
architecture.
A
C
F
C
A
Okay,
so
I
want
to
like
firm
that
up
a
little
bit
more
so
we're
looking
at
two
we're
gonna
have
both
unless,
like
something
befalls
us
that
build
packs
is
gonna
support.
The
80
percent
solution
for
potential
operators
and
then
dystrolis
is
really
for
the
innovators
and
folks
that
are
just
tinkering
and
playing
around.
Is
that
right?
Does
that
make
sense
for
everyone.
E
Well,
I
think
I
I'd
be
curious
to
know,
like
maybe
just
sort
of
defining
the
requirements
so
that
it's
like
very
clear
like
what.
What
are
the
requirements
of
a
a
container
build
solution
right
or
you
know
what
what
are
the?
What
is
the
you
know?
What
are
the
requirements
trying
to
get
out
of
it?
Are
we
trying
to
get
out
easy
s
bomb?
Are
we
trying
to
get
out?
You
know
minimal,
where
possible
those
sorts
of
like
defining
some
of
those
things,
because
then
I
think
we
can.
D
B
A
C
F
F
I
feel
that
the
language
is
not
necessarily
the
most
important
here
is
more
the
package
manager
for
each
of
those
right,
because
that
that's
really
there
are
some
key.
That's
huge
caveats.
You
say
java.
You
talk
about
three
or
four
package
manager.
We
have
totally
different
behavior,
definitely
pinning
reproducibility
and
many
everything
the
subject
is
quite
broad.
I
didn't
find
a
good
solution
for
neither
of
them
right.
So
what
we
can
actually
underline
is
state.
What
are
the
issues
with
each
one
of
them
right
for
python?
C
C
Well,
that's
my
exact
point
and
the
other
thing
is,
I
don't
think
in
a
reference
architecture.
We
should
tackle
every
damn
language,
or
else
we
will
be
here
until
next
year
and
we
will
have
no
reference
architecture
we'll
go
with
the
top
three
and
say:
look
you
all.
If
there's
anything
you'd
like
to
see,
maybe
in
the
future
we'll
do
a
v2
and
we'll
drop
the
mic
all.
C
E
I
I'm
curious,
though,
on
on
that,
do
we
want
to
push
for
things
that
help
take
care
of
some
of
those
things
like
like
basil,
right,
like
basil,
can
sort
of,
say,
hey,
look
behind
the
scenes
as
long
as
you
use
a
package
manager
that
we
support,
we
don't
necessarily
we'll
we'll.
You
know
we'll
work
with
it.
D
F
F
At
least
you
can
measure
if,
if
the
package,
manager
or
or
the
tool
you
use
for
build
in
that
case,
bezel
helps
you
to
make
your
life
easier
across
that
aspect.
Right
I
mean
I,
I
can
imagine
some
old
maven
projects
which
were
doing
everything
with
a
single
plugin
and
if
you
are
to
create
at
the
station
from
it,
you
wouldn't
know
what
happened
in
that
in
total
step
in
that
in
total,
that
happened
everything
right.
So
that's
not
a
good
approach
and
you
need
the
atomicity
of
the
build.
E
Yeah
yeah,
I
mean,
I
think,
the
the
two
things
that
that
are
regularly
talked
about
is,
if
you
can
prove
what
is
in
your
build
environment,
and
you
can
prove
the
reproducibility
of
your
build
environment
and
you're
using
something
like
bazel
which
provides
reproducible
builds.
Then
you
know
that
a
given
source
will
always
generate
the
same
miner.
E
D
E
That
that's
true,
but
using
like,
for
example,
if
you,
if
you're,
using
something
that
looks
like
build
packs
or
using
something
like
nyx,
you
get
that
sort
of
bill
of
materials
for
the
environment,
including
the
you
know,
exact
version.
So
even
if
those
versions
changed
and
you
didn't
pin
the
version,
you
know.
Oh
this
library,
somewhere
upstream,
like
glib
c,
which
you
know
is
used
by
this
tool
down
here,
was
updated,
which
led
to
this
other
one
being
downloaded,
which
led
to
all
these
other
things.
E
That's
why
you
now
have
a
different
hash,
and
you
know
that
maybe
is
okay
right,
but
you
can
at
least
trace
it
back.
It's
not
something!
That's
just
like
did
that
come
in
from
somewhere,
you
know
exactly
where
that
came
in
and
then
the
same
thing
goes
with
like
a
bazel
build
where,
if
your
source
updates
or
if
your
dependency,
you
know
the
java
dependency
updates,
it
will
tell
you,
oh
over
here
in
your
graph,
this
dependency
change,
which
led
to
all
these
other
things.
Changing
yeah.
D
But
do
we
need
to
get
a
point
of
view
that
you
need
to
have
this
dependencies
locked
or
freeze
before
build?
So
we
can
I
mean
one
way:
is
we
ensure
that
you
cannot
do
that
right?
You
need
to
have
the
freezing
all
the
dependencies
spinning
or
we
can
automate
those
and
the
other
way
is
you
build
it,
and
then
you
have
basically
traceability
to
find
out
why
the
bill
differs
across
the
time.
C
C
A
Speaking
out,
that
reminds
me
of
where
this
code
is
actually
going
to
live,
because
we
need
to
have
a
repo
set
up.
And
we
need
to
have
some
level
of
integrations
within
it
to
be
able
to
check
and
make
sure
that
our
folks,
not
that
anybody
would
do
this
or
not
committing
any
kind
of
secrets
or
credentials
and
that
we
are
having
a
scanner
or
some
sort
of
bot
check.
Any
dependencies
that
we're
checking
in
to
make
sure
that
they
are
secure
at
the
time
of
check-in
or
push.
A
I
don't
think
we
have
dependable
built-in
or
any
kind
of
secret
scanner-
it's
very
limited,
because
most
of
our
content
in
the
repo
is
markdown.
So
we
can
create
a
whole
separate
branch
and
we
can
look
at
adding
these
onto
that
branch.
But
I
just
want
to
like
put
that
out
there
that
these
are
all
things
that
we
need
to
be
thinking
about,
as
well
as
by
the
way
creating
this
reference
architecture.
Let's
set
up
the
repo
for
the
code
base
correctly.
C
A
It's
more
of
the
upkeep
after
the
fact,
and
as
well
as
the
initial
overhead
to
get
it
set
up.
We
can
certainly
look
to
the
cncfs
for
some
assistance
in
that
area,
or
we
could
try
to
tackle
it
ourselves.
We,
the
security
tag,
just
doesn't
have
any
code
within
its
repository
to
dates.
We've
never
had
a
need
of
setting
anything
like
that
up.
C
We
should
talk
to
the
person
that
did
the
the
linux
foundation
person,
who
did
the
the
demonstration
for
all
of
us
about
how
they
you
know,
they've
built
this.
This
this
system
would
be
nice
to
kind
of
have
his
feedback
on
this
and
help
us
here,
because
this
benefits
him
as
well
like
to
a
certain
degree.
So,
let's
pull
sidebar
on
that
one.
C
Definitely
great
call
we
are
charged
today,
everybody
drank
their
coffee
this
morning.
It's
beautiful,
we're
like
on
the
ball,
awesome
all
right.
What
else
do
we
have
everyone?
I
think
we
have
a
lot
of
marching
orders
here
to
be
honest
with
you
like
in
terms
of
what
we
have
to
do.
Let's
talk
about
like
next
steps.
C
Here
again,
I
don't
want
to
have
to
you
know,
go
through
all
this,
but
I
think
it
would
be
cool
to
have
on
the
next
meeting
some
of
the
build
pack
stuff
just
to
be
able
to
see
it,
I
think,
would
be
great.
I
think
we
should
go
definitely
more
in
depth
in
terms
of
the
the
targets
to
support-
and
you
know
I'll
probably
end
up
going
back
into
the
kanban
and
adding
some
of
these.
This
detail
in
any
other
kind
of
thoughts
here,
great
feedback.
E
I
know
we
we're
we've
sort
of
been
looking
at
a
couple
of
different
things,
with
tecton
and
tekton
chains
and
and
and
how
you
know
we're
doing
some
of
the
signatures,
and
I
know
he
had
to
drop
off,
but
tim
on
on
my
side
did
a
little
bit
of
investigation
recognize
that
a
lot
of
the
various
work
that's
been
going
on
is
very,
very,
very
bleeding
edge.
A
lot
of
this
stuff
is
in
branches.
A
lot
of
this
stuff
is
in
hasn't
been
pushed
back.
E
A
lot
of
the
stuff
is
still
sort
of
in
proposal
sort
of
mode.
I
think
it's
probably
also
worthwhile
to
sort
of
better
understand.
If
we,
you
know
some
of
the
tools
that
we
do
plan
on
using
what
work
might
need
to
be
done
against
these
open
source
projects
to
actually
get
them
to
have
the
feature
that
we
need
in
order
to
use
them.
C
Specifically
techcon,
if
I
can
just
go
out
there,
I
mean
you
know:
we
have
folks
impact
security
that
are
part
of
that
project,
right,
that
we
can
go
back
to
right
and
then
and
and
talk
through
to
get
some
of
that
stuff
going.
I
think
again,
it's
I
feel
like
it's
almost
like
life
in
the
fast
lane
we
got
to
like
we
got.
We
got
to
just
get
this
out
there.
I
think
and
say
this
is
what
we're
saying
as
a
ref
architecture.