►
From YouTube: SLSA Meeting (August 4, 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
Well
kim
asked
me
to
just
help
the
facilitator
in
the
few
minutes
before
she
comes
online.
I
think
she
is
in
the
car
traveling
for
just
a
few
minutes
I'll
give
it
a
few
more
seconds
for
people
to
join
in,
so
we
don't
just
jump
into
it,
but
I
see
there's
a
busy
schedule
if
you
add
up
all
the
times
of
predicted
and
it's
about
the
full
meeting.
A
A
I'm
guessing
that's
mark
for
just
a
minute
to
two.
If
possible,
please
mark.
B
Hey
so
this
is
just
the
workstream
updates,
yeah
just
to
work.
B
Yeah,
so
we
met
a
couple
times.
We
are
still
working
through
the
scope
for
view
1.0
like
what
are
the
major
things
that
we
want
in
it.
I
don't
think,
there's
anything
kind
of
ready
to
share
yet,
but
we've
been
going
through
that
and
collectively
reviewing
a
design
proposal.
A
Great
thanks
mark
I
see
positioning
is
next
a
member
in
group
melba
or
something
else
you're
free
to
take
the
free
yeah.
A
Yeah,
sorry
about
that,
I
was
just
hoping
you
could
do
a
positioning
sig
update
for
a
second.
If
you
have
anything
to.
C
Yeah,
so
we
we
did
meet
once
we
meet
bi-weekly,
so
the
next
one
will
be
coming
up
thought
it
was
a
pretty
good
meeting
we
we're
talking
about.
You
know
what
what
is
our
scope
right?
I
know
the
the
definition
in
the
proposal
is
kind
of
like
a
one
sentence,
but
we
had
some
questions
around
well,
you
know:
do
we
want
to
include
other?
C
You
know
governments,
because
a
lot
of
this
is
about
the
white
house
executive
order.
So
what
about
other
standards
like,
let's
say
in
the
eu,
et
cetera,
also
talking
through?
How
do
we
compare
ourselves
to
new
standards
and
frameworks?
So
there's
a
new
github
issue
talking
about,
I
think
it's
about
six
different
frameworks
or
standards
and
how
salsa
compares
and
so
we're
trying
to
get
a
set
of
criteria
of
how
we
assess
those
frameworks
with
regards
to
salsa
so
still
in
its
initial
phases.
But
I
think
it's
going
pretty
well.
A
Great
thanks
so
much
mama
and
the
third
work
stream
update
is
tooling,
so
I'm
guessing
it's
mike
lieberman.
I
see
you
over
to
you.
D
Sure
so,
yeah
quickly,
we've
mostly
been
going
through.
So
we
had
the
first
meeting
on
last
friday
and
so
we've
mostly
been
going
through
and
trying
to
one
figure
out
what
categories
of
tools
we
need
for
salsa
so
stuff
like
builders,
libraries
that
actually
generate
the
specification,
verifiers
policy
tools
and
so
on,
and
so
we
built
out
a
couple
of
categories
there.
D
And
then
we
started
sort
of
going
through
and
listing
individual
tools
as
well
as
sort
of
identifying
where
they're,
where
there
are
potentially
gaps
and
then
kind
of
gonna,
go
from
there
and
see
what
we
can
do
to
like,
where
we
should
be
prioritizing
our
efforts
and
what
we
might
be
able
to
do
to
start
trying
to
also
get
additional
folks
involved.
Because
right
now
it
does
seem
like
there's
like
a
handful
of
folks
who
are
like
experts
in
salsa
and
and
they've,
been
the
ones
mostly
focused
on
the
tools.
D
And
what
can
we
do
to
kind
of
get
just
some
additional
folks
from
the
community
to
start
poking
around
contributing
to
the
existing
tools,
developing
new
tools
and
so
on?.
A
One
important
part
of
this
call
at
the
very
beginning,
so
I'm
sorry
about
that.
But
if
there's
anybody
new
who
would
like
to
introduce
themselves,
I
invite
you
to
say
something
I
can't
easily
scroll
through
right
now.
So
please
feel
free
to
say
hi.
If
you're
new.
E
E
E
I
can
give
you
so
the
the
the
quick
4-1-1
is,
I'm
worth
I'm
working
with
the
u.s
air
force
and
we're
looking
at
ways
of
getting
insight
into
open
source
community
practices
with
open
source
software
projects
and
being
able
to
quantitatively
assess
the
processes
that
are
being
used
by
those
teams
and
be
able
to
assess
risk
from
that
direction.
That
could
be
a
salsa
kind
of
thing.
It
could
be
a
scorecard
kind
of
thing.
It
could
be
a
best
practices
or
some
combination
there
of.
A
Over
great
thanks
so
much
scott,
I
don't
think
you're
in
the
wrong
place.
I
suspect
there
are
a
lot
of
right
places
to
be
within
openssf
and
these
related
groups
so,
and
it
certainly
seems
like
there
will
be
a
tooling
meeting
again,
I
believe,
is
it
next
week?
Is
that
right?
Michael?
A
D
Yes,
oh
so
so
yeah
there's
two
tooling
just
to
make
sure
that
to
clarify
theirs.
There's
the
general
open,
open,
ssf,
tooling,
meetings
which
those
are
just
sort
of
generic
open
source
security
things,
and
then
there
is
every
week
on
friday
there
is
a
salsa,
tooling
meeting,
which
is
just
as
we
begin
to
move
towards
1.0.
We
want
to
make
sure
that
the
we
have
a
good
set
of
tools
and
and
work
streams,
building
out
these
tools
for
for
salsa
and
so
those
two.
D
So
we
are
integrating
with
stuff
like
scorecard,
but
we
ourselves
are
not
the
ones
who
are,
let's
say,
writing
up
scorecard
or
writing
up
some
of
the
other,
just
sort
of
open
source
security
tools.
A
F
E
G
I
can
introduce
myself
hey
everyone.
My
name
is
chapman,
I'm
on
the
foundational
infrastructure
team
at
bloomberg,
focusing
on
supply
chain
security,
I'm
also
a
community
contributor
to
encore
sifting
great
products,
I'm
just
really
passionate
about
supply
chain
security
and
interested
in
kind
of
new
and
novel
ways
of
producing
s-bombs,
to
reduce
kind
of
noise
and
developer
fatigue.
H
I
cannot
introduce
myself
as
well.
I
actually
work
with
chapman
pretty
new
into
the
security
supply
chain
space,
but
I
attended
the
open
or
was
it
the
supply
open
source
summit
in
austin
about
a
month
ago.
So
I
learned
a
lot
about
openssf
there
and
got
interested
in
some
of
the
initiatives
so
good
to
meet
you
all.
H
G
Sure
I'll
introduce
myself
hi
gilbert
martin,
really
interested
in
salsa.
I
ran
product
security
for
a
couple
of
companies
really
passionate
about
devops
and
security.
I
really
liked
the
whole
transformation
of
culture.
G
You
know
breaking
down
the
silos
between
security
and
devops
I've.
No
I'm
aware
of
salsa.
I
used
it
in
my
last
company
to
start
you
know
enforcing
security.
I
have
I
have
ideas
and
thoughts
that
I'd
love
to
contribute
to
that's
it.
G
So
thanks
and
I
did
I
did
research
a
lot
on
you
guys,
so
I've
watched
all
the
videos.
I've
listened
to
your
last
meeting.
You
know
watched
josh
and
tom
video
as
well
on
how
they
explained
so
yeah.
Looking
forward
to
it
thanks.
A
I
Else:
yeah,
hey
hi
everyone.
My
name
is
francis.
I
work
at
google
on
the
open
source,
security,
team
and
yeah.
Our
scope
is
alphabet
more
specifically
so
happy
to
join
in
with
the
happy
happy
bunch
here
and
learn
more
about
salsa
and
how
this
can
actually
work
with
us.
So
thank
you.
H
This
is
adrian,
I
I
can
introduce
myself
hi,
I'm
adrian
diglio,
I'm
from
microsoft.
I
lead
the
secure
software
supply
chain
team
and
it's
my
first
time
dialing
in
just
wanted
to
to
listen.
H
H
I
guess
real
quick.
I
can
also
go
I'm
carrie
driscoll.
I
recently
rejoined
google
working
on
the
software
supply
chain.
Integrity
specifically
on
sig
store,
so
excited
to
learn
more
about
salsa
and
how
we
interact.
A
Okay
hearing
none
the
we've
got
a
few
items
today,
and
some
of
them
are
a
little
bit
longer.
So
we'll
try
to
be
quick.
We've
about
48
minutes
right
now,
but
lauren
has
a
five
minute
item
solitary
over
to
you.
F
Yeah
thanks
so
some
context.
We
have
been
working
on
salsa
level,
three
builders
using
github
action
so
for
maintainers
and
projects
that
live
on
github
and
release
on
github.
We
have
salsa
level
3
builders
available
and
recently
we
released
something
that
we
called
a
salsa
level,
three
generator,
which
means
that
it
only
satisfies
the
provenance
level.
Three,
it's
non-forgiable,
but
it
doesn't
satisfy
the
build
level
three
in
practice.
F
What
this
means
is
that
developers
can
continue,
they
don't
have
to
change
their
release,
workflow
and
they
just
need
to
add
a
step
inside
it
to
generate
the
provenance
and
the
provenance
will
have
a
binding
to
the
repository
name.
The
hash
commit
the
trigger
and
so
on
and
so
forth.
So
it
gives
you
strong
provenance,
a
strong
linking
without
major
changes
to
the
to
the
workflow
for
developers
we're
working
on
a
blog
post
for
august
22nd
or
like
anytime
this
month.
F
F
We
have
compiled
a
list
of
maybe
40
projects
that
we
could
try
to
reach
out
to
some
projects
that
are
critical
and
that
we
know
are
building
on
github
and
we're
looking
for
people
to
help
us.
You
know
with
adoption.
It
can
be
as
simple
as
selecting
selecting
one
project
and
trying
to
work
with
the
maintainers
to
accept
the
pull
request.
F
I
also
wanted
to
talk
a
little
bit
about
the
roadmap.
We
are
currently
working
on
verification
for
the
gcb
salsa
builders,
which
are
currently
level
two
and
will
be
soonish
level
3..
This
is
all
happening
in
this
other
project
called
the
salsa
verifier.
That
is
also
open
source.
F
F
We
can
also
just
do
the
provenance
part
level
3
if
users
want
to
keep
building
the
container
themselves
and
just
attach
provenance,
and
then
we
have
another
project
where
we
want
to
allow
people
to
define
their
build.
Their
release,
their
release
steps
via
a
docker
file.
So
basically
it's
like
a
brick.
F
Instead
of
using
github
workflows
to
define
it
the
steps
or
cloud
build
or
any
other
configuration,
we
would
use
a
docker
file
and
we
would
use
it
to
to
build
the
steps
and
the
output
would
be
say
in
a
particular
folder
and
we
would
we
would
add
provenance
to
it
and
attest
that
it's
that
particular
container
that
built
the
you
know
your
binaries
and
so
on
and
so
forth.
F
That's
what
we're
working
on
right
now
and
we're
also
looking
for
the
right
ecosystem
package
manager,
ecosystem.
You
know
npm
java
or
anything
else,
that
you
think
we
should
build
a
builder,
for
we
have
all
the
basic
blocks
to
do
it.
We
know
how
to
do
it.
It's
just
a
few
weeks
worth
of
work
and
but
we'd
like
to
have
some
input
on
whether
there's
an
ecosystem.
That
is
the
right
one
that
we
should
be
looking
at
this
sort
of
things
yeah.
D
So,
just
one
quick
question:
if
folks
wanted
to
sort
of
contribute
to
like
anything
that
they
wanted
to
add
in
there
what's
the
best
way
for
folks
to
contribute.
F
So
to
contribute
to
the
the
generators
and
the
verifiers,
you
can
go
to
the
repositories,
look
at
the
issues,
file,
issues
or
tell
us
if
you're
interested
in
you
know
tackling
some
of
those
issues
or
even
if
you
think
that
the
direction
that
we're
taking,
if
you
have
some
you
know,
opinion
on
what
ecosystem
we
should
be
spending
more
time
on,
we
would
love
to
to
hear
it.
F
So
we
do
everything
on
the
github
repo,
the
the
link,
I
shared
a
link
about
the
list
of
you
know
echo
sorry
repositories
on
github
that
we're
trying
to
reach
out
to
this
is
just
a
list
that
we've
compiled
ourselves.
It's
in
no
way
exhaustive.
It's
not
necessarily
the
right
list.
F
You
should
have
right
access
to
the
document.
I
shared
it
to
the
salsa
discussion
group
this
morning,
so
you
can.
So
if
you
want
to
engage
on
that
side
with
adoption,
you
can
add
to
this
list
or
you
can
select
some
of
these
projects
and
say
that
you
want
to
own
the
relationship
or
try
to
work
with
them
to
to
adopt
some
of
the
the
builders.
A
J
Oh
yeah,
thanks.
First
of
all,
this
is
very
exciting.
Looking
forward
to
play
with
this.
My
question
is
actually
related
to
a
question
that
I
want
to
race
later,
but
I
wanted
to
just
give
a
preview
now.
It's
also
related
to
the
question
that
joshua
had
asked
on
the
github
issue:
it's
and
it's
about
mapping
the
public,
keys
or
identities,
so
to
speak
to
the
steps,
so
we're
curious
about
that.
But
we
can
discuss
this
with
more
of
that
later.
K
B
Yeah
to
the
because
we
had
a
bunch
of
new
folks
which
is
great
and
happy
to
have
you
here
at
least
one
person
mentioned
like
have
feedback
or
suggestions
on
salsa.
I
think
that
suggests
probably
the
best
way
to
do
that
would
be
to
write
it
up
on
a
github
issue.
B
You
could
try
to
find
an
existing
issue
or
do
a
new
one
and
we
could
aggregate,
but
that's
probably
the
best
way
to
track
because
there's
like
a
lot
of
different
people
involved,
and
so
we
encourage
any
sort
of
comments
or
feedback
through
there.
So
thanks.
A
Great
thanks
mark
next
is
one
of
the
large
larger
blocks.
It's
on
a
salsa
salsa
policy
model
for
open
source
software
packages.
Alternatively,
if
if
it's
possible
to
do
this
in
15
minutes,
I'd
appreciate
it,
but
I
know
this
is
a
meteor
topic,
so.
L
Yeah,
I
don't,
I
don't
think
I
need
20
minutes.
Let's
see
if
this
works,
can
you
see
my
slides
looks
good?
Okay,
let's
start
this
is
this
is
salsa
policy
model
for
oss
packages?
This
is
work
with
simon
kent,
also
with
mark
lodato,
but
it's
really
two
persons
doing
this,
not
an
army
of
googlers
that
is
bestowing
this
on
the
rest
of
the
world.
L
It
would
be
nice
if
it
goes
on
to
the
next
space.
So
what
I'm
trying
to
achieve
here,
I
want
to
present
a
high
level
approach.
Details
are
in
the
second
half
of
this
presentation
that
I
will
not
present.
L
I
I'm
looking
for
some
initial
agreement
and
that
this
is
the
right
approach,
that
it
solves
the
right
problem
and
and
and
invite
people
to
to
work
with
us
in
a
smaller
group
than
you
know.
This
is
a
large
audience
in
a
smaller
group
on
the
details
of
of
of
building
this
out.
So
next
page.
This
is
just
to.
L
B
Just
one
quick
comment,
and
also
just
a
little
bit
more
context
on
that.
I
think
this
is
the
type
of
thing
that
should
probably
go
in
one
of
the
sigs,
but
it's
not
clear
which
sig,
because
it's
kind
of
pause
partially
like
the
model,
which
maybe
would
be
specification
partially,
the
tooling.
And
so
I
thought,
it'd
be
valuable.
L
Yep
yep
yeah,
it's
it's
multiple
levels
of
of
figuring
out
how
things
should
be
done
or
may
be.
This
slide
summarizes
the
the
salsa
supply
chain
model.
I
I'm
just
presenting
it
because
it
will
be
easier
to
understand
where
policy
is
going
to
fit
in.
So
we
have
a
supply
chain,
integrity
model.
L
There
are
threats
and
mitigations
the
little
things
in
red.
There
are
requirements,
defined
dot,
address
threads
and
they
are
conveniently
grouped
into
salsa
levels.
So
you
don't
have
to
talk
about
individual
remedies
all
the
time
and-
and
I
I
am
omitted,
the
dependency
part,
which
is
just
a
repetition
of
the
other
ones.
L
L
L
L
L
That
is
that's
a
step.
That
is
not
immediately
obvious
to
lots
of
people.
So
I
will
illustrate
that
with
the
the
next
slide,
which
shows
the
top
is
a
package
is
built
from
source
x
is
the
name
of
a
package.
It
could
be
a
python
package
or
or
something
it
is
built
with
a
build
system.
L
There's
a
policy
check,
does
it
have
says
also
for
province,
and
the
build
has
produced
salsa
for
providence,
and
so
the
check
passes.
The
package
is
published
to
a
repository
and
then
later
somebody
wants
to
install
the
package
on
the
system.
They
they
can
run
this
check
again.
Does
it
have
salsa
for
providence?
Yes
and
they
installed
the
package,
and
why
is
salsa
level
four
provenance
alone,
not
sufficient?
L
Well,
the
next
example
below
shows
a
fork
of
the
package
with
some
you
know,
malware
added
could
be
a
bit
my
bitcoin
generator
or
something
that
steals
credentials
or
exfiltrate.
Other
other
secrets.
L
You
have
a
fork
of
the
of
the
same
package,
but
it
is
different,
use
the
same,
build
system.
It
produces
salsa
for
providence,
so
it
passes
the
policy
the
package
is
published
and
when
somebody
wants
to
install
the
package
they
apply
the
policy
check.
Does
it
have
sales
for
province?
Yes,
it
does
and
the
package
is
installed,
but
it's
the
wrong
software,
and
so
the
purpose
of
the
policy
should
be
to
ensure
that
this
given
package
is
actually
built
from
a
specific
source
code
that
it
should
be
built.
L
Okay?
I
will
move
on
so
the
lesson
here
is
that
say
you
have
a
salsa
for
artifact
that
doesn't
by
itself
mean
much
because
it
could
be
salsa
for
malware.
L
L
Next
up
next
up
is,
if
you
have
a
policy
that
says
this
artifact
must
be
built
from
this
particular
collection
of
source,
then,
by
its
very
nature,
the
policy
is
project
specific.
You
cannot
just
have
a
policy
that
says
it
must
be
salsa
for
it.
You
need
a
policy
that
says
it
must
be
salsa
for
and
it
must
be
built
from
a
particular
source,
and
so
that's
what
I'm
trying
to
illustrate
in
the
figure
below
you
have
instances
of
source
code
revisions.
L
You
have
instances
of
provenance
and
instances
of
artifacts,
and
that
is
all
good,
but
you
have
a
policy
that
is
at
the
level
of
collections.
It
says
artifacts
in
the
collection
named
project
x
package
x.
They
all
need
to
be
built
from
revisions
from
a
source
repository
that
contains
the
source
code
for
project
x.
L
It
is
simple,
as
that
project
is,
is
the
name
that
I
use
here
in
in
different
ecosystems,
people
use
package
name
or
group
id
artifact
id,
but
it's
basically
the
thing
that
identifies
that
distinguish
this
software
from
from
other
software,
by
name
and
name,
of
course,
is
not
a
strong
indicator.
Okay.
L
What
does
policy
look
like
without
going
into
the
details
of
policy
syntax?
The
purpose
of
the
policy
should
be
clear.
Now.
L
Backing
up,
we
have
salsa
providence
of
the
stations.
That's
are
basically
statements
of
fact
about
a
specific
artifact.
This
one
statement
is
about
the
source
artifact
mapping,
this
artifact,
this
source-
that
is
the
code
identity,
and
it
also
has
statements
about
threat
mitigations.
What
source
requirements
were
in
effect
to
prevent
certain
attacks
and
the
difference
also
levels
that
those
are
different
collections
of
of
constru
of
mitigations.
L
An
integrity
policy,
then,
is
a
collection
of
expectations
with
respect
to
salsa
provenance,
for
example.
There
is
an
expected
source
code
which
looks
like
a
uri
pattern,
and
it
corresponds
to
a
particular
field
in
a
salsa
providence.
Auto
station
is
an
expected
build
system.
I
trust
disability
system,
but
I
do
not
necessarily
trust
other
build
systems.
L
That
is
a
different
field
in
the
salsa
providence
and
at
higher
sales
levels.
You
have
an
expectation
that
the
dependencies
will
be
complete.
There
is
no
unaccounted
for
software
in
this
artifact
and
that's
a
different
field
in
the
salsa
province
and
reproducible.
Build
is
an
optional
thing
at
the
highest
level
and
it
has
its
own
field
in
salsa
providence,
and
so
it
is
conceptually.
L
You
can
imagine
that
a
policy
is
a
declaration
of
these
are
the
expectations
that
I
have
with
respect
to
the
contents
of
salsa
provenance,
and
they
are
they
not
at
the
level
of
individual
artifacts
but
they're
at
the
level
of
all
artifacts
in
this
family.
This
package,
family
must
be
built
from
with
these
other
these
expectations.
L
There
is
a
plan
to
implement
a
policy
prototype
evaluated
for
pipey
pipei
packages
we
have
to.
We
have
that
as
a
possible
target.
We
assume
that
attestation
discovery
will
be
solved
in
it
in
a
different
work
stream.
L
And
there's
a
number
of
policy
implementation
issues
that
we
have
ideas
for.
They
will
be
covered
in
in
the
remaining
slides
that
I
will
not
present.
But
initially
there
is
no
policy,
there
is
no
provenance,
so
we
need
to
find
a
way
to
get
some
provenance.
We
could
wait
until
enough
people
adopt
the
github
salsa
3
compatible
action,
but
that
might
take
time
we
could
also
rebuild
packages
and
hopefully
reproduce
the
binaries
close
enough
that
we
can
say.
L
Okay,
this
package
is,
is
compatible
with
salsa
level
2
or
something
like
that
and
then
develop
policies
for
the
for
the
packages
that
we
can
create
provenance,
for
there
is
a
concern
about
policy
changes.
If
you
have
a
policy-
and
it
says
this
thing
must
be
built
from
this
source
and
suddenly
the
policy
changes
and
now
it
suddenly
says
a
different
source
than
that
could
be.
That
could
be
a
security
violation,
and
so
we
have
to
come
up
with
a
way
to
do
that.
There
isn't.
L
The
policy
is
not
signed
as
such,
at
least
in
in
the
current,
the
current
design
draft
that
we
have
and
the
policy
the
policy
is,
is
just
a
thing,
and
the
idea
is
that
if
you
never
seen
the
policy
before,
then
you
might
think
that
it's
probably
safe
to
use,
because,
in
the
absence
of
evidence
to
the
contrary,
and
then
you
keep
using
that
policy
until
it
changes.
L
There
are
thoughts
about
this:
how
how
to
how
to
authenticate
a
change
in
policy,
for
example,
and
the
last
one
is
not.
Everybody
trusts
the
same
builders
to
the
same
degree.
L
I
think
I'll
stop
here,
because
it's
a
busy
schedule,
but
also
because,
if
you
go
into
details,
then
things
get
hairy
really
quickly.
L
A
You
so
much
for
this
presentation.
I
think
there
actually
might
be
a
question
or
two
that
already
came
up
in
the
chat
I
saw
sebastian
and
sri
shank
talking
about
a
potential
question,
so
that
could
be
an
opportunity,
but
if
others
have,
questions
too
feel
free
to
raise
your
hand.
D
C
How
do
you
know
if
it's
me
like?
Does
it
do
it
in
order.
C
Oh
okay,
so
I
appreciate
the
presentation
I
I
definitely
love
this
idea
that
this
is
something
that
I
mentioned
a
couple
weeks
ago.
Right,
if
you
have
garbage
in
you,
have
garbage
out
it
doesn't
matter
if
it
has
salsa
at
the
station
or
not
or
it's
also
a
level
or
certification.
C
Now
I
I
know
you
know
salsa
currently
doesn't
make
any
claims
about
the
trustworthiness
of
code,
but
I
would
challenge
your
group
to
say
why
not
because
me
as
a
company,
why
am
I
going
to
go
through
the
trouble
of
being
salsa
certified
if
I
can't
trust
the
code
right
I'd
rather
just
get.
You
know
iso
certifications
or
shock
certifications
and
you
know
do
it
on
my
own
versus
having
to
go
through
yet
another
thing.
So
again,
I
would
challenge
the
group
to
think
about.
How
can
we
make
this
into
suspect?
C
L
L
I
can
imagine
that
salsa
is
extended
with
things
like
security
checks
must
be
run
over
the
code
in
order
to
blot
that
other,
but
that
is
probably
a
different
thing.
I'll
stop
here.
A
N
Yeah,
so
I
was
wondering
about
the
the
requirements
for
the
source
that
it
was
built
from.
How
do
you
think
that
we
could
accommodate
third-party
builders
who
build
from
mirrored
source
code
and
can
prove
that
their
mirrors
match
the
original
source.
N
H
N
Github
so
yeah,
we
have
a
whole
bunch
of
different
things,
but
we
have
you
know
we
mirror
and
we
can't
maintain
checksums
and
signatures
if
they're
available
for
anything
that
we
mirror.
So
we
can
prove
that
you
know
given
at
that
time
that
we
mirrored
it
it
matched
what
we
got
but
yeah.
We
we're
not
necessarily
using
organ.
We
are
not
using
git
as
a
model
for
our
for
our
mirror,
store.
L
Right,
I
I
am
I'm
familiar
with
source
control
systems
that
have
a.
I
call
this
a
commit
number
basically
and
there
the
number
describes
the
entire
states
of
the
repository.
L
N
It
is-
and
you
know
we
could
say
in
our
attic
stations
that
we
built
direct
from
the
from
the
source
code,
but
that
kind
of
hides
the
fact
that
we've
mirrored
the
source
code,
and
I
would
rather
not
do
that.
I
would
rather
be
open
and
and
clear
that
you
know
we're
ability
we're
building
from
our
local
mirror,
mostly
because
we
know
that
you
know
things
out
in
git
can
change
at
the
end
of
the
day.
N
It
allows
you
to
rewrite
history,
so
yeah
we,
you
know,
we
have
a
nice
a
contained
static
set
of
source
code
that
doesn't
change
but
yeah.
It's
it's
just.
How
do
we
put
that
into
an
attestation
and
say
and
still
meet
the
requirement
that
we
built
from
the
original
source.
A
And
I
see
one
more
hand
raised:
trishank
has
the
same
race.
J
Great
thanks
yeah,
so
so
great
president,
I'm
sorry
how
do
I
I
wanna
be?
How
do
I
say
your
name,
perfect?
Okay,
great
thanks!
Now
I
want
to
be
mine.
Sorry,
great
okay!
I
want
to
be
mindful
of
time.
Also
don't
take
up
too
much
time,
but
I
want
to.
I
want
to
get
everyone's
attention
to
a
few
important
issues.
First
of
all,
great
presentation
loved
how
visual
it
was
and
how
you
spoke
in
plain
english
love
it.
I
need
to
copy
your
tricks,
I'm
going
to
try
to
speak
in
english
myself.
L
Yes,
I
will,
can
I
stop
sharing.
Oh
here.
J
Great
thanks
I'll
make
this
very
quick,
very
quick,
so
I
think
it's
a
great
problem
in
in
total
land,
what
we
call
salsa
at
the
stations
or
in
total,
and
also
in
total
at
the
station
sometime
called
links
in
the
old
language.
J
I
think
one
thing
that
they
do
is
define
the
steps
in
your
pipeline
and
what
sequence
and
who
is
supposed
to
sign
for
what
at
the
station-
and
I
think,
there's
a
feature
called
inspection
which
I
believe,
if
I
understand
correctly
maps
to
policies.
So
that's
something
that
I'd
like
us
to
explore.
J
The
other
question
comes
back
to
authenticity
so
so
far,
I
think
we
all
agree
that
salsa
does
a
fantastic
job
at
solving
the
integrity
problem.
End-To-End
right
this
is
you
know,
just
like
which
I
was
talking
about.
J
The
problem
is,
if
you
don't
solve
the
authenticity
problem,
you
basically
have
salsa
for
malware,
so
you
have
integrity
but
for
malware
and
to
try
to
solve
the
authenticity
problem.
One
thing
that
you
talked
about
was
how
to
distribute
the
policies
or
layouts
whatever
we
end
up,
calling
them
securely,
especially
in
places
like
ipi,
so
for
bootstrapping
processes.
I
I
agree.
We
can
try
something
out
based
on
tofu,
but
I
think
eventually
we
will
need
like
a
secure
way
to
do
it
securely
map
policies
to
to
artifacts.
J
Otherwise
we
we
don't
have
the
authenticity
thing.
So
there's
a
few
proposals
here,
there's
an
ite
that
santiago
and
myself
wrote
for
in
toto
is
something
that
I'd
like
to
discuss
in
the
future,
and
it
reminds
me
of
the
idea
I'll
stop
sparking.
J
I
I
don't
think
I
need
the
time
slot
later,
because
I
wanted
to
revisit
today
something
joshua
lock
and
I
had
discussed
a
few
months
ago,
which
was
how
do
we
define
the
shape
of
the
pipeline
and
who
is
supposed
to
find
who's
supposed
to
sign
for
which
attestation
and
then
we
can
talk
about
how
that
relates
to
policies?
I
just
wanted
to
bring
everyone's
attention
to
these
problems
that
we
needed
to
solve,
and
I
think
it
would
be
great.
I
think
we
can
solve
that
as
part
of
policies.
J
Oh
I'll
paste
the
link
here.
Okay,
I
do.
A
J
Yeah,
so
we
don't
need
to
revisit
it.
I
just
wanted
to
bring
everyone's
attention
to.
This
is
a
problem
we
had
partly
discussed
before.
Policies
does
a
lot
more,
but
a
problem.
I
wanted
to
talk
about
it.
It's
about
time.
We
figure
out
how
to
specify
public
keys
or
identities
to
steps
and
then,
in
turn,
to
policies
themselves.
A
Well,
we've:
I
was
thinking
of
giving
15
minutes
to
that
other
group,
so
we
could
still
spend
a
couple
minutes
here
on
this.
If
anyone
has
questions
now
for
trishank
on
the
salsa
public,
key
distribution
or
joshua.
So
if
you,
if
anyone
wants
to
ask
questions
or
make
comments,
we
don't
have
to
move
on
this.
Second,
I
see
a
question
from
mark
and
from
roy.
B
B
I'd
like
to
first
get
broad
documented
agreement
that
we
all
kind
of
speak
the
same
language
and
think
the
same
way
about
how
the
overall
model
works,
and-
and
that's
why
I
I
do
like
vita's
diagram,
because
it
does
keep
it
very
high
level,
because
I
think
each
of
us
have
noticed
in
conversations
each
of
us
if
we
might
use
the
same
words,
but
we
kind
of
need
slightly
different
things.
B
I
think
we
all
have
a
slightly
different
model
in
our
heads
of
what
we're
trying
to
do
and
how
it
works,
and
so,
if
we
could
get
that
nail
down
first,
that
I
think
would
be
a
big
first
step,
and
I
don't
know
what
a
good
group
for
that
would
be
like.
Should
we
do
that
in
the
specification
sig?
Should
we
do
it
in
a
tooling
sig?
H
M
I
was
going
to
agree,
I
think
specification
makes
sense,
because
I'd
like
to
see
it
be
part
of
the
specified.
J
D
It's
more
just
where
we
should
be
having
that
discussion,
because
there's
a
bunch
of
other
work
streams
that
we've
sort
of
split
out.
While
we
push
salsa
to
1.0.
M
M
Direction
of
forcing
things
from
the
bottom
up
versus
hey
the
only
people
that
can
sign
the
out
product
is
yourself,
so
whether
you
attest
the
inputs,
you
have
to
check
all
the
signatures.
There
seems
to
be
a
little
bit
of
current
in
a
horse
problem
and
that's
why
I
struggle
with
and
agree
with
mark
trying
to
figure
out
what
the
terminology
is
and
where
the
sits
is
key
to
moving
forward.
Here.
B
So
so
no
note
that
this
is
scoped
to
open
source
and
I
yeah.
M
M
Because
solarwinds
used
it
at
what
they
believed
was
a
a
protected
build
system
and
the
fact
that
they
hijacked
it
underneath
the
covers
was
immaterial
to
the
build
system.
It
was
the
os
compromise
they
got
onto
the
box,
and
anybody
that
says
hey
the
box
is
protected,
needs
to
just
look
at
the
last
four
years
of
every
time.
We've
made
that
claim,
there's
always
been
a
back
door
found.
So
that's
why
I'm
struggling
here.
D
D
Go
ahead,
this
is
gonna,
say
I.
I
don't
think
we're
gonna
be
able
to
answer
that
right
now
and
we
still
have
one
more
sort
of
topic.
So
do
we
want
to
put
a
pin
in
that
and
then
kind
of
get
back
to
it,
maybe
in
in
one
of
either
in
slack
or
something
like
that.
B
A
Great,
thank
you
so
there's
one
remaining
major
agenda
item
for
today
and
I
see
four
different
presenters
associated
with
it.
So
whoever
would
like
to
present
please
do.
K
Awesome
yeah,
so
so
I
think
a
couple
of
us
on
the
call
myself,
michael
mihai,
puff
hold.
K
K
So
I
don't
know
whether,
maybe
if
we
we
don't
make
sure
we
continue
next
week,
so
so
just
kind
of
a
little
bit
of
context
around
this
and
I
think
I'll
get
as
far
as
I
can
and
we'll
figure
it
out
if
you
had
to
continue
next
week
so
back
to
kind
of
this
things
up
with
a
little
bit
of
what
we
just
mentioned
about,
you
know
discovery
or
attestations
as
well,
as
you
know,
the
trustworthiness
or
the
particular
properties
of
artifacts
that
that
have
salsa
associations,
so
so
this
is
a
piece
of
work
that
we've
initially
started.
K
We're
calling
an
aff
graph
for
artifact
friend,
finder
fact,
finder
and-
and
this
is
kind
of
bootstrap
currently
meeting
a
couple
of
us
from
google
from
kusari
as
well
as
santiago
from
purdue,
university
and
yeah.
So
so
I'm
gonna
go
through
kind
of
a
little
bit
about
it,
and
hopefully
this
will
solve
some
of
the
the
problems
that
we
talked
about.
Policy
about.
You
know
figuring
out,
discovering
properties
of
artifacts.
K
So
the
motivation
for
this
is,
we
are
starting
to
see
a
lot
of
security
documents
being
generated.
You
know
whether
this
be
salsa,
but
whether
it
be
s-bomb
bex
documents
and
just
in
total,
at
the
stations
in
general,
and
we
also
have
like
vulnerability
scans
certification
checks
for
more,
like
internal
kind
of
configuration,
management,
database,
kind
of
things
and
basically
a
bunch
of
many
different
documents
right
that
do
various
different
things.
K
So
the
the
problems
that
we're
trying
to
address
is
that
we
have
all
these
documents.
First
of
all,
you
know:
how
do
we
link
these
documents
together?
You
know
you.
You
have
different
ecosystems
that
generate
their
own
selves
of
permanence.
K
K
The
second
part
of
this
also,
you
know
the
various
documents,
for
example
salsa.
We
have
supply
chain
information
for
s-bahn.
We
have
dependency
information,
we
have
vulnerability
information.
How
do
we
kind
of
put
this
together
and
kind
of
reconcile?
All
the
identifiers
so
that
we
can
get
meaningful
information
from
the
graph.
K
K
Cool,
so
what
kind
of
supply
chain
or
security
questions
do
you
have
so
this
kind
of
falls
into
three
broad
categories,
but
there
are
other
use
cases
as
well.
One
is
like
proactive,
you
know,
how
do
I
prevent
large
scale
pump
supply
chain
compromises
example
of
this,
is
you
know
the
xkcd
comic?
The
idea
is
that
you
know
how
do
we
identify
some
of
these
projects?
I
believe
you
know
the
regular
expression,
libraries.
K
This
is
something
santiago
found
as
well
as
sed
is
kind
of
like
the
basis
of
a
lot
of
different
libraries-
and
you
know,
maybe
you
should
put
more
effort
into
that
preventive.
This
is
more
of
an
organization
standpoint
where,
if
I
want
to
run
a
particular
binary
or
particular
workload
in
my
cluster,
I
want
to
ensure
that
you
know
it
has
also
properties.
It
has
gone
through
vulnerability
scans.
It
has
all
the
necessary
security
checks
and
approvals,
and
I
have
evidence
of
that
that
I
can
use
for
compliance.
K
And,
finally,
reactive,
is
you
know
how
my
factor
this?
The
big
question
that
people
ask
you
know
block
4g
happens.
A
lot
of
future
happens
up
the
supply
chain
compromises
you
know,
really.
How
am
I
affected?
What
do
I
need
to
do
to
respond
to
this,
and
the
idea
is
by
collecting
all
the
documents
and
creating
meaningful
relationships
and
resolving
the
identifying
information
between
them.
We
will
be
able
to
ask
these
questions
about
our
organization
and
the
software
that
we
use.
K
So
this
is
a
broad
overview
of
kind
of
like
the
architecture
on
the
left
hand
side.
Here
we
see
we
just
have
a
bunch
of
documents
that
we're
ingesting
a
couple
categories
of
things.
You
know
things
from
public
record
from
six
star
from
github
vulnerability,
information
for
osv
dev,
so
this
will
provide
a
bunch
of
documents
about
open
source,
open
source
libraries
and
open
source
applications.
K
We
also
have
organizations
that
develop
their
own
software.
These
may
be
private.
They
may
store
these
documents
within
internally
in
their
own
databases
in
their
own
cloud
storage.
And
finally,
we
also
have
vendors
such
as
those
that
do
vulnerability,
checks
and
certifications.
They
are
able
to
say
you
know
this
particular
piece
of
software
has
to
be
checked
for
vulnerabilities
and
here's
a
certification
or
attestation
for
it,
and
the
idea
is
of
that.
Is
that
taking
all
these
things
together,
we
can
ingest
and
process
them
extract
from
each
document.
K
The
information,
the
relationships
you
want
from
them
and
create
a
graph
of
how
the
artifacts
relate
to
associations
and
relate
to
the
identities
of
those
attestations
and
be
able
to
ask
questions
about
this
graph.
K
Awesome
so
two
major
use
cases.
One
is
a
public
monitor.
So,
for
example,
a
public
good
service
says
run
for
open
source,
libraries
and
applications.
K
For
example,
it's
excel
monitor.
This
would
ingest
all
verifiable
documents
on
top
of
public
records
and
make
a
public
graph
that
is
queryable
from
everyone,
and
then
we
also
see
a
big
deployment
use
case
being
organizations
where
I
have
a
bunch
of
software
that
I
use
both
from
open
source
and
what
I
develop
internally
or
use
from
other
vendors.
K
And
so
what
happens?
Is
my
graphs
ingest,
like
all
my
internal
documents,
as
well
as
the
relevant
parts
of
the
public
graph,
and
mainly
it's
going
to
be
only
incredible
within
organization
yeah,
and
this
is
small
to
kind
of
like
answer
questions
about
my
organization
rather
than
just
open
source
libraries
and
applications
in
general.
K
So
the
vision
of
this
is,
I
think
that
we're
seeing
is
that
how
the
ecosystem
would
look
like
is
that
we
have
a
bunch
of
public
graphs
right
every
every
package
manager,
every
individual
ecosystem
may
have
a
graph
of
information
about
their
open
source
libraries
about
their
packages,
and
what
happens
then
is
like
these
graphs?
Would,
you
know,
be
connected
to
each
other
in
some
in
some
manner.
K
For
example,
you
know
containers
would
use
like
different
different
different
packages
from
pipi,
maybe
java
packages,
and
so
it
would
kind
of
reference
each
other's
graphs,
and
the
idea
here
is
that
organizations
like
private
organizations
like
coco
pepti,
would
have
their
own
internal
graph
with
their
own
internet
applications,
and
then
they
would
kind
of
cross-reference
with
public
open
source
graphs.
K
I
think
that's
kind
of
like
where
we're
seeing
in
the
future,
but
I
think
the
the
more
likely
outcome
of
this
would
be.
You
know
to
start.
We
would
have
something
like
a
six
star
monitor
graph.
You
know
which
would
take
out
the
adaptation
for
six
saw
and
also
put
in
a
public
graph,
and
this
will
kind
of
encapsulate
the
various
different
aspects
of
the
ecosystem.
K
K
So
three
minutes
left
gonna
quickly
go
through
this
two
types
of
query,
once
informational
query
is
like
am
I
affected
by
this
particular
vulnerability?
The
idea
is
here:
it's
like
you
get
a
set
of
nodes
back
and
then
you
can
kind
of
triage
that
we
also
have
evidence-based
queries
to.
How
do
I
make
a
policy
decision
back
to
back
to
the
policy
discussion,
provide
evidence
that
policies
fulfill,
so
this
will
return
the
subgraph
there's
a
bunch
of
math
around
like
why
these
two
queries
are
different.
K
K
We
want
to
have
talkable
plugability
for
document
handlers,
we're
going
to
have
a
predicate
dictionary
of
you,
know,
kuala
properties
and
important
people.
What
do
we
think?
What
do
we
take
the
salsa
at
the
station?
What
the
information
we
extract
out
of
it
s-bomb?
K
What
information
do
we
want
the
s-bomb
to
be
able
to
make
these
questions
about
trustworthiness
of
the
actual
applications
that
go
through
the
supply
chain
and
be
able
being
able
to
to
map
the
properties
to
the
correct
artifacts,
a
big
part
of
part
of
this
obviously
policy
and
trust
being
able
to
say
who
we
trust,
what
we
trust
is
important
to
us.
K
We
are
building
open
source,
we're
using
neo4j
photograph
database
graphql
for
graph
api,
and
I
think
one
big
important
thing
is
like
we.
We
are
kind
of
prioritizing
scale
here,
because
what
we're
seeing
from
from
chatting
with
folks
and
also
doing
our
own
experiments
is
that
supply
chain
graphs
get
really
really
really
big
really
fast.
At
least
that's
the
situation
today.
K
So
we're
thinking
about
scale.
Quite
a
bit.
I'm
going
to
skip
this
site
projects
hosted
in
this
github
repo
artifact
dash
ff
artifact.ff.
We
are
still
in
early
development.
We
are
looking
for
many
contributors,
the
issue
open,
please
fill
it
in
if
you're
interested
in
contributing
and
we'll
we'll
gladly
contact
a
few.
K
We
also
are
gathering
a
set
of
folks
to
be
technical
advisory
members
to
inform
the
project.
The
project
is
still
a
developer's
first
project,
so
everything
that
tango
advisory
members
provide
will
be
more
of
an
informed
basis,
and
we
are
going
to
be
talking
about
this
at
kubecon
in
october,
in
detroit
as
well.
A
Sounds
great
thanks
so
much
for
the
presentation,
brandon
and
everyone
associated
with
this
really
cool
initiative.
I
think
we're
out
of
time.
Unfortunately
thanks
everyone
for
coming
today
and
it's
nice
to
see
so
many
new
faces
too
and
hopefully
see
you
all
in
slack.
A
Yeah,
I'm
sorry
for
being
an
interloper
to
help
run
it,
but
I
thought
jim
said
she
was
traveling.
So
it's
glad
to
help
out
so
yeah.