►
From YouTube: SLSA Positioning Meeting (November 1, 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
A
B
B
I
know
I
know,
and
it's
it's
still.
The
most
I
actually
have
a
personal
objective
to
do
that
and
two
other
posts
this
quarter.
So
now,
even
my
manager
is
starting
to
hassle
me
about
it.
You're
gonna
rest
assured.
A
So,
okay,
so
let's
let's
get
started
now
that
people
and
I'm
sorry
you're,
cold,
Isaac,
I'm
sure
the
Riesling.
If
you
drink
some
it'll,
keep
you
a
little
warm.
A
Okay,
Isaac
well
since,
since
I
I
brought
it
up
and
you're
on
before
I
lose.
You
tell
us
about
the
blog
that
I
believe
it
was
about.
If
I
remember
correctly,
the
difference
between,
like
the
salsa,
the
attestation
piece
versus
I,
think
oh
man,
I
can't
remember
the
other
one.
Was
it
cncf,
I
I,
don't
remember
so
long
ago.
B
A
Okay
and
then
outside
of
that,
once
we
we
wait
for
Isaac
to
share
his
screen.
I
know:
we've
been
working
on
the
development,
blog
and
I.
Think
Jay,
you
were
on
yesterday's
meeting
I.
Think
Isaac.
You
were
on
yesterday's
meeting
to
potentially
I
think
we're
unblocked
now
and
So,
based
off
that
verbiage
I've
been
documenting
some
use
cases
for
like
the
benefits
from
a
developer's
point
of
view.
A
So
I
wrote,
you
know
I,
do
this
all
the
time
right
where
I'm
like
messing
on
my
local
laptop
for
in
a
yaml
file
and
then
I
forget
that
I've
done
something
and
I
go
to
potentially
commit
or
build
and
I've
forgotten
that
I've
done
that
right.
So
you
know
social
level,
one
helps
prevent
something
like
that
or
adding
additional
code
that,
maybe
you
know
I
needed
to
do
something:
testing
or
whatnot
it's
not
supposed
to
be
in
there.
My
understanding
is
also
level
one.
A
It's
supposed
to
help
prevent
something
like
that,
because
it's
not
matching
the
Upstream
when
you
go
go
to
build
and
then
I
think
I
made
another
one
about.
You
know
understanding
dependencies
like
I,
don't
know
somebody
might
want
to
see
if
it's
secure
or
they
want
to.
You
know,
make
it
more
lightweight
and
the
s-bomb
potentially
could
help
with
something
like
that.
A
So
I
kind
of
started
doing
this
a
little
bit
ago
to
document
why
a
developer
would
want
to
consider
salsa,
but
obviously
we
can
keep
working
on
that
and
refining
that
that
was
just
kind
of
off
the
cuff
after
the
discussion
yesterday,
what
I
was
thinking
about.
C
A
It's
internet,
he
just
he
just
left
so
hopefully
we'll
get
him
back
here
soon.
But
oh
there
he
goes.
B
Especially
so
I
can
show
you
I
have
a
narrative
in
deck
form
which
I
was
hoping
to
turn
to
blog,
and
what
I
can
do
is
show
you
the
deck
and
give
you
a
sense
of
where
I'm
at
overall,
if
that's
helpful
foreign,
so
let
me
throw
it
up
here.
Okay,
so
share
my
screen.
B
So
I
think
so
I
have
a
number
of
slides
here.
Can
you
can
you
all
see
my
screen
right
now,
yeah,
okay,
can
you
still
see
if
I
do
this
yep
even.
C
B
Okay,
so
so
this
diagram
here
and
it's
it's
bigger
than
salsa
but
I-
think
as
as
relevancy
to
how
we
think
about
ourselves
and
how
we
think
about
the
layers
above
and
below
us,
also
in
the
overall
stack,
and
so
this
diagram
was
posted
on
the
the
Google
Blog
last
week,
along
with
the
launch
of
guac,
which
is
another
kind
of
adjacent
project
here
and
I
wanted
to
kind
of
explain
how
these
pieces
fit
together
and
that's
kind
of
where
this,
this
idea
of
attestations
come
from
if
I
back
up
to
what
I
think
is
the
core
problem
that
we're
trying
to
solve
around
supply
chain.
B
It's
this
one
right
that,
after
particular
source
that
open
source
software-
you
know.
Yes,
it
brings
tremendous
value.
You
know,
that's
why
it's
in
97
of
commercial
software
and
folks
get
tremendous
value
from
relying
and
depending
on
open
source
software,
and
but
it
brings
significant
latent
security
risk
and
I.
Think
you
know
one
of
the
key
words
to
highlight
there
is
latent
in
that,
but
people
are
aware
that
it
brings
security
risk,
but
it's
it's
mostly
hidden
and
unquantifiable.
B
It's
very
difficult
to
reason
about,
and
so
I
think
the
core
problem
you
know
with
OSS
supply
chain
and
the
large
is
this
one.
Yes,
there
are
parts
of
open
ssf
which
are
looking
to
you,
know,
fix
vulnerabilities
faster
and
make
things
more
secure
by
default,
but
I
think
you
know
independent
of
those
efforts.
We're
always
going
to
have
to
reason
about
an
imperfect
supply
chain.
We're
always
going
to
have
to
reason
about
a
supply
chain
with
vulnerabilities
and
deficiencies
Upstream
of
us,
and
so
the
challenge,
then,
is
become.
B
And
so
I'm
not
going
to
go
through
all
of
these
slides
but
I
think
at
its
core
having
transparency,
drastic
control,
transparency
I
want
to
be
able
to
see
what's
there
and
understand
that
the
risk
and
the
signal
for
them,
seeing
trust
I
need
to
be
able
to
believe
in
the
data.
I
need
to
have
a
reason
that
I
can
trust
metadata,
that
I'm,
seeing
in
a
supply
chain,
outstream
of
me
and
then
ultimately,
control.
This
is
where
the
rubber
meets
the
road.
B
I
need
to
be
able
to
take
actions
to
manage
mitigate
systematic,
reduce
the
risk
that
I'm
reporting
into
my
supply
chain
again
I'm
going
to
skip
over
these
slides.
This
is
what
I'm
going
to
be
blogging
about,
but
this
diagram
here
is
a
more
detailed
version
of
this
one.
So
I
am
going
to
talk
a
little
bit
about
this.
If
you
look
at
openssf
overall,
six
store
at
its
base,
I
think
provides
this
trust
Foundation.
B
What's
the
six
store
provide,
it
provides
a
way
of
signing
attestations
as
providing
links
to
strong
links
to
Identity.
There's
work
going
on
with
distributed
time
and
stamping
in
order
to
Federate
this
trust
foundation
and
the
anchor
flexibly
in
roots
of
trust,
and
so,
if
you
think
of
this,
this
box
at
the
bottom,
as
as
you
know
more
or
less
analogous
to
this,
it's
the
role
that
Sig
store
plays
in
the
ecosystem
is
providing
this
Foundation
of
trust.
B
What
you
can
then
imagine
layering
on
top
of
that
is
a
layer
of
attestations
and
metadata
referring
to
supply
chain,
artifacts,
and
so
salsa,
yes,
is
one
part
of
it.
Solves
provenance
is
certainly
relevant
when
assessing
you
know,
risk
of
side
effects
that
you're
bringing
into
your
supply
chain
that
saw
a
s
Bond
so
is
OSD
and
Vex
OSS.
Oh
sorry,
open,
ssf
scorecards
is
a
relevant
signal
there
as
well,
and
things
like
life
cycle
events.
B
If
I'm
importing
a
library
into
my
supply
chain,
it
would
be
useful
to
know
that
one
of
the
maintainers
of
that
Library-
you
know
their
email
domain,
just
expired
and
was
re-registered
by
someone
else
last
week.
That
seems
pertinent
to
assessing
the
overall
risk
of
this
thing,
and
so,
if
you
can
imagine
having
attestations
that
are
signed,
you
know
with
Sig
store
pertaining
to
entities
in
the
supply
exchange,
and
you
can
then
begin
to
trust
those
attitations.
The
problem
you
then
have
is
that
you
know
sales
are
attaches.
B
All
the
problem
is
attaches
to
an
artifact.
Osds
are
keyed
on
vulnerability.
Scorecards
referred
to
a
repo
developer
reputations
edges
to
a
developer,
who
may
be
working
in
a
repo
life
cycle,
events
to
a
project
which
may
have
many
repos,
and
so
these
attestations
and
metadata
here
are
all
attached
to
different
entities
system
which
have
an
implicit
grasp
between
them
and
so
the
role
of
Glock.
B
If
any
sort
of
like
a
kubecon
last
week
or
sing
I'm,
showing
up
on
open,
ssf
and
exploring
other
slacks,
it's
really
the
layer
of
aggregation
synthesis
where
we'd
like
to
be
able
to
for
a
given
artifact
reason
about
all
of
the
metadata
which
we
can
attach
that
out.
In
fact,
even
transitively.
So
yes
I'd
like
to
know
about
the
salsa
Providence
without
effect,
I'd
also
like
to
be
able
to
figure
out,
you
know.
B
What's
the
open,
SSS
scorecard
score
for
the
repo
from
which
the
artifact
was
built,
do
I
not
have
any
thread
intelligence
data
about
the
project
or
people
working
on
it.
Other
life
cycle
events,
and
so
guac,
is
an
attempt
to
reify
that
implicit
graph
and
aggregate
all
of
these
signals
together
and
across
all
of
these
different
anticipations
and
metadata
types,
and
then
at
the
very
top.
You
know
if,
if
we
have,
you
know
trust
at
the
bottom,
you
know
we've
then
got
attestations
and
metadata
at
one
level.
B
Up
from
that,
aggregation
of
synthesis
is
about
turning
that
data
into
meaning.
What
what
can
I
extract
in
terms
of?
What's
all,
what
are
all
the
Sea
of
data?
What
meaning
can
I
extract
and
then
in
the
top
layer
here,
policy
and
insight
is
how
do
I
turn
that
meaning
into
value
and
I
can
think
about
it
too
in
that
leading
into
value
for
a
variety
of
different
audiences,
and
so,
given
you
know
an
overall
a
holistic
risk
assessment,
for
you
know,
elements
Upstream,
I
mean
and
supply
chain.
B
I
can
drive
policy
in
my
my
own
operations.
I.
Can
you
perform
risk
and
compliance
assessments
developer
assistance?
Even
you
could
imagine
in
an
IDE
where
a
developer
reports,
a
new
library
being
able
to
provide
intelligence
about
that
import.
What
risk
did
you
just
add
to
your
supply,
chain,
governance
and
so
on,
and
so
policy
and
insight?
B
You
know
the
fact
that
we
now
have
guac
incubating
this
aggregation
and
synthesis
layer.
I
think
that
we
can
do
a
much
better
job
of
painting
the
overall
picture
of
how
do
these
pieces
fit
together
into
a
coherent
whole,
which
provides
value
vertically,
all
the
way
up
to
variants
or
audiences
at
the
top.
So
that's
that's
essentially
I've.
B
Just
given
you
the
the
seven
minute
spear
with
some
slides
of
what
I
hope
to
turn
into
our
blog
post
around
around
you're,
looking
at
you
know,
if
I
have
you
know,
given
salsa
Providence
signed
in
six
door,
how
is
that
meaningful
in
the
large?
How
do
if
I
zoom?
How
does
that
actually
help
me?
Do
anything
what
it
helps
you
do
things
through
this
stack
here,
I'm
in
the
same
for
OSD
for
scorecards
for
s-bomb,
even
first
party
proprietary
data,
you
might
imagine
aggregating
to
is
that
helpful?
B
Does
that
make
sense
and
yeah
is
this
worthwhile
blogging
about.
A
So
I
have
two
things:
I
I
do
like
this
I
think
it's
incredibly
useful,
especially
this
picture
right,
I'm,
very
much
a
picture
person,
so
I
really
like
this
picture.
My
question
is:
more
around
I,
see
this
as
two
different
blogs:
there's
the
everything
you
just
talked
about
as
one
blog,
but
it's
not
necessarily
salsa
positioning.
A
But
then
how
do
you
take
this
and
position
salsa
or
a
specific
blog
right
or
a
Blog
specifically
to
salsa
right,
because
there's
the
whole
thing
that
you
want
to
talk
about
and
completely
understand,
but
we
also
want
to
make
sure
that
we
position
salsa
in
this
in
a
separate
blog
to
say.
This
is
why
you
should
use
salsa
from
this
perspective.
Or
how
would
you
go
about
doing
that.
B
I
I
think
I
think
that's
true
and
so
I
think
part
of
you
know
in
my
mind,
when
I'm
imagining
this
I'm,
imagining
like
telling
the
story
layer
by
layer
essentially
and
so,
and
the
attestations
and
metadata
Leia
you
can
imagine
telling
a
story
about
how
these
pieces
are
complementary
and
different.
You
know:
we've
dealt
with
some
confusion
early
on,
like
you
know,
six
months
ago,
around
s-bomb
and
salsa
people
look
at
Salsa
people,
look
at
s-bomb
they're
the
same
thing:
wait
it's
one,
a
subset
of
the
other.
B
How
should
I
think
about
these
two
things
and
gradually
we've
teased
them
apart,
and
you
know
we
post
on
the
open,
SSS,
blogger,
a
post
or
two
about
how
this
woman
cells
are
different
and
complementary,
and
so
I
think
that
part
of
positioning
salsa
is
is
painting
this
picture.
That
salsa
is
a
part
of
an
overall
metadata
ecosystem.
Here
is
the
specific
parts
of
the
supply
chain
or
here's
the
the
types
of
data
that
salsa
is
useful
in
reasoning
about
or
the
the
types
of
risk
I
should
say,
the
Salter
is
useful.
B
People
from
reasoning
about
here's,
how
scorecards
can
help
you
and
so
I
think
positioning
salsa
is
about
telling
the
story
of
this
this
metadata
layer
and
explaining
you
know
what
makes
salsa
interesting
and
different
and
usefully
differentiated
from
all
the
other
sequels
that
we're
seeing
you
know,
2023
with
the
executive
order
with
the
OMB
men
were
coming
out
last
month,
2023
we're
going
to
wake
up
and
find
ourselves
absolutely
Awash
in
a
sea
of
s-bombs
we're
going
to
find
s-bombs
absolutely
everywhere,
which
I
think
makes
this
aggregation
synthesis
problem,
particularly
pressing,
but
salsa
as
well.
B
What
does
this
mean
and
how
do
I,
tease
apart
the
meaning
of
salsa
provenance,
as
distinct
from
you,
know,
an
inventory
of
ingredients
in
an
s-bomb
or
an
open,
SSS
scorecard,
or
even
you
know,
United
Stations
in
Metairie
you
could
imagine
S2
c2f
being
in
here
as
well,
that
you
know
know
it's
an
artifact
or
an
organizational
level
being
able
to
reason
about
what
would
the
you
know,
dependency
management
practices
which
are
Upstream
with
me
in
a
supply
chain.
It's
in
the
data
point
which
we
then
need
to
synthesize
and
so
I.
B
Think
positioning
salsa
against
s2c2f
is
a
symbolize,
an
analogous
problem
to
positioning
salsa
against
scorecards
threat,
intelligence,
developer,
reputation,
s-bomb
and
so
on
anyway,
that
that's
kind
of
how
I'm
thinking
about
it
I
seriously
this
this
is
the
kind
of
this
is
early
thinking.
This
is
crayons
and
and
boxes
and
arrows
level
thinking,
and
so
any
any
input
or
ideas
or
feedback
you
have
I
would
I
would
really
welcome.
Mike,
let's
see
your
hands
up.
D
Yeah,
so
yeah
I
agree
that
this
sort
of
thing
works
really
well.
It
worked
really
well
at
kubecon
when
we
showed
off
guac
and
I.
Think
for
the
to
kind
of
tie
it
back
into
guac.
I
think
the
thing
that
a
lot
of
folks
are
interested
in
is
they
are
interested
in,
like
hey,
so
I
have
these
this
salsa
metadata.
What
do
I
do
with
it
or
how
does
this
fit
into
the
bigger
picture?
D
I
think
that
really
does
help
out
right,
because
a
lot
of
folks
are
like
at
the
end
of
the
day.
It
is
you
know
when
you
have
a
salsa
when
you
have
salsa
metadata,
you
are
tying
an
identity
to
some
metadata,
that's
making
a
claim,
and
then
you
can
go
back
and
say:
hey
do
I,
trust
this
and
so
on,
and
then
I
think.
The
thing
that,
like
really
also
started
to
click
for
folks,
was
this
idea
that,
as
you
were
pointing
out
about
like
now,
we
gotta
aggregate
all
this
data
correlate
it
with.
D
You
know
correlate
salsa
with
your
s-bombs
with
the
Vex,
with
all
that
sort
of
stuff
great,
because
people
are
you
know
it's.
You
know.
A
lot
of
folks
are
like
hey.
It's
cool
that
I
generated
some
salsa.
What
do
I
do
with
this
like?
What's
what's
the
purpose
of
it,
and
and
the
purpose
for
a
lot
of
folks
is
like
you
know,
if
you
just
say
well
now
you
can
see
whether
or
not
you
have
that
salsa
metadata
you're
like
okay,
great
well,
that
helps
out
just
from
the
pure
perspective
of
like
I.
D
D
Those
are
bad
or
or
we
need
to
you,
know
whatever,
but
like
that's,
really
not
a
whole
lot,
whereas
when
you
start
to
say
no,
no,
but
if
you,
if
you
have
hundreds
of
salsa
attestations
and
you
can
correlate
it
with
all
the
other
metadata,
that's
starting
to
come
up
out
there,
you
can
ask
those
richer
questions.
Like
you
know,
hey
I
have
I,
have
a
build,
so
I
know
this.
Build
is
probably
secure
and
if
I
go
and
I
look
at
that,
git
commit
ID
and
I
go
back
and
I
realize
like.
D
Oh,
it
turns
out
that
git
commit
ID
introduced
a
you
know,
I,
don't
know
a
SQL
injection
attack.
We
know
that
we've
had
SQL
ingestion
attacks
for
up
until
some
other
recent
thing
and
stuff
like
and
if
you're
not,
and
if
you're
not
doing
the
aggregation
and
synthesis,
you
don't
get
that
and
then
finally,
you
know
you
can
then
title
together
with
the
policy
and
insight.
I.
D
Think
the
thing
that
that
we've
seen
as
well
is
a
lot
of
folks
are
like
they're
viewing
they've
only
been
thinking
about
the
policy
and
insight
piece
on
a
salsa
attestation
at
a
time
when
they
really
should
be
thinking
about
it
more
holistically
of
like
even
though
salsa
itself
is
not
transitive.
If
you
do
have
salsa
attestations
for
your
dependencies
and
if
you
do
have
salsa
acid
stations
across
your
environment,
you
can
start
to
ask
some
of
those
other
questions
which
I
think
is
really
useful.
B
Absolutely
and
you,
you
brought
up
trust
as
well
and
I
think
that
there's
an
important
element
here
about
how
we
anchor
trust
and
I
think
you
know
some
of
this
there's
a
document
which
I
posted
in
I
think
Isaac's,
also
positioning,
all
the
s2c2f
slack
Channel,
trying
to
you
know,
tease
apart
s2c
to
Earth
and
salsa,
and
one
of
the
things
there.
D
B
Where
is
trust
anchored
in
this
ecosystem
and
I
think
you
know
with
salsa
trust
is
anchored
in
in
the
Builder
and
so
when
you're
thinking
about.
Why
should
I
trust
this
attestation?
Well,
it's
because
this
given
Builder
signed
it,
and
so
my
trust
is
anchored
there
with
S2
c2f.
The
trust
tends
to
be
anchored
in
the
organization
or
an
auditor
of
the
organization.
B
B
You
could
imagine
you
know
here's
an
auditor
use
case
whether
it's
in
delegated
trust,
that's
transitive
and
I'm.
Sorry
I
couldn't
see
here,
trust
the
open
ssf
it
was
delegated
to
Trail
a
bit.
It
was
then
audited,
GitHub
and
so
on
and
I
think.
Actually
this
I
this
picture
here
where
we
use
package,
distributors
or
package.
You
know
package
repositories
as
a
trust,
boundary
consumers
already
trust
IPI
consumers
already
trust
may
have
been
you
know,
implicitly
anyway,
and
so
using
package
managers
to
trust
boundary
has
these
useful
properties.
B
But
in
this
picture
these
consumers
don't
need
to
know
anything
about
the
Upstream
Builder.
It's
the
package
Distributors,
which
are
actually
doing
the
assessments
upstream
and
looking
at
you
know,
transitively
how
what
what
trust
needs
to
be
upstream
and
then
what
trust
can
I
pass
down
in
a
VSA
to
individual
consumers
and
so
I
think
that
there's
a
certain
you
know
in
salsa
land,
there's
a
certain
amount
of
kind
of
hand
waviness
around
how
trust
is
anchored
today,
like
we
say
that
GitHub,
you
know,
GitHub
actions
can
produce
sales
levels
of
the
artifacts.
B
Why
do
we
do
that?
We
do
that
because
we
trust
GitHub
when
they've
told
us
that
their
Builder
is
architected
in
a
particular
way
and
satisfies
hermiticity,
and
if
they're
reality
and
isolated
build
environments
and
so
on.
We
go
okay.
Well
that
meets
false
level.
Three
but
there's
an
inherent
trust
in
GitHub
there,
which
is
I,
think
not
sufficiently
explored
or
articulated
around
salsa,
and
so
I
want
to
I,
want
to
try
and
paint
that
picture
as
well.
C
A
Quarter,
this
has
been
good,
I,
don't
mind
Isaac,
you
said
you,
you
were
promising
your
manager
sometime.
This
quarter
right.
A
Nice,
nice,
okay!
Well,
thank
you.
Thank
you
for
that
that
overview
and
do
let
us
know
if
you
need
help
with
anything
seems
like
you
got
it
covered,
but
just
in
case,
oh
okay,
so
folks
do
we
want.
Does
anybody
else
have
other
items
to
discuss.
C
A
A
Here
and
I'll
put
it
on
the
notes
whether
he's
coming
back.
A
So
the
question
that
came
up
right
as
you
dropped.
If
this
presentation
was
public.
A
Okay,
any
other
agenda
items
for
folks
on
the
call.
A
Okay,
so
let
me-
and
so
this
is
going
to
be
changed
into
like
a
working
session
now
so
obviously,
if
folks
can
stay
fantastic,
if,
if
not
it.
A
Nice
having
you
for
a
little
bit
today,
but
let
me
let
me
share
this
I
think
this
is
the
we
don't
know
who
the
original
owner
was
for
the
last
one
we
couldn't
edit
it.
So
we
had
to
create
a
new
one.
So
let
me
I
love
to
chat.
Where
is
it?
This
is
the
a
new
development
blog
location
and
for
folks
that
haven't
been
here
for
some
of
the
discussions
we
were
thinking
of
two
parts.
The
first
one
was.
A
I
think
Jay
did
a
really
good
job
of
kind
of
covering
the
first.
So
why
should
Gullivers
consider
salsa
and
what's
not
covered
in
you
know,
by
the
social
levels,
at
least
the
ones
that
we're
going
to
be
discussing,
and
then
some
of
the
other
questions
that
we
want
to
ask.
Are
you
know
what
kind
of
problems
can
it
catch
from
a
development
perspective
or
developer
perspective
with
outside
of
the
boundary
and
then
a
call
to
action?
A
So
it's
supposed
to
be
a
relatively
simple
blog,
but
when
we
were
doing
the
comparison
last
week
we
did
get
hung
up
on
some
semantics
of
the,
or
rather
the
wording
of
a
benefit.
So
we
kind
of
had
to
stop
so
I'll
I'll
stop
speaking
there
and
let
folks
chime
in
on
what
they
would
like
to
see
or
add.
We
can
obviously
start
just
typing
away.
I
think
everybody
has
the
ability
to
add
to
this.
If
I'm
not
mistaken,.
A
And
if
I
missed
your
name
up
here
by
all
means
feel
free
to
add
it,
I
I
took
the
the
the
last
sessions
meeting
the
attendees
from
the
last
session
meetings,
to
remind
myself
who
who
started
this
okay.
A
So
what
problems
can
it
catch?
What
use
cases
do
you
think
we
should
discuss
from
a
developer
perspective?
Why
they
care
about
salsa
level,
one
and
salsa
level,
two.
A
Oh
basically
we're
trying
to
tell
the
developer
why
they
should
care
about
salsa.
So
what
what
kind
of
use
cases
do
we
want
to
talk
about
to
say,
hey,
developer,
you
know.
D
C
Just
just
to
to
make
sure
that
I
remember
that
you
discussed
in
the
past
just
make
sure
that
it's
the
part
one
you
be
one
that
it's
more
focused
on.
Why,
yes,
party
two
will
be
more:
how
right
correct.
A
C
C
C
B
One
of
the
organizations
I'd
share,
and
maybe
we
can
make
sure
we're
aligned
on
this
is
I.
Think
I
mean
talking
about
the
value
of
salsa
right
I.
Think
that
there's
just
three
potential
audiences
for
the
value
of
sales,
I
think
audience
number
one
is
like
the
the
community
and
the
ecosystem
at
large
and
the
value
of
salsa.
B
There
has
been
just
like
providing
a
center
of
gravity
for
discussion,
a
common
set
of
terms,
a
common
framework,
a
language,
a
way
of
talking
about
the
same
things
using
the
same
words-
and
you
know
just
crystallizing.
You
know
a
a
disparate
set
of
Concepts
about
supply
chain
down
to
a
single
set
of
vocabulary
and
thinking
about
it
I
think
then,
there's
solster
as
provides
value
to
the
person.
B
The
building
software
like,
as
as
kind
of
you,
know,
building
their
own
software
at
a
particular
sales
level,
and
actually
the
the
where
the
value
seems
to
me
most
prominent
is
in
People
consuming
artifacts
that
they
can
try.
They
can
put
more
trust
in
an
artifact
which
has
a
higher
salsa
level,
so
I
think
I
mean
part
of
part
of
what's
Difficult
about
driving
a
social
adoption
is
that
the
costs
of
implementing
salsa
are
on
a
you
know,
a
builder
of
software.
B
The
benefits
itself
so
tend
to
accrue
to
the
consumers
of
software
and
I.
Think
that
that's
that's
difficult
just
from
an
option
perspective,
but
it's
possibly
something
which
we
should
put
in
the
for
the
framing
of
how
we
think
about
it
here
that
right
now
we're
talking
about
the
benefits
to
the
to
the
developer
of
implementing.
B
You
know
their
builds
at
Salsa
levels,
I
think
the
more
relevant
value
is
the
consumer
who
is
who
no
longer
has
to
bear
the
cost
of
those
Upstream
risks,
if
that
makes
sense,
actually
the
benefits
of
me
as
known
as
maintainer,
producing
Souls
of
conformant
builds
well,
it
is,
is
difficult
to
articulate
I
mean
if
it
was
easy.
I
think
we'd
see,
sulfur
adoption
move
much
much
quicker.
I.
B
B
I
don't
mean
to
derail
this,
but,
but
maybe
I
guess
maybe
we
should.
We
should
think
about
not
not
just
kind
of
why,
from
the
perspective
of,
why
should
I
Implement
salsa
for
my
build,
but
why,
in
the
broader
way
like
what?
What
other
you
know,
what
what
value
might
I
be
providing
to
users
of
my
software
rather
than
what
what
value
might
I
realize?
B
Personally,
if
that
makes
sense,
because
because
I
think
that
that
second
question
is
can
be
tricky
and
actually
it
could
there,
you
know
it
could
be
that
a
given
software
producer
would
look
at
Solstice,
pure
cost.
I,
don't
get
anything
from
doing
this.
It
just
cost
me
money.
It
just
cost
me
complexity
of
my
builds.
All
the
value
is
to
Consumers.
B
I
think
I
think
that's
true,
but
I'm
I
guess
I'm,
saying
that
the
person
who
is
building
software
at
a
given
Salter
level
is
typically
not
the
person
who
benefits
from
that
work.
The
person
who's,
it's
the
consumer
of
the
artifact
who
who
has
the
benefit,
a
lowered
risk
profile
and
the
greater
Assurance
of
Upstream
integrity
and
so
on,
and
they
they
may
conceivably
be
the
same
actor.
But
in
most
cases
they're
not.
E
Yes,
that's
correct,
hi,
hi,
Isaac,
sorry
to
be
late,
but
I
actually
tell
this
narrative
a
lot
as
or
I
formerly
have
as
a
product
security
architect
and
my
take
on
this
is
sure
you
can
use
fud.
E
You
know
the
standard
like
look
at
the
supply
chain
attacks
as
the
justification,
but
I
focus
on
the
quality
aspect
that
it
benefits
everyone
to
write,
quality
to
produce
quality
product,
and
that
would
include
you
know
using
salsa
levels
and
I
also
emphasize
that
the
idea
of
it's
part
of
my
tactic
and
my
Approach,
which
is
security,
is
a
feature
of
a
product
and
that,
ultimately,
it
saves
you
time
money
and
effort
by
integrating
you
know
security
processes
and
secure
components
to
your
product.
That's
typically
my
approach
to
this.
E
If
that
helps,
and
yes,
I
I,
think
it's
like
a
health
care
analogy,
like
you
have
in
in
community
health,
you
have
primary
prevention,
secondary
prevention
and
tertiary
prevention.
Primary
prevention
is
is
actually
the
cheapest,
but
the
results
aren't
immediately
seen
like
you
know,
exercising
and
eating.
Well
right,
you
it's
much
sexier
to
talk
about.
You
know
what
how
you
treat
cancer
than
how
you
prevent
it
way
ahead
right
and
I.
E
Think
that's
what
we're
looking
at
and
I
encourage
you
to
sort
of
use
the
some
of
the
sort
of
Community
Health
language,
for
example,
I'm,
really
a
fan
of
moving
Upstream
over
shift
left
because
it
it
really
provides
more
rationale
and
sort
of
a
bigger
picture.
You
know,
as
a
macro
practitioner
of
how
you
need
to
look
at
the
you
know
the
health
of
your
complete
software
development
life
cycle
and
that,
if
you're
putting
in
unhealthy
components
like
if
you're
eating
junk
food,
then
you
may
see
an
impact
way
down.
E
B
I,
like
I
I
love
that
I
love,
that
analogy
I
mean
I
I,
yes,
I
think
the
analogy
is
useful
and
I
think,
to
whatever
extent
that
we
can
talk
about
this
stuff
in
in
terms
of
people
readily
understand
from
other
parts
of
their
world
that
that's
that's
always
super
helpful.
B
I
still
think
that
there
is
the
problem
that
you
know
for
a
given
a
open
source
maintainer
the
cost
of
their
product
of
being
insecure
is
not
typically,
it's
not
typically
born
by
them.
It's
been
born
by
users,
and
so
that's
an
externality
for
the
maintainer
and
I
think
that
the
problem
that
we
have
is
when
we
look
at
moving
those
costs
and
saying
oh
well
now.
Actually
it's
also
build
you're
gonna
have
to
main
you're
gonna
have
to
bear
some
of
these
costs
yourself.
B
That's
just
in
terms
of
the
incentives,
particularly
around
open
source.
It
can
become
tricky,
but
I
love.
The
analogy
and
I'll
certainly
be
using
it.
A
And
I
think
we
we
try
to
do
some
of
that
right.
We
were
like
when
we
first
started.
Last
week
we
were
like
well,
it
reduces
human
error.
All
right
it
increases
consistency
across
builds
increases
efficiency
of
build
time
and
technically
release
or
time
to
release
right,
because
that's
what
companies
care
about,
also
not
only
just
costs,
but
how
efficient
is
it
to
actually
build
your
software
over
time?
And
how
consistent
is
it
because
consistency
also
drives
efficiency
right?
A
So
we
were
kind
of
these
were
the
three
that
we
could
identify
last
week,
but
I
like
this
preventative
versus
reactive
analogy
with
Healthcare
and
I'm
trying
to
see
what
else
was
there
factors
moves,
I
did
yeah.
We
did
write
this
last
week
for
level
two,
the
attack
vector
or
the
responsibility
moves.
A
So
basically,
instead
of
the
developer,
caring
about
potentially.
A
Caring
about
a
compromised
package,
it's
really
the
devsecops
team
or
the
IT
team
I,
don't
know
if
that's
a
real
benefit,
but
that's
something
that
I
think
we
saw
last
week.
We
were
thinking.
Maybe
that's
a
benefit
to
the
developer.
They
don't
want
to
worry
about
security.
They
want
to
transfer
that
task
to
somebody
else,
and
maybe
this
would
also
help
them.
If
something
is
level
two,
then
they
don't
necessarily
have
to
worry
about
security
as
much
because
it's
being
handled
more
Upstream.
E
I
added
the
note
about
the
whole
narrative,
if
that
makes
it
easier
for
you
to
grab
that
language.
There's
also
something
called
the
spectrum
of
prevention
if
you've
never
seen
that
in
healthcare,
I
can
certainly
put
that
in
there,
because
I
I
think
people
understand
even
senior
leaders
like
who
are
not
Technical
and
and
want
justification
for
maybe
why
they
need
certain
tools
that
support
supply
chain
security
that
might
resonate
better
with
them.
C
I
think
one
element
that
you
should
disclose
because
it's
a
common
question:
it's
not
only
the
value
that
you
can
extract
to
adopting
and
salsa,
but
as
well.
It's
expected
that,
for
example,
the
the
the
CI
pipeline
becomes
lower,
or
that
is
no
change
or
you
expected
that,
even
because
you
have
more
accountability
and
less
error,
because
you
have
more
accountability
to
be
faster.
That's
a
kind
of
debate
that
sometimes
you
have
when
you're
talking
about
supply
chain.
A
Can
you
clarify
for
me
because
I'm
not
sure
I
100
understood,
are
you
talking
about
like
the
performance
if
you're
doing.
C
C
A
It
take
longer
it
takes.
This
is
really
what's
it
called
a
I.
Can't
really
remember
the
term
right
now,
I'm
just
going
to
say
fallacy
for
now,
but
I
get
what
you're
saying
so.
A
C
No
I
I
think
that
we
can
at
least
address
in
the
first
part
and
the
second
part
how
you
make
this
that
not
affect
the
agility
of
the
development
life
cycle,
but
because
why
you,
of
course
you
of
course,
to
talking
about
other
strategies
and
everything
Regarding?
Why
should
I
care
about
salsa,
but
one
thing
that
it's
of
course
a
Latin
question
it's
and
about
agility,
speed.
It's
something
that
is
slowed
down,
creates
some
barriers,
or
things
like
that
that
are
probably
in
their
mind
of
the
the
reader.
A
E
I,
it
might
I
mean
it's
a
good
reminder.
I
always
use
it
in
anytime.
I
talk
about
product
security
because
to
the
point
about
you
know,
why
are
we
doing
this
when
it
might
just
when
we
won't
see
any
immediate
benefits
and
I
think
it's
it's
a
reminder
to
anybody.
Who's.
E
E
I
think
it's
more
I'm,
sorry
I
I
think
it's
more
about
demonstrating
that
that's
sort
of
the
foundational
health
check
for
you
know
does
that
make
sense.
A
A
You
know
how
they
like,
there's,
there's
misnomers
or
there's
a
better
word
for
it.
I
can't
think
of
it,
something
that
somebody
thinks
it's
true,
but
it's
not
it's
it
just
it's
never
true,
but
for
some.
C
C
A
Yeah
kind
of
like
that
right,
yeah,
yeah
and
so
I'm,
trying
to
think
of
a
section.
Maybe
that
says,
like
you
know,
these
are
myth
versus
fact.
There
you
go
myth,
myth
versus
fact
there
you
go
versus
fact.
E
Yeah
I
think
the
devsecops
manifesto
can
sort
of
speak
to
I
mean
if
you
were
using
that
as
your
North
Star
for
your
behavior.
You
know
for
how
you
interact
right.
I
think
that
sort
of
sets
the
tone
that
establishes
a
a
baseline
of
behavior
when
you're
doing
this
right.
A
One
of
the
things
I,
don't
think
we
came
to
conclusion
on-
was
about
the
source
discussion.
All
right
version.
One
does
not
have
anything
to
do
with
Source.
The
only
exception
is
a
do
mention
s-bomb,
but
that's
it.
They
mentioned
that
it
can
create
an
F-bomb.
A
Do
we
mention
I
know
we
mentioned
s-bomb
earlier
or
last
week,
but
do
we
mention
it
at
all?
Given
the
source
discussion
is
can't
be
had.
E
A
A
I
can
do
pictures.
Words
are
hard
for
me.
A
C
A
A
Oh
no
by
no
means
yeah
yeah.
This
is
a
a
a
group
blog
trying
to
put
it
out
as
a
positioning
group.
Okay-
and
we
just
started
writing
I-
think
most
of
the
really
good
writing
is
from
Jay.
It's
not
for
me,
I,
just
kind
of
write,
I,
think
in
bullets
and
I
write
in
bullets
so
that
the
anytime,
you
see
a
bullet.
It
was
probably
me.
A
So
so
yeah
any
anybody,
that's
willing
to
help
with
you
know
wordsmithing!
That's
writing
it
up,
making
it
all
nice
and
pretty
by
all
means
again,
I'm
really
good
at
pictures,
just
not
at
words.
C
Yeah
I
can
roll
up
the
sleeves
and
start
working
as
well.
I
I
I
thought
that
word
holding
the
fan
for
this.
But
if
you
eat
okay,
good
so
nope
are.
A
C
A
I
taught
you
that
I
can
add
it
as
well.
You
can
okay,
perfect,
so
Michelle
if
you
feel
free
to
see
if
you
can
type
in
it
outside
of
the
comments.
E
Yeah
I
I
do
I
I
I'll,
see
if
I
can
like
give
you
a
couple
of
paragraphs
of
stuff.
E
My
voice
tends
to
be
very
specific,
but
I'm
sure
you
can
like
Wordsmith
and
manipulate
it
to
benefit
the
blog
itself.
Yeah.
A
Yeah
awesome
anything
else
from
folks.
You
know
we,
it
looks
like
we
lost
Mike,
but
for
folks
that
are
still
around
that
have
been
quiet.
That's
questions.
A
Cool
okay:
well
then,
I
will
let
everyone
go
I'll,
probably
just
stick
around
and
keep
you
know
playing
with
this
document,
but
I
don't
want
to
hold
anybody
up.
So
if
you
need
to
leave
early
by
all
means
feel
free
to
leave
early.