►
From YouTube: SLSA Meeting (April 28, 2022)
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
C
Yeah
I
mean
mine,
is
just
community
meeting
after
community
meeting.
B
Josh
just
so
we're
clear
on
the
Michael
thing,
the
alpha
omega
project
has
an
unspoken
rule,
which
is,
if
you
want
to
be
part
of
Alpha
Omega.
Your
first
name
has
to
be
Michael.
You're
welcome
to
change
your
name
in
order
to
be
part
of
the
project,
but
you
know
there's
just
no
one.
B
E
F
B
Whose
fault
is
it
it's
Michael's
fault,
Mikey
likes
it
Mike.
He
likes
everything
and
Josh
I
just
want
to
be
clear
right.
People
are
allowed
to
rename
themselves
to
Michael.
So
if
the
job
like
show
us
how
much
this
job
matters
to
you
and
our
passions,
you
are
about
security
right
and
then
also
it's
a
it's.
A
protective
Veil
too,
like
who
reported
that
off
of
on
the
Billy
Bug
without
actually
doing
proper
disclosure
Michael.
Okay,
you
know
the
anonymization
aspect
is
compelling
I'm
going
through
that.
It's
it's!
C
Foreign
cool
I
think
we're
five
minutes
over
I
know.
Kim
usually
facilitates
the
meeting,
but
I
know
a
lot
of
the
folks
over.
There
are
all
in
Nashville
this
week.
So
I
guess
we
could
probably
get
started
here.
Just
a
reminder
here.
The
this
meeting
is
is
recorded
and
we'll
probably
end
up
on
YouTube.
Shortly
after
and
you
know,
you're
abiding
by
openssf
foreign.
C
Code
of
conduct
cool,
so
let's
go
through
the
agenda,
but
before
we
go
through
the
agenda,
is
there
anybody
who
is
new
to
this
meeting
who's?
Who
wants
to
introduce
themselves
it's
hard
to
keep
track?
Because
of
how?
How
large
the
meeting
has
gotten.
F
Hi
I'm
Steve
Winslow
I
used
used
to
work
at
the
LF
I'm
now
working
as
outside
council
with
the
LF
and
was
just
joining
today.
I
think
at
the
end
of
the
agenda,
I'm
going
to
be
sharing
some
things
about
the
community
specification
process
that
you
talked
about.
So
thanks
for
the
invite
and
happy
to
be
here,
hey
Steve
glad
to
have
you.
C
G
Thanks
so
I
wanted
to
just
mention
that
you
know
like
we
have
a
lot
of
GitHub
issues
for
sure
and
we
certainly
need
contributors,
but
I
want
to
call
out
like
there's
a
list
of
like
we
have
a
tag
and
issues
for
like
kind
of
straightforward
website
work.
That
is
not
really
content
specific
around,
like
fixing
up
the
CSS,
so
we
could
have
multiple
menus
fixing
like
CSS
issues,
switching
to
netlify
for
hosting,
and
so
if
anyone
wanted
to
grab
those
I'd
be
happy
to
talk
more
about
those.
G
But
it's
I've
been
doing
a
lot
of
that
right
now,
but
my
bandwidth
is
kind
of
limited,
so
I
just
want
to
mention
that.
G
H
On
the
notify
one
I
think
Jerry
was
gonna,
handle
that
so
we
should
probably
update
the
issue
I'll.
Do
it
now.
G
G
That's
it
for
that
I
think
next
we
had
is
Brandon
here,
yep,
so
I
think
we're
gonna
have
Brandon
talk
about
salsa
nesbaum.
I
Okay,
okay,
cool,
so
I'm
gonna
share
my
screen
really
quickly
foreign.
I
Do
you
see
the
the
blog
posts,
yep
cool
yeah,
so
I
I
talked
a
little
bit
about
this
last
the
last
session,
but
we
kind
of
fleshed
out
a
bit
more
I.
I
Think
like
what
I'm
hoping
to
get
and
get
from
the
course
to
kind
of
just
share
a
little
bit
of
the
broad
ideas
and
I
think
we're
looking
to
have
this
be
part
of
the
salsa,
the
dev
blog
post,
so
I
think
by
the
end
of
the
call,
maybe
get
some
feedback
as
well
on
your
next
steps
about
creating
a
PR
for
this.
I
I
So
what
we're
trying
to
drive
at
here
is
that
you
know
there
are
a
lot
of
heart
problems
that
are
being
addressed
in
s-bomb
and
there
are
ways
in
which
s
bomb
salsa
can
help
accelerate
solving
those
problems,
as
well
as
using
Concepts
and
principles
of
salsa
to
kind
of
make
s-bombs
add.
As
forms
functionality
to
be
able
to
react
to
things
like
supply
chain
compromises,
so
we
talk
about
a
few
main
problems,
first
of
which,
like
I,
said,
you
know
how
to
respond
to
supply
chain
compromises.
I
Can
we
have
s-bombs
also
be
able
to
do
that?
We
talked
a
little
bit
about
the
distribution
problem
and
how
salsa
can
help,
and
we
also
talk
a
little
bit
about
how
most
Xbox
today
are
generated
with
they
call
it
auto
after
creation
tools.
So
usually
you
end
up
scanning
a
container
or
scanning
a
VM
image
to
kind
of
try
and
create
a
list
of
things
so
very
very
quickly.
You
know
we
talked
mainly
about
accuracy
and
completeness
by
using
the
salsa
attestations
and
build
metadata.
I
We
are
able
to
kind
of
create
a
small,
more
constructively
and
also
the
trust
in
terms
of
okay.
Now
we
can
reference
from
s-bombs,
and
this
is
something
that
we're
talking
about
within
the
spdx
build
profile
working
group.
Okay,
now
we
can
reference
salsa
documents
within
the
s-bombs,
and
this
will
able
be
able
to
provide
additional
level
of
assurance
to
say
that
this
particular
artifact
was
also
built
in
a
trusted
way.
I
It
appears
on
the
material
you
can
look
at
and
we
talk
a
little
bit
a
bit
about
also
kind
of
the
ideas
around
salsa
and
implementation
and
tooling,
and
how
that
can
potentially
be
used
as
one
as
well,
and
the
last
part
of
this
is
talking
about
using
salsa,
build
metadata
to
be
able
to
make
Xbox
more
composable
in
a
way
that
tooling
doesn't
have
to
really
need
to
be
in
need
to
implement
how
to
obtain
s-spawn
for
its
input,
but
rather
just
describe
its
process
resulting
in
composer
composable
as
funds,
and
so
people
can
generate
more
complete
s.
I
Yeah
so
I
think
the
next
step
for
this
would
be
to
create
a
PR
to
put
it
in
the
salsa
soft
sub
block.
But
I
want
to
get
comments
and
and
kind
of
thoughts
from
talk
to.
C
Yeah,
no
definitely
interested
in
reading
more
from
that
I
know.
I
took
a
quick
look
at
it
before,
but
yeah
I
mean
I.
Think
one
of
the
big
things
and
I
don't
know
if
this
gets
into
it,
but
I
think
one
of
the
things
that
was
hugely
valuable
to
me
is
also
having
salsa
like
if
I
know.
Salsa
is
mostly
for
software
artifacts,
but
I've.
Also
and
I'm,
not
saying
it's.
The
best
case
here
use
it
as
a
way
to
sort
of
verify
what
tool
had
built.
C
My
s-bomb,
so
hey
I
have
an
s-bomb
and
I
cared,
whether
or
not
you
know
like
in
a
lot
of
ways:
I
care
that
and
I
know
that
the
s-bombs
itself
and
a
lot
of
the
specifications
today,
you
can
sort
of
say
this
s-bomb
was
built
by
this
tool,
but
that's
kind
of
like
a
self.
You
might
want
to
kind
of
have
a
different
thing
external
say.
No.
This
key
says
you
know
this.
C
This
identity
is
claiming
to
have
built
this
generated
this
s-bomb
using
this
tool
and
I
have
signed
you
know
and
signed
off
on
that
I
think
that
has
also
proven
to
be
very
really
valuable
in
in
this
case,.
C
So
so
there's
a
couple
of
I
I:
don't
want
to
go
too
deep
down
down
that
rabbit
hole,
but
there's
two
two
things
one
is:
if
I
have
an
s-bomb
and
the
s-bomb
itself
says
like
hey,
you
know
you
included
these
libraries
and
whatever
else
it's,
you
know
it's
probably
not
going
to
be
perfect,
because
tools
are
not
perfect
and
so
I
I
want
to
know
what
tool
built
it
right,
because
if
I
need
to
go
back
and
go
oh
geez,
there
was
a
there's,
a
huge
bug
in
in
s-bomb
generation
tool.
C
J
Yes,
thank
you.
I
would
like
to
say
that
to
following
what
you
said
that
the
stations
are
also
also,
of
course,
a
big
part
of
the
discussion
on
sisa
and
ntia
and
specifically
I
think
that
in
salsa
terms,
at
least
to
be
part
of
the
conversation
in
terms
of
what
can
be
recorded
and
what
can
be
journaled
in
terms
of
first
of
all
s-bomb
as
a
inventory,
but
also
as
an
inventory
of
inventory
of
assets,
but
also
its
inventory
of
operations
as
well
and
I.
J
I
Yeah
I
think
I
think
I'm
just
just
to
respond
to
kind
of
that
in
the
in
the
blog
post.
We
kind
of
leave
it
at
very
high
level,
but
yeah
I
think
like
like
we
talk
about
how
some
of
the
assassination
techniques
and
some
of
what
we're
doing
can
kind
of.
I
We
can
use
that
to
Maple
s
bombs
as
well,
but
but
I
do
agree
all
that,
all
that
it's
kind
of
things
we
have
to
discuss
and
I
think
the
call
to
action
for
the
the
blog
post
is
for
the
communities
to
get
together
and
start
talking
about
these.
B
G
Yeah
I,
I,
guess
I.
One
thing
to
follow
on
to
the
previous
comment:
I
feel
like
I've,
been
feeling
more
and
more
that
because
the
salsa
provenance
and
s-bomb
are
so
similar
and
it's
actually
pretty
hard
to
describe
the
differences.
G
They
are
mostly
overlap,
but
they
neither
is
a
superset
or
the
other
I
I
I'd
like
to
consider
going
forward
like
how
we
could
align
them
in
maybe
long
term,
even
making
it
the
same
thing
like
expanding
one
to
fit
the
other
or
making
one
a
superset
of
the
other,
or
something
like
that
just
because
right
now,
just
it's
I
think
it's
too
conflu!
It's
too
confusing
that
we
have
two
similar,
but
not
quite
the
same
Concepts.
C
Yeah
I
I
agree
with
Mark
wholeheartedly.
There
I
know,
I
think
that
there's
also
things
there
that
I'm
going
to
put
as
diplomatically
as
possible,
which
is
just
like
it.
It
is
unclear
because
everybody
has
almost
a
different
definition
of
what
an
s-bomb
is
and,
to
some
extent
you
know
for
the
folks
who
who
have
worked
within
the
yes
bomb
space.
You
know
the
ntia's
minimum
specific
or
minimum
things
for
s-bomb
is
quite
broad.
C
You
know
it's
just
you
know
very
simple
and
you
know
spdx
is
taking
a
bit
of
a
sort
of
approach
on
on
what
should
be
included
and
and
Cyclone
DX
has
taken
a
very
you
know
like
hey,
let's,
let's
throw
everything
in
the
kitchen
set
it
and
there's
also
a
lot
of
other
stuff
that
you
know
potentially
counts
as
an
s-bomb,
but
isn't
an
official
thing
and
I
I.
Think
where
we
can.
We
should
definitely
be
a
bit
more
involved
in
some
of
those
conversations.
B
It's
conversations
come
up
a
lot
in
my
life
lately
and
I.
Think
about
this
from
like
sort
of
a
broad
industry,
change
kind
of
effect
right
and
the
first
question
is:
did
somebody
produce
an
s-bomb
and
the
mere
existence
of
an
s-bomb,
whether
it's
correct,
authentic
or
whatever,
is
a
sort
of
a
threshold?
That's
crossed
it's
very
interesting,
so
you
have
some
Upstream
supplier
now.
Can
you
produce
an
s-bond
for
this,
and
the
answer
is
no
okay,
great
I
have
no
idea
what
you're
doing
my
risk
management
fee
was
very
open-ended.
B
C
From
my
understanding,
that
is
literally
one
of
the
purposes
of
s-bomb
is
hey.
If
you
rally
around
a
thing
that
we
are
going
to
require
great
I,
think
one
of
the
problems
that
has
arisen
from
that,
though,
is,
is
hey.
Nobody
really
sort
of
clearly
defined
s
bomb
and
what
the
use
cases
for
s-bomb
were,
which
then
led
to
a
lot
of
Confusion
And.
C
I
Sorry
I
just
wanted
to
to
talk
a
little
bit
about
that
I
think
did
the
earlier
Point
I
think
that
mocked
me
that
I
think
one
interesting
thing
is
like
something
like
spdx
doesn't
claim
to
just
be
a
spot.
So
I
think
that
that
is
that
future
accessibility,
I
know
with
them
for
Microsoft,
is
kind
of
thinking
about
that
in
the
future
as
well,
and
also
to
the
use
cases.
I
I
think
there's
been
kind
of
the
effort
from
the
different
profiles
and
spds
are
kind
of
like
solid
divide,
that
a
little
bit
more
so
I
do
agree
with
you
Michael
that
that
is
something
that
is
lacking,
but
hopefully
we
we
will
get
some
more
clarity
on
that
foreign.
C
A
Yeah
I
mean
I
sort
of
agree
with
one
of
the
other
two
Michael's
right
and
and
I
think
it's
a
great
rallying
call
looking
at
the
the
s-bomb
and
it's
a
good
start.
It
gets
people
to
focus
on
it,
but
one
of
the
things
that
we're
looking
at
is
as
soon
as
people
start
to
send
through
the
M
swarms,
and
you
start
to
try
and
make
some
something
out
of
it.
You
know
we
need
to
look
at
the
contents
of
that
s
bomb
and
the
quality
of
s-bomb.
A
You
know
maybe
not
the
tool
that
it
came
from,
but
you
know
one
s
bomb
isn't
going
to
be
the
same
as
another
one
and
we
need
to
get
an
understanding
of
you
know
the
actual
qualitative
nature
of
the
air
spawn
for
it
to
actually
provide
any
benefit
for
the
end
user
and
well,
you
know
what
we're
trying
to
look
at
is
the
different
attributes
that
make
that
thing
up
as
well
as
you
know
where
it
came
from
and
whether
we
actually
believe
it
in
the
first
place
when
it
gets
distributed.
A
So
let
me
definitely
need
to
start
taking
a
look
at
that.
C
Cool,
so
I
think
probably
want
to
move
on
to
the
next
topic
here,
so
we
still
have
time
but
I
think
one
thing
to
tie
it
together.
It
just
sounds
like
probably:
this
group
wants
to
maybe
talk
more
about
use
cases
and
what
sort
of
the
data
we're
trying
to
get
out
of
there
and
then
collaborate
with
some
of
the
s-bomb
folks
and
then
cool
next
up.
Mark
road
map.
G
G
G
G
You
know
both
long
term
and
short
term
over
the
next
several
quarters
for
the
short
term
and
then
just
kind
of
long-term
guiding
Vision.
So
what
I
have
here
is
an
attempt
to
aggregate
what
I
think
is
the
important
points
that
people
have
been
bringing
up
over
time,
and
so
this
is
more
of
a
starting
point
for
discussion.
It's
not
like
this.
G
Is
it,
but
but
I'd
like
to
I
want
to
propose
present
it
here
during
this
meeting,
and
then
we
could
move
it
to
like
the
salsa
proposals
and
eventually
make
it
like
a
public
thing
with
you
know:
input
from
everyone,
so
I
tried
organizing
around
four
long-lived
themes.
That
I
think
are
the
main
kind
of
areas
of
work
that
will
be
going.
G
You
know
over
the
years
doing
over
the
years
when
related
to
salsa
and
then
some
priorities
for
2022
that
set
realistic
goals
for
what
we
could
actually
accomplish,
and
the
goal
here
is
to
kind
of
organize
people,
so
we
could
kind
of
so
different
folks
could
work
on
the
different
parts
that
they're
they're
they're
interested
in
in
terms
of
themes.
G
I
think
it
seems
to
me
that
the
the
four
main
long
like
areas
of
work
are
specifications
tooling
adoption
and
stand
like
government
or
in
just
like
standards,
something
like
that
in
terms
of
the
specification
we
want
to
have
the
specification
be
stable,
practical
and
useful
for
reducing
risk
with
a
healthy
surrounding
community,
and
that's
like
the
things
around
the
salsa
levels
themselves,
formats,
the
website
documentation,
Etc,
not
any
particular
implementation,
but
just
people
do
to
go
around
the
salsa
project
then
have
tooling
services
and
documentation
makes
also
readily
adoptable.
G
Then
another
third
thrust
would
be
actual
adoption
of
salsa
within
the
open
source
community
so
that
we
with
the
goal
of
actually
reducing
risk
because
just
making
things
possible
doesn't
actually
reduce
risk
and
then
fourth
would
be
to
make
government
and
Industry
widely
accept
salsa
as
the
lingua
Franca
of
supply
chain
security.
G
So
that
way
and
and
I'll
talk
about
each
of
those
in
the
next
couple,
slides
so
I
guess,
I,
don't
know
if
it's
useful
to
kind
of
pause
there
to
talk
about
these
or
to
go
on
I
guess
I'll
just
go
on
and
then
we
could
talk
about
the
whole
thing.
G
Phil,
though,
feel
free
to
interrupt
in
terms
of
the
specific
work
that
we
could
do
in
the
specification
in
the
next
couple
quarters
next
quarter
or
two
I,
like
I,
talked
to
a
couple
other
folks
about
this
as
well.
I
think
it's
worthwhile
to
think
about
having
a
stable
release
say
by
the
end
of
June
September
sometime
within
June,
a
1.0
release,
my
proposal
that
I
would
like
to
start
with
and
I'll.
You
know
actually
have
a
full
proposal
and
we'll
discuss
this
fully
in
a
way.
G
The
pros
and
cons
would
be
to
Pare
down
salsa
to
just
the
core
parts
that
we
all
agree
on
and
I'll
talk
about
that
in
the
next
slide
and
simultaneously
having
a
framework
to
extend
salsa
beyond
that
core
that
core
competency
there's
been
discussions
around.
G
So
first
of
all,
there's
also
one
I
propose
that
removing
like
the
two-party
review
and
the
source
requirements,
because
it's
kind
of
ill-defined
right
now
and
there's
been
a
lot
of
concerns
around
how
we
actually
Implement
that
in
practice
and
whether
that
will
actually
work
and
whether
organizations
can
actually
choose
code
review.
G
G
There
could
be
other
aspects,
other
parts
of
supply
chain,
security
that
are
not
just
build
integrity,
and
so,
if
we
could
figure
out
how
we
could
evolve
salsa
over
time
to
address
these
more
broad
threats
and
kind
of
start
with
something
small
that
we
think
that
we
do
well
and
then
once
we
kind
of
have
that
we
could,
we
could
expand
and
then
also
finalizing
the
or
at
least
having
a
1.0
release
for
our
attestation
formats,
which
are
currently
0.x
and
finally,
something
about
Community
Health.
G
Just
to
make
sure
we
have
like,
by
whatever
measure
we.
We
agree
upon
so
for
for
1.0,
I,
I
I
plan
to
propose
for
for
everyone
to
review
and
get
discussion
on,
that.
We
just
focus
on
build
Integrity,
so
that
is
mapping
a
binary,
artifact
back
to
the
canonical
Source
Repository
and
it,
and
because
that
is
a
I,
think.
G
That's
really
the
core
strength
of
what
salsa
is
today
and
we
kind
of
defer
the
two-party
review
and
Source
Integrity
stuff
for
an
extension
in
terms
of
1.0
things
that
I
would
like
to
see
for
for
1.0
would
be
defining
levels
in
terms
of
actual
security
guarantees
and
threats.
G
I
think
there
was
an
issue
raised
by
I
forget
whom
around,
like
those
I
think,
was
like
less
reductive,
salsa
levels
or
something
like
that
like
resolving
that
and
making
sure
that
the
levels
kind
of
are
more
meaningful,
I
think
we
need
to
re-add
some
concept
of
policy
and
verification
that
has
come
up
several
times
in
discussions.
G
We
have
various
issues
around
Clarity
around
terminology,
Etc
that
we
we
should
resolve
and
then
figure
out
like
what
is
the
upgrade
path
for
versions
like
if
we
call
us
also
something
it's
also
two
today
and
then
the
we
change.
What
salsa
II
means
in
the
future.
How
can
people
refer
to
it?
Do
we
do
a
version
number
Etc?
We
already
have
a
a
GitHub
issue
about
that,
but
I
just
want
to
make
sure
that's
clear
and
documented
and
and
people
and
it's
stable,
going
forward.
G
In
terms
of
tooling
I,
I
think
that,
in
order
to
make
salsa
possible
I
think
what's
what
seems
to
be
practical,
is
figuring
out
three
main
areas.
One
is:
how
do
you
build?
How
can
projects
build
at
least
open
source
software
using
public
CI
CD
systems
in
a
way
that
reaches
High
salsa
levels?
There's
already
some
work
going
on
around
GitHub
actions
in
Sig,
store,
I,
think
this
is
really
valuable.
G
Continuing
that
process
and
that's
just
generating
provenance,
then
the
other
two
main
problems
are:
how
do
we
distribute
the
provenance
so
that
way,
when
people
consume
software
artifacts
that
they
know
where
to
find
it,
and
then
how
do
people
verify
provenance?
And
how
do
you
know
what
to
check
in
particular?
How
do
you
know,
for
example,
that
a
particular
python
package
was
supposed
to
come
from
a
particular
git
repo
and
that
someone
can't
change
that
binding?
So
these
are
the
things
I
think
that
we
should
solve
within
the
next.
G
You
know
at
least
make
a
decision
and
have
a
design
within
the
next
couple
months
and
hopefully
have
implementations
in
the
quarter
that
follows
in
tentatively.
We
can
try
to
propose
this
within
a
python
ecosystem.
We
have
supportive
Dustin
Ingram,
who
is
one
of
the
Python
software
Foundation
steering
committee
members
I,
don't
know,
what's
called
so
there's
at
least
some
support
within
the
quiet,
Sound
Community
that
and
there's
also
I.
G
Think
no
various
folks
here
are
also
worked
on
working
on
efforts
right
now
around
securing
python
around
like
tough
and
things
like
that,
and
so
this
would
not
like
preempt
that
work,
but
would
be
more
follow-on,
work
in
terms
of
adoption,
I,
realistically
I,
don't
think,
there's
I,
don't
think
it's
realistic
to
to
try
to
have
wide
scale
adoption
at
least
this
year.
I
think
we
should
probably
just
search
for
Target
adoption
for
where
we
could
have
kind
of
key
projects
highlight
salsa.
G
You
know
like
we
could
do
this
for
for
six
store
and
District
Lich,
which
we're
closely
lined
with
any
other
volunteers
like
that,
but
I
I
think
it's
kind
of
too
early
to
start
like
trying
to
get
like
thousands
of
projects
to
to
to
do
salsa,
because
it's
not
streamlined
enough
and
then
the
other
theme
in
terms
of
government
is
that-
and
this
seems
I
think
it's
a
pretty
high
priority.
G
That
Salsa's
relationship
to
government
standards
and
conformance
is
is
clear,
particularly
around
s-bomb,
which
we
just
discussed
in
ssdf.
It's
coming
up
at
a
lot
of
community
meetings.
We
have
various
GitHub
issues
around
this,
it's
on
the
top
of
a
lot
of
people's
minds,
and
so,
if
we
have
a
clear
story
for
how
salsa
relates
to
these
things
and
which
Isaac
will
be
talking
about
in
a
minute,
that's
something.
I
G
Like
to
to
have
that,
we
that
we
have
this
clear
documentation,
so
I
I,
don't
know
if,
if
Isaac,
if
you
want
to
go
the
next
thing
or
we
should
just
have
discussion
now,.
K
I
G
G
Yeah
well,
I,
don't
even
know
if
it
would
necessarily
like
want
to
avoid
that
like
I,
think
that
would
be
a
fine
option
if
it
has,
if
there's
value
in
it,
but
like
there's
all
these
other
things
going
on
too
ssdf
and
s
bomb
in
particular,
but
but
there's
other.
You
know,
there's
also
like
PCI
and
various
other
things
and
coming
up
with
a
relationship
to
all
these
things.
I
think
would
be
valuable
like
where,
where
do
we
fit
in.
E
E
I
think
just
like
you
know,
from
our
perspective,
we'd
also
like
to
see
a
mechanism
for
proprietary
build
systems
to
get
Soldier
certified
as
well.
In
that
you
know,
we
we've
got
this
thing.
That
is
it's
kind
of
is
mostly
social
compliant
in
spirit,
at
least,
but
it's
our
proprietary
build
system
as
soon
as
we
start
generating
our
stations.
C
So
one
other
thing
and
I
didn't
see
it
in
there,
but
I
think
it's
something
that
is
is
I.
Think
critical
for
the
1.0
is.
We
should
really
clarify,
maybe
a
set
of
like
demonstrative
artifact
types
that
we
are
sort
of
gearing
towards
for
salsa,
because
I
mean
literally
yesterday
in
the
wild
you
know
did
see
and
to
be
clear
that
the
folks
who
were
sort
of
involved
here
were
like
hey.
C
This
doesn't
make
sense
because
if
I
have
let's
say
a
Helm
chart,
I
can
certify
my
Helm
chart
as
essentially
salsa
IV,
because
it
itself
doesn't
really
have
a
build.
It's
just
some
text,
but
does
that
really
mean
anything
and
I
think
we
should
really
be
clear
about?
You
know
when
talking
about
salsa,
at
least
initially.
We
should
be
talking
about
certain
kinds
of
artifacts
that
are
probably
the
important
stuff
that
you
want
to
have
statistications
for.
C
B
You
know
you
mentioned
home,
charts
or
deploy
scripts
like
that,
and
so
the
line
for
me
is:
was
this
code
reviewed
by
humans
or
managed
by
the
editing
process
of
a
bunch
of
humans,
whether
they
code
review
or
not?
Or
was
this
generated
by
another
piece
of
software,
because
the
sort
of
the
risk
changes
dramatically
there
right
and
so
there's
a
whole
bunch
of
interesting
things
that
happen
with
IDE
plugins?
B
When
you
don't
have
code
reviews
or
when
you
do
have
code
reviews
who
reviews
all
that
generated
boy
that
play
code
and
if
a
Helm
chart
is
programmatically
generated
by
some
Upstream
script
or
something
like
that,
then
that
thing
and
the
thing
that
runs
it
becomes
part
of
your
risk
analysis
as
well.
So
I,
don't
know
if
that's
what
you
meant
or
if
I'm
misinterpreting
what
you're
talking
about.
Oh.
C
Yeah
so
to
be
clear,
I
think
that's
important,
but,
for
example,
if
let's
say
the
helm
chart,
if
somebody
says
hey,
my
Helm
chart
is
salsa.
Three
salsa
four
and
I
can
show
that,
because
the
health
chart
itself
is
mostly
just
text
and
whatnot,
but
then
what
the
helm
chart
calls
like.
All
those
images
have
no
salsa
attestations.
C
B
B
B
C
To
be
clear,
I
think
both
are
important
but
I
think
without
getting
into
the
recursive
salsa
problem
too
much
I
think
that
there
probably
is
still
value
in
sort
of
saying
like
please
be,
please
understand
when
looking
at
these
things,
you
know,
if
you
want
to
sort
of
build
your
salsa,
you
should
be
really
looking
at
these
areas.
The
most
important.
B
Yeah,
like
a
prioritization
of
that
yeah
I,
agree
and
then
one
other
piece
I
really
liked.
You
know
the
presentation
you
just
gave
around
focusing
on
tools
and
adoption.
Personally,
those
things
would
help
me
a
lot.
I
was
actually
just
thinking
this
morning,
man
I
wish
there
was
like
a
really
clear
public
repository
that
that
use,
you
know,
has
salsa
level.
Four
and
I
can
like
just
Trace
that
and
understand
that
it'd
be
really
helpful
for
me
just
to
kind
of
comprehend.
What's
going
on
with
that,
so
that'd
be
great.
B
L
L
Would
it
would
it
be
possible
I,
guess
then,
or
would
it
be
fair
to
say
that
if
you're
looking
at
a
Helm
chart
that
has
dependencies
of
varying
salsa
levels,
would
it
be
more
of
a
an
accurate
representation
to
use
the
lowest
kind
of
common
denominator
to
to
give
the
Assurance
for
that
type
of
artifact,
I?
Guess
like
looking
through
the
dependencies?
If
you
have
something
like
one
dependency,
that's
you
know
salsa
for
one
that
is
salsa
one.
L
Would
that
then
entail
the
overall
like
kind
of
the
package
of
that
to
be
salsa
one
assuming
it
goes
through.
All
the
things
that
it
needs
to
do
in
order
to
you
know
actually
be
social.
C
Yeah
Tom
just
posted
a
link
about
something
that
I
think
is,
is
being
pitched,
as
you
know,
as
a
way
to
sort
of
approach
that
problem.
But
foreign
thing
is
just
there's
a
lot
of
landmines
there
that
we
need
to
be
aware
of
mark.
G
Yeah,
thank
you
Jacques
for
doing
a
time
check.
I
want
to
take
the
last
five
minutes
of
the
slot
to
I
gave
it
to
Isaac
to
talk
more
about
some
long-term
vision.
D
Yeah
thanks
Mark
I,
appreciate
that
and
I'll
try
and
go
quickly.
I
want
to
make
sure
that
we
we
leave
room
for
Steve
at
the
end
until
I'll
just
take
a
few
minutes.
There
are
a
few
observations
that
I've
had
you
know
the
less
a
few
weeks
and
months
here
and
I
would
put
in
a
one
of
them
issue
276,
which
was
raised
in
January,
was,
you
know,
really
broad
but
useful
question
around.
How
does
salsa
fit
into
broader
supply
chain
security?
D
And
we
don't
have
resolution
for
that
issue,
but
it
got
me
thinking
and
then
I've
also
been
you
know.
Reading
the
the
you
know,
the
chain
guard
blog
series
on
on
ssdf.
D
D
If
you
look
broadly
across
across
the
four
categories
of
concerns,
it
covers
that's
preparing
the
organization
protecting
the
software
producing
well
secured
software.
Responding
to
vulnerability
is
there's.
There's
obviously
overlap
of
concerns
there
you
can
call
it.
You
know
specific
items
of
ssdf
which
map
really
well
to
salsa,
particularly
around
protect
the
software
and
produce
well
secure
software,
but
there's
there's
not
there's
not
good
coverage
around
things
like
responding
to
vulnerabilities,
for
instance,
so
I
make
that
that
one
observation
about
their
their
you
know
their
intersection
today.
D
I'd
also
make
the
observation
that
the
ssdf
I
think
you
know
is
you
know
it's.
It's
super
dense
with
footnotes,
it's
very
small
print.
It's
you
know
it
it
caveats
itself.
So
it's
not
a
checklist.
It's
a
descriptive.
You
know
Broad
and
encompassing
Foundation
and
so
I.
Think,
there's
you
know,
there's
there's
an
opportunity
there
for
ssdf
to
think
about.
You
know
how
can
we
make
ourselves
more
more
actionable
and
more
adoptable
if
I
look
at
Salsa,
which
obviously,
who
said
you
know,
shares
a
bunch
of
concerns
with
SSDI?
D
If
I
think
you
know
it's
also,
the
philosophy
seems
to
me
that
it's
it's
rooted
in
pragmatism
and
ergonomics.
It's
it's
very
approachable
and
Mark
talked
earlier
about
that.
The
core
technical
strengths
of
salsa
I
think
the
core
structural
strengths
of
salsa
is
that
it's
the
ergonomics
of
the
framework
itself.
It's
easy
to
get
on
this
lab
and
once
you're
on
the
ladder
each
rung
is
easily
reachable
from
the
last
and
it
gives
it
a
flavor
of
a
transformation
framework.
D
Recognizing
that
adoption
is
is
not
you
know,
a
single
action,
it's
a
journey
for
most
organizations,
it's
a
multi-step
process,
and
so
with
these,
this
set
of
observations
about
ssdf
and
salsa,
and
it
seems
to
me
that
there's
there's
an
opportunity
to
evolves,
alter
over
time
to
fill
this
gap
for
a
transformation
framework,
aligned
with
ssdf
practices
and-
and
you
know,
I-
think
it
was
pertinent
that
we
talked
earlier
about
you
know
we
don't
want
to
be
too
us
Centric
and
think
about.
D
You
know
ssdf
as
the
be
all
and
end-all
of
government
standards,
but
I
do
think
that
you
know
ssdf
as
a
set
of
practices
is
a
useful
foundation
and,
looking
at
you
know
how
could
salsa
expand
its
scope
to
cover
more
of
this
and
actually
become.
You
know
something
more
like
a
prescriptive
counterpart
to
ssds.
A
descriptive
Foundation,
you
know
a
practical,
a
practical
SQL
was
the
guy
to
do
increasing
conformance
with
ssdf
I
think
would
be
really
useful
and
ultimately
I
think
there's
there's
benefit
for
ssds.
D
In
terms
of
you
know,
it
needs
an
actionable
on-ramp
to
conformance
it's
not
actionable
as
as
it
is,
but
it
is
powerful
in
terms
of
I
mean
it
is
Broad
encompassing
and
generic
and
very
broadly
applicable
to
a
wide
range
of
organizations
and
disparate
sets
of
sdlcs
I
think
that
the
salsa
would
stand
to
benefit
from
a
grizzlers
through
increased
relevance
and
value.
I.
Think
that
there
is
this
Gap
and
I
think
that
the
people
are
are
wondering
you
know
where
do
I
begin?
D
You
know
what
is
my
first
step
and
then
what
are
the
next
steps
from
there
in
terms
of
increasing
my
security
posture
and
supply
chain
and
so
I?
One
of
the
things
you
know
I've
been
talking
to
others
about
and
working
on
here
is
you
know,
a
brief
proposal
which,
which
I'd
love
to
share
and
and
use
as
the
the
basis
for
some
discussion
and
where
I
kind
of
laid
out.
D
You
know
these
observations,
how
they
fit
together
and
the
opportunity
I
see
this
also
in
the
long
term
to
become
you
know
broader
in
its
scope
and
really
bring
its
core
strengths
to
bear
in
complementing
these.
You
know
descriptive,
Frameworks,
like
ssds
and
bringing
Salsa's.
You
know
ergonomic
and
approachable
and
and
pragmatic
approach
to
that
so
I'm
gonna,
I'm
gonna
pause.
D
There
I've
taken
my
five
minutes,
but
in
the
next,
the
next
day
or
so
I'd
love
to
share
a
proposal
Doc
and
invite
you
all
to
comment
to
agree
to
disagree
and
and
help
shape.
D
This
idea
and
I
think
that's
something
here,
and
this
isn't
something
which
no
I
I
say
it's
not
entirely
baked,
but
I
I
would
love
to
get
the
input
of
the
group
and
and
help
shape
this
into
something
which
we
can
all
get
behind
and
believe
in
so
I'll
share
a
document
in
in
the
coming
day
or
so
and
I
as
I
said:
I
I.
D
Just
this
is
a
preview
of
some
of
the
ideas
in
that
document
and
invitation
to
to
jump
in
and
and
and
help
me
help
me
take
this
somewhere.
D
Foreign
I
can
yield
my
time
and
Steve
you've
I've
taken
two
of
yours.
You've
got
13
minutes,
left
I.
Think
of
your
15.
F
No
worries
thanks
I
will
go
ahead
and
jump
in
so
this
I
think
is
a
follow-up
from
looks
like
a
conversation
that
the
salsa
group
had
with
I
think
with
it,
with
Mike
Dolan
and
Scott
Nicholas
over
at
the
LF
about
Community
specifications
and
adopting
the
community
specification
governance
and
license
model
for
the
salsa
spec.
F
F
I
put
it
kind
of
in
chatting
with
a
couple
folks
I
put
together
a
draft
repo
for
what
the
governance
could
look
like
for
salsa
using
Community
specs,
and
this
is
basically
leveraging
on
the
what
we
did
on
the
spdx
side,
I'm
on
the
part
of
the
spdx
steering
committee,
and
we
adopted
similarly
adopted
Community
specs
last
year
for
spdx
going
forward,
and
so
what
this
is.
F
This
is
just
in
my
personal
repo
right
or
personal
org
right
now,
but
this
was
a
draft
attempt
to
take
the
community
spec
structure
and
license
structure
for
governance
and
the
standard
files
for
the
community
specification
process
to
take
them
and
Implement
them
for
salsa.
F
There
are
a
few
specific
things
that
I
had
that
I
wanted
to
flag
for
the
community
to
think
about,
and
so
I've
got
issues
listed
for
each
one
of
those
I'm
happy
to
talk
through
those
quickly
on
this
call
or
just
kind
of
leave
it
here
for
the
community
to
look
at
and
to
take
a
closer
look
at,
but
mostly
Kim
they've
been
talking
with
Kim
about
this
event,
she
had
asked
me
to
come
and
share
this
with
the
the
group
to
basically
get
more
eyeballs
on
it
and
get
people
looking
at
this
in
case
this
is
the
direction
the
community
wants
to
go.
F
So
let
me
pause
there.
I
know
I
wasn't
on
the
prior
calls
where
it
looks
like
this
was
discussed
in
December,
so
I'm
not
sure
to
what
extent
folks
on
this
call
are
familiar
with
Community
specs.
If
any
of
this
sounds
familiar
or
not,
but
I'm
happy
to
kind
of
give
a
very
quick,
very
quick
overview
or
talk
about
some
of
the
specifics
for
what
I've
done
here.
H
F
Yeah,
so
I
can
I.
I
can
I'm
not
as
familiar
with
with
sauce's
current
practices,
and
so
what
I
can
speak
to
is
what
the
community
spec
process
looks
like.
So
there's
a
few
a
few
significant
changes,
one
of
them
is
to
adopt.
It
would
be
to
adopt
the
Community
specification
license
as
the
license
for
the
spec
and
briefly,
one
of
the
key
things
about
one
of
the
key
reasons
that
projects
have
been
starting
to
adopt.
The
community
specification
license
is
because
of
the
the
scope
of
the
patent
grants.
F
The
idea
that
it's
staining
clear
patent
license
is
granted
to
Downstream
users
for
the
spec
as
a
whole
for
from
from
among
all
of
the
contributors
to
that
spec,
which
is
Works
a
little
bit
differently
for
specifications
than
it
does
for
software
or
for
other
collaborative
developed
content.
So
the
the
from
a
practical
matter,
I
think
the
major
differences
are
a
couple
of
things.
One
is
that
there's
a
if
you?
If
you
look
in
this
repo
there's
a
the
document.
F
F
For
saying,
for
with
regards
to
the
spec
itself,
or
to
one
or
one
or
its
collection
of
specs,
the
idea
of
having
specific
roles
of
maintainers
and
editors,
the
a
process
and
ways
of
working
that
are
are
similar
to
and
derived
from
other
standards
body
organizations,
but
in
a
way
that
is
meant
to
be
very
lightweight
and
operating
through,
essentially
through
PR's
being
submitted
on
GitHub
and
issues
being
discussed
on
GitHub
rather
than
through
some
of
the.
F
What
can
be
more
heavy-handed,
IP
policies
and
signatures
and
such
for
other
standards
body
operations.
So
but
it
has
a
very
kind
of
lightweight
process
for
defining.
What's
at
what
point
is
something
a
draft
specification
kind
of
having
a
formal
approval
of
it
and
having
that
approval
tied
into
aspects
of
the
community
spec
license
for
when
it
is
published
when
the
license
grants
are
officially
made?
F
So
this
that
this
is
much
of
this
is
heavily
customizable.
On
the
spdx
side,
we
made
some
significant
changes
to
the
governance
policy
to
reflect,
because
spdx
had
been
around
as
a
as
a
project
for
about
10
years,
we
made
a
number
of
changes
to
the
kind
of
the
roles
the
decision-making
processes
different
pieces
of
that
to
align
with
the
way
that
the
community
had
been
working
but
still
aligning
to
the
to
the
enabling
the
community
spec
license
to
work
for
the
spec
itself
and
I
just
I
see
in
the
chat.
F
What
Jacques
just
noted
there
is
exactly
right.
That's
the
the
model
is
basically
that
there
are
different
licenses
for
different
aspects
of
what
the
community
is
producing
and
so
code
would
continue
to
be
under
Apache
too.
The
idea
is
that
the
spec
would
be
under
the
Community
spec
license
so
that
it
picks
up
those
appropriate
patent
licenses
for
Downstream
users
to
rely
on.
F
So
the
the
specific
questions
that
I
had
you'll
see
in
the
issues
here
of
one
of
them.
It
looks
like
shock
I
think
you
may
have
just
answered
this
for
me,
but
it
looked
to
me
that
part
of
the
governance
process
mentions
just
indicating
what
is
the
default
license
for
the
community
use
for
code?
It
looked
to
me
like
Apache.
2
is
what
you're
using
and
it
sounds
like.
That's
the
case.
I
did
see.
F
There
was
one
thing,
just
a
GitHub
actions,
demo
repo
that
was
under
MIT,
but
the
rest
seem
to
be
patchy
too.
So
I
just
wanted
to
confirm
with
the
community
that
you
are
using
Apache
to
for
the
code
side
of
things.
That's
correct.
Okay,
great
in
Arnold,
I
see
that
I
see
you
have
your
hand
raised,
go
for
it.
Yes,.
K
Hi
I'm
actually
quite
familiar
with
the
community
and
the
the
sorry
this
framework,
but
what
I'm
surprised
by
is
the
way
you
present
it
as
like.
This
is
an
option.
I
think
it's
actually
a
bug
that
it's
not
being
used
already.
The
open,
ssf
Charter
actually
specifies
which
license.
We
must.
We
must
use,
and
it
actually
says
we
are
supposed
to
use
this
community
specification
license.
So
it
from
my
point
of
view.
F
Gotcha
and
thank
you-
that's
helpful,
I
yeah
apologies,
I
kind
of
I
came
in
mostly
to
help
with
this,
because
we
had
done
there.
We
had
done
some
similar
implementation
of
it
on
the
spdx
side,
and
so
they
asked
me
to
come
and
help
kind
of
just
get
the
get
the
make
the
specific
tweaks
that
were
needed
to
be
made
to
have
it
work
with
salsa,
but
I
wasn't
I.
F
F
Then
one
is
that
there's
one
of
the
files
in
the
repo
is
called
scope,
and
what
that
does
is
that
defines
essentially
the
scope
of
the
the
intended
scope
of
the
specification
and
it's
relevant,
because
this
is
what
the
scope
what's
in
the
scope
file
drives
the
scope
of
the
patent
licenses
that
are
granted
by
the
license,
and
so
the
what
I
did
was
I
drafted
kind
of
given
my
own
limited
knowledge
of
sauci,
drafted
kind
of
what
it
looked
to
me
would
be
a
kind
of
concise
way
of
describing
the
scope
of
what
the
project,
and
specifically
the
spec,
would
be
addressing
this.
F
This
is
something
again
that
can
be
can
be
modified.
I
may
have
gotten
it
wrong
here,
certainly,
but
the
two
things
I'd
say
is
one:
is
that
this?
This
is
not
limiting
the
scope
of
what
the
project
can
work
on.
J
Yeah
I'm
not
sure
if
it's
relevant
and
you
you
just
I,
think
covered
it,
but
for
what
is
worth
there
is
a
current
discussion.
This
revolving
around
scope
for
salsa
in
general
as
far
as
I
know,
I'm
not
in
front
of
it
right
now,
but
I
think
it's
still
open.
So
you
might
want
to
refer
to
this
discussion
for,
for
whoever
wants
to
join
in.
F
Got
it
got
it?
Thank
you,
yeah
that
that's
helpful
to
know,
and
if
there,
if
you
do
have
or
if
you
find
a
link
to
somewhere
where
that
discussion
is
happening,
I'll
I'd
be
happy
to,
or
you
can
add
it
to
the
the
thread
here.
Mostly
I,
just
I
had
opened
these
threads
to
have
it
be
here
for
the
community
to
be
able
to
to
address
it
so.
J
F
The
Note
perfect,
thank
you,
I'll
go
grab
it
from
there
and
Mark
I
see
you
have
your
hand
raised,
go
forward.
G
Yeah
I
actually
found
I
actually
find
that
this.
Could
this
format
confusing
like
the
scope,
sounds
a
bit
ambiguous
to
me?
I
would
have
expected
that
I
mean
maybe
just
because
I
don't
know
much
about
licensing
of
like
this
file.
Has
this
license
that
file
has
that
license,
whereas
this
scope
is
kind
of
a
very
abstract
definition,
and
it
leaves
a
lot
of
room
for
interpretation.
G
Also,
there's
like
our
documentation
and
specifications
are
kind
of
mixed
together.
So
it's
not
it's
not
obvious
to
me.
What
like
what
applies
to
what
of
like?
G
Does
the
whole
repo
just
have
the
community
specification
license
and
that's
that,
like
I,
don't
understand
really
what
this
scope
is
intending
to
do.
F
Sure
sure,
no
good
good
questions,
the
part
of
the
intent
part
of
the
way
that
Community
specification
as
a
model
works
is.
The
idea
is
that
at
certain
points
in
time,
there's
going
to
be
released
an
official.
This
is
the
version
one
spec.
F
This
is
the
version
two
spec
and
the
idea
is
that
the
I
apologize
I'm
switching
through
tabs
here,
but
the
idea
is
that
the
licenses,
and
particularly
the
patent
licenses
that
are
being
granted
by
under
the
Community
spec
license
that
those
are
tied
to
specific
approved
version
like
specific
approved
specifications
and
their
Grant.
F
The
patent
licenses
are
granted
to
claims
that
are
within
capital,
S
scope
there,
for
so
it's
basically
for
people
who
are
taking
the
spec
and
implementing
it
down
in
in
other
tools
or
in
other
ways
that
the
scope,
what's
determined
for
the
scope
of
the
patent
licenses
that
are
granted,
are
driven
from
the
scope
as
it's
defined
in
this
file.
So
this
file
isn't
really
I
I
understand
your
question.
I
think
I
understand
your
question
about
you
know:
there's
a
variety
of
licenses
that
apply
to
different
things.
F
Like
code
is
going
to
be
Apache
to
documentation,
that's
not
officially
part
of
the
spec
would
be
under
under
Creative,
Commons
and
so
on,
but
for
the
the
ideas
that
the
materials
that
are
the
spec
itself,
their
license
would
be
the
community
specification
license
version
one
and
where
that
license
grants
patent
licenses
driven
by
the
scope.
The
idea
is
that
the
scope
would
be
whatever's
defined
here,
whether
it's
what
I
put
here
or,
however,
the
community
plans
to
to
modify
this
so
I'm,
not
sure.
If
that
answered
your
question
but
I
hope.
F
Any
other
questions,
any
the
the
main
points,
I
would
say
would
be
I
think
what
would
be
helpful
for
next
steps
would
be
to
look
at
these
four
issues
that
I've
got
in
this
in
the
draft:
salsa
governance,
repo
and
weigh
it
that
I'm
going
to
go
ahead
and
close
out
the
one
on
Apache
2
as
the
license
for
source
code,
because
I
think
we've
we've
talked
about
that
the
other.
F
The
other
ones
are
mostly
the
the
particularly
looking
at
the
scope
and
reviewing
the
government's
process
that
process
of
how
to
how
releases
of
the
spec
would
get
designated
as
draft
or
approval
kind
of
reviewing
that
and
seeing
if
those
fit
with
the
way
that
the
community
wants
to
operate
and
then
the
the
other,
the
fourth
one
is
just.
There
is,
as
part
of
this
there's
also
a
code
of
conduct.
F
That's
that's
included
and
part
of
the
files
include
wanting
to
have
points
of
contact
designate
a
few
people
as
points
of
contact
for
code
of
conduct.
So
that's
a
little
to
the
side
of
the
license
and
governance
part,
but
just
also
an
open,
an
open
Point
for
the
way
that
this
is
set
up
so
and
I
yeah
go
for
it.
Oh.
C
I
was
just
going
to
say
so
once
again,
quick
out
of
band
because
we're
already
over
time,
but
is
there
some
way
that
some
of
us
can
maybe
reach
out
to
you
about
some
of
this,
just
to
make
sure
that
it
sounds
like
all
projects
under
openssf
should
be
adopting
this
already
and
if
they
aren't
it's
probably
some
sort
of
you
know
it's
a
bug,
and
so,
if
there's
there's
any
way,
you
know
I
know
there's
a
lot
of
other
open
ssf
projects
that
probably
were
grandfathered
in
or
otherwise
might
not
have
done
this-
that
we
probably
want
to
just
make
sure.
F
F
F
All
right
cool:
well,
thanks
anyway,
everyone,
you
feel
free
to
drop
comments
into
the
threads
there.
The
issue
threads
there
as
I
said
I.
Think
once
it's
lot
once
it's
solidified
the
goal
will
be
moved
it
over
into
this.
The
salsa
org.
So
that's
great.