►
From YouTube: SLSA Meeting (July 29, 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
All
right,
we
can
go
and
get
started
and
folks
will
come
in
as
they
need
to
just
a
reminder
for
anybody
who
just
joined
feel
free
to
put
your
attendance
in
the
meeting.
One
second.
A
This
meeting
is
being
recorded
and
it'll
be
uploaded
to
youtube
at
some
point
later,
and
your
participation
in
this
meeting
is
an
agreement
to
abide
by
the
open,
ssf
code
of
conduct.
A
Cool
okay!
So
it's
the
first
meeting,
so
there's
going
to
be
a
couple
of
different
agenda
items
here,
so
I
think
the
first
one
that
actually
before
getting
into
this
well,
it
looks
like
everybody
on
this
is
our
folks
who
regularly
participate
in
salsa.
So
I
don't
think
we
necessarily
need
to
do
introductions
unless
folks
do
do
folks
want
to
introduce
themselves.
B
If
you
don't
mind,
I
I'd
like
to
introduce
myself.
My
name
is
my
name's
rob
winch
and
I'm
actually
kind
of
new
to
these
meetings.
B
I'm
from
vmware
and
I'm
the
project
lead
for
spring
security,
which
is
a
prominent
spring,
is
a
kind
of
a
prominent
java
project
and
we're
here
trying
to
look
for
ways
to
take
steps
to
secure
our
builds
been
kind
of
following
I'm,
a
colleague
of
joshua
who's,
big
into
salsa,
and
but
I'm
looking
into
ways
to
kind
of
secure
java
builds,
which
I
know
there's
been
steps
with,
go
and
some
other
ones,
and
I
heard
recently
that
there's
interest
in
building
to
better
tooling
for
java
based
builds
so
I'm
kind
of
here
to
kind
of
second.
B
C
I'll
go:
I'm
isaac,
I'm
from
google,
hey,
how's
it
going
and
yeah
I've
been
coming
to
the
salsa
community
and
working
group
meetings
for
a
while-
and
I
am
I'm
actually
super
stoked
for
these-
these
new
working
groups
within
salsa
and
hoping
that
we
can
get
some
get
some
real
momentum
around.
You
know
some
core
topics
and
I
think
tools
is
tools-
is
one
that's
close
to
my
heart,
so
yeah,
I'm
pretty
excited
to
be
here.
B
Yeah,
I
think
I
think
it's
lagging
a
little
bit
but
yeah
I'm
part
of
I'm
I'm
with
michael.
We
are
for
the
startup,
we
started
a
startup
called
kusari,
which
is
focused
on
secure
supply
chain
and
we're.
You
know,
I'm
interested
in
figuring
out
what
we
can
do
and
how
we
can
provide
more
tooling
for
that
lines
with
salsa
and
if
there's
anything
existing
and
we
can
refine
stuff,
and
you
know
that
better
aligns
with
salsa
and
stuff.
So
I'm
glad
to
be
here.
B
I
can
go
next,
I
am
the
being
streamers
and
I
contribute
to
few
opennesses
of
projects
interested
in
salsa,
helping
with
tooling
here
to
contribute,
respected
tool
and
declutter.
Thank
you.
B
Yeah
hi
everyone,
my
name
is
sripad.
I
recently
joined
intel.
I
was
part
of
another
organization
before
and
primarily
focus
on
various
aspects
of
supply
chain
security,
so
happy
to
be
part
of
this
school.
A
Cool
is
there
anybody
else,
otherwise
we
can
get
to
the.
A
Okay,
oh
I
guess
I
haven't
introduced
myself,
so
I'm
I'm
also
mike
I'm
also
at
kusari
doing
a
lot
of
work
on
the
supply
chain
space.
I'm
also
one
of
the
leads
for
one
of
the
security
leads
for
the
cncf
security
tag.
You
know
the
security
group
over
there
and
helped
sort
of
lead
up
the
secure
software
factory
reference
architecture
and
contributed
to
some
of
the
other
cncf
supply
chain,
security,
best
practices,
work
and
so
yeah.
A
A
lot
of
my
interest
is
in
seeing
what
we
could
do
to
sort
of
better
salsa
tooling,
while
also
sort
of
seeing
how
we
can
integrate
that
salsa,
tooling,
with
other
projects
and
and
whatnot
that
are
kind
of
going
on
there.
A
Okay,
so
let
me
so,
I
think
isaac
yours
probably
makes
the
most
sense
to
start
off
with.
Do
you
want
to
yeah.
C
I
I'm
hoping
it'll
be
it'll,
be
brief
and
uncontroversial,
I'm
just
thinking
a
little
bit
about
the
scope
of
this
team.
I
mean
we've
called
the
tooling,
but
I
think,
broadly
you
know.
I've
been
thinking
of
the
chargers
slightly
more
broader,
around
salsa
enablement.
I
think
tooling,
is
a
massive
part
of
that,
but
I
think
as
well.
We
should
be.
You
know
we
should
be
open
to
pursuing
and
generating
patterns
and
examples
and
documentation,
and
really
thinking
that
you
know
this
is
this.
C
Is
you
know
we're
in
the
business
of
reducing
friction
of
adopting
and
using
salsa
and
tools?
Is
gonna,
be
a
big
part
of
that,
but
you
know,
especially
as
we
get
started
as
well.
We
should
be
open
to
considering
you
know
things
that
stopped
short
of
pre-bound
necessary
pre-packaged
tools.
Things
like
you
know,
patents,
like
you
know.
C
The
github
actions
builder
began
as
kind
of
a
you
know,
a
proof
of
concept,
and
I
think
you
know
that
was
that
was
useful
even
before
it
became
a
fully
fledged
tool
of
its
own
right,
and
so
I
wanted
to
to
just
kind
of
float.
That
idea
with
the
group
and
see
if
folks
agree
or
if
there's
yeah,
if
there's
other
ways
to
be
thinking
about
this.
C
And
mike
since
you're,
the
chair,
that's
that's
kind
of
in
the
first
instance
directed
at
you.
A
Yeah
yeah,
I
I
definitely
think
it
falls
somewhere
whether
or
not
it
falls
under
tooling.
I
I
don't
know
just
because
you
know,
I
don't
think.
When
I
look
at
the
other
two
groups,
I
don't
think
that
they
have
that
fight.
Yet
I
think
potentially
the
adoption
group
might
take
some
of
this
long
term,
but
I
would
be
willing
to
take
yeah.
A
I
would
be
more
than
willing
to
take
on
some
of
that
initially
and
then
hand
off
to
the
adoption
group,
because
the
adoption
group
might
not
start
up
for
another
few
weeks
couple
of
months
and
I
think
that's
still
really
valuable,
because
actually
right
before
this
conversation,
we
there
was
watching.
Somebody
else
have
an
interview
about
salsa
and
one
of
the
things
was.
It
seemed
like
there's
there's
a
lot
of
lack
of
clarity
around.
A
A
Here's
you
know
some
of
the
tools
you
might
be
using
and
then
this
is
how
what
salsa
looks
like
throughout
that
that
whole
journey
I.
I
definitely
think
that
that
is
definitely
valuable
and
I
would
be
you
know.
I
don't
want
to
speak
for
every
any
everyone,
but,
from
my
perspective,
I'm
definitely
down
to
take
on
that
scope.
A
Initially,
with
the
idea
of
we
should
probably
just
sort
of
reevaluate
once
once
adoption
gets
started
to
spun
up,
because
I
think
once
it
once
that
gets
spun
up,
it'll
probably
be
there'll,
probably
be
a
little
bit
of
a
shift,
and
you
can
kind
of
see
there.
No.
C
You're
right,
I'm,
like
that's,
super
smart
and
I
think
it's
exactly
the
right
approach
actually
and
to
consider.
Maybe
this
this
I'll
scope
a
little
bit
broader
in
the
immediate
term,
as
adoption
gets
spun
up,
maybe
they'll
break
off
parts
of
the
documentation
and
patents
and
so
on.
As
part
of
you
know,
creating
that
easy
on-ramp
on
the
also
and
yeah.
I
love
that
idea.
Thank
you.
A
Cool
yeah,
yeah
yeah.
I
I
definitely
agree
there.
A
I
also
think
the
the
two
are
also,
I
think,
linked
a
little
bit
because
without
the
tools
it's
hard
to
give
us
getting
started
guide
with
salsa,
because
it's
like,
oh,
you,
can't
really
actually
do
it
without
the
tools.
But
at
the
same
time,
once
we
have
the
tools,
I
think
it
makes
sense
to
say:
okay
and
here's
how
you
adopt
those
tools.
B
Yeah
absolutely:
is
there
already
like
a
list
of
salsa
tooling
that
exists
out
there
is
that
does
that
need
to
be
the
first
step
or
this?
Has
that
already
happened
and
do
we
need
to
go
evaluate
that
and
then
based
on
those
kind
of
toolings?
Maybe
you
can
start
writing.
You
know
this
blog
post
just
on
onboarding
things
that
can
help
people
on
board
hunter
salsa.
A
So
I
think
so
that's
gonna
be
the
the
next
agenda
item
is
talking
about.
I
think
I
think
what
we're
probably
gonna
do
is
go
through
this
a
little
bit
and
then
figure
out
like
what
are
before
we
even
get
to
just
listing
what
tools
are
available
today.
A
I
think
it's
probably
worthwhile
to
talk
about
what
categories
of
tools
are
available
or
are
just
like
what
what
what
we
see
as
being
like
the
categories
of
tools
that
would
fall
under
what
we're
trying
to
do,
and
then
we
can
go
and
say:
okay,
is
there?
Are
there
tools
today
that
do
that
specifically
for
salsa?
Are
there
tools
that
do
that,
but
maybe
if
they
don't
have
a
feature
to
apply
to
salsa
or
whatever,
and
then
are
there
tools
that
maybe
don't
exist
that
should
exist
and
and
so
on.
B
Yeah,
I
think
one
thing
that
might
help
is
that
there
are
some
some
groups
that
they
say
they
are
choose.
Also
three
like
listening
to
the
suze
right
there.
They
are
claiming
that
they
assume
salsa
for
and
they
have
some
practices
and
tooling.
So
maybe
it's
good
to
consider
the
existing
groups
or
tools
or
software
that
they
claim
they
are
achieving
certain
level
and
see
what
they
are
doing,
how
they
are
doing.
Maybe
that
might
be
good
starting
point.
A
Yep
that
that
makes
sense
I
yeah,
I
do
think
yeah.
I
think,
actually,
that
that's
probably
something
also
worthwhile
to
identify
is
is
like
what
are
the
also
generic
versus
versus
specific
right,
like
I
think
the
susa
stuff
is
obviously
very
geared
towards
building
susa
and
it
might
be
valuable
to
sort
of
investigate,
but
maybe
for
right
now
we
might
want
to
you
know,
reach
out
to
them,
and
just
say:
hey
are
some
of
those
tools
you're
using
for
to
to
build
out.
A
Salsa
like
some
of
them
are.
Probably
a
lot
of
them
are
probably
open
source
and
whatever,
but
they
probably
mostly
apply
to
susa.
Is
it
something
that
could
be
made
more
generic
and
that
kind
of
thing.
B
Yeah
again,
and
I
think
more
than
tool
right,
it
also
applies
to
practices
like
how
they
are
doing
their
downloading
dependencies
before
they
use
it.
They
are
storing
it
internally.
So
I
think
that
package,
if
what
practice
they
are
following
that
might
also
be
useful,
because
I
think
the
salsa
most
of
them
fall
under
both
the
tool
like
actual
tools
and
some
basically
practice.
A
Yeah,
that's
actually
a
good
point
that
it
just
seems
to
be
maybe
more
and
more
as
it's
being
discussed,
maybe
just
makes
more
sense.
It's
like
this
group
is
almost
more
like
tooling
and
practice
it's
like.
This
is
how
this
is,
how
you
actually
do.
The
salsa
right,
salsa
specification
is
talking
about
the
requirements
and
talking
about
how
to
define
it
in
a
clear
and
consistent
way.
A
Positioning
is,
then,
how
do
we
map
that
to
other
practices
that
are
being
done,
other
standards
and
whatever,
and
then
this
is
the
one
of
like
okay?
Now,
how
do
you
actually
practically
do
it.
A
Okay,
so
actually
let
me
put
that
down:
does
anybody
have
any
thoughts
on
including
should
should
we
include
practice.
B
C
Yeah,
that
was
the
only
one
I
described
it
with
patents
right
but
yeah.
I
think
it's
a
very
some
similar
notion,
and
I
think
I
mean
your
point
mike
like
we
may
want
to
evaluate
when
the
adoption
group
spins
up
and
then
we
need
to
you
know,
figure
out
what
the
right
dividing
line
is
between
tools
and
adoption,
given
that
one
is
the
enabler
of
the
other,
but
I
think
ahead
of
the
adoption
group
getting
spun
up.
B
I
want
to
play
the
devil's
advocate.
Are
we
taking
too
much
to
to
be
successful
again
just
playing
this?
I'm
just
trying
to
understand.
B
A
Sure
yeah,
I
can
definitely
talk
to.
I
think
I
think
that's
also
once
again
a
good
point.
We
don't
want
to
take
on
everything,
so
the
other
two
groups
which
I'm
also
part
of
isaac,
I
believe
you're
part
of
them
as
well,
or
at
least
one
of
them,
I
think,
and
so
at
a
high
level.
A
The
specification
group
is
primarily
focused
on
generating
the
actual
salsa
requirements
and
clarifying
you
know,
a
couple
things
one
is
is
ensuring
those
requirements
are
clear
and
consistent
and
and
unambiguous,
making
sure
that
they
are
also.
They
are
clear,
well
separate
from
from
specifically
that
but
like.
In
addition,
it's
like
they
are
clear
to
the
outside
world,
because
I
think
there's
been
a
couple
of
comments
that
there
are
certain
things
in
there
that
seem
to
make
sense
to
googlers,
but
maybe
outside
of
google.
A
It
doesn't
you
know,
there's
a
lot
of
folks
who
are
like.
I
don't
know
what
that
means,
so
you
have
to
define
it
and
that
kind
of
thing
so
there's
there's
definitions
and,
and
that
sort
of
thing
also
focused
on
just
generally.
What
is
the
scope
of
salsa
as
a
requirement?
A
Also
they're
focused
on
the
specification
as
far
as
the
metadata
right,
so
the
salsa
attestation
predicate
format
you
know.
Are
there
things
that
need
to
be
added
removed,
made
clear
in
the
predicate
format
as
we
kind
of
drive
towards
1.0?
So
that's
the
specification
group
isaac.
Do
you
have
anything
or
anybody
else
have
anything
else
to
add
on
there
that
I
might
have
missed.
A
And
then
the
other
group
which
is
positioning
is
more
focused
on
how
do
we
work
with
the
various
open
source
groups,
companies
and
so
on?
That
are
starting
to
do
a
lot
of
this
work
or
in
the
supply
chain
space
and
make
sure
that
it's
clear
where,
where
salsa
begins
and
ends
for
folks,
where
we
can
do
mappings
between
salsa
and
other
standards,
like
the
cncf
best
practices
guide
that
talks
a
lot
about
supply
chain
security
as
well
like.
A
Are
there
ways
that
we
can
kind
of
say:
hey,
here's
salsa,
here's
how
you
would
do
it
in
a
cloud
native
way,
because
the
cncf
has
already
sort
of
done
that
so
that's
the
focus
of
positioning
while
also
talking
to
some
of
the
while
also
trying
to
what
groups
we
should
probably
have
representatives
from
salsa
join
and
then
try
and
get
folks
from
other
groups
to
join
here.
So
this
is
stuff
like
there's,
there's
ietf
skit.
A
There
is
a
a
whole
bunch
of
stuff,
that's
happening
in
the
supply
chain,
general
supply
chain
space,
and
we
just
want
to
make
sure
that
you
know
if
we
try
to
really
push
salsa.
A
As
you
know,
the
really
good
standard
that
people
should
be
following,
we
also
want
to
make
sure
that
we
don't
step
on
each
other's
toes,
because,
just
as
an
example,
the
cd
foundation,
which
is
another
linux
foundation
group,
is
starting
to
spin
up
supply
chain
best
practices,
rules
for
the
cd
foundation,
and
it
probably
makes
sense,
for
you
know
us
to
kind
of
work
with
them
on
on
that
as
well.
A
A
Cool
and
then
finally,
the
adoption
group,
it
will
be
spun
up
and
the
idea
was
the
adoption
group
would
be.
How
can
we
make
it
very
easy
for
folks
to
get
on
to
salsa
use
salsa
understand,
salsa
get
you
know,
training,
certification,
whatever
and
and
the
problem
with
spinning
that
group
up
so
early
is
that
without
the
tools
without
the
specification
clarified
without
understanding
our
relationship
with
all
these
other
groups,
it's
just
gonna
probably
cause
a
lot
of
confusion,
because
we'll
you
know
be
telling
people
do
it
do
this.
A
A
All
right
so
to
get
back
to
naveen's
question,
which
I
think
is
also
very
valuable,
though,
is
it?
Is
you
know
we
don't
want
it?
I
agree
we
don't
want
to
take
on
too
much,
so
I
think
it's
probably
worthwhile
to
scope
it
within
the
context
of
the
tools
that
we
are
spinning
up
like
we
shouldn't
necessarily
talk
about
too
much
about
the
specification,
because,
obviously
the
specification
team
is
is
building
that
out.
We
probably
shouldn't
go
too
deep
into
this.
A
Just
my
personal
opinion
about,
like
we
shouldn't
go
too
deep
into
stuff,
like
as
an
example
like
oh
here's,
the
cncf
tool
that
does
this
that
and
the
other
thing
it
should
probably
be
like.
I
think
we
should
just
focus
on
on
what
makes
sense
and
what
folks
are
are
super
familiar
with
here.
Otherwise,
I
do
think
that
we'll
we're
going
to
end
up
like
pulling
in
a
bunch
of
different
folks,
it's
going
to
get
complicated,
at
least
until
adoption
gets
spun
up.
B
B
A
So
I'm
just
gonna
put
mine.
I
I
plus
I
plus
one
that
I
want
us
to
not
have
to
do
all
that
extra
stuff
once
the
it
gets
spun
up.
Does
that
make
sense
to
other
folks?
Do
other
folks
have
different
opinions?
A
All
right
cool
any
objections.
A
Okay,
we
we
can
move
on
cool,
so
I
think
okay,
so
we
have.
B
A
An
idea
here
so
now.
I
think
that
the
next
step
is
to
maybe
get
into
the
categories
of
what
what
what
sorts
of
things
from
the
tools
patterns
practices
perspective.
Do
we
want
to
start
actually
working
on
and
then
or
sorry
that
we
think
fall
under
the
stuff
that
we
want
to
work
on
in
the
short
term
to
get
us
to
1.0.
A
So
I
had
a
list
here,
but
obviously
I
think
some
of
those
based
on
some
of
the
practices
me
just
also.
A
Oh,
I
see
we
already
have
actually
some
of
that
written
up
so
build
up.
A
So
I
see
oh
actually
I
realize
I
haven't
been
sharing.
The
notes
here
probably
makes
sense
for
me
to
share
the
notes
while
we
go
through
so
I
can
point
to
them.
Okay,.
B
The
distribution,
verification,
decisioning,
so
training
best
practices
and
then.
A
B
Yeah
one
thing
that
might
help
is,
if
you
can,
map
this
to
salsa
levels,
billion
production,
it
maps
to
certain
salsa
level,
or
I
think
that
categorization
might
also
help
or
just
the
annotations,
not
kind
of
just
whenever
we
discuss.
A
Yep,
so
let's,
let's
put
in
maybe
put
that
in
somewhere
here
on
this
category,
the
the.
A
And
so
this
could
be
scorecard.
This
could
be
source
code
control.
A
So
do
these
categories
make
sense,
so
the
first
category
is
like
build
in
production,
which
I
believe
is
just
like.
You
know,
yeah
build
tools
so
whether
it's
the
all
the
salsa
github
actions
work.
That's
in
the
salsa
frame,
sorry
in
the
salsa,
under
the
salsa,
org
or
tools,
other
tools
under
open
ssf,
like
fresca
or
git,
lab
or
github
actions
that
are
be
starting
to
support.
Salsa
probably
falls
under
here.
A
A
A
Are
you
verifying
that
it's
signed
with
the
right
identities
and
are
you
doing
policy
decisions
to
ensure
you
know
whatever
like
admission
control,
that
kind
of
thing,
training
and
best
practices,
that's
kind
of
what
isaac
was
talking
about
and
then
the
other
tooling
involved,
which
these
are
things
I
think
that
are
not
quite
salsa
specific,
but
probably
still
going
to
be
involved
in
some
of
what
we
do.
So
this
is
stuff
like
scorecard
and
and
some
of
the
stuff
that's
kind
of
going
on
with
scorecard
is.
A
Could
you
use
scorecard
to
identify
elements
of
your
git
repository
and
whether
or
not
it's
applying
certain
salsa
best
practices
around
your
git
repository
that
kind
of
thing,
security,
insights?
That
kind
of
you
know
all
those
projects
that
are
getting
spun
up
and
then
you
know
specifically
source
code
control
because
there's
you
know
there's
there
are
requirements
around
source
code
control
around
two-person
code
review.
A
B
B
Or
is
this
a
separate
tool
all
by
itself
to
say
you
know
what
somebody's
going
to
identify
where
there
is,
but
some
another
tool
is
going
to
verify
whether
it
is
what
it
is,
because
I'm
thinking
hypothetically
usually
like
I'm
using
something
like
this
store
to
make
sure
all
my
artifacts
are
in
one
place
and
you
can
like
use
it
in
and
using
that
as
a
as
a
place
to
store,
usually
verification
happens,
but
need
not
be.
It
can
be
other
place
also,
but
just
trying
to
say
is:
is
there
too
many
categories
coming
out?
C
Actually,
sig
store
fits
squarely
under
distribution
and
discovery,
but
six
store
is
not
doing
salsa
verification
itself
and
it's
not
doing
policy
or
decisioning,
and
so
that
that's
to
me
why
it
makes
sense
to
separate
these
out.
But,
looking
at
six
or
as
a
tool
set,
it's
not
six
door
doesn't
do
anything
around
building
production.
It
doesn't
do
anything
around
verification
decisioning,
but
it
could
form
part
of
the
solution
that
we
need
for
distribution
of
discovery.
B
A
Yeah,
so
I
think
maybe
we
and
I
don't
I'm
not
very
good
with
words.
So
so
I
don't
know
what
how
to
maybe
reword
this
a
little
bit
where
it
sounds
like
distribution
and
discovery.
It's
also
six
store
does
do
is
right,
is
six
store,
does
verify
against
identity
right?
It
verifies
that
you've
signed.
You
know
that
you
have
signed
it
with
a
specific
key
and
that's
good,
and
I
think
there
still
is
some
overlap,
but
I
think
what
isaac
said
is
a
good
way
to
sort
of
split
it
up.
A
Where
one
is
your,
it's
focused
around
stuff,
like
verification
of
identity,
making
sure
like
the
sig
store
stuff
is
also.
You
know
you,
you
store
attestations
in
recore
and
once
some
of
the
bugs
are
are
fixed
in
record
you'll
be
able
to
to
verify
the
signatures
in
record,
but
but
the
the
thing
there
right
is
that
kind
of
makes
sense
from
a
purely
identity
perspective,
but
sig
store
outside
of
just
verifying
and
outside
of
their
whatchamacallit.
A
They
have
a
they
have
their
own
emission
controller
web
hooked
thing
now,
but
but
I
think
those
two
things
are
kind
of
somewhat
separate
right,
because
you
you
that
would
be
a
little
bit
separate.
A
Then
if
you
look
at
something
like
key
verno
or
opa
gatekeeper,
which
is
probably
also
doing
both
things
right,
you're
you're,
both
verifying
that
the
identity
is
correct,
it's
been
signed
with
the
right
secrets
and
and
so
on,
and
in
addition
to
that
you're,
actually
looking
at
the
metadata
inside
of
the
salsa
at
a
station
to
then
say
you
know,
was
this
using
an
approved
builder?
Was
this
you
know
using?
Do
I
trust
you
know?
Do
I
trust
the
other
elements
that
are
kind
of
happening
in
there?
B
B
A
Yep,
so
so
do
we
want
to
put
something
in
in
the
first
topic
then
to
to
make
it
clear
it's
about.
B
B
B
Like
usually,
I
would
say,
like
I
usually
like
the
word
that
I
usually
use
is
policy,
but,
like
decisioning,
is
the
same
sort
of
thing
yeah.
So
it's
like
you're
verifying
the
identity
of
the
person
of
the
whatever
created
of
the
builder.
I
guess
that
created
the
the
the
providence
and
you
know
verifying
that
the
provenance
has
the
type
of
or
the
you
know,
has
the
types
of
values
in
it
that
you
expect
or
that
you
want.
B
To
build
on
that,
you
also
want
to
be
able
to
have
some
sort
of
mapping
between
the
way
that
people
are
used
to
consuming
the
artifacts
and
the
metadata,
because
right
now
it
maps
a
lot
to
the
github
repository,
but
our
users
in
the
java
space.
They
don't
really
know
much
about
the
github
repository
when
they're
consuming
the
artifacts.
They
just
have
like
a
coordinate
for
the
binary
and
so
like.
B
A
B
A
Yeah,
so
maybe
if
we
go
the
other
way
around,
because
because
I'd
be
curious
here
like
based
on
some
of
this
right,
the
verification
and
decisioning
distribution
and
discovery,
it
sounds
like
something
like
sig.
Storm
might
fall
under
both
of
those
categories
at
some
level
right
where
so,
distribution
and
discovery
rate.
You
know.
A
Actually,
there's
a
separate
thing
here,
which
is
just
like
actually
the
generation
of
the
generation
and
signing
of
salsa
providence.
I
don't
you
know,
I
think
it
probably
falls
under
one
of
these
categories
as
we're
kind
of
building
that
out,
but
six
store.
Does
that
piece
right?
It
stores
stuff
in
recore
you
can
it
also
using
cosign
and
similar
tools.
You
can
store
stuff
inside
the
oci
registry.
A
Given
some
of
the
work
that's
being
done,
you
know
across
the
board
some
there's
there's
discussions
about.
Could
you
inject
this
into
a
python
package
using
something
like
sig
store
and,
and
that
kind
of
thing,
or
at
least
have
it
somewhere
live
alongside
it
and
then
separately,
when,
when
consuming
that
you
can
use,
you
can
still
use
six
store
tools
to
do
the
initial
like
hey?
Was
this
python
package
signed
by
the
maintainer
of
the
python
package
or
the
you
know,
or
is
it
different?
A
So
do
folks
are
folks
comfortable
with
it
falling
like
a
potent
you
know,
with
potentially
tools
falling
under
multiple
categories.
C
Yeah
I
mean
I
you,
you
could
imagine
kind
of
laying
these
categories
out
in
some
kind
of
columnar
view
and
then
having
you
know,
literally,
like
visually
mapping
tools
onto
it
and
saying
you
know
this
tool
set
here.
Spams
these
two
categories
here
or
actually
this
tool
set
here,
covers
the
entire
lifecycle
and
then
helps
you
you
know
through
from
bill
and
production
all
the
way
through
decisioning
on
the
policy
side
yeah.
I
would.
B
Tools
will
do
discovery
and
verification
decision,
so
like
you'd,
be
able
to
cover
the
salsa
for
a
package
and
then
verify
that's
also
you
know
like.
So
I
would
imagine
a
lot
of
tools
to
do
both
but,
like
you
know,
there's
going
to
be
two
sides
of
that.
How
do
you
discover
the
package
and
how
do
you
actually
like
kind
of
distribute.
C
You
know,
we've
got
these
problems
around,
you
know
verification
and
discovery,
let's
say
or
distribution
of
salsa
providence,
and
we
may
need
you
know
maven
or
pipe
or
whatever
to
you
know,
be
a
part
of
this
and
help
us
build
parts
of
the
solutions
for
particular
language
ecosystems
I
mean,
and
so
I
think
I
guess
that
the
categories
stand
out
to
me
as
kind
of
these
are
these
are
neces
we're
going
to
need
necessary
or
sorry
we're
going
to
need
solutions
which
span
all
of
these
end-to-end
to
have
a
successful
salsa,
and
it
could
be
that
for
some
language,
ecosystems,
these
are
standalone
tools
for
some.
A
Cool,
so
I
think
that
that
that
seems
fairly
reasonable.
A
So
do
we
now
want
to
kind
of
start
going
through
and
identifying
current
tools
that
that
exist
today
that
are
trying
to
at
least
solve
this
problem
or
in
some
way
involved
in
solving
this
problem
and,
like
I
created
a
little
thing
here
under
current
tooling
and
gaps,
and
so
we
can
also
identify
if,
like
there
are
certain
things
like
you
know,
oh
there's,
no
tool
that
seems
to
hit
this
specific
thing
for
salsa,
and
we
can
kind
of
call
that
out.
Does
that
make
sense
to
folks.
A
Yes,
yes,
so
feel
free
to
start
putting
stuff
in
here,
because
you
know
there's
going
to
be
a
whole
lot,
probably
to
put
in
there.
You
know
I'm
going
to
put
in
obviously
some
of
the
tools
that
I
am
familiar
with,
or
I'm
working
with.
C
Michael
could,
could
you
say
a
few
words
about
fresca.
I
I
kind
of
I
see
this
coming
up
again
and
again
and
I
mean
vaguely
following
along,
but
I'm
not
quite
sure
what
it's
about.
Could
you
contextualize
it
a
little
bit.
A
Sure
so
fresca
the
history
of
fresca
is
while
salsa
was
starting
to
come
up
and
while
the
cnc
act
was
building
out
their
secure
software
factory,
when
a
few
of
us
were
over
at
city,
we
were
building
an
implementation
of
that
using
a
bunch
of
using
a
bunch
of
open
source
tools
underneath
the
linux
foundation
stuff,
like
techton
techton
chains,
trying
to
tie
it
all
together
such
that
we
could
follow
all
the
best
practices
right
and
and
like
by
default
and
constrain.
You
know
so
right.
A
You
can
run
tecton
without
actually
following
salsa,
but
we
wanted
to
sort
of
say:
hey
here
is:
if
you
deploy
this,
it
is
configured
in
such
a
way
that
you
have
spiffy
spire,
so
you're
getting
short-lived
workload,
identities
helping
hit
the
non-falsifiable
requirement.
You
know
you
know
in
all
of
these
different
things,
and
so
really
it's
a
collection
of
tools
and
abstractions.
On
top
of
those
tools
intended
to
sort
of
be,
you
know
like
a
lot
of
the
the
github
action.
A
C
A
Thank
you
cool,
thank
you
and
yeah,
so
it's
open
source
and
it
actually
it
is.
It
falls
also
under
the
open,
ssf
supply
chain,
integrity,
working
group.
So
it's
a
it
is
a
sister
project
to
salsa
in
that
that
context.
B
I'm
going
to
ask
a
question
on
that
again:
it's
not,
I
don't
know.
B
Does
it
make
sense
to
bring
that
into
this
tooling
working
group,
because
now
we
have
a
specific
stuff
that
is
people
resources
being
spent
on
this
having
diversified
is
great,
but
then
with
that
comes
distribution
of
resources
which
might
not,
which
might
be
hard
to
keep.
I'm
just
trying
to
ask.
I
probably
that's
not
the
this-
is
not
the
forum
to
ask
that
question,
but
just
throwing
that
out.
A
Yeah,
I
mean,
I
think,
for
at
least
initially
the
scope
of
this
group
is
more
around
also
just
sort
of
I.
I
think
we
first
need
to
identify
what
already
exists
what's
out
there,
and
then
we
can
kind
of
go
back
and
say,
oh
great,
like
does
it
make
sense
for
folks
in
this
group
to
start
partnering
with
six
store
to
get
some
of
this
stuff
out?
A
Maybe
yes,
maybe
no,
maybe
six
store
already
is
doing
the
right
things
and
we
don't
necessarily
need
to
do
that
same
thing
with
any
of
the
stuff
here,
like
techton
or
or
kiverno,
opa,
gatekeeper
and
so
on.
I
think
the
first
step,
though,
is
just
to
identify
what
exists
today.
A
A
So
ian
I
know
you
have
a
bunch
of
little
tools
underneath
the
salsa
actual
org
you
and
and
laurent
and
others
do
you
want
to
add
some
of
those.
Oh
yep
there
we
go
salsa,
github,
generator,
yeah.
B
Yes,
so
the
generator
we
also
have
the
verifier,
which
I'll
edit,
in
the
verification
section
here.
B
A
Yeah,
that's,
it
is
a
good
point.
I
saw
a
couple
of
folks
write
up
some
examples
and
I've
actually
written
up
some
examples
in
the
past
as
far
as,
but
we
could
also
identify
that,
as
you
know
like,
because
I
do
think.
For
example,
kiverno
has
like
native
support
for.
B
There's
also
yeah,
I
don't
think
oba
gatekeeper.
You
have
to
be
more,
create
your
own
policy
that
you're
checking.
Basically,
I
don't
think
it
currently
exists.
A
Yeah,
I
saw
a
few
folks
writing
up
some
libraries
for
it,
but
let
me
just
actually,
if
I
do.
B
Yeah
I
mean
like
you
could,
theoretically,
like
you,
could
have
a
rego
policy
that
you
create
using
oppa
or
whatever,
but
I
don't
know
if
there's
any
like
open
libraries
or
like
anything,
that's
like
that.
I've
seen
that,
like
actually
support
salsa
in
a
meaningful
way,
I
guess
like
verifying
the
signature
and
things
like
that.
B
A
So
maybe
we
just
identify
that
as
because
I
do
think
it
is
remember
the
other
thing
I
think
we
probably
want
to
do
while
sort
of
figuring
this
out
is,
for
example,
yeah.
If
opec
gatekeeper
has
multiple
gaps
in
doing
this,
we
might
just
want
to
open
up,
like
you
know,
not
focus
our
time,
but
just
open
up
an
issue
on
oppa's.
You
know
github
just
say:
hey,
there's
a
lack
of
some.
You
know,
tooling.
A
That
makes
this
sort
of
thing
easy
and
then
just
sort
of
leave
it
at
that,
and
does
that
make
sense.
B
A
I
think
it's
probably
worthwhile
under
the
like
tabbed
in
it
probably
makes
sense
to
also
talk
about
specifically
if
it
hits
a
specific
salsa
level
in
certain
cases
that
is
irrelevant
or
it
doesn't
really
make
sense,
but
I
think
also
some
of
the
stuff
in
there
that
that's
probably
valuable
is
like
as
we
go
through,
for
example,
the
other
tooling
right,
there's
gonna
be
stuff
here,
you
know
github's
two-person,
pull
request
right
is
going
to
satisfies
this
specific.
A
A
So
I
will
also
I'll
highlight
something
that
a
few
of
us
over
at
google
and
oh
sorry.
Well,
I'm
not
at
google,
but
a
few
folks
at
google
plus
santiago
from
from
purdue
and
a
few
of
us
from
kusari
are
working
on
a
tool
called
aff
which
we
are
building
out,
some
proof
of
concepts
for,
and
I
will
bring
up
the
document
for
it.
But
it's
it's
a
distribution.
B
A
Yeah,
but
the
the
idea
behind
aff
would
be
a
way
to
take
stuff
like
salsa
other
associated
supply
chain,
metadata,
transform
it
into
a
graph
that
you
can
then
run
queries
against
or
stuff
like
decisioning,
eventually
and
and
whatnot,
but
the
big
idea
there
right
being.
If,
if
I,
if
I
have
a
salsa
at
a
station
and
my
dependencies
have
salsa
ada
stations
up
to
some
level,
then
I
can
essentially
build
a
graph
out
of
those
salsa
attestations
and
be
able
to
ask
more
ask
interesting,
deeper
questions
about
stuff.
B
B
A
Github
generator
there's
a
salsa,
just
a
blog,
also
coming
out
of
github,
just
to
show
that
at
least
they
are
it's
not
just
like
you
know.
Github
is
also
interested
in
this.
A
Okay,
so
we
only
have
three
minutes
left,
I
think
obviously
offline
folks
can
kind
of
add
in
additional.
B
A
Folks
can
put
in
obviously
additional
tools
in
here
also
as
we
kind
of
go
through
pl.
You
know
please.
If
you
identify
like.
Oh,
there
really
appeared
to
be
no
tools
that
do
x,
feel
free
to
put
it
in
here
and
identify
that
that
is
like
a
gap,
because
I
do
think,
for
example,
from
the
distribution
and
discovery
perspective.
A
I
know
that
some
folks,
for
example,
from
the
distribution
discovery.
A
You
know
they
just
store
attestations
assigned.
B
A
Like
they
do
that,
oh
right,
yeah,
google
cloud
build
yeah
so
feel
free
to
just
add
more
stuff
in
there
over
the
next
week,
and
then
probably
does
it
make
sense
for
next
week,
then
we
kind
of
go
in
and
start
to
do
just
sort
of
a
generic
like
analysis
of
okay.
Where
are
the
big
gaps?
What
needs
to
start
getting
addressed
sooner
rather
than
later,
and
then
identify
where
we
actually
want
to
throw
our
support
behind
sounds.
A
Cool
any
other
questions,
comments,
concerns.
A
Cool
well
I'll,
see
you
all
in
in
in
slack
and
have
a
good
weekend.
Thank
you.