►
From YouTube: SLSA Specifications Meeting (May 22, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj
A
B
C
A
A
A
D
Well,
so
so
we
were
talking
in
the
in
the
positioning
at
the
sci
positioning
meeting,
and
you
know,
after
a
series
of
presentations
that
we've
all
given
on
on
the
different
Frameworks,
that
we're
working
on
inside
of
the
supply
chain,
Integrity
workings,
it's
also
being
one
of
them.
One
of
the
things
that
that
we've
noticed
based
on
the
questions
we
received
with
salsa.
That
makes
it
very
well.
D
You
know
we
we
we
muscled
through
them,
because
of
course
working
on
it.
You
know
we
understand
what
we're
attempting
to
do
or
what
we're
what
we're
trying
to
convey,
and
we
understand
the
usability
and
we're
excited
about
it,
but
when
it
comes
to
the
way
that
the
community
is
consuming
salsa
and
the
way
they
understand
salsa,
one
of
the
things
that
we're
recognizing
is
that
you
know
we.
We
are
saying
security
framework,
then
we're
saying
conforming
or
complying,
then
we're
saying
no,
then
they'll
their
maturity
levels
and
one
of
the
things
I.
D
Don't
think
that
we
do
a
good
enough
job
of
in
the
specification
in
the
text
in
the
documentation
is
discerning
security
framework
from
compliance
requirements
and
then
maturity
model
based
on
the
maturity
of
either
meeting
the
respective
security
controls
or
maturity
in
terms
of
where
we
are
in
in
compliance
and
then
when
is
it
one
or
the
other?
When
can
it
be
both?
D
So
it's
use
its
use
in
what
context
and
then
it'll
help
us
when
we're
discussing
the
and
nature
of
salsa,
meaning
we're
not
trying
to
change
what
you're
currently
doing
we're
trying
to
enhance
what
you're
currently
doing
with
the
use
of
of
salsa,
but
how?
But,
but
how
does
that
work
when
we
are
not
being
specific
in
text
on
what
is
it
when
it
is
what
it
is
and
then
how
do
you
properly
incorporate
it
within
your
organization
based
on
desired
use
and
purposes?
E
F
D
So
so
Chris
when
we
talk
about
level
one
two,
three
and
four
that
suggests
maturity,
all
right
and
and
the
capability
of
maturity
model
any
capability
maturity
model,
any
material
model.
You
see
when
you're
discussing
levels,
that's
maturity
and
that's
the
way,
the
that's
the
way
the
industry
recognizes
maturity
in
levels,
okay,
so
and
then
in
the
beginning,
this
is
way
last
year,
salsa
was
a
compliance.
It
also
was
a
set
of
compliance
requirements
and
then
changed
to
a
security
model
until
later.
D
Okay,
so
what
I'm
saying
is
when
you
take
a
look
at
what
it
used
to
be,
what
it's
morphed
into
and
keep
in
mind
a
lot
of
great
work
has
been
done
to
narrow
it's
to
narrow
its
focus,
narrow,
its
scope,
get
something
that's
usable
and
now
to
the
consumer.
Remember
the
work
that
we're
doing
is
not
seen
by
everyone
else,
so
transparency
and
transparency
out
they
see
what
was
in
the
beginning.
They
see
what's
happening
now,
so
we
get
a
lot
of
questions.
G
D
Oh
Absa
absolutely,
and
the
reason
why
that
I'm
bringing
this
up
here
is
because
we're
looking
at
similar
what
could
become
similar
issues
down
the
road,
but
in
s2c12
we're
not
detracting
from
it
being
matured
before
being
a
maturity
model.
We're
not
detracting
from
that.
We
actually
say
that
we
say
it's
a
maturity
model
based
on
meeting
a
set
of
security
controls,
there's
nowhere
in
s2c
to
work
for
we're,
saying
it's
a
complex,
it's
a
compliance
requirements.
D
What
I'm
saying
is
that
in
the
beginning,
salsa
started
off
as
a
set
of
compliance
requirements.
Then
it's
a
set
of
security
controls
and
now
we're
saying
salsa
conformance.
What's
the
difference
between
conformance
and
compliance
right
and
what
I'm
saying
here
is
that
we
have
to
be
very
careful
with
what
salsa
is
when
it
is
in
order
to
properly
say
well.
This
is
how
you
can
incorporate
it.
The
difference
between
Salsa
and
s2c2f
in
this
regards
that
s2c12
was
never
a
set
of
compliance
requirements.
It's
always
been
a
security
framework
and
it's
a
maturity.
D
D
A
You
so
I
feel
like
you're,
saying
words
and
I:
don't
know
what
they
mean
like
I'm,
not
familiar
with
the
term
compliance
requirements
versus
maturity
model.
When
you
say
it
was
compliance
requirements
of
his
now
maturity
model
like
could
you
go
into
more
detail
of
like
when
that
happened,
and
what
like?
What
is
the
difference.
D
D
We
have
salsa
levels,
one
two,
three,
four
whatever
and
at
this
level
I'm
meeting
this
set
of
security
requirements,
so
I'm
influenced
so
when
I
implement
this,
and-
and
this
is
good
and
I-
can
attest
to
this
and
then
I'm
meeting
this
level
of
of
salsa
that
makes
salsa
at
that
maturity
at
that
respective
maturity
level.
I'm
meeting
these
sets
of
complexion
requirements,
if,
in
fact,
you
are
saying
in
this
instance
we're
using
salsa
as
a
set
of
com
of
compliance
requirements.
D
Now,
if
you're
saying
I'm,
saying
I'm
using
salsa
as
a
security
framework,
then
I'm
at
level
two
maturity
based
on
meeting
B
sets
of
this
criteria
of
security
controls.
Now
you
can
say,
salsa
in
this
regard
is
a
security
framework.
When
used
this
way,
it's
compliance
requirements
when
used
this
way
help
you
might
even
be
able
to
get
away
with
saying.
If
you
implement
this
set
of
controls
or
requirements,
then
you
are
in
terms
of
security
for
salsa
you're
at
a
level
three,
but
in
terms
of
compliance
based
on.
D
You
know
the
implementation
of
this
against
these
set
of
compliance
requirements
and,
let's
say
you're
using
something
like
I,
don't
know
and
once
again,
I'm
being
a
bit
facetious
here,
let's
say
using
PCI
or
HIPAA
or
something
else,
then
I'm
then
again
send
using
these
compliance
requirements
against
also
this
compliance
requiring
based
on
industry.
We
are
adding
level
two,
so
you
could
say
I'm
a
level
three
for
security
I'm,
a
level
two
for
compliance.
I
know
that
that
is
a
lot
with
them.
D
Just
what
I'm
saying
right
now,
but
what
I
mean
here
is:
if
we're
not
properly
putting
that
in
the
specification
in
the
text
and
giving
those
examples
to
the
consumer,
it
could
become
very
difficult
for
them
to
understand.
Hence
why
we're
receiving
a
lot
of
the
questions
that
we're
receiving
in
these
presentations.
E
F
D
Compliance
requirement:
you
need
to
make
sure
that
your
policy
is
updated
once
a
year.
So
when
an
assessor
comes
down
and
looks
at
your
security
policy,
if
they
look
at
the
data
security
policy
and
your
security
policy
has
not
been
updated
in
the
years,
then
you
are
not
in
compliance.
Okay,
security
control.
D
You
need
to
make
sure
that
your
security
policy
is
reviewed
by
two
people.
It
has
to
have
two
people
in
a
review
process,
so
compliance
says
well.
My
policy
is
updated
within
the
year
so
for
compliance
I'm
good,
but
as
a
security
control.
Well,
yeah.
Your
policy
has
been
updated,
but
your
policy
hasn't
been
updated
or
hasn't
been
reviewed
by
two
people,
so
you're
not
meeting
the
right
security
control.
The
control
says
this
needs
to
be
reviewed
by
two
people.
D
In
order
for
it
to
be
considered,
you
know,
in
order
for
it
to
be
considered
right
or
whatever
it
is
so
compliance
says
it's
been
reviewed
in
the
year.
What
I'm
doing
here
is
I'm
taking
it
outage
of
your
car
is
posted,
and
this
is
a
meme
I
love.
Your
car
is
supposed
to
have
a
spare
tire.
It
doesn't
say
what
size
the
spare
tire
needs
to
be.
It
just
needs
to
have
a
spare
tires.
You
can
have
17
inch
wheels
on
your
car.
Your
spare
tire
in
the
back
is
15..
D
Do
you
have
the
spare
tire,
of
course,
but
does
it
mean
that
if
you
get
a
flat
tire
your
car
is
going
to
be
able
to
run
properly
yeah?
No,
all
right
so
that's
I
mean
there's
a
difference
between
compliance
and
I'm,
breaking
it
down
ounces
to
small
boats
here
for
since
they
asked
the
question,
but
that's
the
between
compliance
and
and
security
controls
in
general.
F
F
D
B
D
The
the
required
the
compliance
requirement
is,
is
the
frequency
not
the
control.
The
control
is
what
you
need
to
have
in
place
to
make
sure
that
that
you're
you're
either
you
go
through
the
process
of
protect
prevention,
protection,
detection,
correction,
you
know,
I
mean
God,
you
have
to
be
a
security,
but
I
mean
security.
Folks
will
understand
this
potential
protection,
prevention,
correction,
detection,
there's
a
there's
a
fifth
one.
In
there
you
you,
those
are
controls.
F
I
I'm
not
sure
I
I
mean
I
I.
Think
that
there's
some
background
that
I'm,
missing
and
I
can
look
that
up
on
my
own
time,
but
it
sounds
to
me
like,
and
so
both
freshness
and
two-party
review
are
ways
of
building
confidence
in
the
correctness
of
the
policy.
I
see
those
as
both
being
related
to
security,
so
I
think
that
there's
there's
a
detail
that
I'm
missing
or
there's
a
framework
for
discussing
security
that
I'm
not
familiar
with
so
I
I
believe
we're
at
the
point.
Thank
you
for
your
patience.
E
So
what
one
quick
thing
just
because
I
as
somebody
who's
lived
in
both
worlds
I
can
maybe
provide
a
little
bit
of
color
there.
There's
still
a
lot
to
be
read
about
and
to
kind
of
take
Jay's
analogy
with
the
car
a
little
bit
more
right,
like
compliance
is
stuff
like,
for
example,
in
New
York
right
I
need
to
get
my
car
inspected
every
year.
That
is
compliance.
That
does
not
mean
that
my
car
is,
you
know
safe
from.
E
Like
you
know,
my
engine
is,
is
well
maintained
or
whatever
it's
just
it's
a
set
of
things
to
make
sure
that
I'm
actually
complying
with
the
law,
and
often
compliance
has
a
lot
of
different
factors.
Sometimes
it's
internal
compliance.
Are
you
complying
with
your
own
internal
practices
and
those
sorts
of
things
they're,
not
necessarily
always
focused
on?
Like
actual
you
know,
bike,
you
know
in
certain
cases,
by
complying
with
these
things.
E
You
know
that
that
is
a
very
true
sort
of
thing,
especially
among
csos
is
they're
balancing
between
hey,
if
I
sign
off
on
these
things
and
it
turns
out
they're
not
correct,
I
could
go
to
jail
for
that
which
is
separate
from
actual
security
controls,
but
but
and
then
to
kind
of
go
into
the
security
control
space
a
little
bit.
Security
controls
are
just
usually
sort
of
descriptive.
E
What
should
exist
that
indicates
that
you
know
you're
protecting
against
some
sort
of
risk.
It's
usually
associated
with
a
risk.
Something
like
you
know,
the
the
risk
is,
you
know
we're
worried
about.
Third,
you
know
we're
worried
about
external
things:
external,
like
dependencies.
You
know
compromising
our
systems,
so
we
have
a
control
that
you
know
protects
against
ingestion
or
whatever,
so
that's
kind
of
a
very,
very
high
level
and
there's
a
whole
bunch
of
stuff
in
there
about.
E
You
know
you
have
policy,
usually
at
the
top,
and
then
you
have
you
know,
controls
and
you
have
processes,
and
you
have
a
bunch
of
other
things
there
and
it's
kind
of
like
an
Enterprise
e-risk
sort
of
thing
that
doesn't
apply
to
every
different
space,
but
I
think
from
the
salsa
perspective.
There's
concern
about
how
it's
interpreted
and
how
folks
are
looking
at
this
like,
for
example,
nist,
853,
190
Etc
are
controls
and
it's
a
control
catalog
and
that
sort
of
thing
and
is
salsa
a
set
of
controls.
Is
it
a
compliance?
E
G
F
E
So
I
think
a
little
bit
of
it
is
is
from
my
perspective,
what
I
think
has
happened
is
a
little
bit
folks
who
are
not
aware
of
the
differences
that
are
mostly
a
management
and
executive
sort
of
vocabulary
thing
you
know
when
we
say:
oh,
are
you
compliant
with
salsa?
We
use
it
very
colloquially,
whereas
there
are
certain
folks
who
view?
Oh,
are
you
compliant
with
salsa?
B
A
C
E
You
know,
because,
because
I've
heard
just
to
be
clear,
like
I've,
I've
I'm,
not
as
deep
as
as
Jay
is
in
in
probably
those
like
sorts
of
discussions
that
he's
having
and
and
folks
that
I
believe
who
are
who
are
involved
in
the
salsa
Community
are
having.
But
what
I
will
say
is
I
know
that
there's
going
to
be
groups
of
folks
who
are
at
that
sort
of
at
a
certain
level
in
in
Enterprises
that
are
looking
at
Salsa
and
at
some
level
they're
saying,
hey,
I
have
a
set
of
boxes.
E
I
have
a
set
of
boxes
for
standards
for
guidelines,
for
you
know,
policies
for
compliance
and
so
on
and
they're,
not
sure
which
of
the
boxes.
Salsa
exactly
falls
into
and
part
of
it
is
more
of
a
language
thing,
but
I
think
to
you
know
some
of
the
discussions
that
was
brought
up
is.
It
sounds
like
it's
more
of
just
like,
maybe
even
in
the
FAQ
a
little
bit
to
just
sort
of
have
something
in
there.
That
says,
salsa
is
of
this
and
when
you're
you
know
viewing
it.
A
Yeah
I
think
in
general,
like
not
specific
to
this
particular
issue,
but
in
general
I
think
the
we
could
do
more.
I
would
like
to
see
more
Clarity
around
like
how
you
use
salsa
and
how
it's
expected
to
be
used
of
like
how
particularly
how
you
would
apply
salsa
to
an
organization
like
if
you're
a
company
like
how
you
know.
A
How
would
you
go
about
using
salsa
I,
think
that
would
be
valuable
like
even
if
you're,
not
in
this
compliance
world,
I
think
just
in
general,
just
to
kind
of
give
a
framework
for
like
this
is
how
we
think
about
salsa,
and
this
is
how
we
kind
of
expect
to
be
a
stuff.
I.
I
agree
with
that.
Even
without
having
to
understand
the
intricacies.
E
Yeah
and
and
just
something
actually
forgot
to
bring
up
but
I,
think
that's
along
those
same
lines
is,
you
know,
and
I've
worked
in
sort
of
the
banking
compliance
world
and
from
that
standpoint
really
I,
don't
think
I,
don't
think
salsa
fits
into.
Let's
say
the
the
compliance
side
of
things,
because
I
think
it's
you
know
and
I
don't
mean
to
hate
on
compliance.
E
I
anticipate
salsa
at
a
lot
of
Enterprises,
especially
I'll
talk
about
banking,
because
that's
the
one
that
I'm
most
familiar
with
is
banking
will
have
something
like
a
a
set
of
high-level
policies
and
those
high-level
policies
might
include
something
like
you
know.
You
need
to
be
following
a
set
of
Frameworks
on
securing
against
third
party
risks
or
whatever
or
securing
you
know.
You
know
securing
the
software
delivery
life
cycle.
Great!
E
That's
sort
of
a
high
level
policy
and
then,
when
you
get
down
to
the
actual
standards
or
or
in
in
some
cases
procedures,
you
might
say
we
are
adopting
salsa
as
the
framework
that
helps
us
hit
this
internal
requirement.
We
have,
and
so
that's
kind
of
where
a
lot
of
that
would
go
through
and
so
like
from
a
high
level
policy
standpoint.
E
If
you
look
at
ssdf,
it
has
a
lot
of
these
high
level
controls
and
in
fact,
I
believe
ssdf
does
cite
salsa
as
something
to
look
at
as,
like
you
know
the
the
guidelines
for
yeah.
So
yes,
there's
a
mapping
from
salsa
ssdf,
but
there's
also
the
opposite,
I
believe
as
well.
If
I
do,
there
is
somewhere
in
the
ssdf.
G
E
E
E
And,
and
also
to
what
Andrew
said
yeah
so,
there's
also
a
lot
of
in
this
sort
of
space,
the
difference
between
sort
of
prescriptive
and
descriptive
right.
So
a
lot
of
cases,
you
know
compliance
and
a
lot
of
stuff
like
controls,
are
more
descriptive,
like
you
are
providing
evidence
of
a
thing,
as
opposed
to
prescriptive,
of
like
you're,
actually
doing
a
specific
thing.
C
C
Think
that
that
some
of
the
concerns
in
this
area
might
be
able
to
be
deferred
to
the
Auditors
in
the
conformance
program
who
are
are
like
you
can
have
Auditors,
and
then
you
can
have
Auditors
who
are
trusted
by
some
other
entity
which
actually,
like
you,
can
audit
the
Auditors
to
make
sure
that
what
they're
checking
is
actually
sensible
for
your
own
organization.
Your
own
internal
processes
like
how
thorough
are
the
Auditors?
C
What
are
the
the
auditor's
actual
requirements
so
like
again,
I
I
feel
like
a
lot
of
these
are
important
questions
and
I
think
that
it
really
depends
on
what
the
perspective
is
that
you're
coming
from,
and
how
you're
approaching
the
the
secure
supply
chain
process
and
what
it
is
that
you're
concerned
about
and
and
where
you
you
place.
Your
trust.