►
From YouTube: CNCF SIG Security Supply Chain WG 2021 02 26
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
D
D
Make
it
so,
I
think,
emily
and
anders
you
you
guys
were
driving
us
pretty
nicely
the
the
last
meeting.
We
actually
got
a
lot
of
stuff
done
and
went
nicely
through
that
document.
I
was
going
to
reach
out
and
ask
her
to
do
the
same
again,
but
should
we
go
and
take
a
look
at
that
document,
see
how
we're
getting
on
and
share
it
together.
A
So
john,
just
yeah,
can
you
guys
hear
me?
Yes,
yeah
yeah,
yeah
sure
so
just
a
request.
I
actually
have
to
pick
up
my
son
in
20
20
minutes,
so
I
just
wanted
to
go
through
my
section
quickly.
Just
give
everybody
highlight
and
then
later
I
can
I
mean
then
later
you
guys
can
discuss
and
I'll
kind
of
review,
but
I
just
wanted
to
put
my
point
across
because
I'll
I
I'll
have
to
leave
in
20
minutes.
So
I
mean,
if
possible,.
A
D
A
Can
you
guys
see
the
document
yeah?
Okay,
so
so
couple
of
points?
I
do
want
to
emphasize
that
this
week
my
focus
was
more
around
adding
content.
Okay
and
right
now
things
might
seem
here
or
there
right.
I
mean
every
paragraph
is
different
from
the
previous
one.
So
eventually
the
focus
this
week
was
that
I'll,
add
content
more
today.
A
Sorry,
if
this
week
and
then
next
week,
we
can
kind
of
try
to
smooth
out
things
or
try
to
remove
or
add
things
right,
but
I
think
having
content
was
the
I
mean
first,
we
need
to
have
content
right
before
we
can
go
through
all
the
phases
right,
so
so
in
securing
source
code
section.
What
I
have
done
is
that
I
have
started
to
add
content
to
it.
A
Okay
and
you'll
see
a
lot
of
content
in
the
under
this
section,
but
there
are
three
main
points
that
I'm
trying
to
emphasize
right
within
this
section,
I'm
only
focusing
on
how
to
secure
the
source
code.
That's
it
right.
I
mean
we
are
not
addressing
any
operational
issues.
We
are
not
addressing
what
are
the
different
things
around
supply
chain
attacks
or
we
can?
How
we
can
make
things
better
right,
but
this
section
is
purely
focused
on
one
agenda,
and
that
is
how
to
secure
a
source
code
right.
A
That
is
the
question
that
we
are
trying
to
answer
here
right.
What
are
the
recommendations
around
it
right?
There
are
three
categories
to
it:
okay,
that
I
have
identified
that
we
should
focus
on.
There
might
be
more
so
please
everybody
should
take
this
opportunity
to
add
more
ideas
around
it
that
if
I'm
missing
some
category
but
the
first
category
that
I'm
trying
to
identify
my
recommendations
are
around
identity
and
access
manager,
management
for
the
source
code,
repository
right
source
code
needs
to
be
somewhere.
Okay.
So
what
are
the?
How
we
can?
A
A
So
the
first
thing
is
identity
and
access
management,
and
the
second
thing
is:
what
are
the
different
configura
contribution
policies
that
can
be
set
up
by
by
any
administrator
or
any
enterprise
to
to
kind
of
secure
the
repository
right
and
again,
this
is
to
help
the
secure
the
source
code
only
okay
and
the
third
thing
is
how
to
establish
non-repediation
and
integrity
at
the
source
code
level.
Okay.
So
these
are
the
three
sections
that
I'm
trying
to
categorize
information
in.
If
you
find
later
on
that
there
is
any
other
section.
A
Please
add
to
it
and
just
add
few
comments
around
it.
Then
then
we
can
take,
take
it
beyond
right.
So
then
each
section
starts
identity
and
access
management.
Richard
has
added
a
lot
of
information
here.
Okay,
so
thanks
richard
right
again
in
recommendation,
then
we
are
going
for
recommendations
right
now
right
for
each
of
these
sections
that
we
have
described.
Okay.
What
are
our
recommendations?
A
Okay,
so
in
the
justification
section,
we
are
trying
to
add
some
information
background
to
it.
Why
mfa
is
needed.
This
is
just
an
example
right
we
can
shorten
it.
We
can.
I
mean
it
depends
eventually
when
we
will
refine
or
sweep
the
whole
code
what
we
do,
but
with
each
section.
What
we'll
try
to
do
is
that
we'll
add
recommendations
around
it?
Okay,
that
what
are
our
recommendations
for
each
of
these
subsections
right
and
they
can
be
different
right,
mfa,
ssh,
keys,
okay,
how
to
rotate
ssh
keys
should
be
rotated.
A
B
These
are
general
iem
recommendations.
They
could
apply
to
every
single
part
of
the
system.
Every
system
that's
going
to
be
part
of
these,
these
steps.
So
my
my
question
for
the
overall
purpose
of
the
paper.
You
know
when
I
I
wrote
it.
I
was
really
focused
at
contributing
source
code
to
a
a
source
code
hosting
platform
and,
like
I
know
that
all
the
like
enabling
mfa,
you
know
we
know
that.
That's
something
you
need
to
have
mfa
as
well
on
any
of
these
systems
on
your
on.
You
know,
logging
into
jenkins.
B
You
know,
whatever
whatever
is
going
to
be
doing
your
build
any
of
your
security
software
like
testing
tools,
all
those
are
going
to
probably
also
need
that
same
sentence.
So
the
question
I
had
was:
are
we
going
to
copy
all
of
these
recommendations
across
the
paper
or
are
we
going
to
have
you
know
it?
That's
the
part
where
I
was
like
why.
A
A
A
Mfa
is
a
thing
that
you
can
say
is
general
in
nature,
but
underneath
other
recommendations,
if
you
see
around
these,
are
specific
to
source
code
repositories,
I
mean
there
are-
I
mean,
for
example,
you
say
how
to
access
amazon
right
or
aws
services
right,
they
will
have
their
own
recommendations
right,
how
to
store
your
im
credentials
and
things
are
around
it
right.
But
the
recommendation
that
I
am
giving
here
they
are
more
specific
to
how
to
manage
iam
around
source
code
repositories
or
you
can
call
it
a
hosting
platform
or
a
devops
platform.
A
Anything
we
will
we'll
come
back
to
the
terminology,
but
these
recommendations
are
specific
to
source
code
repositories,
personal
access
tokens-
and
these
things
I
mean
these
things
are
different:
okay
for
different
other
parts
of
the
system.
Okay,
so
I
do
not
think
so
that
you
will.
You
will
share
this
information
with
other
sections.
The
only
thing
that
can
be
shared
is
mfa
right
because
it's
generally
I
mean
in
general
right
now.
There
is
a
trend
right.
You
need
mfa
for
everything.
Right
I
mean
you
are
accessing
website
as
well.
A
You
need
mfa
right,
but
but
again
here
I'm
trying
to
emphasize
this
solar
wind
attack
that
happened
okay
and
where
this
thing
happened
right
because
there
was
a
credential
issue
there.
There
I
mean
just
read
through
this
section:
okay,
with
mfa,
we
may
want
to
sw.
We
may
want
to
place
this
section
somewhere
else,
but
if
you
look
at
all
other
recommendations,
they
have
to
be
here
because
they
are
more
directly
related
to
source
code
repositories.
They
are
not.
They
are
not
a
general
in
nature.
I
mean
you
know.
C
C
It
becomes
more
more
targeted
and
more
implementation
is
specific
to
how
it
pertains
to
that
particular
area,
and
at
that
point
it
would
be
easier
like
hey
here,
is
how
we're
applying
this
overarching
principle
in
this
particular
section
richard.
Is
that
what
you're,
thinking
or
you'd
like
structure.
B
I
I
just
I
the
thing
I
worry
about
is
us
writing
the
same
sections
over
and
over
again.
That's
that's
kind
of
my
my
key
thing
here.
When
I
think
about
this
section,
I
think
about
it,
I'm
starting
an
open
source
project.
I
want
to
know
what
cncf
thinks
is
the
most
secure
way
of
communicating
with
github.
E
B
F
E
Mean
I've
worked.
That's
my
current
job.
We
also
from
an
operational
perspective,
has
fewer
protocols
there's
no
ssh.
I
only
have
https
ingress
into
my
environment
right,
so
there
actually
are
a
number
of
reasons
to
pick
one
over
the
other.
Those
aren't
these
answers.
That's
not
for
this.
That's
an
operations
answer
but
yeah.
I
didn't
yeah,
so
this
yeah
as
written
I,
I
know
everything's
in
progress
document,
but
yeah
yeah.
A
Okay,
so
so,
personally
again,
this
is
what
I
added
this
morning
as
well
right.
So
so,
in
my
view
as
well,
both
are
the
option,
and
this
is
how
I'm
trying
to
put
it
here
in
the
document
as
well.
Ssh
is
an
option.
Okay,
and
there
are
issues
around
it
right
I
mean
it
is
secure
because
it
also
creates
an
encrypted
channel.
I
mean
you
can
see
in
this
section
what
I
have
written
right,
but
if
you
can,
you
should
go
for
personal
access,
token
right
but
personal
access.
A
Token
again
they
are
more
oriented
toward
build
agents,
cicd
pipeline
agents,
and
things
like
that.
So
that's
why
I
have
put
this
comment
and
read
that
you
need
to
more
focus
on
when
we
describe
this
thing,
that
okay
for
build
agents
right
now,
let's
recommend
this
thing:
okay,
but
for
use
developers,
let's
try
to
focus
on
ssh
keys
somewhere
right,
so
the
description
is
there,
but
in
general
I
agree
overall,
that
if
you
have
personal
access
token,
they
should
be
preferred,
and
I
I
miss
I
mean
I
I
cannot
read.
A
Because,
from
operational
point
of
view
right,
I
I
know
what
you're
trying
to
get
at
right,
and
this
is
what
what
is
my
experience
too,
that
that
https
network
security
teams
will
say:
okay,
https,
good,
ssh,
okay,
let
me
review
the
system.
Okay,
so
again,
add
comments.
I'll,
add
more
things
to
it,
but
I
will
add.
I
will
recommend
both
the
things
we
shouldn't
remove
any
of
them.
Okay,
because
because
there
are
scenarios
where
ssh
keys
will
be
preferred
by
open
source
community,
it
is.
E
Yeah,
it's
not
going
to
go
away,
but
I'm
not
sure
if
I
might
strengthen
a
statement
of
one's
preferred
over
the
other.
I
mean
there
are
other
weaknesses
of
ssh.
You
have
rng
problems.
Protocol
like
crypto
gets
old
over
time,
like
those
concerns
are
not
present
with
a
token,
because,
typically,
a
token
can
be
manually
expired
in
compromise
or
can
typically
has
a
one
year
expiration
or
you
pick
a
time
frame
when
you
issue
it.
A
B
Yeah
like
just
because
I'm
I'm
quite,
I
just
want
to
make
sure
that
there's
no
confusion
when
we're
talking
about
using
personalized
developers
for
a
developer,
for
literally
as
as
my
I'm
not
going
to
have
an
ssh
like,
I
will
not
configure
my
hosting
platform
I've.
If
you
were
starting
a
an
open
source
project
today
and
you
wanted
to
be
as
secure
as
possible,
you
would
require
your
developers
to
use
personal
access
tokens
rather
than
the
sss.
B
E
F
B
E
G
A
G
E
E
B
C
Keep
going
should
one
of
you
put
in
there
that
this
is
for
developers
and
make
the
distinction
between
the
machine
yeah
richard
sounds
like
there's
already
enough
for
perhaps
you
to
start
putting
principles
in
the
executive
summit.
Maybe
the
is
the
executive
summary
of
here
the
high
level
things
you
should
be
doing
across
end
to
end,
and
these
things
may
may
be
realized
differently,
depending
on
the
place
where
you,
where
you
do
it,
I
did
change
the
face
or
change.
The
pat
is
should
be
preferred
to
is
preferred
now
that
we
have
the
content.
A
Yep
yeah
so
yeah
again,
please
go
through
this
document.
Okay,
I
have
couple
of
minutes.
I
just
want
to
go
through
the
whole
section.
I
know
that
there
can
be
a
heated
debate
right
on
these
things
right,
but
overall
I
have
added
all
the
content.
Okay
and
I
because
I
also
use
personal
access
tokens
to
manage
my
infrastructure.
Okay,
so
I
do
know
about
them
and
that's
why
I
have
added
all
these
comments
here.
If
you
have
anything
additional
go
for
it
add
content,
let
me
know
what
you
think
about
it.
A
Okay,
but
again
I
just
want
to
go
through
this
whole
section
quickly,
so
that
then
I
can
just
kind
of
drop,
and
then
I
give
it
to
you
guys
to
kind
of
discuss
right
again.
I
am
then
I
am.
We
need
to
articulate
this
topic
heading
well,
but
we
need
to
define
roles
right,
because
rules
can
help
us
to
define
permissions,
enforce
4i
principles
and
different
things.
So
all
these
recommendations
come
around
iam
right.
This
first
section
that
I
identified
then
in
the
next
section
as
well
in
terms
of
contribution
policies.
A
Again,
I
have
given
all
the
recommendations
that
I
think
should
be
there.
Like
branch
protections
require
signed
commits,
we
should
prevent
committing
secrets
to
the
source
code,
how
to
do
it
and
then
there
is
this
option
as
well
right-
and
this
is
the
only
section
I'm
confused
about-
should
it
be
here-
configure
security
and
vulnerability
analysis
features,
should
it
be
in
the
somewhere
else
or
in
this
section
of
contributes
configuring
contribution
policies
at
the
source
code
repository
level.
So
again
guys
just
go
through
this
section.
A
I
have
added
a
lot
of
content
here
I
mean,
if
you
have
more
recommendations.
Add
it
okay,
but
again,
please
keep
in
mind
I'm
trying
to
focus
on
the
security
aspect,
not
the
operational
aspect,
okay,
so
that
has
to
be
understood
and
then
in
the
end.
I
have
this
section
establishing
non-repudiation
and
integrity
at
the
source
code
level
right
and
there
are
two
ways
to
use:
do
it
gpg
and
s
mime?
Okay.
A
In
the
end,
we
will
recommend
gbg
keys
because
they
are
more
prevalent
okay
and
they
should
be
used
for
for
establishing
non-repudiation
and
integrity.
But
generally
there
are
two
options:
okay,
so
just
go
through
all
these
sections.
Okay,
I
have
added
my
comments
on
the
right
as
well.
There
were
few
questions.
A
What
is
the
thought
process
and
what
I'm
thinking
about
this
whole
section?
Okay,
how
to
present
it,
but
but
this
is
the
high
level
three
categories
that
I'm
thinking.
If
you
find
more
categories
right,
please
let
me
know,
but
in
my
view,
if
we
present
these
three
categories
and
recommendations
under
these
three
categories,
I
think
we
are
good,
at
least
on
securing
source
code.
Okay,
so.
C
A
I
don't
have
any
I
mean
I
haven't
thought
about
this
thing
or
to
be
honest
right
now.
My
my
point
was
that
okay,
these
three
things
need
to
be
established
and
then
I'm
generally
giving
recommendations.
I'm
not
I'm
not
saying
this.
One
takes
more
preference
right,
they
are
general
recommendations
and
we
can
take
a
different
approach.
It's
interest,
it's
interesting
kind,
kind
of
giving
more
priority,
but
right
now
I
haven't
thought
my
agenda
for
this
week
was
have
content,
and
now
we
can
all
dig
in
and
refine
it
and
yeah.
D
D
A
A
D
Yep,
no,
it's
great
thanks
for
the
the
detailed
content
on
that
one.
Thank
you!
So,
just
just
trying
to
get
back
to
the
top
of
that
document,
I
guess
or
look
at
what
additional
people
have
added
in.
Do
we
want
to
go
through
the
people
on
the
call
and
and
in
the
similar
way,
that
fazal
has
done
sort
of
highlight
the
area
or
the
section
that
you've
taken
on
and
give
a
quick
update.
D
But
you
know
you've
got
a
lot
of
people
in
the
call
right,
so
maybe
like
five
minutes
or
less
on
anything
that
you
want
to
bring
to
people's
attentions
for
a
bit
of
a
bit
of
feedback,
a
bit
of
area
that
you
need
help
on
a
bit
of
area
that
you're
not
quite
sure
about.
Should
we
go
through
that?
Maybe
if
you're
not.
D
I
I
I
I
J
I
I
B
I
I
I
So
yeah,
so
in
this
area
I
mainly
focus
on.
I
think
we
need
to
rephrase
that
title
also.
Maybe
I
think
the
software
artifact
will
be
produced
as
a
part
of
the
build
process
right.
So
I
was
just
focusing
on
how
the
s-bomb
itself
being
produced.
So
you
know
so
we
we
we
can
have
multiple
ways
to
generate
aspirin
right.
One
one
way
to
generate
is
during
the
build
process
using
the
build
information
from
build
or
package
management,
also
how
the
software
itself
is
produce,
so
we
can
generate
s-bomb
from
that
data.
I
The
other
data
is
a
software
composition.
Analysis
like
a
once.
You
have
a
software,
you
can
generate
also,
you
know
reverse
engineer
and
going
back
to
find
the
components
inside
the
software.
So
there
are
different
kind
of
tools
currently
available
in
the
market
like
it's.
Some
of
them
support
both
spds
and
cyclone
deals,
some
of
them
just
for
a
cyclone
or
just
for.
I
I
mean
I
put
the
one
right,
so
my
I
mean
with
my
testing
early
testing
and
the
trials.
I
find
that
you
know
the
build
process.
Tools
has
more
accuracy
because
you
know
they
can
find
actually
what
exactly
the
software
is
built
off
right
like
a
like
maven
tools
or
a
node
or
some
whatever
the
build
tool.
If
it
is
a
gradle
or
maven.
If
we
can
use
in
that
build
process,
we
can
have
more
accuracy
in
the
s-bomb
compared
to
the
reverse,
engineering
or
a
manual
process.
Right
so
manually
say
you
know.
I
So
I
I
want
to
ask:
do
we
need
to
give
some
example
or
do
we
need
to
give
some
more
detail
how
far
we
should
go
with
the
generation
of
s-bomb
right
like
or
is
it
just
high-level
information,
and
these
are
the
tools
available
often
so
I
just
put
open
source
tool
at
the
moment.
Moments
like
how
to
generate
best
problems,
yeah.
D
Well,
my
gut
feel
right
was,
if
there's
anything
open
source
already
out
there,
use
that
if
there's
anything
cncf
prioritize
that
and
at
least
provide
some
actual
guidance
on
you
know
which
of
those
tools
to
execute
and
if,
if
there's
a
gap
and
one
doesn't
exist
and
there's
not
a
decent
tool,
then
we
identify
there's
a
gap
and
we
take
it
as
something
that
we
might
want
to
come
back
to
and
actually
implement
the
solution.
Right,
maybe
that's
that's
an
option
to
take
on
that'd,
be
my
feel
for
that.
I
But
at
the
same
time
the
landscape
is,
you
know
we
need
to
consider
technology
landscape,
not
all
technology.
Like
I'm
saying,
go
language
there
are
so
many
other
programming
languages
right.
So
not
all
programming
language
may
have
a
on
plug-in
or
big
tools
to
generate
a
spoon
right.
So
there
are
other
challenges
in
general,
so
yeah.
H
H
You
know,
however,
that
that
tool
records
the
packages
that
it
used
during
the
build
process
that
needs
to
be
recorded
in
the
spdx
format,
all
right
so
there's
tools
that
don't
exist
and
are
going
to
need
to
be
built
to
do.
Some
of
these,
like,
let's
say,
add
up
right.
We
need
to
build
an
spx
for
an
ad.
I
don't
have
any
idea
how
to
do
that.
Nor
does
many
people
write,
but
I'm
sure
it
can
be
done
if
we
talk
about
that
in
a
high
level.
H
J
D
D
I
H
H
I
There
is
a
minimum,
you
know,
support
for
all
these
spdas
cyclone
and
s
feet
or
something
that
the
three
main
one.
But
you
know
they
have
minimum
mapping
right,
but
it's
not
a
full
mapping
for
all
these
standards,
but
there
are
tools
like
as
an
example,
os
dependency
track
which
consume
both
spds
and
cyclone
and
it
will
convert
so
you
can
in
theory,
you
know
you
can
import
to
one
format
and
generate
other
format
from
that
tool
also,
so
there
are
different
options.
H
I
I
Think
that
that's
more
that's
mostly
dictated
by
the
standard
itself
right,
so
that's
how
the
star,
spds
and
cyclones
varies.
They
have
their
own
minimum
required
data
in
the
spec
itself
right,
so
you
know,
I
think
in
our
case,
we
need
to
at
least
in
my
view,
like
we
need
to
at
least
identify
what
package,
except
what
version
is
that?
Where
is
that
originated
or
where
it's
a
source
code?
And
these
are
the
like
minimum
attributes
out
there
like
in
both
the
spirits
and
cyclone
dx
right?
I
D
I
D
I
D
H
D
H
H
So
that's
going
to
just
be
knocking
that
out.
If
someone
wants
to
take
some
of
that
or
help
with
some
of
that
would
really
appreciate
it,
you
can
just
assign
yourself
to
maybe
one
of
those
sub
sections,
otherwise
I
will
be
continuing
on
you
know.
One
thing
I
did
do
that
we
hadn't
talked
about
before
really
probably
deserves
some
discussion
is
defining
of
different
user
roles.
H
Right,
have
this
idea
of
segregating
responsibilities
of
the
software
factory
and
do
different
different
roles
with
checks
and
balances
between
those
roles
right,
so
you
have
like
a
policy
maintainers
right.
The
idea
is
that
the
policies
kind
of
decoupled
from
the
software
factory,
that
gives
you
the
constraints
on
what
users
can
and
can't.
F
H
H
Yeah,
you
know
they'll
define
either
the
pipeline
templates
like
in
in
idea
platform
one
and
some
are
back
rules
for
developers,
automation
around.
You
know
when
you,
when
you
instantiate
a
new
project.
What
what
permissions
does
that
project
have?
Where
does
that
project
get
deployed
to
right?
So
that's
all
policy
that
should
be
encoded.
Then
you
have
developers.
You
know
those
are
the
end
users
right,
so
you
should
have
depending
on
you
know
how
large
your
organization
is
right.
H
D
Go
ahead,
no,
it
was
just
that
that
that's
kind
of
my
thought
is
that
you
and
you
know
to
go
back
to
the
dod
right.
It's
all
the
cool
work,
that's
heading
into
the
iron
bank
and
leveraging
those
containers
in
the
middle
of
the
software
factory.
It's
it's
identifying.
We've
got
a
really
good
software
factory
implementation.
We're
talking
about,
but
it's
really
the
the
real
heart
of
the
matter
is
what
what
does
and
doesn't
go
into
those
containers
that
are
actually
created
and
how
they're
hardened
in
the
first
place.
D
H
D
No,
I'm
sorry,
I'm
talking
about
the
the
actual
hardened
containers
that
you're
going
to
string
together
with
in
that
software
factory
itself
right,
so
that
each
of
the
individual
tasks
you're
going
to
put
together
within
that
pipeline
right,
you
know
one's
going
to
have
building
everyone's
going
to
have
sas.
Then
it
one's
going
to
have
some.
D
H
Okay
right
right,
so
we
talk
about
the
steps
here
of
of
what
a
pipeline
is
and
all
the
steps
that
a
pipeline
needs
to
have
in
order
to
produce
a
hardened
container
right.
So
we
have,
you
know
functional
testing
and
testing
right,
so
we
know
that
it
works
and
it
matches
the
the
specification
and
I
think.
H
You
know
verification
right
here
right
that
that's
an
aspect
of
hardening
validation
of
the
build
process
right,
so
these
are
the
steps
that
go
into
a
process.
I
think
there
needs
to
be
some
sort
of
a
diagram
here
to
make
that
more
apparent
and
say
hey.
These
are
the
steps
that
go
into
it,
and
this
is
what
your
end
product
looks
like
it,
or
maybe
it
needs
to
have
like
a
different
introduction
or
a
title
or
something.
C
F
D
K
I
have
this
in
my
notes
somewhere
down
here,
so
the
big
things
I
think
that
I've
done
in
the
past
is
you
know
the
build
worker
should
be
single
use.
Why?
Well,
if
the
build
gets
compromised,
then
your
build
worker
is
fundamentally
compromised
at
that
point.
So
if
you're
not
constantly
sort
of
refreshing
your
build
worker,
whether
it's
like
a
container
or
vm,
or
something
else,
then
you're,
potentially
building
on
a
compromised
worker,
you
know
the
the
main
sort
of
principles
around.
K
It
are
sort
of
have
a
golden
image
that
should
ostensibly
only
keep
track.
Sorry,
it
should
only
include
the
the
tooling
that
is
needed
for
the
build
so
like
keep
that
image
as
as
minimal
as
possible,
so
if
you're
compiling
gcc
or
whatever
it
should
really
only
have
gcc
and
some
other
few
things
to
support
that
it
shouldn't
you
know
consist
of
like
it
should
you
shouldn't
have
a
build
worker
that
is
for
java,
plus
gcc,
plus
all
those
other
things.
It's
it's
way
too
much
attack
surface.
K
The
other
thing
that
I
think
is
big
is
you
know
the
build
environment,
so
that
sort
of
consists
of
the
dependencies
and
and
the
sources
that
you're
going
to
be
then
using
to
build
your
artifact,
and
so
the
the
big
thing
there
that
you
know
suggesting
is
that
build
environment
should
be
created
for
the
build
worker
so
as
much
as
possible
that
build
worker
should
be
more
or
less.
You
know
not
completely
necessarily
air-gapped,
but
it
should
be
air-gapped
in
the
sense
that
it
should
not
have
network
access.
K
It
should
be
using
stuff
like
shared
drives
as
our
shared
shared
storage
and
those
sorts
of
things
such
that
you
know
the
pipeline
will
be
creating
the
or
sorry
creating
the
build
environment
which
would
include
its
sources
and
dependencies
for
the
build
worker,
and
then
the
build
worker
just
knows
to
pick
up.
It's
a
build
environment
from
storage,
and
then
the
build
command
itself
should
also
be
passed
into
the
build
worker.
K
You
know,
if
it's
a
container,
you
imagine
it's
just
when
I
run
the
container,
I
tell
it:
hey
here's
the
command
and
the
command
should,
for
the
most
part,
just
consist
of
something
like
a
you
know.
Compile
this
thing
or
whatever
plus.
Usually
something
like
here
is
the
signature
of
the
build
environment
that
you
should
be
looking
at
and
you
know
validating,
and
then
the
output
should
be
an
artifact
which
is
get
which
gets
written
to
another
piece
of
shared
storage,
which
then
you
know
the
pipeline.
K
Orchestrator
would
then
pick
up
and
then
on
the
build
workers.
Behalf
upload
that
to
an
artifact
repository,
because
you
know
there's
just
too
much
going
on
in
the
you
know,
given
that
the
build
worker
right
is
running
potentially
arbitrary
code
in
building
the
artifact,
there's
way
too
much
stuff
going
on
to
give
it
sort
of
network
access.
Because
then
you
know,
if
you
say,
hey,
I'm
going
to
allow
this
to
push
artifacts.
K
K
E
E
K
Yeah
yeah
exactly
and
actually
one
of
the
things
along
those
lines
which
is
not
necessarily
captured
in
here,
because
I
don't
think
it
necessarily
is
part
of
this.
But
it's
something
that
I
do
think
needs
to
be
either
discussed
or
captured
somewhere
is
so
one
of
the
things
that
made
a
lot
of
this
sort
of
work.
K
For
me
in
the
past
is
by
building
sort
of
a
merkle
tree
of
the
dependencies
and
building
a
merkle
tree
of
also
the
signatures
of
in
you
know
the
things
that
you're
building,
which
has
allowed
us
to
sort
of
say,
hey.
If
your
artifact
essentially
self-describes
its
it's
tree
of
dependencies,
it
makes
it
much
easier
to
kind
of
say
well.
This
is
not
a
valid
signature,
because
that
signature
is
not
based
on
the
hash
of
the
other
stuff
that
creates
that
artifact
and
becomes
much
easier
to
know
like
oh
well.
K
I
know
that
this
you
know,
if
I'm,
if
I
built
all
of
its
dependencies,
there's
some
amount
of
signatures
for
each
of
those
dependencies
that
are
essentially
based
on
the
hashes
of
those
dependencies
and
then,
when
I'm
building
the
final
artifact.
Well,
the
final
artifact
is
essentially
it's
a
hash
based
on,
or
you
know,
it's
a
hash
which
consists
of
the
signature
of
the
final
artifact,
which
itself
is
also
based
on
the
you
know,
validating
the
hashes
of
all
the
previous
dependencies.
K
And
so
by
doing
that,
that
kind
of
allowed
us
to
sort
of
say
hey
when
when
securing
the
build
workers,
it
made
it
much
easier
to
sort
of,
say:
hey
the
build
worker
exported
something
that
doesn't
match
up
with
what
we
have
upstream,
because
it
has
to
be
based
on
the
the
hashes
of
the
dependencies
and
it's
giving
me
something
that
appears
to
not
match
up
and
that
made
it
easier
to
sort
of
catch.
Those
issues.
E
Exactly
what
you're
saying
I
think
entoto
actually
does
some
of
that.
I
believe
it
signs
its
inputs
and
signs
as
outputs.
It
signs
a
hash
of
all
of
its
input
files
individually
and
it
signs
a
hash
of
all
its
output
files
individually,
which
is
not
quite
a
miracle
chain
in
the
same
way.
But
if
you
post,
build
validate
all
those
chained
together,
you've
got
a
very
similar
validation.
E
K
Yeah
yeah
yeah,
so
I've
been
a
little
I've
been
a
few
years
out
of
that
whole
space.
So
I'm
a
little
unfamiliar
with
with
some
of
the
newer
tools
but
yeah
that
that
makes
sense,
and
then
so
I
mostly
sort
of
focused
on
to
go
back
to
sort
of
the
build
worker.
Real
quick,
mostly
focused
on
the
build
worker
stuff,
mostly
trying
to
provide
guidance
around
you
know,
for
example,
try
and
remove
anything
that
is
really
not
related
to
the
build
from
the
build
worker.
K
So
you
know,
if
you
don't
need
vim
on
the
build
worker,
don't
include
vim
in
the
golden
image.
You
know
the
as
much
as
possible
is
the
build
workers.
Dependencies
should
be
given
to
it
as
opposed
to
having
the
build
worker
pull
in
its
dependencies,
because
it's
much
easier
to
kind
of
have
a
something
like
a
pipeline
orchestrator
that
its
only
responsibility
is
just
to
sort
of
move
the
pieces
around
to
have
that
push.
K
You
know
the
build
environment
to
the
build
worker
and
then
the
same
way
that
the
output
of
the
build
worker
can
then
be
pulled
by
the
pipeline
orchestrator
push
to
whatever,
and
then
you
know
the
pipeline
orchestrator
will
take
all
that
data
and
do
whatever
it
needs
to
do
with
it.
There's
a
bunch
of
other
pieces.
Oh
sorry,
so.
L
I
Clarify
that
when
you
mention
we'll
work
right,
so
I
think
most
of
build
tools
in
the
market.
Like
you
know,
even
you
know,
maven
gretel
or
you
know
what
are
the
tools
that
we
have
right?
Most
of
them
works
on
the
tool
model
right
when
they
need
to
build
a
software.
If
they
can't
find
in
cash,
they
pull
it
from
the
remote
trip
or
whatever
they
have
confidence.
D
Can
I
just
can
I
just
jump
in
a
second
we've
only
really
got
10
10
minutes
left.
Unfortunately,
I
just
wonder
if
we
want
to
take
this
one
as
a
bit
of
a
sidebar,
because
again
it's
huge
amount
of
good
content.
Right,
maybe
pick
this
up
on
slack
or
a
separate
conversation
just
keen
on
making
sure
we
get
get
a
few
minutes
with
everyone
else
on
the
call
there
are
others
that
are
others
that
have
been
able
to
contribute
that
haven't,
haven't
talked
so
far,
marina.
F
L
G
Oh,
I
was,
I
was
able
to
add
a
bet
to
the
distribution
mechanism,
so
I
I
basically
approached
it
in
the
sense
of
what
properties
we
want
any.
You
know.
Any
distribution
mechanism
must
have,
and
I
borrowed
pretty
heavily
from
the
properties
that
stuff
offers,
and
I
think
it
does
make
a
lot
of
sense
to
especially
for
the
cnc.
I
have
to
recommend
using
top
for
distribution
mechanisms.
D
G
But
I
I
think
I
could
use
some
help,
or
at
least
someone
to
discuss
a
couple
of
things
with
with
respect
to
handling
metadata.
Specifically,
especially,
I
think
there
was
some
discussion
about
handling
metadata
internally
yeah,
that
that
that's
a
scenario
I'm
not
very
familiar
with
so
I'd
like
to
go
over
that
I
can.
D
M
D
C
M
G
Thank
you
on
a
separate
one.
I
think
I,
over
the
next
few
days-
I'll
probably
be
kind
of
you
know,
jumping
in
on
a
couple
of
places
and
securing
the
pipeline,
which
goal
is
working
on,
and
I
haven't
taken
a
look
at
securing
the
build
yet.
But
but
I
am
curious
to
see
where
in
total
makes
sense
in
a
few
of
those
different
places,
so
I'll
probably
also
be
either
leaving
comments
or
making
suggestions,
cool.
F
Genuinely
I
protest
too
much
the
yeah.
My
contributions
are
yet
to
land.
I
have
everything
printed
out,
but
it's
been
so
much
activity
that
I'm
actually
only
halfway
through
and
gonna
start
again.
So
I
will
have
something
more
useful
for
next
week,
but
it
looks
awesome,
I'm
so
impressed
with
the
best
I've
read
through
so
far.
J
No
anyone
so
I've
added
a
few
things
around
signing
artifacts
and
thanks
to
to
michael
and
maria
for
that
commentary,
I
think
it'd
be
worth
having
some
help
around
validation
signatures
at
deployment
and
runtime.
I
think,
there's
a
bunch
of
different
components,
working
among
startups
such
as
toto
s,
bom,
artifact
distribution
or
signatures
gpg,
so
I
think
there's
some
affinities
with
some
of
the
previous
headings.
So
I
wonder
if
there's
someone
who
could
help
in
that
section.
D
M
H
E
M
D
M
E
D
N
C
D
Totally
fine
just
join
in
on
the
slack
channel
or
just
what
we're
doing
is
just
go
in
there
and
assign
it
a
section
to
yourself
and
jump
in
any
commentary.
Very
much
welcome
right,
okay,
cool,
so
a
huge
amount
of
progress
last
week
you
know,
I
think,
more
refinement
more
contributions.
Coming
in,
I
I
think
emily
was
suggesting
that
by
the
end
of
next
week
you
know
aiming
to
get
at
least
a
decent
run
through
the
document
ready
for
editing.
C
The
week
feels
a
little
bit
tight,
but
yeah,
so
you
know
I'm
happy
to
offer
pseudo
office
hours
same
time.
Slot
monday
wednesday
friday
for
people
want
to
jump
in
and
work
through
things
that
same,
if
you
rather
break
out,
I
feel
we
we
might
need
yet
another
week.
I
think
we
can.
We
can
push,
but
let's
see
well
should
start
taking
a
lot
of
shape.
D
D
F
F
D
What
I'm,
I
think,
so
what
I'm
trying
to
sort
of
suggest
is,
is
as
we
building
out
the
software
factory
right
and
we
define
what
the
opinionated
pipelines
are
going
to
be.
Maybe
you
have
one
for
a
java
image,
you're
going
to
build
a
java
project,
you're
going
to
build
or
go
project
or
whatever
within
that
pipeline.
I'd.
Imagine
that
you
select
a
number
of
different
steps
that
you're
going
to
put
within
each
one
of
each
one
of
those
pipelines,
so
you
would
assemble
those
different
steps
or
components.
D
H
D
Yeah.
Exactly
okay
yeah,
because
because
I
think
that's
really
really
important,
because
there's
quite
a
lot
of
of
detail
that
you
should
put
in
there
to
make
sure
that
people
aren't
just
pulling
stuff
straight
off
the
web
or
just
you
know
again,
building
something
off
the
laptop
and
then
using
that
as
the
sort
of
heart
of
the
really
super
secure
software
effect.
H
Yeah
yeah,
I
can
talk
about
hey,
you
know.
This
is
where
we
need
to
really
understand
the
ideas
of
reproducibility
and
you
know,
distributed
trust
along
these
networks
and
kind
of
evaluate
our
risk
of
our
of
our
build
materials
that
we're
bringing
in
that
we're
saying:
hey.
We
trust
these
well,
why
do
we
trust
them?
What's
our
risk
profile
and
how
do
we
evaluate
that
and.
D
Then,
ultimately,
getting
to
the
point
where
the
software
factory
itself
could
be
used
as
the
mechanism
to
build
those
images
and
secure
those
images
right.
So
you
kind
of
sort
of
get
itself
to
eat
itself.
But
you
know
you,
you
do
need
a
decent
level
of
control
when
you're
building
that
sort
of
stuff.
H
H
D
Absolutely,
and-
and
there
was
I've
been
thinking
also
about
the
you
know,
monitoring
those
individual
components
and
steps
right
and
the
way
I
look
at
it
when
you
get
to
you
know
not
all
of
those
steps
are
equally
important
or
maybe
they
are,
but
but
certainly
the
build
step
is,
is
pretty
damn
important
to
make
sure
that
no
one's
interfering
with
that
build
step
and
injecting
code.
In
that
you
you
weren't
expecting
and
such
or
I
guess
what
this
really
is
is
anything
that
actually
affects
the
end
result
other
than
sort
of
a
test.
D
D
The
way
I
was
going
was
there
was
a
really
good
presentation
about
tracy
the
ebpf
monitoring
tool
from
aqua
and
the
open
ssf
team
did
a
presentation
on
it.
I
was
thinking
you
know
some
interesting
sort
of
tooling.
You
could
maybe
bring
to
bear
on
that
build,
build
component
and
see
if
you
can
learn
from
what
what
it
usually
looks
like.
H
H
D
H
D
H
D
H
D
D
But
yeah
exactly
right
exactly,
and
it
got
me
thinking
as
well,
because
I'd
read
this
paper
from
the
acm
I'll,
send
it
to
you.
I
don't
recall
the
name
of
it,
but
it
was
basically
looking
at.
I
think
his
thoughts
on
the
forensic
output
from
a
malware
attack
or
something
it's
not
quite
that,
but
basically
they
were
saying
that
they'd
analyzed,
open
source
libraries
and
then
analyze
analyze.
D
The
components
after
it'd
been
infested
with
malware,
and
you
know
there
was
like
a
thousand
percent
difference
in
the
the
materials
post
exploitation
if
you
actually
did
a
deep
dive
into
into
the
the
actual
file
structure
which
which
makes
complete
sense
right,
but
but
that
sort
of
situation
is
a
monumental
signal.
So
if
we
have
that
sort
of
diagnostics
on
that
build
step,
that'd
be
pretty
handy,
and
I
think
what
was
the
example
that
they
were
using
the
other
night.
I
think
it
was
basically
looking
ebpf
and
anti-debug
or
something
like
that.
D
D
H
K
Yeah
one
of
the
things
I've
done
in
the
past
is
you
want
to
limit
the
capabilities
of
the
container
to
just
like
literally
the
bare
minimum,
which
is,
I
think,
goes
back
to
some
of
the
stuff
I
was
talking
about
before,
like
at
previous
spots.
We
just
literally
didn't
give
containers
the
network
capability
whatsoever,
and
so
it
just
you
know
the
thing
that
was
doing
the
actual
build
would
not
have
the
ability
to
sort
of
go
out
to
the
network
for
anything.
K
Even
if
there
was
something
else,
you
know
saying:
hey
yeah
go
out
or
whatever,
and
I
think
those
sorts
of
things
like
you
know
the
camera.
What
the
it's
some
of
this
called
in
there,
but
like
the
anonymized
users
inside
of
the
containers
and
and
ensuring
that
you
know
yeah,
the
capability
is
just
completely
separate
from
all
the
other
namespaces.
H
D
H
K
So
that's
why,
at
least
in
the
past
it's
been,
you
know
you
want
to
limit
that
blast
radius
where
you
say,
okay,
I
I
told
it
to
just
compile
this
one
thing:
that's
all
I
told
it
to
compile,
and
so
at
least
there
I
can
maybe
start
to
scan.
You
know
that's
where
I'm
going
to
focus
my
scan.
If
you
tell
it
oh,
I
wanted
to
compile
these
10
things.
Then
it's
10
things.
You
need
to
worry
about
that.
F
K
You
know
on
the
third
thing
it
compiled,
it
did
something
weird
and
so
and
then,
in
addition
to
that,
I
think
the
thing
that
we've
done
is
sort
of,
like
you
have
the
build
worker,
which
you
kind
of
limit
to
a
very,
very
small
sliver
of
thing.
And
then
you
have
a
bunch
of
these
other,
like
helpers
that
do
stuff
like
it
will
download
all
the
the
dependencies
and
the
sources
and
then
just
hand
it.
A
network
storage,
it
just
hand
it
shared
storage
and
say:
hey
build
worker.
K
Well,
the
only
thing
it
wrote
was
it
wrote
this
one
file
and
I'm
gonna
scan
that
file
and
you
know,
look
at
all
that
sort
of
stuff,
whereas
if
you
kind
of
give
the
bill
worker,
you
know
in
the
past
at
least
our
concern
was,
if
you
give
the
bill
worker
too
much
permission
to
like,
let's
say
push
to
the
artifact
repository
directly,
then
you
know
and
then
say:
okay,
well,
I'm
going
to
download
it
and
do
another
scan.
Well,
what
happens
if
you
know
whatever
that
artifact
did
like
it's
hard
to.
H
Yeah
and
we
need
to
set
up
that
build
but
let's
say
you're
you're,
maintaining
a
cncf
project
right
and
I'm
consuming
that
project.
As
a
you
know,
as
an
end
user,
I
need
to
be
able
to
verify
that
you
did
what
you
said:
you're
going
to
do
and
not
in
a
way
that
I'm
trusting
a
human
being
right
and
you
drop
trust,
some
sort
of
cryptographic
process
that
you
limited
the
c
groups
or
the
the
linux
capabilities.
H
D
H
D
Yeah
and
it's
not
just
the
actual
artifact
you're
building,
what
you're
saying
is
the
the
the
ecosystem
that
is
in
place
as
you're
building
it.
So
it
comes
along
with
like
the
artifact
and
the
the
the
metadata,
along
with
that
artifact
plus
the
metadata
from
the
pipeline
that
was
used
to
create
the
thing.
That's
quite
powerful
right.
K
Yeah,
so
I
was
reading
some
work,
there's
some
folks
in
japan
at
some
university
that
I
think
we're
doing
trying
to
do
this
sort
of
thing
through
zero
knowledge
proofs
of
hey.
Could
you
prove
that
a
particular
artifact
was
built
in
a
particular
way
it
seemed
like
it
was
very,
very
early
on
with,
like
you
know,
a
very
narrow
set
of
things
but
yeah.
K
I
agree
that
that's
kind
of
the
the
biggest
challenge
right,
because
even
if
you
sort
of
even
if
you
cryptographically
sign
hey
here,
is
my
container
manifest
right
who's
to
say
you
actually
use
that
container
manifest
in
the
output
and
in
the
past.
The
thing
that
we've
done
is
what
you
do.
Is
you
take
snapshots
of
all
the
build
workers
and
whatever
and
you
kind
of
go
back,
and
you
know
if
somebody
says
hey,
we
want
to
validate
this
thing.
You
go
back
and
you
scan
the
container.
F
Can
I
just
confirm
what
I
think
I'm
understand
for
what
I
think
I
understand,
which
is
when
we're
talking
about
injecting
all
the
dependencies
into
a
thing
into
a
build
worker
in
order
to
essentially
have
a
hermetic
build
in
order
to
do
that
with
a
container
based
system.
You'd
still
presumably
need
to
construct
the
container
beforehand,
and
it's
just
that
one
stage
of
say:
artifact
compilation,
but
but
actually
source
code
transformation.
I
guess
into
an
artifact
that
we're
talking
about.
K
The
actual
sort
of
build
would
have
access
to
one
is,
it
would
have
read-only
storage
of
the
inputs,
it
would
have
sort
of
a
working
storage
for
it
to
do
all
of
its
work
and
then
the
last
step
would
be
to
sort
of
take
that
and
copy
it
to
an
output,
storage
and,
and
so
and
then
it
would
hand
that
off
right.
It
would
just
say:
okay,
now
I'm
done
and
then
once
that
container
sort
of
was
you
know,
died
or
whatever
you
know
it.