►
From YouTube: SLSA Specifications Meeting (September 23, 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).
B
A
C
You
know
I
saw
that
a
lot
I
took
a
lot
of
stuff
today,
I
put
do
a
lot
of
pen
and
Pen
the
paper
stuff
today.
I
only
have
really
Friday
now
only
to
to
a
lot
of
the
writing.
Yeah.
B
Yeah
I
I'm,
not
a
fan
of
writing.
To
be
honest,
it
takes
me
forever
and
a
day
I'm
much
better
at
visualizations
than
that
takes
me
forever
to
write
a
page.
B
Okay,
let
me
see,
did
anybody
else
because
I
know
Gilbert
said
he
could
make
this
Marcella
said
she
could
make
this
so
we'll?
Oh
there's,
Aleister,
hey
Aleister!
Thanks
for
joining
all
right,
we'll
give
folks
a
couple
more
minutes,
because
I
do
know
that
there
were
other
people
that
said
that
they
could
join
at
this
time.
D
Hey
Jay
nice
to
second
call
this
week,
I've
been
on
with
you.
C
Yeah
we
we,
we
have
to
keep
meeting
like
this.
That's
with
us.
We
have
to
keep
meeting
like
this.
These.
These
calls
are
great
because
of
fun.
B
But
Jay
is
this
and
John
actually
do
you
do
open
source
as
a
full-time
job
or
is?
Is
this
just
kind
of
like
a
side
part
of
your
job?
Well,.
C
My
whole
Rhyme
or
Reason
is
is
open.
Ssf.
C
That's
my
whole
Rhyme
or
Reason
and,
of
course,
I
have
other
other
projects
or
programs
I'm
spearheading
too
internal
to
Microsoft,
but
they're
all
centers
around
Microsoft's
Community
involvement
in
open
source
and
centered
around
our
involvement
and
in
the
in
the
open,
ssf
nice.
A
Kind
of
both
in
the
you
know
my
day,
job
is
working
for
active
State
and
doing
whatever
they
want,
but
active
state
is
primary.
Focus
is
on
producing
binary,
builds
of.
E
A
B
F
Yeah,
would
you
want,
would
you
like
my
answer
or.
F
Okay,
sure
I
wasn't
sure
yeah,
so
we
our
platform,
I'll
call
it
we
up
level
or
the
devops
orchestration.
So
we
we
integrate
existing
Investments
that
you
know
a
customer
has
used
either
open
source
or
non-open
source,
so
commercial
or
open
source.
We
ourselves
spin
up
a
bunch
of
Open
Source
projects,
open
source
tools,
like
you
know,
Jenkins
summer
Cube,
Argo,
CD,
Etc
right,
so
we
ourselves
use
open
source
to
to
help
customers
out
there.
F
B
It
okay
yeah
this.
This
is
definitely
not
my
full-time
job.
It
just
happens
to
coincide
with
some
of
the
stuff
that
I
do
and
so
I
always
I'm
always
curious
how
people
can
attend
so
many
meetings
because
I'm,
like
oh
man,
all
my
other
meetings
are
like
killing
my
schedule
so
yeah.
It
just
happens
to
be
that
I
work
in
supply
chain
security
right
internally
and
I'm
like
okay.
C
F
There
there
is
definitely
I
hear
you
from
a
supply
chain:
security,
I
used
to
run
product
security
for
a
company
before
this
one
and
it's
a
it's
like
a
very
love-hate
relationship
with
Community
or
with
like
developers
and-
and
you
know,
it's
really
hard
to
get
them
to
change
if
you're,
not
with
them
at
the
ground.
Yeah.
B
F
That's
what
we've
experienced
and,
and
then
you
hear
all
these
like
the
stuff-
that's
happening
in
the
news.
As
of
you
know
two
days
ago,
right
or
last
week
what
happened
with
Uber
and
this
week
what
happened
with
American
Airlines
and
you
you
continue
hearing
those
things
and
you're
like
man.
Why?
Why
does
this
keep
happening?
Mm-Hmm.
D
I
am
I,
I,
still
I
kind
of
think
of
myself
as
a
developer.
Even
now,
but
I
I,
I
I
work
with
a
lot
of
developers
and
and
I
I
worry
about
the
supply
chain.
Security,
stuff
I
have
done
for
quite
a
while,
and
but
most
people
just
don't
it's
like
they.
They
want
to
see
stuff
work
and
anything
to
do
with
this
stuff
doesn't
help
them
make
stuff
work.
D
It
makes
it
harder
because
they
have
all
this
other
stuff,
that
you're
saying
they
have
to
think
about,
and
they
just
want
to
go
and
pick
up
something
from
npn
or
or
made
in
Central
and
use
it.
It's
it's.
It's
a
challenge
to
get
people
to
kind
of
realize
that
there's
all
of
these
you
know
attack
vectors
that
they
need
to
care
about
yeah,
it's
like.
Why
would
anyone
do
that?
It's
like
well,
because
they
want
to
hurt
you
I.
F
Mean
right,
that's
funny.
Yeah
I
would
love
to
talk
to
you,
though,
more
on
that
topic,
and
not
not
today,
obviously,
but.
B
B
So
where
do
you
want
to
go
from
here
because
I
know?
Last
time
we
talked,
we
had
this
whole
sticky
session
and
then
I
created
this.
You
know
nice
condensed
picture
and
then
Jay
talked
about
the
new
Microsoft
framework
that
came
out
and
I
know
that
there's
this
question
that
you
have
out
there
that
I've
not
answered.
So
where
do
you
wanna
go
with
this
martial
because
I
know
you
had
some
thoughts
for
today.
E
I
think
mostly
I
want
to
make
sure
that
we
align
with
the
Microsoft
SSC
either
make
sure
that
we
complement
that
or
just
even
understand,
yeah
how
those
two
fit,
because
the
last
thing
that
I
think
any
of
us
wants
is
to
duplicate
work
at
this
point,
so
I
think
if
we
can
just
get
a
better
understanding
of
what
the
SSC
is
going
to
be
covering
and
what
the
gaps
are,
that
salsa
may
still
be
able
to
fill
I
think
that
would
be
my
a
sort
of
goal
for
today.
C
C
Okay,
these
the
scope
of
these
are
two
different
two
different
Scopes
and
they
should
remain
two
different
scopes
once
focused
on
on
producing
bill,
builds
that
that
Encompass
open
source
and
they
and
it
involves
the
bills
that
get
produced
from
the
secure
supply
chain
and
the
other
one
involves
ingesting
open
source
and
third-party
binaries
towards
the
build
of
services
and
and
applications
throughout
the
supply
chain.
Right,
so
so,
I
do
want
to
keep
that.
That's
like
the
separation
of
church
and
state.
C
C
Charity
and
the
controls
and
the
architecture
and
and
the
posture
that
you're
taking
towards
how
you're
consuming
open
source,
unless
you
thoroughly
understand
what
the
end
result
is
going
to
be
and
how
you're
going
to
reach
IA
and
GA
regarding
the
builds
and
the
packages
that
are
produced,
and
then
you
can't
successfully
build
guard
rails
around
or
compliance
around
or
artifacts
and
attestations
around
how
those
builds
were
developed,
s-bombs
or
otherwise,
without
understanding
your
ingestion
point
with
respect
to
the
components
of
the
third
party
binaries
used
in
order
to
to
create
those
builds.
E
Yeah
absolutely
the
reason
why
I
did
bring
that
up,
though,
is
because,
during
the
last
meeting
that
you
unfortunately
weren't
part
of
there
was
some
of
what
we
talked
about
was
actually
ingesting
open
source
software
into
proprietary
Enterprise
settings.
E
And
so
that's
kind
of
the
touch
point.
That
I
was
seeing.
B
C
Okay,
yeah
got
it
got
it,
got
it:
okay,
good
good,
so
so
so
yeah
excellent,
then.
So
this
is
an
excellent
topic
of
the
session
to
bring
in
because
this
is
exactly
what
the
vision
is
marching.
These
two
documents
together
because
I
think
they
run
hand
in
hand,
so
so
excellent,
good,
good,
good,
groundhog,
yeah.
B
Yeah,
so
this
is
what
we
came
up
with
based
off
of
how
I
think
a
few
of
the
folks
on
the
call
how
they
do
their
ingestion
of
Open,
Source
software
and
so
there's
two
different
scenarios,
and
this
is
how
it
runs
with
the
build
whether
it
be
an
internal
mirror
that
that
is
being
pulled
from
for
the
build,
or
it
looks
at
some
sort
of
database
for
the
record
of
here's,
where
you
should
be
pulling
the
open
source
software
from
and
then
you
can
go,
pull
it
from
the
actual
public
repo,
so
I
it
sounds
like
your
framework.
B
C
You
know
what
I'm
asking
so
this
diagram
is
great.
There
is
one
out
there
right
now
that
does
this
from
end
to
end
John
Meadows
created
it
for
City
I'm,
asking
them
right
now
he
has
a
scrubbed
version
of
it,
because
I
think
it's
outstanding
and
I
think
it
speaks
to
both
ends
of
the
scale.
C
It
coincides
with
this
one
that
can
help
fill
gaps
on
this
I
I
so
and
the
reason
why
I'm
saying
that
is
because-
and
so
so
John
Meadows
is
he's
the
working
group
chair
for
for
the
end
users
working
group.
C
Okay-
and
they
opened
us
this
up,
so
we
don't
have
to
recreate
the
wheel
here.
We
can
improve
upon
the
wheel,
that's
being
we
have
to
recreate
it,
we
can
improve
upon
it
right.
He's
he's
he's
this
diagram
he's
created,
goes
from
ingestion
all
the
way
to
to
to
to
availability.
I
mean
this:
it's
like
it's
a
complete
diagram
and
and
he's
he's
looking
at
this
stuff
in
such
a
way
where
he's
like
dude.
This
fits
right
in
right
here.
This
fits
right
in
over
there.
C
Adrian
and
I
had
a
one-on-one
with
him
right
now
to
talk
about
how
the
what
he's
doing
in
City
the
mirrors,
what
where
what
we're
talking
about
in
the
SSC
and
of
course,
on
the
other
end
on
the
build
end,
what
he's
doing
there
has
relevancy
and
mirrors
what
what
we're
talking
about
in
salsa?
So
so
it
so.
The
use
case
is
here:
I
just
asked
them
for
a
copy
of
that.
C
That
I
could
then
could
bring
bringing
this
mean
if
he
responds
to
me
right
away
I'll,
so
a
scrub
version
of
it,
of
course
yeah
but
I'll
bring
it
here,
but
but
yeah
no
absolutely
I
mean
we
can
talk
about
the
gaps
gaps
between
one
side
and
the
other
yeah.
B
Sounds
like
then,
Jay
you're
waiting
for
John
to
reach
back
out,
because
I
I
would
be
curious
to
see
it
to
see.
Does
he
have
other
scenarios
or
how
many
scenarios
does
he
have
in
terms
of
how
this
could
be
accomplished?
B
B
C
As
soon
as
he
reaches
back
out,
you
know
I
just
message
him
just
now.
I
know
and
I
know
he
had
another
meeting
so
so,
and
I
I
just
spoke
to
him.
Maybe
like
20
minutes
20
minutes
ago,
so
I
know
he
was
jumping
to
another
meeting.
C
He
reaches
back
out
I'll,
be
able
to
I'll
be
able
to
pop
this
in,
but
he
had
a
few
use
cases
yeah.
He
had
a
few
use
cases
and-
and
it
looks
so
good
and
that's
the
reason
why
I'm
I'm
even
bringing
it
up,
because
when
I
looked
at
I
said
oh
man,
this
is
amazing.
Somebody's
already
did
this
work.
Yep.
B
B
So
then
Marcella
because
of
this,
do
we
want
to
hold
on
these
questions
that
you
had
because
ultimately
they
stemmed
from
you
know
right
the
separation
of
attestation,
but
you
first
have
to
understand.
Well
how
does
the
source
work
yeah.
A
B
C
Well,
I
think
I
think
that
goes
that
ties
back
into
what
we
were
saying
before
about
scope
and
and
making
sure
that
that
we
that
we
don't
you
know
in
an
effort
to
try
to
cover
cover
down
on
all
ends.
We
begin
to
do
a
little
scope.
Treat
can.
C
I
was
going
to
say
we
we
begin
the
scope
creep,
where
we
got
other
things
that
that
we're
doing
that
could
clothes
could
fill
those
gaps
right.
C
That
are
that
that
have
their
own
scope
and
that
way
we
can
keep
things
streamlined
on
on
one
side
of
the
other,
and
it
takes
less
thought
or
or
less
you
know
it
takes
less
muscle
to
just
go
with
the
flow
of
what
we're
currently
doing,
letting
the
other
one
come
in,
and
you
know
tack
on
a
bolts
on
you
know
where,
where
the,
where
the,
where
there's
separation,
you
know
you,
you
can
keep
them
separated,
but
then
kind
of
bridge
Bridge
those
two
thoughts
together,
so
that
you
maintain
the
scope
of
each
respective
one,
but
there's
Bridges
to
close
those
gaps.
F
I
was
just
gonna
point
out
some
use
cases
on
the
build
scenario
right
sure
that
was
it.
So
a
couple
of
use
cases
that
we've
seen
is
obviously
securing
the
build
machine
right
that
no
one
can
inject
code
at
the
time
of
build
right.
That
would
be.
That
would
be
one
number
two
a
lot.
A
lot
of
the
use
cases
we
see
is
the
build
machine
itself
like
where
how
secure
is
that
from
a
I'll
call
it
code,
AS
image
or
image
as
code?
F
You
know
that
that's
number
two
and
then
number
three
yeah
definitely
challenging
or
recording
all
of
the
build
metadata
right.
How
do
we?
How
do
we
record
that
and
then
number
four
would
be
what
is
in
the
build
like
what
kind
of
I'll
call
it
a
blueprint
if
you
will
of
of
what
the
build
looks
like
at
every
run
time
or
every
every
time
it's
ran
in
a
pipeline,
so
the
run
count.
F
What
changes
in
the
run
count
happen,
so
those
are
kind
of
four
things
that
we
see
number
five
I
guess
would
be
like.
Do
we
challenge
the
person
that
is
actually
building
the
artifact
when
you're
you
know,
can
we
challenge
that
author?
Even
though
we
have
it,
can
we
still
challenge
them
as
a
salsa
level?
4
capability,
because
the
problem
in
open
open
source
is
that
we
don't
have
control
over
the
source
even
today,
GitHub
gitlab
Etc.
F
B
So,
are
you
talking
so
you
said,
use
cases
on
build,
but
you're
purely
talking
about
not
the
software
and
the
protection
or
the
Integrity
of
that
software
more
on
the
build
system,
and
what
it's
doing
is
that
is
that
accurate,
yeah.
C
F
You
have
a
salsa
also,
we
got
to
track
the
history
and
the
metadata
right
of
who
touches
those
artifacts
like
component
mentorship
and
Providence
verified
I've
I've
built
a
diagram
for
us,
can
I
share
it.
I
I,
don't
know,
it'll
be
completely
there
of
what
you
want
and
I
have
I
haven't
Incorporated
the
stuff
that
you
built
or
that
we
built
on
the
salsa
stuff
last
time,
I
I
just
kind
of
want
to
explain
that,
but
I
mean
they're,
definitely
agree
with
sharing
here.
F
I,
don't
know
if
this
helps,
but
this
is
kind
of
what
I
was
I
was
thinking
so
developer
checks
in
code,
a
new
for
feature,
X
right.
We
don't
have
kind
of
governance
over
GitHub
or
gitlab
or
et
cetera,
because
they
they
require
a
lot
of
things
from
a
security
point
of
view,
so
the
authorship
in
Providence
gets
recorded
to
a
metadata
store.
Some
metadata
I
just
call
this
inception
for
now,
which
is,
if
we
think
about
metadata
stores,
we
I
think
of
them
as
connected
assets
or
connected
objects.
F
Right
from
you
know
like
a
neo4j
graph
database.
Eventually
that
has
metadata,
and
we
continuously
record
that
metadata
right
and
then
in
in
my
ideal
world
I
would
inceptionally
challenge
right,
I,
don't
have
to
say
I'm,
sorry
but
I'm,
sorry,
I'm,
sorry,
I
will
challenge
the
2fa
against
the
author
to
verify
that
that
is
the
correct
author,
because
if
Jay's
credentials
are
compromised,
I'm
just
picking
you
out,
Jay
sorry
don't
mean
it.
I'll
get
you
specifically,
but
if
Jay
is
saying
hey,
this
is:
is
this
really
J
right
as
opposed
to
a
bad
actor?
F
F
A
It
does
I'm,
not
sure
I,
think
you
might
get
a
bit
of
pushback
against
that
again
in
kind
of
General
open
source.
You
know
I've
published
my
thing
and
I'm
done
with
it.
It's
kind
of
the
the
way
that
they
want
to
do
it.
They
don't
want
to
kind
of
be
Fielding.
2Fa
queries
every
time
somebody
ingests
their
source
code.
C
Got
it
yeah
I'm,
not
I'm,
not
totally
sure
it's
it's
it's
it's.
There
was
well
in
the
perfect
world,
you'd
like
to
think
that
everyone
has
a
has
a
moral
compass
or
everyone
has
a
an
ethical
responsibility,
but
that
but
I
think
we're
talking
about
ethics
versus
versus.
C
You
know
it's
not
their
responsibility
to
make
sure
you
secure
your
environment
right,
you
can
go
back
and
challenge
them,
but
but
I
mean
they're,
not
they're,
not
trying
to
hear
that
they
publish
it's
out
there.
If
you
decide
to
ingest
it
in
your
organization,
you
need
to
do
the
proper
scans
and
and
check
for
profits
and
check
for
licensing
and
everything
else.
You
gotta
do
that.
You
gotta
make
sure
that
that's
covered
down
yourself,
I.
A
C
D
I
think
I
think
it's
I
think
this
is.
It
feels
like
in
case
where,
if
you
don't
trust
the
open
source
project
X
to
have
validated
that
the
source
being
contributed
to
it
came
from
a
trusted
developer,
then
you
probably
shouldn't
be
using
that
piece
of
Open,
Source
and
I.
I
definitely
agree
that
if
you
come
back
six
months
later
and
so
I
try
to
interrogate
somebody
who's
the
commit
as
to
whether
or
not
they
are
who
they
really
are,
I,
don't
think
you're
going
to
be
able
to
do
that.
D
And
you
know
that's
because,
like
there's
privacy
issues,
potentially
with
that,
but
I
I've
seen
cases
you
know
log
when
log4j
happened
right,
there
was
a
whole
bunch
of
people
who
were
basically
sending
email
to
random
open
source
projects.
Saying
I
need
you
to
confirm
by
the
end
of
day
today
that
you
do
not
do
or
do
not
include
log
for
J
in
your
open
source
project
because
of
my
corporate
compliance
requirements
everywhere
that
happened.
I
saw
a
backlash
against
it.
A
F
But
that
that's
not
I
mean
that's,
not
a
scalable
solution
right
in
my
opinion,
just
because
everybody
has
to
go
back
manually,
look
for
the
lock
for
Jay,
and
we
we
did
see
that
right,
there's
no
way
of
tying
back
open
source
or
pipelines
or
anything
to
how
did
this
open
source,
like
you
know,
block
projecting
happen
like
I
I
want
to
say
that
there's,
probably
companies
still
out
there
manually
looking
for
log4j
I'm
deviating
here,
but
I
just
kind
of
wanted
to
I
put
this
on
paper
a
week
ago
and
I
wanted
to
just
share
it.
A
No
I
mean
I,
think
there's
something
there's
something
in
it
in
that
you
do
want
to
ensure
that
what
you
really
want
to
ensure
is
that
when
the
author
published
their
code
that
they
authenticated
to
whichever
repository
you're,
drawing
from
in
a
way,
that's
compliant
with
your
policy
when
they
did
that
you've
then
got
to
make
sure
that
you
know.
A
Obviously,
all
the
other
parts
of
ingestion
is
like
okay,
so
you've
got
to
check,
but
the
checksum
that
he
well,
they
actually
uploaded
with
matches
the
thing
that
you
downloaded
and
all
of
those
kind
of
all
of
those
things
that
source
of
provenance
is
supposed
to
keep
you
but
yeah
I.
Think
one
of
the
things
that
we
you
have
to
be
very
careful
of.
Is
you
can't
impose
standards
on
open
source
users
or
open
source
authors?
E
A
Think
everything-
that's
that's
every
time
anyone's
tried
that
there's
been
a
backlash,
I
mean
even
just
getting
2fa
into
you
know.
Popeye
publishing
for
those
popular
packages
has
been
a
struggle,
so
I
think
trying
to
impose
things
on
people
just
because
you
know
that
I
characterized
it
the
other
day.
It's
like
pay
us
important
guys
need
you
to
comply
to
our
policies,
because
otherwise
we
can't
use
your
stuff
and
we're
dependent
on
it.
D
But
but
I
think
I
think
in
terms
of,
if
you're
a
maintainer
of
an
open
source
project
I.
Think
being
able
to
being
you
know
that
there
are.
There
are
useful
things
as
a
maintainer
of
being
able
to
you
know,
do
I
trust
this
commit.
Do
you
know
it?
May
not.
It
may
be
I
care
about
Who,
provided
it
maybe
I.
Don't
it's
whether
or
not
the
content
of
the
commit
is
is
trusting.
D
But
what-
and
you
know
you
I
think
Jay
mentioned
about
trust
right
if
I'm
going
to
consume
an
open
source
project,
I
and
I,
don't
trust
them
to
have
done
a
good
job
on
the
source
contribution,
then,
should
you
be
using
that
open
source
project
and
I
think
coming
back?
You
know
a
long
time
trying
to
build
something,
so
somebody
can
come
back
a
long
time
later
and
with
some
something
that
might
be
a
you
know,
looks
a
bit
like
a
centralized
model.
I
think
is
probably
not
going
to
be
very
successful.
D
I
think
you
know
I
think
it.
It
probably
needs
something
that
can
cope
with
being
more
distributed.
So
if
everyone
open
source
project
says
yeah
I
want
all
my
contributors
to
sign
their
git
commits
they
get
a
a
you
know:
a
a
gold
star
and
people
who
just
require
you
to
have
two-factor
authentication
on
GitHub
or
gitlab.
It's
you
get
Silver
Star
open.
It.
C
Well,
when
you
talk
about
that
too
right
we're
going
back
and
this
this
this
was
kind
of
coined
a
couple
of
months
ago
by
my
car.
Well,
the
first
time
I
heard
it
was
from
one
of
my
colleagues
here,
Microsoft
Ava,
Ava
black.
You
know
they,
they
said
trust
the
process,
not
the
not
the
person
right.
C
So
so,
wherever
you're
pulling
the
component
from
whatever
their
processes
are
around,
how
commits
are,
are
you
know,
pull
requests,
issues
or
commits
or,
however,
their
processes
are
by
which
a
component
gets
gets
into
the
repo
and
then,
whatever
processes
are
followed
by
how
you
pull
that
you
know
component
built
into
your
environment,
trust
that
process
if
that
process
is
good
deal.
Necessarily,
if
you
trust
the
process,
the
process
is
sound,
then,
regardless
of
how
the
what
the
author
did
or
didn't
do,
that
becomes
that
becomes
a
new
point.
F
So
my
yeah
I-
don't
I,
don't
want
to
necessarily
challenge
that
that
statement,
but
but
I
kind
of
do
at
the
same
time.
I
know
that
there's
processes,
but
you
know
Bad
actors
still
still
manage
to
you,
know
get
in
to
that
process
and
follow
the
process
or
add
bad
code
to
that
process.
So
I
I
just
feel
like.
Instead
of
trusting
the
process,
I
verify
the
process
right
and
verifying
the
process
is
by
doing
the
you
know,
challenging
of
I
want
to.
Let's
just
ignore
this
2fa
for
a
moment,
but
what?
F
If
I
had
every
time
I
see
this
user
I
had
a
database
on
the
side
that
had
a
unique
ID
for
that
user,
separate
from
their
corporate
or
their
GitHub
login
and
I
challenge
and
I,
say
hey.
This
user
looks
different
something's
different
about
this
user,
like
almost
an
anomaly
of
that
I,
don't
know
I'm
still
struggling
Jerry
to
be
honest,
I'm
not
trying
to
challenge
you,
but
oh.
C
No,
no,
no
I'm
with
it
I
mean
you,
but
you
you
validate
as
well
right.
You
can
validate
the
process
as
well
right,
so
you
verify
that
there's
a
problem.
You
you
verify
that
there
that
they
have
a
process,
but
you
validate
the
process
against.
What's
your
own
security
policies
and
posture
is
in
your
own
organization
right,
so
so
you
you
have
you
have
with
your
own
security
constraints?
C
Are
you
have
with
your
own
security
appetite
is,
and
then
you
weigh
that
against
what
the
process
is
from
the
repo
whatever
it
is
that
you're
pulling
you're
a
repo
that
you
should
be
mirroring
in
your
organization.
First
of
all,
you
should
be
mirroring
within
your
organization,
something
reputable,
but
you
can
only
verify
it's
it's
reputation,
based
on
what
you
verify
and
validate
against
your
own
security
posture
right.
C
You
I
mean.
If
you
did
that,
then
then
you
then
you're
you're
you're,
three
quarters
of
the
way
there.
And
of
course,
if
you,
if
you
ingested,
you're
taking
on
that
risk
right.
But
then
that's
what
that's
where
your
scanning
comes
in
and
all
of
your
internal
processes
come
in
by
which
you
Safeguard
your
internal
environment
after
you've
decided
that
you
you've
mirrored
the
the
right
repository
and
you're
ingesting.
So.
F
Yeah
you're
100
right
that
I
think
the
idea
that
I
was
trying
to
communicate
here
guys
is,
let's
collect
the
day
information
and
then
eventually
come
into
here
and
set
a
policy
where
you
set
some
sort
of
levels
of
your
own
security
posture,
and
then
you
verify
against
those
levels:
Without
Really,
creating
a
friction
if
you
will,
with
with
with
a
developer
or
with
the
end
user,
I'll
call
it
right
and
then,
until
you
start
getting
to
like
level
four
you
unfortunately
you're
gonna
have
to
create
friction
with
that
to
to
really
validate
the
authenticity.
F
D
I
I
I
would
be
worried
about
what,
if,
if
you
have
some,
you
know?
Well,
if
you
have
a
separate
system
which
holds
things
I
think
you've
got
a
whole
bunch
of
security.
Related
second
attack
threats
against
that
data
store.
D
D
It's
another
place
that
somebody
can
potentially
attack
if
they
want
to
do
bad
things,
so
it
just
feels
it
feels
like
a
I,
don't
know,
maybe
I,
just
don't
I'm
not
worried
enough
about
the
problem
that
you're
worried
about
so
I
I
I,
look
at
it
and
think
it
seems
you
know
it
doesn't
seem
like
it
provides,
provides
value
commensurate
with.
D
A
Yeah
I
mean
I.
Think
if
that
store
is
I
mean
it's
important
for
you
to
be
able
to
map
identities
to
trust
levels.
If
you've
got
policies
that
say
you
know,
I
will
not
ingest
for
this
particular
purpose.
I
won't
ingest
anything
from
somebody
who
I
don't
trust
to
this
level,
so
I
think
internally,
it's
useful
for
you
to
have
something
that
says:
okay,
given
these
external
identities
or
internal
identities,
I
trust
them
to
a
particular
level
and
I.
A
You
know
I
expect
that
having
yes,
yes,
that's
a
kind
of
that's
a
useful
Target
for
security
thing,
but
I
think
it's
actually
an
important
thing
to
have
at
a
policy
level
as
well,
because
otherwise
you
don't
really
have
that
insight
into
into
variable
levels
of
trust
of
where
things
have
come
from.
A
I
think
you
do
have
to
delegate
trust
to
a
certain
extent,
because
this
is
really
multi-organization
flow
and
so
at
some
point,
you're
going
to
have
to
say
yeah,
I
think
GitHub
can
handle
usernames
and
passwords
yeah
I
think
GitHub
can
handle
2fa.
You
don't
want
to
be
saying
to
everyone
that
you
ever
ingest.
Anything
from
you
have
to
do
a
full
audit
on
their
stack
in
order
to
determine
your
level
of
trust
in
them.
A
E
So
I'm
gonna
jump
in
here
for
a
moment
because
I
mean
when
you
said,
and
I
definitely
want
to
give
Melba
a
chance
to
speak
up
as
well.
She's
been
holding
her
hand
up
for
quite
a
while.
So
in
terms
of
sort
of
a
metadata
store
right,
I
mean
I.
Think
Sig
sore
is
moving
a
little
bit
towards
that
sort
of
accepting
more
than
just
container
signatures
right
and
they
do
provide
sort
of
an
auditable
data
structure
that
underlies
that
data
store.
E
So
it
might
not
address
all
of
the
issues,
but
it
is
a
potential
option
to
just
collect
metadata
that
you
can
then
query
repeatedly,
which
I
think
is
what
it
is
that
you
would
like
as
well,
more
or
less.
But
yes,
anyway,
please
Melba
go
ahead.
Thank.
B
B
B
There's
no
privacy
issues
right
because
it's
more
of
a
company
trying
to
ensure
that
whatever
is
pulled,
is
actually
being
pulled
from
the
right
place
and
it
wasn't
tampered
with
during
transmission
or
even
maybe
it's
a
duplicate,
URL
or
IP,
or
something
like
that
right.
So
I
could
see
an
internal
use
case
for
it.
B
B
But
are
you
thinking
more
of
a
you
know,
policy
as
code,
where
you
say:
okay,
if
this
open
source
repo
has
this
this
and
this,
and
this
then
yay
we're
good.
If
it
doesn't
let's
flag
it,
because
we
need
to
do
a
review,
is
that
what
you
meant.
F
Yeah
and
that's
what
I
meant,
but
I
mean
yeah,
you
hit
the
nail
on
the
head:
that's
what
I
was
thinking
in
my
head.
You
probably
said
it
more
elegantly
than
I
did,
but
but
that's
exactly
what
I
was
thinking,
because
would
we
see
a
lot
in
the
industry
as
we
see
security,
doing
a
lot
of
what
we?
What
they
call
you
know,
technical
security
requirements
right
and
those
technical
security
requirements
are
more
on
the
I'll
call
it
waterfall
Enterprise
companies,
the
open
source
community.
F
You
know
they
tend
to
run
really
fast
and
more
agile,
right
and
so
having
the
system
where
we
don't
need
to
again
create
friction,
but
if
we
can
validate
in
some
way
that
these
are
kind
of
the
standards
and
then
get
validation.
Oh
hey
this!
This
is
new.
We
see
this
as
a
new
thing.
Then,
let's,
let's
just
have
a
conversation
right
and
then
conversation.
B
B
Why
can't
you
use
this
right,
so
I
don't
see
anything
wrong
with
that
if
it's
internal
betting
I
think
like
folks
on
the
call
said
like,
if
you're
trying
to
do
this
externally,
that
that's
a
different
story
but
I
policy
is
code
to
verify
that
that
community
that
package
is
sound
before
you
can
actually
use
it.
I
think
that's
perfectly
fine
right.
E
So
to
bring
this
back
to
salsa,
because,
especially
if
we,
if
we
really
try
to
separate
what
counts
as
ingestion
and
what
counts
as
production
really
can
we
start
to
formulate
requirements
for
assigning
salsa
provenance
levels
to
code
that
is
put
out
in
a
repository
because
I
think
that's
really
sort
of
one
of
the
goals
of
this
particular
subgroup
of
specification
right.
B
That
is
the
goal
yeah
and
I'm
trying
to
find
Source
management
requirements.
I
was
looking
at
your
comments
from
earlier
Source
management
requirements
from
the
OSS
consumer
and
we
would
capture
certain
properties
of
the
process
of
consuming
the
open
source
and
the
final
salsa
build
provenance
here.
Let
me
let
me
put
this.
This
was
in
the
slack
channel
that
you
put
you
put
it
Marcella.
B
E
Yeah,
so
it
I
mean
taking
into
account
what
Jay
was
saying
earlier
about
separating
consuming
versus,
producing
I.
Think
if
the
SSC
is
focused
on
sort
of
communicating,
information
about
or
requirements
about,
consuming
software
can
be
still
from
a
salsa
perspective,
generate
a
list
of
requirements
for
producing
or
putting
out
open
source
software,
essentially
producing
these
open
source
software
dependencies
right
right.
What
it,
what
does
it
mean
to
be
a
salsa
level
to
open
source
repo?
E
D
Probably
everyone
else
on
the
call,
but
when
I
had
what
I
had
reviewed
of
it,
it
felt
like
it
was
more
about
the
build
output
or
rather
than
the
reposits
So.
When
you
say
repository,
do
you
mean
like
the
source
repository
or
do
you
mean
the
like
the
artifact
repository
like
Maven,
Central
or
npm?
Whatever
your
language
is
the
story,
distribution
mechanism.
E
Yeah
I
think
that's
a
really
good
question
and
a
really
important
distinction
to
draw
as
well
is
that
I
think
so
to
give
you
some
context,
initial
salsa
does
mostly
books
on
build,
and
so,
but
they
were
initially
in
this
0.10.2
versions
of
the
specification.
There
were
a
couple
of
source
requirements
as
well,
and
so
as
part
of
developing
the
1.0
version
of
the
specification,
there
was
a
decision
in
the
specification
working
group
to
sort
of
take
out
the
source
requirements
from
the
1.0,
because
those
seem
orthogonal
to
the
build
requirements
yeah.
E
At
the
same
time,
we
do
think
it's
important
to
formulate
a
sort
of
source
repository
and
also
artifact
repository
requirements
at
some
point,
and
so
I
think
this
is
what
this
group
right
now
is.
Sort
of
trying
to
figure
out
is
what
are
some
of
these
Source
requirements
and
I'm
using
Source
very
Loosely
right
now,.
A
Yeah
I
think,
ultimately,
what
salsa
wants
to
provide
you
with
is
a
complete
chain
of
custody
from
the
author
through
to
your
installed
bits,
and
what
we're
talking
about
now
is:
okay,
we're
going
to
refine
the
source
of
State,
this
all
suspect,
to
just
build
and
that
that
means
it
kind
of
it
goes
back
as
far
as
you
know,
the
ingestion
of
the
source
code
through
to
the
bits,
and
we
want
to
reach
back
further
and
find
out
stuff
about
the
source
as
well
and
I.
A
Think
you
know
one
of
the
things
that
you
know
that
that
kind
of
the
integration
point
between
Salsa
and
SSC
is
cancels
the
provide
enough
information
that
SSC
can
be
validated.
Can
we
validate
that?
We've
met
all
the
requirements
of
SSC
just
by
looking
at
the
salsa
output.
D
Right
but
I
I
think
so.
This
is
perhaps
where
I
I
am
not
quite
following,
but
when
we
talk
about
Source
in
my
my
kind
of
mind,
I
think
about
source
code,
whereas
the
osse
stuff
I
think
is
about
how
do
you
ingest
something
else
and
that
that
something
else
is
something
that's
been
built.
D
So
in
my
you
know,
in
my
you
know
the
way
I've
I
viewed
what
Jay
has
presented
it
he's
wearing
his
his
thing
is
worrying
about
what
what
do
I
do
when
I'm
consuming
the
outputs
of
of
a
build
and
salsa
is
the
attestation
of
how
confident
you
know
how
how
much
can
I
trust
that
thing,
so
it
still
doesn't
necessarily
address
the
early
part,
which
is
how
how
much
can
you
trust
the
source
that
leads
into
the
build
yeah.
A
C
F
So
so
Melba
or
Marcella
or
anyone
would
it
help
to
like
go
through
an
example
and
have
a
scope?
Do
we
want
to
focus
on
the
build
and
then
understand
the
salsa
provenance
and
the
authenticity
of
that
build,
or
do
we
want
to
focus
I
mean
that's
what
I'm
I'm
at
least
understanding,
because
because
it's
really
hard
to
focus
on
the
source
right,
like
Sean
mentioned
earlier,.
B
I
I'm,
honestly,
not
100,
sure
I'm,
like
I'm
capturing
notes,
as
you
all
are
talking
and
I'm
like
okay.
What
what
goes
first,
what
goes
second
and
just
trying
to
wrap
my
head
around?
What
do
we
need
right?
I
think
that
visual
helps
right.
We
know
that
hey
the
source
is
coming
from
over
here,
but
we
don't
know
anything
about
the
source
before
right.
B
So
that's
that
trusting
you
know
where
the
source
came
from
that
chain
of
trust
that
someone
was
talking
about
and
what
artifacts
do
we
need,
throughout
the
system,
from
a
salsa
perspective,
to
trust
that
that
source
code
and
I
think
that's
what
you're
asking
like.
What
do
we
need
to
do
to
get
to
that
point.
Is
that
right.
F
I
I
guess
let
me
I
can
stop
sharing
yeah
I
think
it
is,
but
I
think
what
what
the
the
value
is.
We
want
to
provide
guidance
to
companies
to
protect
their
supply
chain.
What
part
of
the
supply
chain
are
we
giving
guidance
or
best
practices
for
them
to
protect
against
the.
F
Know
I
know,
but
the
entire
thing
I
think
Sean
mentioned
earlier.
The
entire
thing
is
just
very
difficult,
especially
if
you
are
not
a
a
Google
or
a
Facebook
or
a
big,
a
big
company
that
has
a
bunch
of
resources
right.
How
do
the
smaller
guys
do
it
and
how
do
they?
You
know
to
Jace
Point?
How
do
we
start
the
the
trust,
where's,
the
trust
come
from
right
and
eventually
I
I.
F
Think
last
time
I
mentioned
something
like
you
know,
kind
of
like
what
SSL
does
today
right
with
verisign
how
they
put
their
stamp
of
approval
on
all
the
websites,
and
you
know
they're
kind
of
the
certificate
authority
of
trust
right
for
us.
So
so
how
do
we
create
something
similar
in
my,
in
my
opinion,
right
and
and
then,
how
do
we
in
this
team?
F
E
Yeah
I
mean
I,
guess,
there's
two
parts
to
your
question:
I
think
there
actually
is
an
effort
to
produce
salsa
badges
or
something
am
I
right
about
that.
So
I
think
that
is
at
least
externally.
One
way
that
since
you
mentioned
the
very
assigned,
Badges
and
and
there's
other
badging
systems
too
right,
I
think
that
is
parallel
effort.
E
The
question
of
root
of
trust
I
think
salsa
doesn't
want
to
prescribe
who
the
root
of
trust
is
because
it
ultimately
depends
on
the
verifier.
It's
It
ultimately
depends
on
each
yeah
interested
party
really
to
decide.
You
know.
Do
I
want
to
trust.
Github.
Do
I
want
to
trust
this
random
repo
I
pulled
from
GitHub
instead
I
think
it's
salsa
probably
should
provide.
E
The
information
you
need
to
verify
these
identities
right
and
I
think
that
does
come
back
to
what
you
were
mentioning
earlier
about.
How
do
we
authenticate
the
origin
of
code
that
we
are
consuming?
E
So
if
there
was
one
of
the
goals
that
I
see?
If
this
subgroup
here
is
to
start
to
develop,
I
think
a
framework
for
expressing
for
I,
don't
know
if
it
should
be
developers
or
if
it
should
be
more
at
the
level
of
GitHub
to
capture
information
that
allows
verifiers
to
authenticate
right,
so
yeah
I
mean
maybe
individual
developers
shouldn't
be
in
the
business
of
producing
this
code
on
their
own,
but
could
I'm
just
putting
that
out
there,
because
GitHub
right
produce
salsa
compliance
metadata
for
repos
that
opt
into
it.
E
F
Yeah
I,
like
definitely
love
that
concept,
I,
think
I,
think
the
lack
I
mean
GitHub
I
mean
these
bigger
source
code
management.
Repository
systems
would
have
to
provide
an
API
to
produce
that
metadata,
which
they
can
argue
also
that
it
could
be
a
privacy
thing
right,
but
I
thought
about
that.
A
little
I
mean
I.
Think
it's
a
great
suggestion.
I,
don't
know
I,
don't
yeah.
Things
are
not
very
black
and
white
I'll
leave
it
at
that
foreign.
B
So
I
think
that
you
have
something
with
the
badges
Marcella
right
kind
of
the
same
thing
with
what
is
it
called?
There's
the
CII
badge
I
think
as
well
like
the
best
practices
badge
right.
B
So
potentially,
if
the
repository
has
you
know
not
only
the
salsa
badge
and
the
salsa
badge
requires
the
CIA
badge
as
an
example,
then
the
trust
level
probably
goes
up
so
potentially
that
is
a
way
of
deferring
trust
right
to
another
entity
to
do
the
verification
on
our
behalf,
and
we
don't
have
to
go
all
the
way
you
know
down
that
rabbit
hole
ourselves.
E
Yeah,
that's
a
good
idea
to
sort
of
piggyback
off
of
some
other
existing
Integrity
or
compliance
Frameworks
processes,
and
maybe
even
start
with
that
and
say
you
know
salsa
Source
level,
three
or
whatever
is.
If
you
have
these
three
other
compliance.
If
you
meet
these
other
requirements
already.
B
Okay,
I
am
getting
paid
by
my
manager,
so
I'm
gonna
have
to
drop,
but
I
I.
If
you
all
want
to
stay
on
by
all
means,
feel
free,
but
but
I
do
have
to
drop
right
now.
Okay,.
E
F
I
guess
I
can
start
I
I,
think
Marcela.
We
could
focus
on
on
the
build
requirements
because
we
I
feel
like
we
have
more
control
over
over
that
step
in
the
process,
because
it's
just
one
one
one
step
in
the
in
the
whole
supply
chain
and
then
come
up
with
requirements
of
what
we
feel
you
know
are.
C
I'll
I'll
see
if
I
can
get
that
from
John.
Hopefully,
although
I'm
scrub.
It,
though,
because
it
is
something
that
he's
working
on
in
terms
of
his
organization
so
make
sure
he
scrubs
it
but
I'll
be
yeah.
I
can
I
can
see
if
I
can't
get
that
and
bring
it
here.
Look
at
it.
B
F
Guys,
sorry,
what
do
you
think
gay
and
how
do
I
say
his
name
Allah
said
as
I
say
we
are.
C
Yeah,
no
so
I
mean
it's
a
great
suggestion.
I
mean
I
I,
defer
to
to
further
Marcella
my
soul
on
this.
One
I
think
this
is
an
outstanding
initiative
at
this
level,
just
to
bridge
just
to
bridge
these
two
together.
So
how
how
the
questions
you're
asking
are
probably
questions
that
everyone
has
so,
let's,
let's,
let's
get
them
answered.
E
C
Is
this
is
this
is
a
great
vetting,
a
great
vetting
place
as
being
an
outside
kind
of
you
know
an
outside
the
wire
type
of
of
conversation,
our
ideas
and
thoughts.
We
can
bring
back
to
the
specification,
it
might
help
move
things
along
a
bit.
I
mean
yeah.
A
lot
of
these
meetings
get
hung
up
on
on
you,
know,
governance
type
items
and
not
enough
on
the
actual
nuts
and
bolts
of
what
we're
there
to
do.
C
E
No
totally
agree
Okay,
so.
E
I
guess
a
few
questions
should
we
make
this
a
more
regular
meeting.
I,
don't
know
every
two
weeks
every
three
weeks,
something
like
that:
I,
don't
know
third
Friday
of
the
month
or
something
along
those
lines.
Why.
C
Not
okay,
why
not
I
mean
so
so
the
like
I
said
my
my
aspirationally
I
wanted
to
see
an
ISO
one,
two
and
three
yeah.
That's
what
I
want
to
see,
aspirationally
and
I
wonder
and
and
if
I'm
being
for
being
a
a
bit
a
bit,
my
head
is
being
a
bit
too
far
into
the
Stars.
C
F
I'm
with
I'm,
with
Jay
on
this
I'm,
very
aspirational,
very
I'll
call
it.
You
know
far-fetched,
but
I
want
to
see
it
actually
sooner
than
a
year
like
I
want
to
sit
here
exactly
three
to
six
months.
Right,
like
I,
want
to
see
the
version
one
come
out
and
you
because
we're
not
going
to
be
perfect
right.
Masala
and
yeah.
F
D
F
C
C
Yeah
to
get
something
through
the
iso
process
a
year
or
two
and
then
I
actually
have
revisions
after
that,
how
things
improve,
but
the
iso
process
itself
I'm,
not
sure
how
long
that
is,
but
I
think
if
we
can
get
to
the
point
where
we're
having
those
conversations
towards
publication.
E
I
think
so
the
timeline-
and
this
is
something
that
brought
up
at
the
specification
meeting
on
Monday
the
timeline
for
salsa
1.0
I,
think
is
end
of
this
year
to
have
a
version
just
for
build
out
there
and
I
think
even
sooner
I
have
a
draft
out
by
mid-october
or
something
like
this
so
I
think
finally
we're
starting
to
get
things
moving,
but
it's
yeah
like
you're,
saying
Jay,
like
things,
definitely
have
been
getting
solved
over
various
discussions.
E
So
okay,
so
we
can
sort
of
turn
this
into
a
well.
Given
that
the
road
map
for
specification
for
build
requirements
is
decently
tight.
Actually,
maybe
it
makes
sense
to
have
these
working
meetings
more
frequently
if,
if
people
have
time
for
that,
should
go
back
to
Melba
and
also
ask
if
that's
something
that
she
can
support.
C
E
All
week
long
while
we
go
no
totally
agree,
yeah
so
yeah
I
mean
I,
guess
the
point
I
was
making
more.
Is
the
specification
meetings,
the
weekly
ones,
don't
feel
like
working
meetings
so
much
as
they're
a
bit
higher
level
I
think
well.
C
Yeah,
absolutely
that's
why
this
is
important.
I
mean
this
is
important.
I!
Think
every
two
weeks
will
work.
Just
fine
one
we
can
kind
of
speed
up
is
once
we
get
a
good,
unfortunately
tarantine
as
I
say:
Tarantino
Wing
a
lot
you
gotta
work.
You
start
at
the
end
to
work
the
middle
right.
Usually
you
wind,
usually
you
start
spacing
them
out
more
as
time
goes
on,
but
now
you
know,
but
in
this
particular
instance
you
space
them
out
in
the
beginning.
C
C
My
fear
is
that
doing
it
every
week,
we're
going
to
come
into
these
and
and
in
an
effort
to
have
something
to
talk
about
we're
not
going
to
have
we're
not
going
to
our
our
deliverables,
for
each
person
may
be
working
on
a
task
might
be
a
little
shorter
just
to
have
something
to
talk
about,
rather
than
providing
real
impact,
which
can
be
covered
over
a
couple
of
weeks.
Man
until
we
start
marching
that
that
that
that
that
1.0
comes
out,
the
SSC
gets
built
out
a
little
bit
more.
C
These
things
are
Marching
In
Parallel.
We
can
clearly
identify
the
gaps.
Now
we
have
clear
Direction,
clear
guys.
We
need
to
cover
down
X,
Y
and
Z
by
this
date
right
we
can
put
milestones
in
there.
Then
we
can
have
weekly
meetings,
because
then
it's
required
just
from
a
project
management
standpoint
to
to
keep
thinking
to
keep
the
training
the
tracks
yeah.
E
I
think
you're,
absolutely
right:
okay,
so
I'm
trying
to
just
organize
that's
my
thoughts
around
what.
E
What
we
want
to
accomplish
in
the
next
two
weeks,
then,
for
this
particular
group.
C
I'll,
have
the
the
diagram
from
John
I'll
bring
that
up,
I
I,
think
also.
You
know
this
might
be
a
tasking
for
maybe
a
couple
of
people
I
know
I'll,
do
it,
let's,
let's
really
break
open
the
SSC
and
and
the
salsa
Frameworks,
as
they
are
right
now
and
see
where
the
see
where,
where
there's
bridging,
where
there's
parallels
and
all
that
kind
of
stuff,
then
take
a
look
at
the
diagram.
So
the
diagram
needs
to
needs
to
come
out
so
that
we
can
both
do
this.
C
So
we
can
see
so
we
can
overlay
both
Frameworks
on
top
of
this
diagram.
First
of
all
identify
the
gaps
in
the
diagram.
Then
overlay
the
Frameworks.
On
top
of
the
diagram,
see
where
the
lines
begin
to
blur
right,
see
where
there
needs
to
be
a
little
bit
more
rigor,
a
little
bit
more
structure
and
then
and
then
we
can
go
from
there.
C
Yeah
I
mean
I
mean
I,
that's
that's
the
that's
the
long
and
short
by
the
time
we
get
to
in
a
couple
of
weeks.
We
should
have
all
of
that,
and
then
we
have
more
stuff
to
talk
about
yeah.
F
Gotta
go
to
my
next
meeting.
I
really
I
really
enjoy
this
topic
so
yeah,
absolutely
and
Marcela.
We
can
work
off
asynchronously
too
right
on
yeah
cool
thanks
Jay
for
that
for
that
link.
I'll
I'll
review
this
as
a
homework.