►
From YouTube: SLSA bi weekly sync (August 25, 2021)
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).
A
Awesome
and-
and
my
name
is
kim
lewandowski
for
those
of
you-
I
haven't-
met-
I'm
on
the
google
open
source
security
team,
so
I
worked
closely
with
avishak
and
tom
and
helped
get
salsa
off
the
ground
here
from
the
google
side.
So
I
I
will
share
the
meeting
notes
and
we
have
a
couple
of
logistical
things
just
to
get
through
in
the
beginning
and
then
and
then
there's
a
bunch
of
discussion
topics
on
there
as
well.
A
All
right
and
one
thing
about
the
the
recording,
so
I
try
I
the
the
last
recording
is
on-
is
there's
a
link
to
it
down
below
these
are
posted
in
the
open,
ssf
channel.
So
I
try
to
make
sure
I
get
them
up
there
pretty
quickly.
So
if
you
ever
and
then
we'll
try
to
make
sure,
I
update
our
notes
with
the
with
the
link
to
the
latest
recording
so
feel
free
to
check
it
check
it
out
there
and
so
at
the
top.
A
We
collect,
like
just
attendee
list,
so
feel
free
to
opt
in
and
add
your
name
I'll
pop
a
link
to
the
stock
into
the
gvc
into
the
chat
too
and
just
most
yeah.
So
it's
up
here
most
of
our
docs
we've
been
sharing
with
the
salsa
discussion,
google
group
and
so
usually
that'll.
That's
what
will
give
you
access,
but
I
mean
it's:
it's
fine
to
share
things
completely
publicly
as
well,
and
I
think
it's
probably
encouraged.
A
I
I've
noticed
on
some
other
public
docs,
we'll
get
like
a
bunch
of
spam
comments
and
things.
So
I
don't.
I
don't
know
if
that's
going
to
become
an
issue,
but
there
is
that
that
google
group
up
there
okay
cool
and
then
is
there
anyone
new
on
the
call.
So
it
looks
like
you
if
you
all
sort
of
went
through
a
bunch
of
intros
last
time.
Is
there
anyone
new
on
the
call
that
wants
to
introduce
themselves
quickly.
C
D
Oh
go
ahead.
Sorry:
okay,
my
name
is
mikey.
I'm
an
engineer
in
israel,
a
small
little
startup
doing
a
dev
set-ups
and
we're
looking
at
salsa
as
a
guide
to
to
build
up
to
our
tools.
E
D
C
Yep-
and
this
is
alex
caplica,
I'm
a
manager
within
pwc
cyber
security
practice
and
I'm
looking
at
salsa
to
kind
of
help.
Someone
navigate
to
my
clients
through
securing
their
supply
chain.
A
Nice
very
cool
awesome,
any
anyone
else,
no
okay
cool.
So
the
next
thing
I
have
on
on
the
agenda
is
just
a
recap
from
the
last
meeting
and
abhishek
and
tom,
or
whoever
else
was
there,
is
there
anything
you
wanted
to
discuss
quickly
from
last
meeting?
I
know
there's
discussion
about
the
steering
committee.
A
There
is
a
pr
that
I
link
to
that.
That
has
set
up
the
steering
committee
for
salsa
any
other
any
other
items
from
last
time.
A
Yeah
thanks
thanks
for
the
great
note-taking,
feel
free
to
jump
in
anyone
and
help
with
note-taking,
and
then
the
next
thing
I
had
was
just
meeting
facilitators.
So
I'm
happy
to
you
know,
help
try
to
drive
these
meetings
and
wondering
if
anyone
else
wants
to
volunteer
feel
free
to
throw
your
name
in
there.
Let
us
know,
and
then
we
can
try
to
rotate.
A
Who
can
you
know,
help
drive
this
meeting
and
and
then
the
last
small
item
is.
We
are
planning
a
workshop
just
to
help
build
out
a
roadmap
for
salsa.
I
believe
peter
from
projects
by,
if
is
on
the
call
and
has
invited
most
of
the
steering
committee
members
peter.
I'm
not
sure
if
you
want
that
to
be
like
a
larger
group
or
if
you
have,
if
you
have.
G
H
A
Cool
cool
all
right,
and
now
we
can
jump
into
discussion
topics,
let's
see
who
who
wants
to
go
first,
so
who
added
some
of
these?
This
is
this
you,
tom.
I
Is
yeah,
I
I
yes,
I
think
so
so,
like
one
of
the
things
that,
like
that
we've
been
discussing,
is
that
it's
like
there
are.
There
are
some
issues
that
have
that
have
come
up
and
it's
a
little
bit
difficult
to
know
like
how
like
how
should
those
things
be
be
resolved,
because
I
don't
think
that
we
necessarily
have
have
agreement
on
like
what
are
the
goals
of
like
each
of
the
salsa
levels.
What
is
the
like?
I
What
are
the
goals
of
like
salsa
generally,
so
I
as
a
first
part
as
a
first
part
to
that,
like
what
is
the
goal
for
salsa
generally,
like
so
far,
we've
we've
been
thinking
that,
like
that
salsa
can
should
should
be
focused
primarily
on
on
on
integrity
and
that
it
can
provide
a
a
basis
by
which
you
can
build
other
things,
sort
of
sort
of
on
top
of
it
like
like
it's
one
thing
to
do
vulnerability
scanning
of
of
of
code.
I
It's
another
thing
to
know
that
that
that
code,
that
source
code
that
you
scanned
and
that
git
repo
is
actually
what
was
is
actually
what
was
delivered
and
running
in
in
production.
So
like
so,
I
think,
like
my
proposal
might
be
like
like
salsa
itself
is
is,
is
is
just
is
just
integrity
and
we
can
build
other
things
on
top
of
that,
but
those
would
be
outside
of
the
scope
of
salsa.
F
F
I,
as
long
as
it's
clear,
there's
always
a
case
for
if
it's
too
big
I
mean
we
can't
do
it.
It's
too
small.
Nobody
cares,
but
at
least
I
think,
on
the
current
repo,
it
says
it's,
including
security
as
well
as,
more
generally,
not
just
integrity.
I
Yes-
and
I
you
know,
I
like
there's
been
a
lot
of
churn
in
the
in
the
repo
lately
like
that,
could
be
simply
a
factor
of
of
of
some
of
the
of
some
of
the
wordsmithing
that
has
happened.
That,
like
could
have
been
that
could
have
been
a
mistake
from
from
from
from
you
know,
from
the
initial
from
the
initial
documentation.
I
don't
know
that
we
need
to
stick
with
like
just
whatever
the
repo
says
now,.
J
I
so
I
think
the
last
item
on
the
agenda
probably
relates
to
this
a
good
deal,
because
we
haven't
really
fleshed
out
how
you
extract
security
properties
or
whatever,
whatever
from
from
integrity
guarantees,
but
I
think
that's
absolutely
an
intent.
J
Definitely
I
I
think
tom
to
to
our
mind,
but
I
don't
know
it
probably
is
ultimately
what
you
know:
users
or
the
community
does
want
right.
You
want,
you
want
to
be
able
to
get
some
value
from
the
information
you're
recording,
however,
secure.
K
Right,
I
agree
with
both
of
you
that
focusing
here
is
a
good
idea.
Making
it
too
small
and
too
big
is
not
great
either.
I
think
I
think,
as
long
as
salsa
can
tell
give
you
integrity
guarantees
for
one
particular
software
supply
chain,
the
one
that
you're
looking
at
right
now,
you
don't
necessarily
need
to
include
information
about
other
supply
chains.
You're
using
you
can
maybe
pull
it
up
recursively,
but
I
don't
think
it
should
be
a
strict
requirement
and
then
you
can
go
as
big
as
you
like.
Some
people
want
s-bombs.
H
Yeah
yeah,
I
I
agree
with
that
as
well.
The
only
thing
that
I
think
we
should
make
clear
is
is
make
make
it
clear
that
we
aren't
cons.
You
know,
but
it's
out
of
scope
like
the
the
other
folks
supply
chain
is
out
of
scope,
and
but
it
is
still
obviously
a
security
concern
just
out
of
scope
for
what
else
is
attempting
to
do.
A
I'm
curious
if
there
are
other
frameworks
that
folks
know
of
that,
might
capture
more
of
the
security
elements,
something
that's
come
up.
Conversations
that
I've
been
having
like
does
it
cover
things
like
scanning
hi,
david
yeah,
you
know
is
the
is
the
artifact
scanned
and
should
that
be,
it's
also
requirement
and
I
think,
that's
sort
of
what
we're
trying
to
discuss
now
like
what
in
scope
versus
with
other
scope.
A
F
Sure
why
not
the
elephant
in
the
room,
hopefully
a
small
elephant,
so
yeah,
so
I
lead
the
ci
best
practices
badge
with
a
cii
best
practices
badge
which
has
a
bunch
of
criteria
focused
on
security
in
general.
F
There
are
some
integrity
things
so
not
quite
as
focused
on
the
other
has
a
whole
lot
of
other
things
that
are
more
general
security.
You
know
scanning
that
sort
of
thing
also.
It's
specifically
for
open
source
software.
We've
had
occasional
discussions
about
how
to
you
know
how
you
know
how
to
how
also
handle
proprietary
software,
but
at
least
at
least
for
now-
and
I
suspect,
for
a
while-
it's
really
focused
on
open
source
software,
so
it
both.
F
It
doesn't
cover
exactly
the
same
things,
and
I
certainly
want
to
make
sure
that
someone
can
do
both
salsa
and
the
best
practices
badge.
If
both
make
sense-
and
I
think
in
at
least
the
in
the
case
of
open
source
software
projects,
that
should
make
sense.
M
F
Been
following
this,
this
thing
in
great
detail:
kim's
been
following
this
to
at
least
some
extent
I
think
as
well.
You
know,
nist
has
been
asked
to
do
a
number
of
things
and
us
government
agencies
more
generally
for
this
executive
order.
Yeah
somebody
asked:
can
someone
link
to
the
nist
guidelines?
Well,
actually,
that's
a
little
bit
of
a
challenge
right
now.
For
the
most
part,
they
don't
exist.
There's
eo
guidelines
that
say
that
things
will
exist.
F
That
said,
there
are
some
things
that
exist
right
now.
Perhaps
the
most
pertinent
in
terms
of
specific,
must
do
x's
kind
of
thing,
although
must
musters,
probably
the
wrong
term.
Nist
has
released
a.
How
do
you
evaluate
software,
but
it's
really
a
laundry
list
of
use,
static,
analyzers
use,
fuzzers
use
this
use.
That
is
that
you
know
what
what
could
you
do
to
analyze
software
and
I
I
said
the
word-
must
there
and
I
shouldn't
have
said
that
because
in
fact
it
doesn't
say
you
must
do
all
these
things.
F
It's
much
more
of
a
here
are
some
things
you
should
think
about,
but
it's
not
a
requirement.
There's
another
area.
Now
the
eo
does
talk
a
whole
lot
about
software,
build
materials
and
there's
an
implication.
Then
they
specifically
asked
hey:
nda
did
a
identified
a
minimum
viable
are
the
things
that
need
to
be
added.
So
there
are
things
that
are
in
progress.
They
have
released
some
things
yeah
that
yeah
ndar
has
listed
some
guidelines.
F
I'll
note
you
know
and
you,
but
there's
enough.
Basically
there's
a
lot.
We
don't
know
yet.
Can
you
feel
free
to
correct
whatever
I
misstated.
A
Yeah
I
mean
that's
about
as
much
as
my
awareness
too.
I
think
I
think
I
think
we'll
be
hearing
more
and
more
very
soon,
so
it
could
definitely
be
something
that
we
talk
about
every
few
weeks
in
this
group
and
how
we
can
potentially
be
aligned
with.
What's
going
on
there.
F
In
many
ways
it
may
be
the
other
direction.
I
actually
submitted
a
whole
bunch
of
papers
to
nist
about
about
these
topics,
and
you
know
you'll
either
be
delighted
or
horrified
to
know
that
I
specifically
pointed
to
salsa,
as
well
as
the
best
practices
badge
and
score
cards
and
some
other
projects.
E
So
yeah,
I
wanted
to
point
two
things
here
which
are
not
part
of
the
supply
chain.
Inequality.
One
is
the
continuous
security
testing
things
like
fuzzing
guidelines
and
the
second
is
vulnerability
management.
So
I
would
say
those
are
part
of
supply
chain
security,
but
not
of
integrity.
So
I
think
they
shouldn't
be
part
of
salsa
but
obviously
curious
to
hear
your
thoughts
as
well.
H
H
I
think
that
that
second
part
is
probably
mostly
out
of
scope
outside
of
saying
hey.
You
know
like
well
yeah,
if
you
don't,
if
you
do
not
secure
your
build
system
at
the
end
of
the
day,
they're
gonna
find
a
way
in
and
and
compromise
that.
H
The
second
thing
that
I
also
want
to
bring
up
as
just
another
thing
that
I
know
it's
another
they're,
calling
it
a
standard,
the
oh
wasp
scbs,
the
software
component,
verification
standard.
I
know
that's
one
thing:
that's
out
there,
what
will
there's
some
interesting
stuff
in
there?
I
think
a
lot
of
very
good
principles.
H
There
are
some
concerns,
I
think,
with
some
contradictory
things
in
there,
like
as
an
example,
you
know
you
should
have
a
reproducible
s-bomb,
but
then
they
also
say
all
s-bombs
must
have
a
time
stamp
so
which
is
it
but
but
that's
I
think
there
is,
I
think
at
least
a
lot
of
good
information
in
that
thing
as
well.
I
So,
just
michael
just
just
revisit
something
that
that
you
said
earlier,
you
were
mentioning
that,
like
you
know
that
people
don't
don't
secure
their
builder
and
an
attacker
gets
in
that
way
that
I
like,
were
you
saying
that
that
should
be
out
of
scope
for
for
salsa
or
in
scope.
H
Well,
I
I
think
if
it
is
in
scope,
we
just
need
to
be
clear
with
which
pieces
are
in
scope,
because
we
can
like
that
that
can
obviously
go
as
broad
as
we
at
right
like
or
do
we
want
to
say,
hey
make
sure
that
you
know
a
developer's
workstation
is
also
secured
against.
You
know
its
own
set
of
attacks,
because
you
know
a
developer's
workstation
could
also
be
used
as
a
way
to
eventually
compromise
the
supply
chain.
Do
we
want
to
focus
on
just
which
pieces?
I
I
think,
partly
because
we
are,
depending
upon
the
other,
the
the
other
requirements
like
the
like,
like
code
review,
that
is
managed
by
by
by
a
separate
system
and
like
the
source
control
system
and
the
builder
platforms
requiring
two-party
auth
for
for
for
any
for
any
configuration
changes
and
that
that
should
like
that
should
help
and
to
hopefully,
not
matter.
If,
if
the
developer's
workstation
has
been
compromised,
because
that's
probably
going
to
happen.
F
J
No,
I
so
the
way
I've
been
thinking
about
it,
and
maybe
this
is
something
that
could
well
just
focusing
on
the
sort
of
outcomes
or
the
the
security
properties
like
the
builder
should
not
be,
or
you
know,
for
for
source
code,
the
the
user
should
not
be
able
to
unilaterally
like
submit
code.
In
that
case,
maybe
you
just
bound
it
at
the
user
identity
and
similarly
for
like
builders,
you
say
it
should
have.
F
Yeah
I
I
would,
I
would
say,
authorized
people
one
of
the
tricks.
I
think
and
we've
I've
mentioned
this
before
a
huge
number
of
open
source
projects.
There's
one
person,
so
you
know
how
we
handle
that
I
think
is
going
to
be
a
little
tricky.
But
it's
not
it's
totally
doable.
It's
just.
You
have
to
think
it
through.
H
Sure,
yeah
yeah,
I
I
think
that
there's
two
things
that
come
to
mind
based
on
what
matthew
just
said,
which
was
like
one
thing,
was
like
zero
trust
right
like
some
of
these
things,
sort
of
hey.
H
If
you're
assuming
some
of
the
network
stuff,
is
probably
not
secure
in
the
first
place
and
you're
focusing
on
identity,
then
you
can
kind
of
say:
hey
look,
you
know
on
that
end
and
then
the
second
thing
which
is
related
to
I
think
some
of
the
secure
builder
and
some
of
the
other
things
that
salsa,
I
think
helps
out
with
is
like
salsa,
is
fundamentally
incompatible
with
shadow
I.t
right
and
so
like.
I
don't
know
how
we
want
to
sort
of
state
like
look
this
is
you
know
this?
H
You
need
to
solve
your
shadow,
it
problem
in
order
to
get
the
benefits
from
salsa,
because
if
folks
are
just
working
around
whatever
you're
doing
to
sort
of
generate,
you
know
salsa
and
I
get
that
we're
gonna,
try
and
include
that
metadata
signed
in
the
you
know
in
toto
and
whatnot.
But
if
those
sorts
of
things
are
like,
if
folks
are
still
finding
a
way
to
deploy
random
stuff
to
production,
it's
kind
of
you
know
it's
a
moot
point.
K
K
I'm
curious
how
we'd
make
some
of
these
properties,
like
I
don't
know,
only
authorized
people
can
administrate
the
ci
cd
automatically
verifiable.
That's
something
to
think
about
yeah.
I
Option
to
you
know
well
so
to
to
to
disagree
with
with
matthew
somewhat
what
what
what
we
do
like.
I
What
we've
been
thinking
about,
and
the
way
that,
like
we
handle
this
with
our
our
internal
builders,
is
that
is
that
there
are.
I
There
are
some
properties
which
are
sort
of
which
are
sort
of
self-evident,
and
then
there
are
others
where,
like
you
need
to
trust
whomever
the
whoever
the
the
the
tester
is
and-
and
you
need
to
have
ideas
to
why,
if
they
make
some
claim,
you
can
trust
it
and
what
we've
sort
of
been
thinking
and
there
might
be
other
ways
to
to
do
this-
is
that
at
higher
salsa
levels
that
there
might
be
some
sort
of
some
sort
of
accreditation
process
by
by
which
some,
like
third
party,
like
analyzes,
a
builder's
design,
analyzes
the
source
control
systems
design.
I
I
They
could
counter
sign
the
signing
keys
that
that
builder
uses
to
sign
to
sign
providence
and,
like
you,
could
you
could
sort
of
bootstrap
it
that
way
and
say:
aha,
this
has
been
signed
by
an
open,
ssf,
salsa
level.
Three
key.
So
therefore
it
like
meets
the
salsa
level
three
requirements
or
like
it,
meets
these
sort
of
implicit
requirements.
Yeah.
I
was
not
considering
that
to
be.
J
F
F
The
scorecard
basically
says
we're
going
to
figure
out
what
we
can
measure
automatically
and
what's
great
about
that
is
scale.
You
know,
you're
gonna,
you
can
scan
everything.
The
problem,
of
course,
is
that
what
you
can
automatically
examine
is
not
necessarily
what's
important.
F
So
this
is,
you
know,
there's
so
many
things
are
just
even
if
you
can
automatically
verify
them
only
in
certain
cases,
not
in
the
general
case.
So
you
know
you
know
I,
so
I
think
it
would
be
unwise
to
makes
also
require
require
that
salsa
only
check
things
that
can
be
automatically
checked.
I
I
What
what
I
mean
is
that,
when,
when
an
artifact
and
like
attestations
about
that,
artifact
are
are
presented
at
some
verification
point
that
that
verification
point
can
can
can
look
at
the
artifact
and
and
can
look
at
those
those
those
attestations
and
evaluate
it
against
some
policy
and
then
make
a
yes
or
no
decision
as
if
that
artifact
should
be
should
be
admitted
and
that
part
of
that
process
can
like
leverage
prior
like
prior
accreditations
that
have
happened,
but
that,
but
that
you
should,
but
that
that
decision
should
be
like,
should
be
able
to
be
made
at
that
point,
and
that
might
require
other
like
human
analysis.
I
Much
earlier
in
the
like
in
the
process.
F
Okay,
yeah,
okay,
that
makes
all
right
yeah.
I
see,
there's
a
there's,
a
fine
there's,
a
hair,
that's
being
split,
and
it's
not
really
it's
it's
pretty
important.
So
I
I
think,
if
I
understand
you
correctly,
I
agree
with
you,
but
at
some
point
what
I,
what
I
want
to
avoid
is
the
I
never
need
a
human.
Everything
can
be
completely
determined
automatically,
and
I
don't
think
that
that's
reasonable
for
salsa.
I
think
I
think
for
that
kind
of
task.
F
J
Yes,
yeah,
I
think
that's
a
good
point,
michael,
like
the
the
big
difference
here
is
like
mutually
trusting
versus
mutually
distrusting
parties,
so
like
inside
an
enterprise
versus
just
distributing
open
source
and
having
someone
yeah.
N
And
this
is
something
we
spoke
about,
I
think
in
the
last
week,
because
we
were
talking
about
like
look
on
certain
areas,
you
can
actually
put
a
technical
check
and
absolutely
check
the
box
and
say
this
meets
this
category
of
salsa,
but
on
the
other
stuff,
it's
really
up
to
the
individual,
the
company
in
that
little
area-
and
this
is
one
of
the
things
we've
talked
about-
maybe
come
up
with
a
way
to
go
in
and
verify
that
like
if
we're
a
package
deployment
company.
So
we
can
cover
certain
aspects.
N
But
when
you
go
back
to
the
software
build
side
of
it,
it's
really
in
our
customers
to
basically
do
the
right
thing
there.
But
could
we
provide
a
service
that
would
go
back
in
and
say
we'll
walk
through
and
kind
of
do
a
security
audit
with
you
to
make
sure
you're
meeting
all
these
salsa
things?
So
then
you
can
say:
okay,
we've
checked
and
and
a
second
party's
kind
of
checked
us
and
validated
that
we
meet
salsa
level,
three
or
four
or
whatever
you
decide.
N
H
D
At
what
point
does
is
there
a
connection
between
the
providence
of
set
by
humans
or
by
a
previous
check,
for
example,
if
if
a
developer
pushes
code
to
his
csm,
it's
good
and
you
sign
it
in
total,
you
send
home,
you
send
this
signature
out
and
the
next
step.
The
build
step
should
have
some
kind
of
connection
to
to
to
that
providence,
the
previous
one.
D
So
so
we
can
show
not
only
that
I
did.
I
I
built
my
my
ci,
my
application
in
the
in
a
specific
way,
but
I
built
it
in
the
specific
flow
that
the
previous
previous
step
in
the
flow
was
a
two
review,
two
reviews
and
reviewed
in
the
put
request
and
beforehand
whatever
whatever
the
policy
defines.
I
Oh
so
I
talked
about
this
summer
at
least
about
how,
like
we've
been
thinking
about
it,
and
that
is
that
the
the
salsa
provenance
which
is
created
by
by
the
builder
should
should
wind
up
indicating
which
source
control
systems
the
source
was
was
was
pulled
from,
including
like
including
the
git
commit
hash
right,
and
so
in
that
providence.
You
say
this
like
binary.
I
Artifact
was
like
built
from
like
all
these
sources
at
these
hashes
and
then
there's
this
other
issue
that
I
linked
to
in
in
in
chat
about
creating
an
attestation
that
captures
the
source,
control
systems,
security
settings,
and
I
I
have
a
proposal
which
I
have
yet
to
which
I've
got
to
provide.
I
But
the
idea
is
that
that
attestation,
that
the
subject
of
that
attestation
would
be
like
like
the
get
commit,
and
so
then
you
would
bundle
up
all
like
you
would
have
a
source
control
the
builder
when
it's
building
the
thing
it
would
also.
I
It
would
also
get
these
these
source
control
attestations
for
for
for
each
of
the
repos
that
it
pulled
from
and
it
would
bundle
to
build
provenance
along
with
all
the
source
provenance
provide.
It
to
some
sort
of
and
then
provide
it
to
to
to
the
policy
engine,
and
then
the
policy
engine
can
look
at
the
build
providence
and
then
go
down
each
of
those
listed
source
control
systems
and
join
it
with
with
the
provided
source
attestation
and
ask
questions
like:
does
the
source
control
system
meet
the
salsa,
the
salsa
level
that
we're
targeting?
D
I
That's
that's
like.
I
think
that
that's
yet
to
be
like
that's
yet
to
be
agreed
upon,
but
that's
that's
that's
sort
of
what
that's
sort
of
what
we
were
thinking
and
that
for
source.
I
We
were
hoping
that,
like
that,
these
attestations
can
be
stored
stored
in
the
source
control
system
like
you
could
actually
store
these
attestations
within
something
like
a
git
note,
so
that
so
that
every
time
the
code
review
system
doesn't
merge,
it
like
it
can
issue
a
new
attestation
that
says
hey
this,
like
merge,
had
two-party
review
and
met
these
other
properties.
I
Creative
news
that
is
the
best
place
at
the
moment.
It
just
talks
about
defining
the
the
the
predicate
I
yeah
there,
but
there's
no
other
place
where
that
is
currently
discussed.
H
One
quick
question
there,
because
I
I
know
that
salsa
itself
is
is
like
talking
about
currently
non-transitive
dependencies,
but
the
the
things
that
we're
currently
discussing
now
like,
for
example,
the
source
code
repository,
are
sort
of
key
components
of
of
this,
and
and
some
of
the
things
that
you're
talking
about
whether
it's
like
you
know
hey.
Can
these
things
attest
to
those
things
based
on?
H
You
know,
identity
and
whatever
else,
but
like
those
particular
components
I
feel
like
if
their
supply
chains
have
been
attacked
and
they
are
reporting
the
wrong
information
to
you,
then
all
of
a
sudden,
you
know
everything
you're
doing
is
also
now
compromised.
I
Yeah,
I
I
I
agree
that
that's
that
that's
a
problem
that
that
that
we
should
solve,
we
just
haven't
really.
We
just
haven't
really
addressed
it
yet
because
it's
it's
very,
I
think
that
it's
very
easy
to
say
what
we
want,
which
is
that
we
like,
like.
We
want
a
policy
that
says
that
this
artifact
must
meet
salsa
level.
Four
and
all
all
of
its
dependencies
must
transitively
meet
salsa
level
four
as
well.
Now
the
problem
with
that
is
that
that
that
graph,
that
supply
chain
graph
is
enormous
and
goes
back.
I
H
Yeah,
no,
I
I
definitely
agree
with
that,
for
sort
of
generic
sorts
of
you
know
like
libraries
and
sources
and
those
sorts
of
things,
I'm
actually
thinking
more
about
the
system
that
you're
using
to
actually
implement
the
salsa
stuff
right
like
so
so
as
an
example
right
like
to
some
extent,
I
I
would
agree
that
you
know
with
everything
you
said,
and
I
the
thing
I
would
say
is
like
maybe
the
first
thing
that
you
do
look
at
if
you
start
to
look
at
some
of
those
transitive
dependencies
is
like
hey
your
build
system
right
like
what's
the
supply
chain
of
of
of
that.
I
Yes,
I
I
agree-
and
I
think
we
had
discussed-
but
maybe
not-
but
I
think
it's
probably
not
been
defined
in
the
in
the
requirements
table-
is
like
a
requirement
that
it's
also
level
four,
that
a
builder
like
that
all
of
the
components
that
the
builder
uses
meet
likes,
also
level
three
or
or
you
know
like
you-
can
meet
salsa
level
three
for
like
a
month.
I
But
yeah
like
like,
I
think
that
would
be
a
very
reasonable,
like
a
very
reasonable
requirement
to
to
to
add,
and
that
would
be
pretty
valuable.
A
A
Okay,
perfect:
let's
yeah,
let's
see
where
we
are,
which
one
matthew
version.
J
No,
the
purpose
is
of
each
level.
Okay,
I
can
quickly
present
it's
it's
very
short,
but
basically
just
conceiving
of
the
levels
as
sort
of
bundles
of
those
different
requirements,
so
build
source
and
and
dependencies
is
another.
M
J
Let
me
present
and
how
the
latter
is
meant
to
sort
of
gradually
work
back
from.
J
So
I
mean
this
is
a
somewhat
arbitrary
three-stage
sort
of
visual
represent,
like
you
know,
schema
that
I've
put
here
but
sort
of
going
from
l1,
where
you
might
have
build
source
and
depths
at
you
know
just
like
best
effort
sort
of
confidence,
integrity
whatever
you
want
l2
bumps
up
build,
but
still
has
relatively
little
to
say
about
source
and
depth
and
not
anything
really
in
terms
of
integrity,
whereas
l3
sort
of
we
have
in
many
ways
sort
of
the
ideal
builder.
We
don't
really
have
to
trust
it.
J
It'll
just
take
in
and
spit
out
what
you
give
it
and
there's
some
real
sort
of
requirements.
You
know
assurance
we
can
get
from
source
now
that,
like
it's
hosting
the
build
definition
stuff
like
that,
still
nothing
on
depths
and
then
sort
of
l4
you've
now
sort
of
pushed
it
back.
You
have
all
of
the
nice
two-party
review
bits
of
source.
You
have.
J
You
know
the
full
commit
log
stuff
like
that,
and
now
you
start
to
make
statements
about
dependencies
as
tom
was
just
saying
yeah,
so
that
I
mean
independent
of
the
way
it's
phrased
in
the
in
the
in
the
repo.
I
think
this
is
a
you
know
a
way
that
the
current
ladder
ultimately
breaks
down
into
those
pieces
anyway,
yeah.
F
It's
really
a
tone
of
by
the
way
for
a
request
and
access.
It's
a
tone
thing
more
than
really
an
objection
overall,
but
I
think
of
all
this
stuff
in
terms
of
risks.
I
don't
think
l1
is
better
than
nothing.
I
think
it's
much
better
than
that,
because
you
have
made
things
harder
than
they
would
have
been
otherwise,
conversely,
at
l4
trying
to
claim
that
hey,
it's
not
possible.
Well,
you
see,
you
know
something's
infeasible.
F
I
don't
believe
you,
you
know
if
you,
if
you
got
you
if
you're
a
nation
state,
maybe
it
doesn't
matter
okay,
I
subverted
the
silicon
before
it
got
to
you.
I
subverted
all
of
them,
but
that
doesn't
make
it
very
likely
and
you
certainly
have
reduced
each
of
these
levels,
the
risks,
and
so,
if
you
characterize
this
is
just
this
is
an
exercise
in
greatly
reducing
the
risks
at
each
of
these
levels.
F
I
think
it's
much
easier
to
clean
deal
with
both
the
low
and
the
high
end.
Every
level
has
a
value.
J
Oversell
level
four,
where
right
I
mean
a
lot
of
the
purpose
of
that.
That
write-up
is
to
kind
of
explain
l1
honestly,
that,
like
it
they're
clearly
like
really
big
dividends,
it
yields
not.
You
know,
cryptographically,
verifiable
necessarily
but
like
in
terms
of
scoping,
and
you
know
really
getting
a
handle
on
the
totality
of
the
problem.
It's
extremely
important.
F
I
say
a
remarkable
number
of
the
problems
that
have
happened
out
in
the
real
world.
Don't
require
vast
sums
to
counter.
They
just
require
something
so
yeah.
One.
K
H
Thumbs
up
just
a
quick
thing
from
an
end
user
perspective,
it
would
also
be
useful
to
know,
like
you
know,
hey
those
are
the
goals,
but
like
one
of
the
things,
I
think
we
would
also
like
to
figure
out
is
like
what
sorts
of
attacks
could
this
lower
the
risk
for
right?
You
know
what
what
sorts
of
like
you
know
and
then
maybe
what
sort
of
you
know
sophistic?
You
know
what
level
of
sophistication
and
what
areas
it's
it's
sort
of
preventing
that,
because
then
that
helps
us
sort
of
figure
out.
H
H
No
sorry,
sorry,
I
just
saw
that
somebody
posted
a
a
pull
request
which,
looking
at
let's
see,
what's
this
one's
add
thread
and
mitigations
page
yeah,
I
think
yeah.
Something
like
this,
I
think
is
is
is
a
good
thing,
especially
for
the
individual
salsa
level.
So
folks
know
like
hey
salsa
one
doesn't
protect
against
these
sorts
of
attacks,
but
I
have
you
know
a
solid
set
of
monitoring
tools
and
other
scanning
tools.
M
Is
it
feasibly
something
where
a
willing
test
pilot
project
could
be
walked
through
moving
from
el?
God
knows
what
to
l1
to
make
this
more
tangible
for
people.
This
is
really.
This
is
the
lower
level
is
basically
it's.
It's
a
hygiene
play
like
here's,
a
basic
standard
of
of
supply,
chain
hygiene
for
you
to
follow
and
showing
how
someone
can
move
from
a
sort
of
naive
few
developers
cranking
out
a
project
to
a
more
managed
properly
hygiene
situation
could
be
really
useful
and
would
probably
teach
the
salsa
team
a
lot
too.
N
Zach,
I
think
that's
a
great
idea
and
honestly
from
the
from
the
package
deployment
side
for
our
company.
Like
we're
kind
of
trying
to
see.
Can
we
build
something
like
that,
so
that
our
customers
can
then
we
can
use
salsa
as
that
framework,
so
that
if
you
come
on
as
a
customer
to
deploy
your
packages,
we
can
help
like
walk
you
through
that
whole
process.
So
this
is
part
of
why
we're
kind
of
jumping
in
and
kind
of
having
this
conversation,
there
should
be
a
way
to
do
that.
N
It's
gonna
have
to
be
a
mix
of
technical
administrative
controls.
There's
gonna
have
to
be
a
way
to
determine
what
salsa
level
should
you
be
at
and
then
what
can
we
do
to
basically
help
you
get
those
check?
Those
boxes
either.
Give
you
a
checklist
to
yourself
we'll
give
you
a
way
that
someone
can
kind
of
check
check
those
with
you
to
make
sure
you're
doing
the
best
practices
right.
Yes,.
H
So
a
a
project
that
I'm
in
charge
of
at
the
cncf
or
co
in
charge
of
the
cncf
is
the
supply
chain,
security,
working
group
and
we're
doing
the
secure
software
factory
and
the
one
of
the
goals
of
the
secure
software
factory
is
to
sort
of
build
a
you
know:
a
flow
of
sort
of
a
ci
cd
system
and
whatever
additional
components
that
would
be
able
to
generate
right
now.
You
know
we're
gearing
for
something
like
hey
you.
H
If
your
stuff
goes
through
here,
we
with
the
additional
extra
sort
of
requirements,
we
would
expect
you
to
be.
You
know
salsa
one
like
any
sort
of
things
that
come
through
there.
H
So
that's
just
sort
of
stuff
like
hey
we're,
pulling
code
down
from
a
source
thing,
we're
doing
all
the
right
sorts
of
you
know
we're
using
in
toto
and
we're
signing
the
stuff
and
we're
tracing
it
through
that
whole
process
and
then
at
the
end,
hey,
you
know
this
is
a
salsa
one
artifact,
that's
that's
sort
of
our
goal,
so
we're
definitely
willing
to
not.
We
don't
have
a
project
per
se
of
saying
hey.
H
E
Okay,
great
idea,
like
do
people
have
their
own
projects
that
they
want
to.
Try
like
it
would
be
nice
to
have
a
mix
of
things
like
some
stuff
from
cncf,
some
stuff
from
like
other
steering
committee
members
like
if
they
have
recommendation
from
their
own
company,
it
would
be
nice
to
have
a
mix
of.
I
would
say
three
to
five
projects
that
we
try
against
also
level
one
and
two.
A
Yeah,
it
would
be
great
if
you
journeyed,
you
wrote
down
your
journey
on
the
way,
so
we
could
all
use
it
as
a
case
study
too
and
learn
from
it.
M
Should
the
project
be
smaller
or
bigger,
I
mean,
for
example,
I
reached
out
to
one
of
the
php
build
release
managers
that
I
know
because
large
project
used
by
many,
but
unless
things
have
changed
a
lot
since
I
last
worked
on
it.
A
little
ad
hoc
and
practices
like
would
a
larger
project
be
a
good
testbed,
or
is
that
too
big
of
a
place
to
start.
J
No,
I
think
it's
it's
it's
good
to
get
a
mix,
especially
so
like
yeah.
I
just
laid
out
in
in
the
that
dock,
that,
like
a
single
developer,
sort
of
larger,
open
source
project
php
seems
to
fit
pretty
well
into
that.
I'd.
Imagine
and
then
sort
of
an
enterprise
where
you
have
sort
of
yeah
different
concerns.
F
If
I
could
jump
in
here,
because
I
of
course
did
this
with
the
ci
best
practices
badge
stuff-
we
intentionally
went
out
and
worked
with
projects
that,
where
we
were
trying
to
in
some
sense
find
the
extremes.
F
So
we
interacted
with
the
linux
kernel
big
project
high
velocity
widely
used.
We
also
talked
with
curl
single
developer.
I
mean
widely
used,
you
know
in
node
and
libreoffice,
and
there
were
a
couple.
Others
github
was
an
early
early
one
too
you're,
not
github.
Gitlab
was
an
early
one,
but
basically
we
tried
to
get
several
different
kinds
of
projects
so
that
we
wouldn't
be
swayed
by
well.
F
We
grab
projects
but
they're
all
javascript
cop
projects
from
company
x,
well
they're
going
to
have
some
things
that
are
going
to
be
the
same
from
everything
else
and
so,
for
example,
an
email-based.
You
know
development
process
is
going
to
look
totally
different
than
one
that
uses
github
as
or
get
lab
as
their
basis.
A
Yeah,
I'm
just
I'm
just
thinking
through
if
there's
ways
that
we
can
help.
You
know
some
of
these
projects
too.
If
it's,
you
know
more
engineering,
resources
or
sort
of
understanding
the
things
that
they
need
to
try
to
meet
these
levels.
If
it's,
you
know,
infrastructure
credits,
that's
something
we're
trying
to
do
within
the
open.
A
This
foundation,
as
well,
is
just
figure
out
how
to
best
support
these
critical
projects,
so
the
more
info
we
have
as
folks
are
trying
to
harden
up
their
their
projects.
You
know
we
can
feed
that
back
into
the
technical
committee
and
then
the
governing
board
when
they're
as
the
typical
ones
available
for
these
types
of
efforts,
so
that
would
be
good
to
learn
too,
as
people
work
on
this
sort
of
thing.
H
Yeah
on
the
cncf
side,
I
know
we're
always
looking
for
for
more
input
from
folks
on
the
supply
chain
stuff
you
know
and
and
right
now
we're
not
in
the
the
actual
sort
of
hands-on
keyboard.
You
know
technical
implementation,
but
there
are
definitely
things
from
just
even
the
reference
architecture,
especially
with
this
being
such
an
evolving
space.
H
There's
a
lot
of
different.
You
know
there's
a
lot
of
different
tools
that
help
out
here,
but
I
don't
think
as
far
as
I
can
tell
outside
of
like
the
federal
the
us
federal
government
nobody's
really
implemented
an
end-to-end
sort
of
solution,
or
rather
I
say
outside
of
also
internal
companies.
Nobody
in
the
in
the
public
space
has
really
implemented
an
end-to-end
solution
of
like
hey
here's,
how
you
do
tracing
you
know
your
supply
chain,
securing
it
yeah
yeah.
F
H
No,
I
yeah
yeah,
sorry
what
I
meant
was
there
is
one
of
the
things
that
that's
coming
up
consistently
with
with
some
of
this
new
stuff,
the
cloud
native
and
whatever
right
like
some
folks
are
like
hey.
If
you
need
to
have
identity
on
the
individual
worker
nodes
and
you
need
to
you
know,
be
able
to
sign
all
the
things,
there's
not
really
a
lot
in
the
the
space
of
an
end-to-end
sort
of
solution,
similar
to
like
hey,
I
can
deploy
a
jenkins
with
some
stuff.
H
A
I'm
glad
I
wore
the
shirt
for
the
the
occasion
I
was
gonna
say:
that's
a
really
cool
logo.
It's
a
text
on
robot
cat
cool,
so
we
have
about
seven
minutes
left.
Can
we
touch
on
one
of
these
last
topic,
quick
or
maybe
put
on
one
of
them
to
the
next
time?
A
I
think
these
are
the
two
left
of
my
might
write
on
that,
so
maybe
jump
into
versioning
for
the
next
five
minutes
and
then
see
where
we
land
on
that,
and
then
we
can
move
these
other
topics
to
issue,
discussion
and
email
discussion
or
you
know,
pick
up
pick
them
up
next
time
does
any
who
added
the
versioning.
I
That
that
so
at
the
moment,
salsa
is
still
like
in
in
in
alpha
according
to
the
page
and
what
we've
seen
with
some
of
the
folks
that
that
we're
talking
to
is,
they
are
trying
to
plan
products
and
communications
and
so
forth
and
they're
like
when.
Is
it
going
to
come
out
of
alpha
to
some
version
that
they
can
point
to
so
that
they
can
plan
so
that
they
can
plan
accordingly?
I
And
I
I
think
that
there
are
a
couple
of
outstanding
issues
that
are
sort
of
going
one
way
or
the
other
in
terms
of
whether
or
not
source
control
should
be
required
at
at
l1.
Whether
configures
code
should
be
required.
But
but
apart
from
that,
I
remember
that,
like
the
c
plus
standard
committee
like
they
had
this
big
problem
with
like
versioning,
where
like
it,
would
take
them
what
it
took
them
years
and
years
to
like
get
a
particular
version
out,
because
they
were
just
trying
to
get
everything
into
it.
I
And
I
was
wondering
if
we
should
plan
if
we
could
schedule
version
releases
so
that,
like
releasing
like
releasing
a
salsa
version
by
like
the
end
of
september.
Might
not
like
doesn't
mean
that
if
your
thing
doesn't
get
in
there
for
the
september
release,
that
doesn't
mean
it's
never
getting
it.
That
just
means
that
it
might
not
get
in
until
the
march
release.
I
K
M
And
for
getting
to
1.0,
I
would
imagine
that
there
need
to
be
trial,
implementations
a
certain
number,
so
we
could
have
some
sense
of
how
easy
this
is
to
do,
etc
because
flagging
it
as
1.0
but
having
it
be
really
tough
for
the
desired
audiences
to
get
their
head
around
would
be
a
bad
thing
right.
K
F
Where
you
know
we,
we
had
first
drafts
of
require
of
requirements,
but
it
was,
I
think,
something
like
six
nine
months,
like
nine
months
before
we
finally
said
okay,
this
is
the
official
1-0
version,
because
we
wanted
to
make
sure
that
in
fact,
multiple
organizations
could
implement
them.
So
I
think
getting
neat
trial
implementations,
I
would
say,
think
that's
key.
I
mean
call
it
a
draft
or
whatever,
but
be
able
to
point
to
specific
implementations
that
you
can
actual
others
can
look
at.
I
would
say:
trial
public
implementations.
F
But
when
there's
public
implementations
then
then
people
can
learn
from
them
and
it
also
has
a.
I
don't
know.
If
other
people
do
it's,
I
don't
I
won't
say
it's
lemmings
like,
but
you
know,
then
people
can
learn
from
them
and
are
more
likely
to
do
them.
Just.
F
I
Oh
I
guess
I
was
just
going
to
ask
like
what
what
should
we
do
then,
so
that
those
so
that
those
first
movers
have
something
that
they
can
point
to
that
says
this
is
what
we
did
right
like
if,
if,
if
we're
changing
requirements
from
one
week
to
the
next,
then
it's
hard
for
anyone
to
say.
Oh,
this
is
salsa
one
or
two
well
like
which,
like
which
version?
Do
you
mean.
O
When
people
are
looking
at
these
existing
implementations
for
inspiration,
they're,
not
all
trying
to
replicate
kubernetes
when
that's
like
not
tractable
for
the
majority
of
such
projects,.
E
I
Address
your
concern
like
or
yeah
yeah
that,
like
like
that'd,
be
totally
fine
like
the
folks
that
I
talked
to.
They
would
be
completely
fine
like
as
long
as
they
can
say
where
salsa
this
like
this
thing
is
what
we
did
and
not
have
it
be
obsoleted
because
of
a
change
that
we're
making
as
like
we're
developing
the
standard.
So
I
think
then
the
like,
then
the
question
is,
is
I
mean
like
it
probably
is
like
well,
the
steering
committee
needs
needs
needs
to
decide
like.
I
O
I
think
we
should
try
and
resolve
them
yeah.
I
I
think
it's
a
tricky
position.
It's
been
to
ask
people
to
start
implementing
things
when
we
know
there's
potentially
contentious
issues
going
for
potentially
conscientious
changes
coming
in.
A
Yeah
I
gotta,
I
gotta
run
too
yeah.
I
think
there's
an
issue
around
this
too,
so
feel
free
to
chime
in
there.
If
that's,
not
the
link
that
goes
to
the
motivation,
I'm
not
sure,
but
thanks
thanks
everyone
for
the
great
discussion
and
we'll
kick
it
up
next
time
have
a
good
day.