►
From YouTube: SLSA Bi Weekly (March 31, 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).
D
C
C
Okay
bruno:
is
it
yeah?
That's
me,
okay,
so
I'll
message
you.
D
D
All
right,
let's
go
ahead
and
get
started.
I
have
a
first
couple
of
items
on
the
agenda,
the
second
one
we
can
maybe
move
to
to
the
end
of
the
day.
If
we
have
time
the
first
one
was
just
a
link
that
I
wanted
to
share
and
we
saw
this
thoughtworks
piece
on
salsa.
D
I
thought
it
was
pretty
cool,
feel
free
to
feel
free
to
check
it
out.
Is
anyone
from
thoughtworks
on
the
call
or
had
any
thing
to
do
with
this?
D
F
D
Cool
yeah
so
check
that
one
out
and
then
the
next
thing
I
put
this
is
more
of
a
discussion
topic
and
for
some
of
the
folks
on
the
call
you
can
just
tell
me,
there's
already
an
issue
for
this,
but
one
of
the
things
we
were
talking
about
at
my
company
was
just
like:
does
every
does
every
company
need
to
strive
or
every
project
need
to
strive
to
get
to
salsa
for
or
even
the
higher
salsa
levels,
if
we,
if
we
do
introduce
them
and
just
kind
of
curious?
D
If
people
had
thoughts
on
this,
if
there
was
already
an
issue,
if
there's
some
way,
we
can
say
well,
if
you're
not
touching,
you
know
pii
or
sensitive
data,
maybe
salsa
2
is
enough
or
just
curious.
How
folks
have
thought
about
this.
G
Yeah,
I
think,
that's
also
related
to
to
one
of
the
other
topics
a
little
down
below
that
I
also
added
there
about
how
to
better
communicate
salsa.
I
think
there
is
a
lot
of
confusion
around
that.
I
think
on.
On
my
end,
the
way
I
sort
of
view
it
is
you
know,
salsa
4
is-
is
aspirational.
G
There
are
certain
things
like
reproducibility,
and
that
is
you
know
just
given.
The
state
of
things
is
maybe
not
going
to
be
something
that
is
viable,
but
there
is
going
to
be
other
things
that
that
you
know
you
could
probably
can
do
like
hermeticity
and
and
whatever
I
think
we
do
want
to
hit
as
high
of
a
level
as
we
can.
However,
I
think
that
there's
also
a
lot
of
confusion
around
great.
Let's
say
I'm
salsa
4.
What
does
that
actually
mean
like?
But
if
my
dependencies
aren't
salsa
4?
G
What
does
that
mean?
You
know,
I
think
I
think,
there's
things
there,
you
know
and
it
helps
prioritize
because
if,
if
let's
say
I'm
salsa
4
and
none
of
my
dependencies
are
salsa
4,
what
am
I
protecting
against?
I
think
that
sort
of
question
really
needs
to
be
answered
in
order
to
kind
of
have
a
more
informed
have
a
more
informed
answer
to
your
question.
D
Yeah
I
mean
we've
talked
about
higher
levels
as
well
like
there's
nothing
stopping
the
group
from
introducing
like
us,
also
level
five
that
really
goes
deep
in
the
transitive
turtle
turtles,
all
the
way
down
project
problem
trying
to
take
notes
while
you're
talking
so
is
there
we
can.
We
can
talk
about
this
more
when
we
get
down
to
your
your
bullet
point.
Like
is
there
another
comment?
Someone
has
their
hand
raised,
melba,
yeah,.
H
Sorry
you'll
have
to
excuse
my
voice,
I'm
a
little
sick,
but
you
know
to
your
point
kim
on
mapping
it
to
like,
let's
say,
pci
or
hipaa.
One
of
the
things
that
I've
been
doing
is
trying
to
map
it
to
the
white
house
executive
order
and
the
numerous
frameworks
right,
and
so
it's
not
clear
right
to
many
people.
They
just
see
salsa.
H
They
think
you
know,
that's
the
end
all
be
all
and
salsa
does
a
great
job
of
addressing
things
that
the
white
house
executive
order
doesn't
address,
but
then
there's
details
that
are
still
missing
for,
like
let's
say
in
the
common
areas
that
nist
or
the
white
house
executive
order
expects
right.
So
I
do
think
that
we
need
to
get
a
little
bit
more
granular
and
have
kind
of
like
a
table
mapping.
Just
you
know
to
have
okay,
hipaa
pci
white
house
executive
order.
Whatever.
H
If
you
meet
the
salsa
levels,
then
you
would
be
compliant
with
these.
I
think
that
would
be
good
for
the
industry
as
a
whole.
Yeah.
J
Thanks,
I
just
kind
of
wanted
to
tag
on
to
what
the
last
speaker
was
saying
about
that
my
company
actually
gave
a
webinar
recently
where
we
talked
about
the
ssdf
that
nist
released
as
well
as
google
salsa,
and
we
described
them
as
more
complementary
frameworks.
More
than
anything
else.
The
way
that
I
see
it
the
nest
ssdf
is
a
lot
more
descriptive,
whereas
salsa
is
much
more
prescriptive
and
that
it
suggests
specific
mitigation
strategies
to
to
utilize.
Of
course,
there's
still
gaps
within
it.
J
Of
course,
there's
no
factor
or
internal
threat
or
detecting
anomalous
activity,
but
yeah
there's
no
way
that
we
can
possibly
provide
a
full
guarantee
right,
but
at
the
same
time
it
really
does
provide
a
very
comprehensive
view,
or
at
least
very
good,
a
starting
point
to
secure
both
the
source
and
the
build.
D
Well
did,
did
you
is
that
webinar
public?
Is
that
something
we
can
link
to
in
the
notes.
I
So
I
want
to
give
a
big
plus
one
to
what
melba
said.
I
really
like
the
idea
of
having
some
sort
of
a
matrix
or
some
presentation
of
you
know.
If
you
are
looking
at
hipaa,
then
our
recommendation
is
for
you
to
be
at
least
at
this
level.
C
I
Something
that
will
make
it
very
easy
for
people
to
understand
people
who
aren't
security,
engineers
and
researchers,
but
who
still
need
to
think
about
this
sort
of
stuff
right.
So
who
is
the
audience
for
that?
And
how
can
we
make
it
easy
for
them
to
do
the
right
thing
and
take
that
information
to
their
security
teams,
but
our
presentation
of
it
must
be.
We
got
to
be
sensitive
and
careful
about
that
right.
We
can't
say
this
is
the
end-all
be-all.
I
K
Thank
you
so
rewriting
the
question
of.
Should
everyone
strive
for
salsa
4
and
looking
at
salsa
4,
you
have
two
sets
of
criteria.
One
two
party
review
and
hermetic
builds
to
michael's
point.
Hermetic
builds
are
somewhat
aspirational
and
in
fact
no
one's
gonna
do
hermetic
builds
for
the
sake
of
doing
her.
Hermetic
builds
yeah,
but
salsa
could
be
what
precipitates
like.
Even
if
it's
to
check
a
mandate,
that's
coming
top-down
organization
must
comply
with
salsa
and
we
should
do
so
at
the
highest
levels
of
confidence
and
trust.
K
It's
going
to
accelerate
that
now
taking
two-party
reviews
out
of
it.
I
I
do
think,
and
even
the
ways
that
the
website
phrase
it
is
two-person
reviews
are
an
industry
best
practice
for
catching
mistakes
and
deterring
bad
behavior
they're,
not
they're,
not
of
of
like
zero
cost
like
we're
going
to
incur
cost
or
some
overhead
and
doing
two
person
reviews.
But
should
this
really
belong
at
level?
K
L
Understanding
is
that
it's
to
do
with
single
person,
projects.
L
D
G
So
so
I
I
do
think
that
that
that's
another
thing
we
need
to
just
sort
of
address
which
is
like.
I
am
okay
with
saying
that.
I'm
sorry,
but
single
maintainer
projects
maybe
need
to
have
more
maintainers
before
people
start
using
them
like,
because
we
saw
that,
with
with
some
of
the
the
the
recent
supply
chain
attacks
where
people
were
sort
of
compromising
their
own
compromising
their
own
projects.
Because
for
any
of
myriad
number
of
reasons,.
L
C
G
Well,
yeah,
but
I
mean
you
know
some
people.
It
was
hey
they.
You
know
there
is
indication
that
some
projects,
somebody
might
have
been
slipped
some
money
to
put
something
in
their
own
project
right.
You
have
multi-party
reviews,
that's
you
know,
and
then
obviously,
there's
also
yeah
a
lot
of
the
political
stuff.
G
So
I
have
one
more
comment,
just
which
was
more
about
the
compliance
piece
and
just
as
a
really
quick
thing
just
for
some
folks
who
are
not
super
familiar
and
maybe
coming
from
companies
where
who
haven't
really
had
to
do
the
compliance
piece.
So
just
I
think,
there's
a
camera
who
had
said
it
before
that
there's
most
most
com,
whatchamacallit
regulations
and
and
that
sort
of
stuff
is
all
sort
of
descriptive.
G
I
think
salsa
is
purposefully
prescriptive
and
so
that's
gonna
be
a
good
mapping
from
hey.
Here
are
the
practices
you
can
actually
do
that
then
hit
those
higher
level
things
where
they
are,
whether
they're
you
know
nist,
ssdf
or
hipaa
or
pci
or
any
of
these
other
sorts
of
things.
But
I
think
we
also
need
to
be
careful
around.
G
There's
there's
a
lot
of
concern
about
it's
very
easy
to
say:
yep,
I
checked
the
box
in
in
whatever
the
easiest
way
is
humanly
possible,
even
if
it
doesn't
actually
hit
the
the
end
goal.
So
we
just
need
to
be
cognizant
of
that.
D
Yeah,
I
agree
all
right.
Let's
take
one
more
comment
on
here
and
then
we'll
we'll
skip
to
the
next
agenda
and
maybe
table
this
one
for
now.
I
I
think
eric
is
next
and
andres's
hand
is
still
up
from
before.
Okay.
E
Okay,
thank
you
just
a
couple,
quick
things.
So
I
agree
on
the
the
one
person
project
kind
of
comment,
but
I
think
that
kind
of
speaks
toward
more
of
a
governance
and
best
practices,
type
of
discussion
as
well
be
relevant
in
some
of
the
other
working
groups,
but
overall
for
the
compliance
another
capability
discussion
as
we
kind
of
work
through
the
different
levels.
I
think
one
of
the
key
aspects
I've
seen
very
specifically
very
recently
and
trying
to
implement
salsa
level.
Two,
for
example,
is
the
provenance
component.
E
You
know
obviously,
there's
going
to
be
variant
ways
to
do
it,
but
an
example
using
some
of
open
ssfs,
maybe
projects
or
variant
very
widely
used,
not
one-person
projects
that
you
know
can
help
solve
some
of
these.
These
potential
levels
right.
So
how
do
we?
How
do
we
do
that
and,
of
course,
we're
not
trying
to
outline
hey,
only
use
these
tools,
but
here's
a
case
study.
That
is
an
example.
D
Yeah
yeah,
I
think
I
think
we
we
have
a
case
studies
folder
that
we
put
in
the
repo
with
to
be
aspirational
about
putting
more
examples
in
there,
and
we
definitely
have
a
few
like
the
kubernetes
project
itself
has.
Some
has
has
some
write-ups
about
how
they're
trying
to
reach
the
salsa
levels-
and
I
know
we
have
a
few
other
examples
like
in
the
repo
and
other
projects,
but
we
should
be
better
about
calling
these
out
and
maybe
even
putting
them
on
the
website
for
others
to
use
as
a
guideline
guidance.
E
Yeah,
I
think
finding
them
is
possibly
part
of
the
problem,
and
it
just
needs
to
be.
You
know,
maybe
diagrammed
out
and
made
kind
of
a
more
official
way
to
solve
a
problem.
D
Yeah
yeah
that
one
might
I
tweeted
yesterday
that
I'd
love
to
hear
about
companies
like
trying
to
meet
salsa
in
their
own,
their
own
organizations,
and
maybe,
if
some
were
more
open
about
it,
we
could.
We
could
help
with
more
case
studies
there.
So
I
like
it
all
right.
Can
we
move
on
or
we
have
time
when
I
see
one
more
hand
up
now
I
have
my
oh
lauren.
C
M
Yeah,
I
wanted
to
say
something
about
two-party
reviews.
I
think
it's
github
doesn't
allow
you
to
do
this
efficiently
today,
because
so
I
think,
two-party
reviews
means
two
things
like
do.
You
have
two
lgtm
on
your
pr
is
one
thing,
but
some
people
can
actually
add
code
after
the
lg
tms
happen
so
and
github
doesn't
allow
you
to
do
this
in
a
very
usable
manner
today
like
either
it's
every
time.
Someone
pushes
a
new
commit
to
the
prerequisite
pull
request.
M
It
basically
removes
all
the
lgtm,
which
is,
you
know,
virtually
impossible
in
terms
of
usability,
or
you
have
to
accept
that
you
lgtm
apr,
and
maybe
you
have
two
lg
tms,
but
someone
can
can
then
can
then
just
add
a
commit
to
the
pull
request.
So
it's
not
clear
if
this
even
counts
as
a
two-party
review.
If
you
do
that,
like
it
actually
doesn't
so.
M
D
Discussion
topic
or
issue:
if
we
don't
have
it
and
circle
back
to
it
all
right
moving
on.
Thank
you,
everyone
that
was
a
good
discussion.
Sultan
you
want
to
take
the
stage.
N
N
I
tried
to
speak
up.
Can
you
hear
me
better
now
yeah
a
little
bit?
Well:
okay,
maybe
that's
my
headset
anyway!
So
anyway,
my
topic
came
up
when
we
analyzed
salsa
framework
for
adoption
in
ibm
cloud
and
this
the
discussion
started
with
the
threat
model
of
the
south
of
river.
N
We
came
up
with
three
more
ideas
that
we
felt
that
could
be
added
to
the
framework,
so
I
thought
I
would
come
and
share
these
ideas.
We
found
them
useful
on
our
internal
analysis,
at
least
so,
if
I
may
take
over
the
screenshot
for
a
little
bit.
D
I
saw
an
issue
about
another
threat
that
wasn't
captured
too
is.
Was
that
you,
or
is
that
a
different
person.
D
N
So
this
this
chart
is
is
based
on
your
original.
N
We
extended
it
with
items,
k
and
j,
and
I
think
I
yeah
so
basically,
we
we
also
came
up
with
a
written
definition
for
them,
so
one
is
similar
to
your
class
type
d,
which
is
about
a
compromised,
build
environment,
but
it's
rather
about
a
compromised,
build
tool
or
test
tool.
So
if
you,
if
you
upgrade
your
test
tool
and
and
the
new
version
comes
compromised,
then
that
that
can
be
a
threat,
that's
the
first
one.
N
We
identified
the
second
one
it's
about
if
your
records
about
dependencies
used
are
incorrect,
so
you
don't
not
you,
you
do
not
know
exactly
what
kind
of
dependencies
are
used
anymore.
We
had
a
hard
time
accessing
the
lock
4j
incident.
N
N
I
see
I
don't
know
who
was
first
rick,
maybe.
N
Oh,
you
mean
we
called
item
j.
Basically,
yes,
so
the
threat
here
lies
in.
If,
if
you
do
not
keep
your
dependency
records
accurate
or
if
your
dependency
records
become
compromised
in
some
way,
so
that
that
can
be
obviously
avoided.
If,
if
you
use
some
kind
of
secure
bill
of
materials
which
are
stored
in
a
secure
manner
and
stuff
like
that,
but
yeah
there's
there's
a
threat
in
there.
If
somebody
accidentally
or
or
intentionally
modifies
these
frequencies.
C
N
B
Yeah,
I
think
well,
one
of
the
problems
that
we're
coming
to
grips
with
at
the
moment
is
the
fact
that,
when
you
start
to
factor
in
vulnerability
information,
it
means
that
the
the
status
of
artifacts
change
changes
over
time.
So.
B
At
one
particular
point,
and
then
a
vulnerability
is
discovered
in
it.
B
If
you're
going
to
put
that
sort
of
information
in
the
attestation,
it
means
that
the
attestation
can
get
out
of
date
with
respect
to
the
artifact
and,
if
you're,
making
a
statement
about
an
artifact
when
you
make
the
attestation
and
the
fact
that
it
may
change
over
time.
B
Does
that
mean
that
you
then
need
to
be
able
to
modify
things
like
the
salsa
level
or
some
other
part
of
the
attestation
after
the
artifact
has
been
generated?
And
that's
why
we
kind
of
steered
clear
and
dealt
with
vulnerability
information
as
orthogonal
to
what
to
our
artifacts
and
something
that
you
can
assess?
You
can
come
back
and
revisit
details
about
the
artifact,
but
they
aren't
things
that
would
be
covered
in
an
attestation.
So
there's
like
stuff
that
changes
over
time
like
vulnerability,
information
which
we
see
as
kind
of
orthogonal
to.
N
So
that
that
totally
makes
sense
so
yeah
we
might.
We
might
consider
removing
that
from
this
list
and
yeah
mitigating
it
by
rebuilding
all
the
artifacts
and
then
regenerating
with
the
attestations
on
the
build
process
and
something
like
that.
But
yeah
thanks.
E
O
Yeah,
I
think,
actually,
I
think,
it's
important
to
clarify
the
model
versus
like
the
actual
solutions
here,
because
I
think
what
you're
you're
describing
here
is
the
model,
and
so,
even
if,
however,
you
implement
it
like
through
attestations
or
whatever,
it's
probably
useful,
like
it
for
the
model
to
capture
it.
So
so
I
don't
think
necessarily
that
it
has
to
be
stricken
from
from
here.
You
know.
Ultimately,
the
model
is
a
simplification
of
the
overall
problem
to
make
it
like
easier
for
people
to
comprehend.
O
I
think,
for
I
like
step
effectively,
I
think
what
you're
saying
is
separating
the
compromise
of
the
build
tool
which
is
distinct
from
a
compromise
of
the
builder
or
compromise
of
the
dependencies.
I
think
that
also
goes
in
line
with.
We
have
another
open
issue
around.
O
I
think
differentiating
between
like
sources
versus
dependencies
versus
build
tools.
So
I
I
think
it's
worth
us
thinking
about
expanding
the
model,
to
include
that,
because
I
think
it's
a
it
seems
like
a
fairly
important
distinction,
so
that
sounds
good.
I
I
wonder
for
j
and
k
I
I
certainly
agree
it
doesn't
really
fit
in
the
model
that
we
have
right
now
like
because
it's
the
model
isn't
really
more
written
to
convey
integrity
text
of
like
tampering
as
opposed
to
like
unintended
vulnerabilities.
O
One
way
to
look
at
it
would
be
like
there
is
a
the
actual
inclusion
of
the
vulnerability
was
something
either
through
the
source
or
the
dependency,
and
then
it
was
only
like
discovered
after
the
fact,
but
but
yeah
I
think,
at
a
minimum.
I
I
would
like
to
include
these
vulnerabilities,
these
threats
on
the
threat
page,
if
they're
not
already
there,
and
I
think
we
should
consider
like
how
do
we
like
the
picture?
How
do
we
do
the
picture
in
a
way
that,
like
is
the
right
level
of
complexity?
It's
just
not.
D
D
All
right
awesome
thanks.
Thanks
for
sharing
this.
D
G
Sure,
okay,
so
this
is
something
andres
had
brought
up
a
few
days
ago.
I
know
he's
he's
not
at
a
pc,
so
I
will
just
actually
share
it.
Give
me
one
second.
G
Yeah,
if
you
could
just
screen,
share
the
issue-
yeah
sorry,
my
machine's
a
bit
of
a
mess
right
now,
so
this
is
a
sort
of
a.
I
think.
We've
we've
seen
something
like
this
sort
of
issue
multiple
times.
This
is
pretty
much
hey.
The
transitive
salsa
problem
like,
and
I
think
it
ties
into
my
second
point
of
how
do
we
communicate
salsa
better
like
what
is
the
purpose
of
a
lot
of
these
things,
but
to
kind
of
just
go
through
briefly.
G
You
know,
I
think,
there's
there's
concerns
here
like
hey
great.
What
if,
if
my
end
state
application,
you
know
I
built
it
reproducibly.
You
know
I
built
it.
I
know
all
my
dependencies,
I've
you
know
done.
I
have
two-party
code
review
for
my
code,
all
that
good
stuff,
great
I'm
salsa,
for
what
does
that
actually
mean
right,
because
if
one
level
above
me
is
salsa
0
and
you
know
it's
been
compromised,
what
am
I
actually
sort
of
getting
out
of
it?
G
This
is
sort
of
where
the
transitive
salsa
stuff
that
I
know
is
still
in
discussion
is
being
sort
of
thought
out,
but
I
think
that
then
ties
into
my
second
point,
which
is
how
do
we
communicate
this
a
little
bit
better
so
that
folks
understand
hey
you're,
salsa
4?
What
does
that
actually
mean?
Honestly?
G
It
probably
means
not
a
lot
right
now,
but
it's
it's
in
it's
valuable
information
that
can
then
be
used
for
other
things
down
the
line
and
as
we
flesh
out
the
transitive
salsa
level,
maybe
we
can
provide
other
stuff,
but
just
wanted
to
kind
of
get
folks
sort
of
thoughts
on
that,
because,
even
just
from
some
of
the
stuff
previously
right,
we
were
talking
about
compliance
and
folks
are
sort
of
concerned
with
hey.
You
know:
do
I
need
to
hit
salsa
in
order
to
hit
a
compliance
requirement.
O
Yeah
one
I
I
I
saw
the
thing
I
haven't
had
time
to
respond,
yet
I
think
one
one
thing
to
think
about
is
like.
O
The
one
there's
there's
the
aspect.
Well,
I
guess
a
couple
things
one.
Yes,
I
would
really
like
for
someone
to
have
a
proposal
for
how
we
make
some
sort
of
transitive
salsa
level.
I
think
that
would
be
a
great
thing.
I
don't
know
if
there
has
to
be
a
separate
level
or
some
other
score
or
something,
but
that
would
be
great.
O
So
if
anyone
wants
to
do
that
or
create
a
proposal
or
start
that
that'd
be
fantastic
in
terms
of
the
value
of
salsa
by
itself,
I
think
one
thing
to
think
about
is
like
who
who
the
threat
actors
are.
O
So
if
you
are
a
an
organization,
let's
say
a
company
and
you
have
salsa
level
four
for
your
first
party
code,
even
if
you,
if
you
know
that
all
of
your
transitive
inputs
are
like
open
source
projects,
there
probably
is
still
some
sort
of
value,
because
your
employees,
your
insider
risk,
is
reduced
because
those
employees
can't
compromise
your
code.
O
It's
true
that
someone
could
compromise
the
open
source
packages,
but
that's
kind
of
a
different
attack
has
different
visibility,
that
the
actors,
who
can
do
that
are
different.
It
requires
a
different
set
of
capabilities,
and
so
I
think
that's
something
to
keep
in
mind
that,
like
not
every
package
is
created
equal.
It's
not
like
it's
equally
easy
to
compromise
one
package
versus
another,
so
I
wouldn't
dismiss
the
value
in
having
salsa
for
my
own
company.
We
happen
to
use
a
mono
repo,
and
so
in
this
case
we
don't
really
have
well.
O
We
have
trans
and
dependencies,
but,
like
it
looks
different
in
our
picture
and
so
again
the
threat
like
in
a
mono
repo
case.
It's,
I
think,
more
value
and
that's
kind
of
where
we
started
from.
K
Yeah,
that's
that's
super
insightful.
Thank
you
for
those
like
transient,
open
source
software
that
we
see
in
our
that
make
its
way
through
first
party
software
at
my
employer
that
we
dictate
that
that
software
must
be
rebuilt
from
source
and
going
back
a
little
bit
to
well.
We
can't
expect
a
lot
of
open
source
projects
to
do
these
things,
but
commercial
vendors
in
the
space,
be
it
red
hat,
be
it
vmware,
be
it
cisco,
like
they're,
producing
their
downstream
distributions
of
these
different
things.
K
So
what
we
hope
to
get
our
engineering
teams
to
adhere
to
is
when
you
are
building
boring.
Crypto
on
your
your
building,
open
ssl,
you
should
strive
to
meet
south
support
in
those
components
and
it
will
make
the
job
easier,
packaging
and
binaries
of
the
products.
We
were
developing
showcase
transitive
levels
and,
like
the
final.
O
Yeah,
I
sorry
your
mic
was
cutting
it
out.
So
it's
a
little
bit
hard
to
hear.
I
don't
think
I
fully
comprehended
everything
I
think,
I'm
a
I'm
a
visual
person,
so
it's
I
I
kind
of
I
find
it
difficult
to
to
picture
things
when
listening.
I
I
think
what
you're
saying
is
like
to
have
to
what
you
might
be
saying
is
using
the
different
social
scores
of
the
thing
and
kind
of
form
like
a
graph
and
have
some
sort
of
transitive
score
is
that
is
that
what
you're,
suggesting
or
something
else.
H
O
So
that's
fine.
I
couldn't
tell
from
your
issue
if
you
meant
this
issue
to
me
purely
about
the
transit
problem,
or
if
there
was
anything
else.
If
there's
other
things,
it
might
be
good
to
split,
but
in
terms
of
the
transit
thing
yeah,
I
think
having
a
concrete
proposal
would
be
great.
O
Originally,
when
we
were
drafting
the
salsa,
the
original
draft
salsa
levels,
we
did
have
some
concept
of
transitivity
and
the
one
of
the
challenges
with
having
something
transitive
is
that
like,
if
all
your
inputs
have
to
be
the
same
level
as
the
top
level
thing
and
those
inputs
have
to
be
at
this
level,
you
kind
of
can
never
start
anywhere.
O
You
have
to
start
like
all
the
way
at
the
very
beginning,
from
like
some
sort
of
kernel
and
build
up
which
makes
it
challenging,
but
I
think
what
you
described
of
having
like
some
score
on
top
is,
in
my
mind,
a
promising
venue,
because
then
we
could
have
different
ones
for
different
use.
Cases,
like
you
said
like
the
crypto
was,
was
one
particular
use
case,
and
so
I
think
you
could
build
up
some
sort
of
practical
level
or
score
or
metric
or
something
like
that
for
different
use.
O
Cases
like
you
could
say:
okay,
well,
I'm
going
to
do
the
all
of
these
for
my
source
dependencies,
but
not
my
like
build
tool
dependencies
or
something
like
that
or
you
could
kind
of
have
some
sort
of
thresholding
to
say,
like
some
inputs
are
more
important
than
others.
I
think
there's
certainly
room
for
that,
and
so,
if
you
have
proposals
that
would
be
fantastic.
K
B
Yeah,
I
think
you
know
just
to
expand
on
the
idea
of
kind
of
being
able
to
graph
this
as
well.
I
think
there
is.
There
is
value
in
that
being
able
to
generate
at
least
some
sort
of
metric
about
an
entire
stack,
because
when
you're
looking
at
a
bundle
of
attestations,
it
tells
you
a
lot
about
all
the
individual
things
are
in
there.
B
But
not
why
they're
the
way
they
are
and
so
being
able
to
kind
of
map
out
that
graph
and
decide
whether
okay,
well,
I've
got
a
bunch
of
artifacts
here
that
all
source
level,
four
and
particular
part
of
that
graph.
That
I'm
interested
in
has
an
entry
point
there,
which
only
maps
to
that
part
of
the
graph
means
that
I
can
use
that
comfortably
in
a
source
of
four
or
with
that.
That's
also
for
level
of
trust
on
it.
B
B
That
form
your
stack,
and
so
they
give
you
that
gives
you
some
some
agency
as
a
user
and
just
a
consumer
of
artifacts,
in
that
you
can
make
choices
on
the
artifacts
that
you
consume.
That
and
give
you
kind
of
improvements
to
your
over
overall
level
of
trust.
In
your
stack.
A
Heather
yeah,
so
real
quick,
I
I,
I
think
the
idea
of
trying
to
come
up
with
some
sort
of
transitive
score
is
probably
a
good
long-term
idea,
but
probably
not
worth
focusing
on
right
now.
Here's
my
argument.
I
I
am
sure
that
this
this
group
can
come
up
with
a
number
of
algorithms
to
do
to
calculate
some
sort
of
transitive
score.
I
mean
the
obvious
one
is
take.
The
set
of
all
your
dependencies
find
the
minimum
salts
of
value,
which
is
probably
zero.
Congratulations.
You
have
a
salt
of
a
transitive
score.
A
If
you
don't
like
that,
you
could
use
an
average.
Maybe
you
could
weight
it
by
how
close
it
is.
We
can
do
all
sorts
of
things
now.
My
point
is
that
there's
a
lot
of
ways
you
can
calculate
it,
but
for
most
of
the
transitive
dependencies
they're
not
going
to
be
using
salsa,
so
the
problem
is
it
doesn't
matter
what
algorithm
we
use
we're
not
going
to
have
enough
inputs
to
matter.
A
So
what
I
would
suggest
is,
you
know
you
know,
mature
ups.
Also,
we've
got
some
questions
about
wording,
some
changes
and
so
on
to
to
make
it
stronger
and
then
go
back
once
you
know
where,
hopefully
many
projects
will
start
using
salsa
once
it's
more
mature
and
then
we'll
have
some
inputs
to
use
in
an
algorithm.
A
We'll
also
have
an
idea
of
what
that
data
will
look
like,
so
we'll
be
able
to
make
a
better
choice
for
a
some
sort
of
algorithm
for
combining
the
data,
but
I
I
have
no
doubt
that
we
can
do
the
transit
combined
data
somehow
to
be
provide
some
in
something,
but
I'm
I'm
worried
we're
doing
it
to
that.
We're
talking
about
it
too
soon.
Does
that
make
sense?
Okay,
anyway,
my
my.
A
G
J
If
I
butted,
is
there
any
sort
of
requirement
for
continuous
monitoring
within
salsa
that
could
potentially
mitigate
that
issue?.
J
Continuous
monitoring
to
make
sure
that
salsa
standards
are
still
adhered
to.
Obviously,
there's
the
point
of
we
certify
that
a
build
pipeline.
Yeah
continuous
compliance
is
a
really
good
way
of
articulating
it,
but
yeah
like
once.
We
have
certified
that
particular
build
achieved,
say
salsa
level
three.
How
do
we
ensure
that
changes
aren't
introduced
within
the
actual
build
that
produces
it.
G
So
ideally,
we
we
do
want
to
have
like
every
build
should
be
generating
that
sort
of
provenance
metadata
and
then,
where
that
providence
metadata,
maybe
isn't
disclose.
Let's
say
it's
a
vendor:
they
don't
want
to
disclose
their
stuff,
and
some
third-party
auditor
is
certifying
that
there's
definitely
routes.
We
can
do
there,
but
I
think
the
idea
is,
you
know.
Salsa
attestations
normally
have
time
stamps
I
mean
they
have
time
stamps
on
them.
G
I
should
say,
and
so,
if
folks
are
concerned
about
like
hey,
when
is
the
last
time
you
know
this
thing
had
a
salsa
at
a
station.
We
can
kind
of
look
back
a
week
two
months
whatever
and-
and
you
know
the
individual
sort
of
consumer
of
that
sort
of
thing
can
expire
it.
But
I
think
that
also
leads
into
the
next
thing,
which
is
just.
I
don't
want
to
go
too
deep
down
the
the
rabbit
hole.
G
I
think
there's
two
things
I
kind
of
wanted
to
to
address
there,
which
I'm,
which
concerns
me
about
some
of
the
transitive
scores
and
whatever,
and
maybe
something
like
the
maybe
something
like
how
critical
of
a
piece
of
software
is
important
right
like
this
is
something
I
brought
up.
A
couple
of
times
is:
if
I
have
a
thousand
dependencies
and
999
of
them
are
just
you
know,
nonsense,
and
one
is
openssl
and
openssl
is
salsa
zero.
The
rest
of
them
are
all
salsa
four.
I
really
wanna
know
that.
G
My
you
know
my
encryption
and
and
security.
Libraries
are
the
ones
that
are
have
a
high
level
of
salsa,
some
of
the
other
ones.
G
Maybe
if
they're
not
within
a
critical
path,
I
don't
care
so
much,
but
given
some
of
the
the
stuff
that's
been
brought
up
already,
it
could
be
very
easy
to
game
it,
and
you
know,
and
to
be
clear,
that's
up
to
the
enterprise
to
kind
of
sort,
some
of
that
stuff
or
the
individual
organization
or
project,
to
sort
some
of
the
stuff
out
for
themselves,
but
that's
just
something
we
should
highlight
and
then
separately.
G
I
think
that
there
is
also
a
pretty
big
open
question
on:
is
the
transitive
salsa
level
up
to
the
producer
or
up
to
the
consumer
right,
because
there
is
some
valuable
arguments
around
hey
here.
Is
you
know,
here's
my
transit.
You
know
I
can
pull
out
elements
of
that
graph
and
then
there
might
be
elements
of
that
graph
that
I
do
not
have
access
to
right.
This
comes
from
some
vendor
that
is
attesting
that
they
are
salsa
level
x,
but
they
are
not
providing
higher
level
information
into
their
element.
G
You
know
their
aspect
of
the
graph,
so
is
that
something
that
we
wanted
to
sort
of
like
at
what
level
do
folks
feel
comfortable
with
sort
of
making
that
attestation
on
their
behalf?
How
much
of
that
is
them
saying?
Hey
you,
as
the
consumer
should
run
a
query
yourself
to
to
figure
that
sort
of
information
out.
So
that's
some
of
the
stuff
I
know
jacques
has
talked
about
with
the
universal
asset.
G
G
You
know
saying
you
don't
have
access
to
my
aspect
of
the
you
know
my
half
of
the
graph
anyway,
just
some
things
to
sort
of
consider.
There.
L
I'm
stoked
you
mentioned
the
universalist
of
because
it
means
I'm
not
the
only
one
doing
it
like
a
lunatic,
but
I
won't
talk
about
it.
Two
things
that
jumped
out
of
me
one
is
in
terms
of
the
question
of
communicating
salsa
levels
for
dependencies.
L
That's
something
got
discussed
in
the
vulnerability
score
attestation
or
something
at
testation.
I
forget
what
it
was
vsa
and
the
main
thing
that
I
pushed
for
there
was
that
each
of
the
levels
should
be
counted
separately,
so
you
should
have
one
data
point
for
salsa
level,
four
dependencies
for
level
three
level,
two
etc,
because
this
leads
to
my
second
point:
salsa
is
an
ordinal
scale,
it's
not
a
nominal
scale,
it's
not
a
ratio.
L
Scale
interval
scale,
it's
an
ordinal
scale,
so
there
are
names
they
have
an
ordering,
but
that's
it
that's
all
you
can
derive
from
it.
That
means
that
the
operations
that
you
can
perform
on
it
sort
of
arithmetically
are
limited.
You
can
bucket
things
together.
You
can
count
them.
That
makes
sense.
You
can
take
a
minimum
or
a
maximum
that
makes
sense,
but
taking
an
average
doesn't
make
sense
right.
It's
like
taking
the
average
of
people
who
got
gold,
silver
and
bronze.
It's
not
a
meaningful
operation.
L
M
Sure
what
is
it,
what
I
wrote?
Oh
yeah,
so
asura
and
I
presented
some
work
at
the
last
meeting
on
doing
salsa,
3
and
above
generation
and
verification
using
github
workflows.
M
D
M
Oh,
oh
yeah,
I
had,
I
had
just
a
comment
on
the
scores
like
I
work
a
lot
on
a
scorecard
and
we
found
out
that
I
mean
I
think
it's
in
retrospect.
It's
probably
obvious,
but
we
we
found
out
that
scores
are
too
granular
enough
in
practice
to
enforce
policies
at
the
consumer
level.
So
when
you
run
scorecard
just
having
scores
make
it
makes
it
not
super
actionable.
M
If
you
want
to
enforce
flexible
policies
on
top
of
it,
and
I
feel
that
south
side
is
kind
of
like
this
as
well.
So
when
you
start
adding
dependencies
and
transitive
dependencies,
calculating
scores
is
basically
losing
so
much
information.
M
I
think,
like
people
said
like
criticality
and
things
like
that,
so
I
I
just
want
to
say
that
what
we're
doing
in
scorecard
now
is
we
we're
also
going
to
output
like
the
more
raw
results
before
we've
applied
any
kind
of
scoring,
and
we
let
users
apply
some
policies,
so
they
can
actually
decide
like.
M
I
want
these
settings
to
be
on
in
branch
protection,
or
I
want
reviews
to
have
two
reviews,
and
I
want
only
this
list
of
reviewers
to
have
reviewed
the
the
pull
requests
and
things
like
this,
and
I
feel
that
this
model
might
actually
also
work
for
salsa.
So
long
as
you
give
that
information,
the
consumer
can
decide
and
interpret
the
way
they
want,
because
even
something
as
simple
as
criticality
means
very
different
things
based
on
who,
like
which
consumer
is,
is
using
the
salsa
provenance
information.
D
O
Yeah,
I
think
I
I
agree
about
not
having
like
boiling
it
down
to
one
number,
because
it's
not
super
meaningful.
I
think,
if
we
think
about
like
how
would
an
organization
use
this
data
and
and
use
it
to
reduce
their
risk
because,
ultimately,
what
salsa
is
about
is
reducing
risk.
I
think
that's
important
to
keep
in
mind,
and
I
I
suspect
that
probably
like
a
way
that
a
lot
of
organizations
would
would
use
it
or
maybe
the
way
that
we
could
show
them
using.
O
It
would
be
to
one
be
able
to
identify
the
things
that
are
high
risk,
because
the
salsa
level
is
low,
and
so
you
wouldn't
necessarily
need
to
know
that
oh
5
out
of
15
dependencies
are
this,
but
rather
we
would
identify.
Oh
here's
where
we
might
want
to
focus
effort
to
shore
up
our
security
or
maybe
remove
these
dependencies,
because
I
find
them
too
risky
or
something
like
that.
So
using
it
more
as
like
a
guide,
as
opposed
to
like
a
check
box
of
like
I'm
good
or
not,
is
probably
useful.
O
It's
probably
also
useful
to
use
to
actually
average
the
score
and
average.
You
know
like
or
have
some
sort
of
number
of
like
bronze
silver
gold,
not
in
terms
of
like
you're,
good
or
not,
but
rather
for
motivating
organizations.
O
If
you
have
some
teams-
and
you
have
different-
you
know:
15
20,
different
teams,
if
you're
in
a
large
organization
or
like
hundreds
or
thousands
of
teams,
if
you're
in
a
huge
organization,
you
could
kind
of
use
it
to
name
and
shame
effectively
of
like
hey,
you
need
to
get
your
things
up
to
snuff
and
if
you
want
to
make
some
sort
of
bulk
change
across
a
large
organization,
that
sort
of
number
is
useful.
O
But
it
is
important
to
note,
like
the
limitations
of
it,
of
like
this,
this
number
or
whatever
is
useful
for
your
organization
purely
for
getting
people
to
move
and
not
because
you're
trying
to
actually
boil
down
risk
into
some
number.
So
those
are
maybe
things
to
that
ways
that
people
could
use
some
sort
of
transitive
metric
to
add
value
to
an
organization.
O
B
Yeah
I
mean
going
back
to
the
score:
there's
a
risk
there
that
organized
use
organizations
use
it
as
a
up
and
to
the
right
kind
of
metric
where
they
will
just
see
that
you
know
try
to
drive
improvements
in
the
number,
and
that
leads
to
kind
of
the
gamification
issue
that
I
think
we
mentioned
earlier,
but
I
I
you
know
I
I
agree
as
well
that
I
think
more
granularity
in
the
data
that
we
present
is
is
useful
as
well
so
saying
you
know:
okay
well,
this
would
have
been
source
of
level
four,
but
it's
only
sort
of
level
three,
because
we
didn't
hit
hermiticity
or
one
of
the
other
requirements
would
allow
users
to
basically
make
their
own
decisions,
because
in
multiple
ways
you
can
attack
risk,
you
can
mitigate
it.
B
You
can
ignore
it.
You
can
insure
against
it.
You
can
do
anything
you
like,
and
users
should
be
given
the
chance
to
make
their
own
determination
about
how
about
their
risk
posture
towards
a
given
artifact
based
on
why
it
didn't
make
the
particular
source
of
grade
that
they
were
aiming
for.
M
G
So
two
things
one
is
actually
in
celebration.
I
guess
of
the
new
salsa
blog
that
I
know
is
coming
out
that
that
we
plan
to
sort
of
I
am
writing
a
blog
article
to
sort
of
talk
through
some
of
these
things
like
what
would
a
hypothetical
organization?
How
would
it
use
it?
My
thoughts
on
that,
but
I
do
think
this
because
I
I
do
want
to
kind
of
transition
just
a
little
bit
into
the
better
communication
of
salsa
piece,
which
I
think
a
lot
of
this
sort
of
stuff
is
hey.
G
There's
still
a
lot
of
confusion
on
how
folks
use
salsa,
how
you
could
what
what
makes
the
the
information
valuable?
What
is
it
even
saying-
and
I
think
one
of
the
things
that
to
kind
of
go
in
there
a
little
bit
that
that
is,
has
been
missing
from
the
conversation
is
or
we
haven't
done
a.
I
think,
a
good
job
at
communicating
is
really
communicating
that
salsa
is
in
addition
to
what
you're
already
doing
like
don't
stop
doing,
sass
and
dust
and
and
other
security
scans
and
just
switch
the
salsa.
It's
like
no.
No.
G
You
built
your
software,
you
did
all
that
sort
of
stuff
and
we
have
some
level
of
proof
and
and
a
chain
of
custody
saying
yes,
what
you
running
ran
in
production
did
have
those
scans.
Those
scans
happen
on
these
days.
They
were
signed
off
by
these
services
and
I
think
that
sort
of
stuff
is
is
really
valuable,
but
I
think
that
level
of
it
is
really
not
being
communicated
very
well
and
maybe
some
some
of
these
blog
articles.
Maybe
some
clarifications
would
be
really
really
valuable.
D
D
Are
any
any
last
minute
comments
or
we're
gonna
call
it
a
day.
Great
discussion,
though
everyone.
This
is
awesome.