►
From YouTube: SLSA Meeting (February 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).
A
Hey
everybody
kim-
I
can't
be
here
today
so
I'll,
be
running.
The
meeting
today
welcome
everyone.
I
guess
we'll
give
folks
a
few
more
minutes
to
trickle
in,
as
always,
if
you
could
edit
the
community
meeting
notes-
and
we
invite
you
to
add
yourself
I'll
paste
it
in
the
chat
for
easy
reference.
A
A
A
All
right
looks
like
people
aren't
trickling
at
this
point,
so
hi.
Everyone
welcome
to
another
salsa
bi-weekly
meeting
a
couple:
administrative
things
to
take
care
of
quickly.
One
several
steering
committee
members
can't
make
this
time
slot,
and
so
we
we'd
like
to
consider
moving
it
to
thursdays,
but
on
the
opposite
week.
So
the
next
meeting
would
be
march
17th,
as
opposed
to
what's
two
weeks
from
now
the
and
it
would
be
at
the
same
time,
slot
9
to
10
a.m.
A
Pacific
we
asked
if
you
can't
make
the
new
meeting
if
you
could
fill
out
that
google
form
so
that
way
we
know
we
will.
A
Plan
like
the
default
decision
is
to
plan
is
that
we
will
move
the
meeting
to
that
time
slot.
But
if
there's
a
significant
number
of
people
who
can't
make
it,
then
then
we'll
we'll
will
not
do
that
and
we'll
send
out
either
way
we'll
send
an
announcement
over
the
salsa,
discuss
mailing
lists
and
we'll
update
the
calendar
on
on
the
shared
calendar
on
the
website
and
in
a
google
doc.
A
So
hopefully
everyone
should
know,
but
again
please
fill
out
that
form
that
the
link
is
in
the
meeting
notes.
I
had
two
related.
Oh
first
of
all,
I
guess
any
comments
on
that.
A
Okay,
if
you
do
just
feel
free
to
jump
in
another
kind
of
administrative
item
we
in
the
past,
we
talked
about
switching
to
community
specification.
I
think
we're
gonna
someone
volunteered
to
actually
start
doing
that.
I
don't
know
if
you
have
any
preferences
on
that
like
if
there's
like,
if
we
just
use
a
single
repo
or
have
a
separate
community
repo.
A
Please
comment
on
that
on
that
issue,
otherwise
we're
just
and
doing
that,
and
similarly
there's
issue
296,
which
is
the
actually
I
should
present
my
screen.
Sorry,
I'm
so
used
to
kim
running
this
that
I
am
not
doing
as
good
a
job
as
she
does.
C
A
A
B
I've
never
heard
of
that
problem
because
I
present
with
presentations
all
the
time
on
a
shared
screen.
So
I.
A
Okay,
there's
just
no
indication
that
that
it's
working,
if
you
share
a
tab,
it
mutes
you
if
you
share
a
window,
it
doesn't.
A
That
so
the
anyway,
if
you
have
any
opinions
there,
please
please
adam
happy
to
discuss
now,
but
that
might
not
be
the
best
use
of
time
since
we
have
several
other
items
in
the
agenda,
if
anyone
wants
to
speak
up,
feel
free
to
do
so
now,.
A
B
B
Me,
my
fault,
sorry
yeah,
so
basically
for
each
of
e,
there
are
several
salsa
criteria.
I
actually
didn't
I
linked
to
an
issue
that
gave
an
example.
Yeah
number
20.
didn't
that
yeah.
I
had
a
rationale
and
examples
for
every
requirement,
so
this
is
based
on
my
experience,
not
just
with
the
best
practices
badge
but
really
over
decades
of
working
with
other
organizations
that
create
you
know
best
practices
lists
is
don't
just
tell
me
why
what
you
should
do.
Tell
me
why
that's
important?
B
B
Why
that
I
chose
that
one,
because
if
we
can't
give
a
rationale
for
that
one
we're
in
trouble,
but
you
know
basically,
you
know
what
is
that?
What
is
the
problem
that
you
are
trying
to
counter?
What
would
be
the
bad
thing
that
happened?
B
If
you
didn't
do
this,
you
know,
and
if
nothing
else,
for
example,
if
it
turns
out
that
there's
a
situation
where
the
rationale
is
wrong,
then
that
suggests
that
you
know
maybe
this
is,
you
know,
needs
to
be
fixed,
or
maybe
you
need
to
declare
that
and
not
applicable
or
something,
but
you
know
something
for
each
of
the
of
the
requirements.
B
One
issue,
of
course,
is
where
to
stick
it.
You
know.
One
easy
pr
way
would
be
just
using
htmls
details
tags,
but
but,
however,
we
want
to
do
this.
I
think
it'd
be
important
to
include
a
rationale
for
each
and
we
can
do
this
over
time.
This
is
not
something
you
have
to
do
instantaneously.
A
Yeah,
I
I
agree
with
that.
I
I
also
agree
with
using
the
like
simple
html
for
that
on
the
threats
page
salsa.dev
threats,
we
that's
what
I
use
there
of
like
just
the
summary
details
and
then
use
css
to
format
as
a
table.
So
if
anyone
likes
doing
that
sort
of
stuff
with
web
development
and
css
and
stuff,
I
would
you
know-
certainly
welcome
having
someone
figure
out
a
better
way
to
format.
B
How's
this
I
can
volunteer
to
at
least
that
first
text
of
the
rationale
I
would
like
somebody
else
who
is
more
patient
with
css
to
to
fix
the
css.
If
it's
necessary,
I
mean,
if
it
you
know,
if
the
there's
existing
you
know
it
may
be
that
the
existing
stuff
is
good
enough.
But
if
not,
you
know,
I
think,
it'll
be
good
to
fix.
It's
also
easier
to
fix.
B
Once
you
have
some
text
to
look
at,
you
know,
oh,
this
is
what
it
would
look
like
so
and,
as
I
said,
I
think
this
is
the
sort
of
thing
that,
once
you
add
once
you
add
one
and
it
looks
okay,
we
can
iterate
through.
I
think,
for
the
most
part,
we
shouldn't
have
problems,
giving
rationale,
but
my
experience
has
been
as
you
had
the
rationale
you
suddenly.
B
B
Okay,
so
all
right,
I
will
self-assign
some
making
at
least
a
first
stab
using
that
rationale,
probably
as
a
starting
point
and
mark,
I
will
probably
need
to
chat
with
you
about
exactly
where
to
stick
this
in
the
html,
so
that
we
don't.
The
goal
is
to
work
together
and
not
screw
things
up.
A
B
My
goal
was
just
generic
descriptions
if
we
want
to
include
oh
whoops,
there's
some
strange
tech,
I
mean
if
we
want
to
mention
the
rationales
als
of
that
linking
to
something
else
is
fine,
but
I
actually
don't
agree
that
linking
to
say
nist
is
enough
of
a
rationale.
B
F
Hey
david
I'd
be
interested
in
helping
to
collaborate
on
that
with
you.
You
know
I'm
coming
in
newer
to
salsa,
so
you
know.
Maybe
I
could
be
your
your
layman
to
consume
some
of
this
and
work
on
it.
B
B
The
first
version
people
will
hate
for
some
reason
or
other
and
then
we'll
fix
either
its
location
or
the
text
and
we'll
just
beat
on
it.
And
but
yes,
that'd
be
fantastic,
so
aaron,
I'm
sorry!
I
don't
know
how
to
pronounce
your
last
name.
F
B
F
F
B
Okay,
so
I
will,
I
will
try
to
create
a
a
first.
A
very
first
cut
mark
will
beat
it
our
aaron
will
beat
it.
Other
folks
are
obviously
welcome,
but
but
yeah
that
would
be
fantastic.
Thank
you.
G
G
Yes,
this
is
brian
from
google,
okay
and
I,
I
just
add
a
note
in
the
doc
putting
that
in
there
too,.
B
Let's
see
here,
this
is
the
scope
of
salsa
discussion.
I.
B
This
one
this-
this
was
a
I
I
may
have,
but
it
links
to
actually
something
posted
by
mark.
How
does
salsa
fit
into
the
broader
supply
chain.
A
Maybe
I
ended,
I
don't
even
remember
two
weeks
ago
was
a
long
time
ago.
B
A
Yeah,
I
think
we
I
I'd
like
to
consider
like
whether,
if
anyone
has
opinions
on
how
best
to
consider
salsa
in
the
broader
supply
chain,
security
right
now,
salsa
is
focused
entirely
on.
A
Integrity,
meaning
protection
against
tampering
both
at
the
source,
level
and
and
binary
level
for
most
users,
that's
probably
not
the
biggest
concern
we
we
talked
about
this
in
in
previous
bi-weekly
meetings.
I
think
there's
not
we
within
google
we
had
talked.
I
talked
to
some
other
folks
about
this
and
it
seems
like
there's
at
least
a
reasonable
argument
that
you
could
expand
salsa,
at
least
the
brand
to
consider
more
than
just
integrity
like
well
particularly
vulnerability.
A
Management
is
one
of
the
biggest
things
that
users
face,
and
also
provenance
and
declaring
dependencies
is
very
related
to
s-bomb
and
vulnerability
management,
and
so
there's
probably
a
good
opportunity
to
have
a
a
story
that
kind
of
solves
user
needs
bigger.
So
I
I
think
it's
worth
coming
up
with
a
proposal.
I
think
we
could
use
the
proposal
framework
that
we
mentioned
earlier
to
at
least
write
up
the
idea,
and
then
we
could
discuss
it
kind
of
more
broadly
michael.
D
Oh
yeah,
I
just
wanted
to
add
on
that.
That
was
something
that
was
actually
recently
discussed
right
before
we
released
the
cncf
reference
architecture
for
for
public
comment.
D
One
of
the
things
was
that
salsa
does
fit
the
the
providence
piece
that
has
been
missing
right,
like
there's
a
lot
of
things
that
are
out
there,
whether
it's
security
scanning
tools
and
network.
You
know
security
tools,
all
that
sort
of
stuff
that
can
help
in
lots
of
different
areas,
but
one
of
the
things
that
has
been
missing,
which
is
what
I
think
salsa
really
really
hits,
is
the
piece
around
specifically
around
provenance
and
like.
D
A
Yeah,
so
if
anyone
is
interested
in
collaborating
to
write
up
her
proposal
at
least
to
me
personally,
it's
not
a
slam
dunk,
I'm
concerned
around
scope
creep
and
making
it
less
focused
and
kind
of
adding
more
confusion.
So
I
I'd
like
to
see
some
sort
of
more
clear
proposal
away
in
the
pros
and
cons
and
like
how
we
could
communicate
this
and
incorporate
the
broader
supply
chain
security
in
a
way
that
you
know
doesn't
cause
us
to
lose
focus.
H
You
know
like,
like
you
know
whether
it's
some
sort
of
enterprise
or
or
firm
and
how
they
would
look
at
procuring
their
supply
chain
using
salsa
or
using
other
products
and
trying
to
figure
out
you
know
is
that
is
that
something
we
could
work
on
and
try
to
identify
what
those
use
cases
are
all
those
requirements
are
and
then
try
and
figure
out
how
that
maps
to
the
gaps,
perhaps
in
salsa
and
then
ultimately
take
that
as
user
requirements
then
highlight
well,
you
know
what
that's
not
appropriate
for
salsa,
we'll
leave
it
or
we'll
put
it
somewhere
else,
but
at
least
we
know
what
people
are
actually
looking
at
trying
to
solve.
I
Hi,
this
is
my
sarah
evans
with
dell.
This
is
my
first
meeting
with
salsa,
and
that
was
the
very
question
I
had
that
I
want
this.
Salsa
is
great:
how
does
it
fit
into
the
into
the
bigger
ecosystem?
Because,
with
security,
automation
and
orchestration,
you
have
individual
components
that
exist
in
a
silo
and
understanding
how
they
integrate
into
the
hole
is
the
big
picture
of
security
that
I
think
that
everyone's
looking
for
so
I'm
happy
to
contribute
to
what
is
the
role
of
salsa
so
that
it
doesn't
have
scope
creep,
but
then
also?
I
How
does
it
fit
into
the
broader
ecosystem?
And
I
I'm
excited
to
engage.
A
D
D
So
I'm
just
gonna
show
off
some
of
this
stuff
and
I,
as
as
sort
of
announced
in
the
sub
the
supply
chain,
integrity
working
group,
we
we
are
going
to
be
contributing
the
this
to
the
open,
ssf
and
wanted
to
kind
of
just
give
a
highlight
and
how
it
sort
of
integrates
with
salsa
how
it
and
how
the
different
pieces
come
together.
So
just
give
me
one
second,.
D
Can
you
see
the
diagram
that's
up.
G
D
All
right
cool
cool,
so
I'm
just
so
a
lot
of
this
comes
from
the
cncf's
supply
chain.
Reference
architecture.
D
We
have
you
know
our
team
sort
of
has
built
out
a
reference
implement
or
sorry
an
implementation
of
that
reference
architecture,
and
you
know
we're
contributing
it
to
the
open
ssf,
which
should
hopefully
come
through
in
the
next
few
weeks
and
just
kind
of
wanted
to
you
know.
I
know
I
showed
a
couple
of
demos
of
a
few
of
the
different
pieces
working,
but
one
to
kind
of
show,
a
high
level
architecture.
D
Maybe
one
quick
example
and
just
you
know,
show
how
we're
sort
of
integrating
some
of
the
salsa
pieces
and
then,
where
we
also
see,
maybe
some
needs
or
not
needs,
but
some
some
future
work
that
we
would
like
to
sort
of
participate
in
with
salsa.
And
you
know,
maybe
some
you
know
gaps
we're
seeing
there
so
once
again
the
secure
software
factory
is
more
or
less
just
you
can
think
of
it
as
just
a
ci
cd
that
has
some
additional
stuff
baked
on
top
of
it
right.
D
D
And-
and
so
one
of
the
things
here
right
is,
is
so
the
secure
software
factory
is
just
a
ci
cd
system
with
some
additional
stuff
baked
on
top,
and
so
that
could
be
stuff
like
you
know,
policy
and
whatever
else,
and
so
you
know
you
imagine,
you
know
your
cicd
system,
your
secure
software
factory
pulls
code
from
you
know.
D
Various
things
pulls
dependencies
from
the
outside
world,
whatever
pushes
those
things
to
artifact
storage
and
you
know-
gets
used
in
production
environments,
you
have
a
production
emission
controller
so
on
I'm
gonna
quickly
kind
of
go
over
some
of
this,
and
let
me
just
make
this
really
large
here,
so
this
is
sort
of
what
the
architecture
looks
like
here.
D
So
the
the
idea
right
is,
and
I'm
just
going
to
go
quickly
around
in
a
circle
here
right.
You
know
you're
providing
identities
to
the
various
systems.
Inside
of
this
is
running
inside
of
kubernetes,
but
you're,
essentially
providing
identities
to
all
the
different
pieces
of
the
puzzle.
You
know
you
have
a
pipeline
observer,
so
this
is
in
this
case
tecton
chains
for
our
implementation.
D
But
you
imagine,
you
need
to
have
something
that
sort
of
records
what
the
bills
are
doing
and
signs
off
on
them,
and
so
that's
what
tech
tons
chains
is
doing
and
so
techton
chains
is
generating
salsa
attestations
based
off
of
what
it's
seeing
in
tecton
and
not
a
hundred
percent
fully
integrated
yet
but
using
stuff
like
spiffy
spire.
We
can
actually
begin
to
attest
to
that.
D
The
the
tecton
builds
are
happening
on
the
right
nodes,
so
we
begin
to
get
stuff
like
non-falsifiability
and
that
sort
of
stuff
and
the
same
thing
for
workloads
themselves.
Like
am
I
actually
writing.
Am
I
actually
running
the
workload
that
I
think
I'm
running
right?
That's
that's
where
some
of
that
sort
of
stuff
comes
into
play.
All
of
this
sort
of
stuff
gets
stored
in
metadata
storage,
whether
it's
oci
or
or
a
public
transparency,
log
or
another
database.
D
We
also
use
sort
of
admission
controllers
for
what's
actually
happening
inside
the
build
system
itself.
So
you
know
if
I
go
and
try
and
run
a
build
and
I'm
not
using
a
base
level
container
or
you
know
the
right
sorts
of
yeah
if
I'm
not
using.
Let's
say
a
base
level
container,
that's
signed
off
by
you
know
our
team,
then
it's
just
not
gonna.
Let
it
run
right.
D
So
that's
trying
to
sort
of
block
those
sorts
of
pieces
and
fit
into
some
of
the
you
know,
sort
of
eventually
start
to
flow
into
sort
of
either
a
summary
salsa
or
a
recursive
or
transitive
salsa
setup
we're
also
looking
at
sort
of
runtime
well.
The
pipeline
framework
here
is
just
sort
of
like
we're
using
tecton
and
then
we're
trying
to
also
do
stuff
with
runtime
visibility.
Right
where
you
know
this
is
some
longer
term
stuff.
This
could
be
sort
of.
This
could
be
you
know,
falco.
D
It
could
be
some
of
the
aqua
security
stuff.
It
could
be
witness.
It
could
be
a
lot
of
different
things,
but
the
idea
of
like
sort
of
tracing
what's
actually
happening
in
the
builds,
so
that,
if
I
do
detect
something
hey,
what's
actually
going
on,
you
know
can
detect
sort
of
anomalous
behavior.
So,
even
if
we're
following
salsa
best
practices
around
stuff,
like
hermetic,
builds
and
ephemeral,
builds
and
isolated
builds.
D
I
still
want
to
know
about
that,
and
so
largely
this
is
sort
of
a
very
basic
sort
of
example
here,
and
this
is
sort
of
what
you
would
imagine
you
know,
each
of
these
is
itself
like
a
salsa
at
a
station,
so
the
pipeline
observer,
you
know
as
each
of
these
individual
tasks
work
run
like
I'm
fetching
the
code
and
dependencies,
I'm
recording
that
information,
pushing
it
to
metadata
storage
and
the
same
thing
with
stuff
like
pre-build
tasks.
D
So
this
could
be
security
linting
that
sort
of
thing
when
I'm
running
a
build,
I'm
doing
the
the
same
sort
of
thing
there,
and
and
and
so
on,
okay,
and
then
one
of
the
things
that
we're
doing
right
in
order
to
kind
of
help
us
manage
all
of
this
to
sort
of
enforce
that.
Yes,
everything
needs
to
have
salsa,
attestations
and
needs
to
comply
to
certain
levels
of
policy.
D
We
are
using
kulang
as
a
configuration
management
language
to
help
us
manage
stuff
like
hey
when,
when
running
builds
right
at
a
high
level,
we
might
enforce
something
like
you
must
have
this
sort
of
security
scan.
You
must
follow
these
sorts
of
tasks
and
we
want
to
make
sure
that
you
know
developers
have
some
level
to
sort
of
tweak
as
they
need.
D
But
if
somebody
is
enforcing
a
security
policy,
you
don't
get
to
work
around
that
security
policy
and
that's
been
a
big
concern
is
that
it's
still
very
easy
to
kind
of
just
you
know,
figure
out
a
way
to
sort
of
change,
something
in
a
task
and
push
that
out
qlang
sort
of
says.
No,
you
know
developers
won't
have
access
to
the
actual
underlying
scripts.
They
just
might
have
access
to.
D
You
know
their
maven,
their
their
go
configs
and
those
sorts
of
things,
but
not
have
access
to
sort
of
swap
out
what
version
of
go
with
something
else
that
is
sort
of
unchecked,
and
then
this
sort
of
thing
allows
us
to
sort
of
deploy
all
of
that
out
quite
easily
all
as
one
package.
So
one
sort
of
q
set
of
definitions,
we
can
have
a
very
simple
interface
into
it
for
end
users
and
that
sort
of
deploys
out
stuff
like
stuff
into
chains.
D
B
I
have
just
kind
of
a
broader
question.
You
know
there's
a
number
of
tools
that
really
want
you
to
do.
You
know
curl
curl
pipe
to
shell,
and
I
was
curious
how
you
deal
with
that
kind
of
circumstance.
B
D
D
Yeah,
so
I
think
the
thing
here,
and
so
I
don't
want
to
go
too
deep
into
the
weeds
on
on
all
the
specifics.
But
if
I
go
back
to
let's
say
this
diagram,
this
one
right
is
so,
ideally
anything
that,
let's
say
is
doing
something
like
that.
You
would
sort
of
limit
the
scope
of
that
as
much
as
humanly
possible.
So
if
you
were
to
you
know,
if
you
are
required
100
and
there's
no
way
to
work
around
a
curl
pipe
sh,
maybe
you
just
have
okay.
D
I
have
a
single
task
that
is
purely
around
that
curl
pipe
sh
and
you
know
you
need
to
enforce
certain
things
like
hey
that
curl
pipe
sh
should
be
pushing
it
to
some
sort
of
cache
or
some
sort
of
build
storage
right,
and
so
we
can
sandbox
it
as
much
as
is
possible
so
that
we're
only
allowing
it
access
to
absolutely
what
it
needs
and
nothing
else.
D
So
if
it
does
try
to
do
something
weird,
we
can
detect
it
right
and
that
plus
some
of
the
runtime
visibility
pieces
I
think
help
out,
but
as
much
as
is
possible,
we're
also
trying
to
push
back
against
that
sort
of
pattern
of
doing
things,
but
I
think
we
also
recognize
that
inevitably
you're
gonna
have
like
yeah,
okay,
here's
the
one
area
where
we
do
it.
We
don't
think
it's
a
big
deal.
Okay,
great
we're,
gonna,
isolate
it
and-
and
you
know,
make
sure
that
the
blast
radius
of
it.
D
B
But
in
your
figure,
that's
basically
the
top
left
within
the
box,
fetch
code
dependencies
task,
and
I
guess
you
would
hope
that
would
actually
be
subdivided
further.
So
for
that
part,
is
that
that
that's
what
you're
thinking
right,
yep.
D
Yep-
and
you
know,
this
is
something
that
have
implemented
in
a
previous
life
where
all
dependencies
were
fetched
before
the
actual
build
happened
and
in
a
completely
separate
sort
of
security
context,
so
that
hey
you
can
download
the
dependencies.
It
could
only
write
to
this
build
storage
and
everything
else
for
all
those
dependencies
in
yayada.
But
then,
once
the
build
happened,
the
build
couldn't
actually
go
out.
Get
network
access
to
that
other
stuff.
C
First,
yeah
yeah:
I
wanted
to
riff
on
top
of
what
you
said
in
a
previous
life
when
I
was
using
my
favorite
tool
concourse,
it
had
an
explicit
distinction
between
resources,
which
are
essentially
things
that
you
get
from
a
network
or
sent
to
a
network
and
tasks
which
could,
in
theory,
access
a
network,
but
it
was
bad
form
to
do
so.
C
So,
yes,
you
would
have
your
curl
in
a
resource,
so
it
was
isolated.
That
concept
didn't
fully
make
its
way
into
tech
time.
But
that's
another
story.
The
other
thing
I'd
add
in
this
riffing
is
something
that's
been
kicked
around
in
six
store
land.
Is
this
idea
of
an
s-get
utility?
C
Essentially,
it
behaves
like
a
curl,
it
retrieves
something,
but
it
also
relies
on
the
transparency
log
to
say:
have
I
seen
this
before
and
is
it
trustworthy
so
that
you
have
additional
guarantees?
So
that's
a
distinct
sort
of
like
security
control
like
on
a
different
axis,
from
making
sure
that
you
have
the
asset
before
you
do
anything
with
it
in
the
different
security
context,
as
michael
said,
but
it
adds
an
additional
protection
against
the
change,
the
loss
of
integrity
in
the
remote
asset
before
it's
retrieved.
D
Yep
and
and
quickly
on
that
point
yeah,
the
the
what
we're
doing
here
on
that
on
that
end
is.
We
are
actually
doing
that
for
the
the
secure
software
factory
itself,
the
code
itself
is
going
through
we're
like
we're
using
esket
and
we're
vendoring
those
tools
and
and
we're
sort
of
enforcing,
like
that.
You
know
you
know
where
possible
right,
we're
also
doing
stuff
like
we're
enforcing
hashes.
So
if
we
know
hey,
these
are
good.
E
Yeah,
I
was
just
wondering
whether
you
have
you
know
for
those
use
cases,
whether
you
have
specific
mechanisms
for
defining
egress
controls,
because
so
far
we've
only
found.
I
think
I've
spoken
about
this
before
the
only
thing
we've
found
where
we
can't
completely
isolate
our
containers
from
the
network
has
been
authentic,
signing
where
we
need
to
go
and
get
a
real-time
timestamp,
but
everything
else
we've
been
able
to
firewall
off.
E
D
Yeah,
so
one
of
the
things
that's
kind
of
where
I
think
the
spiffy
spire
piece
comes
in,
so
a
lot
of
the
ways
that
people
are
trying
to
do
it
now
is
so
you
would
get
you
know
you
would
sort
of
mount
the
spiffy
spire
socket
in
in
the
container,
and
it
would
be
able
to
kind
of
get
that
from
there
and
that's
kind
of
you
know
you
are
because
it's
like
you're
just
giving
it
the
socket
you're,
not
giving
it
like
actual
access
to
you
know
the
internet
depending
on
who
you
talk
to
that
could
be
hermetic.
D
It
might
not
be.
I
think
some
of
those
conversations
are
are
going
to
be
really
interesting
as
we
as
a
sort
of
community
begin
to
all
generally
get
much
better
at
this.
I
think
some
of
those
questions
on
like
hey.
Can
we
trust
that
socket?
D
Can
we
trust
the
you
know
accessing
that
time
server
you
know,
but
I
think
the
thing
there
is
yeah
where,
like
the
big
thing
from
the
build
perspective,
like
my
opinion
is
yeah,
if
you
can
restrict
it
and
you
can,
you
know
materially,
restrict
it
and
use
runtime
visibility
to
actually
monitor
and
verify
that.
I
think
you
can
kind
of
get
a
a
pretty
good.
I
would
feel
a
lot
more
comfortable
to
say
yep.
It's
only
hitting
this
service,
it's
not
hitting
something
else,
vicky.
J
Hey
no
sorry,
I
dropped
my
hand
but
didn't
unmute.
Oh
technology
is
hard.
So
hey
there
everybody.
This
is
the
undershirt
with
so
you
say
it
goes
out
and
it
grabs
dependencies
and
and
keeps
some
of
your
artifact
repository
and
that's
awesome.
But
does
it
do
anything
special,
for
instance,
for
containers
should
it
have
to
go
out
to
for
let's
say
docker
hub
or
something
like
that
was?
J
Is
it
can
it
unpack
that
container
and
inspect
it
and
see
what's
going
on
and
you
know,
are
there,
does
it
rebuild
the
container?
How
does
it
container,
I
guess
yeah,
because.
E
J
That's
a
special
case
that
a
number
of
companies
I've
worked
with
have
really
found
concerning,
and
it's
not
simply
the
individual,
npms
and
pipis,
and
things
like
that
of
the
world
right.
The
containers
are
a
major
concern
as
far
as
security
and
compliance
and
things
like
that.
D
Yeah,
so
we're
trying
to
take
the
sort
of
similar
to
sort
of
the
like
how
salsa
right
is
trying
to
establish
the
provenance
piece,
so
the
idea
here
is
we
would
use
either
in
the
pre-build
or
post
build
tasks
some
scanning
tool,
some
you
know
whatever
tool.
That
would
do
that,
but
the
idea
is
by
sort
of
still
keeping
it
in
this
factory
right
and
keeping
it
within
the
constraints
of
this
factory
and
the
policies
and
whatever
we
would
say.
Okay
great.
D
I
have
confidence
that
that
this
container
I
just
built-
or
this
container
I
unpacked-
is
the
container
I
thinking
that
I
wanted
to
unpack
or
that
I
wanted
to
scan
that
I
wanted
to
build.
So
in
this
case,
like
we're
not
making
much
of
a
decision
there,
like
you
know,
obviously
for
examples
and
demos
purposes,
we'll
probably
include
some
various
open
source
scanning
tools
and
show
that
we
can
sort
of
track.
D
You
know,
yes,
you
downloaded
your
source
code
in
dependencies
now
you're
running,
let's
say
some
scanning
against
those
dependencies
or
you're
validating
attestations
already
right,
maybe
from
a
policy
perspective
you've
already.
You
know
you
have
a
separate,
you
know,
process
to
download.
You
know
container
images
and
sign
off
on
them
for
for
them
to
be
available
to
this
secure
software
factory.
D
That's
another
sort
of
model
here
and
we're
trying
to
be
relatively
general
and
flexible,
not
saying
that
you
know
there
could
be
multiple
approaches
to
the
problem,
but
generally
we're
trying
to
say,
hey,
look
we're
our
tool
itself
is
the
primary
goal
is
to
sort
of
track
the
different
tasks
as
they're
happening
and
say
that
you
know
the
first
thing
that
happened
was
fetching
code
independencies
and
it
handed
it
off
to
the
pre-build
tasks,
and
you
know
we're.
D
You
know
we're
able
to
see
that
you
know
via
an
audit
or
whatever
see
that
yes,
the
the
code
and
dependencies
we
downloaded
is
what
ended
up
in
the
pre-build
tasks
and
after
that,
what
ended
up
in
the
build
artifact
task
and
so
on
and
so
forth.
D
And
then,
if
some
of
that
is
stuff
like
unpacking
of
images
and
scanning
and
whatnot
yeah
like
we
can,
that
would
be
more
of
like
a
runtime
decision
or
not
runtime
decision,
an
operational
sort
of
decision
of
hey,
I'm
allowing
these
sorts
of
scanning
tools,
these
sorts
of
unpacking
tools
to
run
inside
of
the
pipeline
and
from
a
policy
perspective,
you
might
even
say
I'm
enforcing
it
like
nobody
can
actually
deploy
a
job
that
doesn't
include
that
scanning
task.
Something
like
that.
That
answer
your
question
yeah,
it
does.
Thank
you
cool
okay.
D
So
let
me
quickly,
if
I
do,
I
don't
want
to
take
up
too
much
more
time.
I
can
show
a
very
quick
example
if
folks
want,
but
if
there's
something
else
on
the
agenda,
I
don't
want
to
take
up
too
much
more
time.
D
Okay,
no
objections,
I
guess
so
I'll
share
my
screen
here
real
quickly
and
let
me
just
go
through
and
clear
from
the
last
demo
I
just
gave
on
this
a
little
while
ago.
So
this
is
just
a
very
simple
build
packs
example.
This
could
you
know
this
could
be
anything
it
doesn't
have
to
be
build
packs.
It
could
be.
D
You
know
it
could
be
a
java
pipeline.
You
know
it
doesn't
even
need
to
necessarily
create
a
docker
image,
but
just
to
kind
of
show
you
what
that
docker
image
is.
D
Right
so
this
is
a
ttl
image,
so
this
is
ttl
is
just
a
it's.
A
public
open
sort
of
service
that
deletes
images
every
few
hours
so
that
you
could
use
it
for
demo
purposes.
So
I
don't
have
to
pollute
like
an
actual
public
sort
of
docker
repository.
Anything
like
that.
So
let
me
so.
This
is
just
tailing.
You
know
it's
building
the
image.
This
is
the
sort
of
log
here.
D
D
Usually,
like
15
20
seconds
here,
okay,
there
we
go.
It's
now
signed
now,
just
to
kind
of
show
you
what
that
looks
like
using
crane
right,
which
hey.
This
is
the
actual
image
the
latest
here,
but.
D
D
Has
does
it
have
an
a
does?
It
have
an
accurate
salsa
attestation,
yes,
and
if
we
want
to
actually
look
what's
in
that
salsa
attestation,
I
can
run
cosine
again
here
and
it's
pretty
much
saying
hey.
Was
it
signed
with
this
key?
This
is
for
the
basic
stuff,
obviously
like.
If
you
were
using
this
yourself,
you
have
a
vault
or
you'd
use,
spiffy
spire.
That
kind
of
thing.
But
if
I
go
in
here,
you
can
see
you
know
it's
an
entota
statement.
D
It
is
probably
it
is
the
salsa
providence,
predicate
type
the
subject
here
is
that
image
right
and
and
that
image
has
this
digest
and
then
we
can
look
at
you
know.
How
did
it
run
right?
You
know
here's
what
that
sort
of
script
actually
looked
like
when
it
was
running
the
build.
You
know
what
were
the
arguments
you
know
and
what
was
the
sort
of
upstream
image
and
you
know
some
other
information.
D
What
were
what
were
arguments
to
this
sort
of
creator,
script
and
and
so
on,
and
so
this
is
just
one
example
here
and
then
and-
and
I
don't
have
time
to
show
the
sort
of
more
full-fledged
one,
but
we
can
you
know,
one
of
the
things
is
hey.
We
can
sort
of
string
together
a
lot
of
these
things,
so
if
you
did
have
a
job
that
included
a
link
like
a
security
linting
step
and
after
it's
built
some
some
scanning
steps
you'd
be
able
to
go
and
say:
okay.
D
Well,
let
me
pull
down
all
these
attestations,
make
sure
that
all
the
various
hashes
line
up
so
that
you
know
that,
yes,
the
the
output
of
one
thing
led
to
the
input
of
another
and
based
on
all
that
sort
of
thing
you
can
kind
of
say,
okay
great.
I
now
have
an
attestation
that
I
got
scanned.
I
have
an
attestation
that
I
got
built
a
certain
way.
B
I
I
think
I
know
the
answer,
but
I
feel
I
should
ask
you.
You
include
a
lot
of
informa
metadata
here,
including
things
like
build
dates
and
so
on.
Obviously,
for
some
of
these
things
one
counter
measure
for
some
attacks
is
reproducible
builds.
E
B
But
you
know
this
is
data
about
a
particular
build
it's
not
being
embedded
into
the
executables
and
so
on.
So
it's
fine
to
reproduce
builds
multiple
times
and
say:
hey
keeps
giving
me
the
same
answer
even
though
these
are
different
builds
and
I'm
obviously
running
them.
Typically
in
different,
build
times
correct.
D
D
Yep-
and
I
don't
have
the
example
all
sort
of
configured
for
the
latest
one,
but
I
do
have
an
example
using
nyx,
where
I
can
create
a
container
using
nics
and
that
container
using
nyx
will
always
have
the
same
digest.
So
when
I
generate
this
sort
of
thing,
yes,
this
data
will
should
more
or
less
be
identical.
D
Besides,
maybe
a
couple
of
flags
just
to
show
that
hey,
I'm
running
it
on
different
systems
and
to
show
that
hey
I'm
running
on
different
systems,
but
they're
still,
you
know
converging
to
the
same
hash,
and
then
you
know
the
the
metadata
might
still
be
different,
and
you
know
you
might
have
some
unique
identifier
right,
just
to
kind
of
say.
D
Yes,
this,
you
might
have
a
unique
identifier,
just
to
kind
of
relate
it
back
to
did
this
actually
run
on
two
different
build
modes,
because
if
it
ran
on
the
same,
build
node,
there's
obviously
attack
vectors,
just
to
kind
of
say,
oh
well,
that
that
node
has
been
compromised
and
it
will
just
always
tell
you
it's
the
same
hash.
Each
time.
D
Cool,
so
that's
that's
really
about
it.
I
just
wanted
to
kind
of
give
you
an
overview
there
talk
about
how
you
know
we
do
plan
to
sort
of
integrate,
obviously
a
lot
more
salsa
stuff.
You
know
looking
at
maybe
areas
where
hey
this
doesn't
make
sense
for
it
to
be
a
salsa
predicate.
B
Yeah
and
I
I
think
in
a
few
cases,
I
think
some
of
the
salsa
text
I
think,
could
be
refined,
and
so
I'm
hoping
that
the
the
interactions
back
and
forth
will
will
make
sure
the
language
is
what
in
fact
what
was
when
inten.
What
was
intended.
A
A
lot
michael,
I
think,
the
last
item
on
the
list.
I
think
someone
from
red
hat
posted
this.
I
believe
number
235
project
maintainer
package
versus
distribution
package.
C
K
I
I
didn't
add
it,
but
I
mean
I
had
some
thoughts
that
are
sort
of
related
to
it
and
it
kind
of
covers
or
goes
with
the
conversation
we
had
before
the
demo
and
even
parts
of
the
demo
was
it
was.
You
know
I
look
at
salsa
as
sort
of
a
it's
a
stamp
on
a
pipeline
that
builds
a
product,
and
you
know
the
customers
look
at
the
product,
and
so
we
can
say
we
can
hand
them
a
product
and
say
you
know.
K
This
was
built
on
a
pipeline
that
that
is
at
this
salsa
level.
The
problem
is,
there's
a
whole
lot
of
things
we
pull
in
from
upstream,
and
you
know,
even
if
I
can
verify
you
know,
an
image
that
I
pulled
in
and
and
do
a
hash
on
it.
I
don't
necessarily
know
you
know
what
what
pipeline
did
they
use?
You
know
how
the?
How
did?
How
do
they
secure
their
pipeline?
Are
they
at
a
certain
salsa
level?
K
I'm
not
sure
what
my
actual
question
is
just
not
sure
how
to
address
it.
I
guess
you
know,
because
I
want
to
hand
a
product
to
a
customer
and
say
you
can
be
assured
that
this
has
gone
through
this
process
or
this
this
level
of
security,
but
I
can
only
ensure
that
for
my
pipeline,
I
can't
necessarily
point
back
to
you
know
the
source
of
everything
I
ever
use
within
my
pipeline
to
build
the
ultimate
product
that
I
hand
to
the
customer.
That
makes
sense.
L
L
Something
to
that
also.
I
think
this
is
eric
ties
with
wipro.
I
agree
with
you,
but
I
think
a
lot
of
the
salsa
framework
is
mostly
a
lot
of.
It
is
process
orientation
right
so
having
having
a
number
of
components
around
you
know
some
of
it
would
be
standards
around
actually
checking
the
third-party
tools
that
you
you're
you're
using
as
well.
L
You
know
using
instead
of
pulling
down
binaries
pulling
down
code
and
actually
doing
scanning
of
the
of
that
as
part
of
your
process
as
well
and
reassuring
them
to
some
marginal
degree
of
error,
because,
while
this
is
you
know,
I
I
think
this
is
a
great
project
and
I
think
there's
a
lot
of
benefits
to
it.
It's
not
going
to
100
guarantee
everything,
but
it'll
get
you
a
lot
closer,
so
I
think
it
really
becomes
a
discussion
around
documented
governance
being
able
to
show
them.
You
know
the
the
checklist
of
everything
that
you've
done.
L
You
know
as
a
continued
process
and
what
the
s-bomb
outputs
of
of
scans-
and
you
know
how
you're
meeting
the
needs
you
know
at
least
of
the
salsa
framework
endo
or
whatever
the
sla
is.
You
promise
your
clients
is
really
the
only
way
you
can
go,
but
it's
all
about
transparency
right,
I
mean
from
that
perspective,
it's
having
strong
governance
and
making
that
transparent
to
the
the
end
user.
A
Yeah
one,
I
think,
with
this
issue,
it
sounds
like
there's
two
related
things
here.
One
is
the
notion
of
like
the
transitive
level,
which,
right
now
we
haven't
really
defined.
There's
been
some
discussion
in
the.
If
someone
could
add
it
to
the
notes,
the
verification
summary
that
tom
hennen
started.
I
know
there's
a
there's,
a
lot
of
discussion
there.
A
It
seems
kind
of
similar
there
because
you
could
say
like
the
distro
provided
this
process,
but
one
of
its
dependencies
was
this
input
which
itself
has
its
own
set
of
you
know.
D
A
Its
own
provenance,
and
maybe
its
own
salsa
level,
and
I
think
better,
defining
that,
like
what
was
mentioned
in
the
thread
and
at
a
previous
meeting
was
like
when
we
say
the
source:
do
we
make
the
chain
all
the
way
back
to
the
upstream
repo,
or
does
it
just
go
back
to
the
distros
I'll
call
it
a
fork
for
lack
of
a
better
word,
although
that's
maybe
not
the
best
word
for
it,
which
you
know
pulls
in
some
distro
specific
patches
and
the
upstream,
or
does
it
go
all
the
way
back
to
upstream,
like
what
is
the
model?
A
That's
one
thing:
if
anyone
wants
to
do
that
and
submit
a
pull
request
or
or
I'm
happy
to
talk
about
that,
if
you
want
to
bounce
ideas
off
of,
I
think
better,
defining
that
model
would
be
good
to
me
at
least
my
mind:
either
is
okay
as
long
as
we
define
it,
one
one
other
topic
that
I
think
is
related,
although
I
don't
know
if
we
want
to
get
into
that
now
is
source
packages,
because
many
linux
distributions
actually
not
just
link
substitutions
language
distribution
as
well
like
python
and
go
you
start
with
the
actual
source
of
truth
is
like
a
git
repo,
and
then
you
upload
that
to
a
effective
like
a
tar,
ball
or
a
zip
or
something
and
that's
a
source
package,
and
then
you
build
from
that
and
like
do
we
trace
back
just
to
the
tarball
or
do
we
go
all
the
way
back
to
the
get
repo?
D
Yeah
yeah,
so
I
think
you
you
hit
on
the
vast
majority
of
my
thoughts
yeah,
I
think
for
from
like
an
end
user
perspective.
The
main
thing
I
just
want
to
know
is
like
from
a
transparency
sense
like
what
am
I
actually
like?
What
are
you
actually
attesting
to?
Are
you
attesting
that
I
own
this
code?
Are
you
attesting
I
just
own
this
package?
Are
you
attesting
that
I
own
the
package
plus
the
patches,
and
I
know
in
certain
you
know
certain
companies
are
saying:
hey,
look.
You
hire
us
we'll.
D
We
are
saying
we
will
completely
support
all
the
source
code,
even
the
what's
the
stuff
we
didn't
write,
so
there's
lots
of
different
stuff
there,
and
I
think
we
just
need
to
figure
out
a
way
to
adequately
and
accurately
communicate
that
information
so
that
as
an
end
user,
when
I'm
pulling
that
down,
I
pull
down
that
sauce
at
a
station.
I
just
might
want
to
know
hey.
What
are
you
attesting
to?
Are
you
purely
attesting
to
the
fact
that
yep
I
ran
the
build?
That's
it
I'm
not
attesting
to
that.
D
That
you
know
whether
or
not
any
of
the
actors
who
committed
the
code
and
whatever
I'm
not
attesting
to
whether
or
not
they're
trustworthy
whatsoever
that
I
know
anything
about
them.
You
know,
I
think,
just
having
that
information
is
gonna,
be
or
having
a
way
to
communicate
that
information
is
going
to
be
really
valuable.
B
I
could
be
easily
talked
out
out
of
it,
but
I
I
at
least
what
was
just
said
makes
sense
to
me
because
there's
so
many
variants
if
we
can
at
least
identify
the
options
capture
that
and
record
this
salsa
station
covers
you
know,
step
a
to
step
b
and
clearly
defining
what
step
a
and
b
are
the
other
option.
A
In
terms
of
like
concrete
next
steps,
if
anyone
wants
to
volunteer,
I
think
the
I.
I
have
a
pull
request
that
I'm
I
started
and
I
plan
on
pushing.
I
didn't
get
to
do
in
time
before
this
meeting
that
I
worked
with
joshua
to
better
define
the
build
model,
he
started
pull
requests
and
I
also
added
to
it.
I
think.
Similarly,
if
we
define
the
source
model
in
terminology,
we
could,
I
think
it's
probably
worth
saying
something
of
like
you:
go
you
build
directly
from
a
repo
where
you
build
it.
A
Does
it
get
repo
and
then
some
sort
of
mirror
or
fork
or
whatever
that
adds
in
patches,
and
then
you
build
from
that
or
you
build
that
to
a
source
package
of
that
and
just
define
these
terms.
So
at
least
people
understand,
even
without
making
a
decision
of
what
is
or
isn't
canonical.
At
least
we
have
a
that'll,
be
a
good
step
in
the
right
direction.
B
I
I
I
you
might
be
able
to
do
this
in
like
just
a
page
or
two
of
like
a
picture
of
you
know,
hear
each
of
the
steps
label
each
part,
and
you
know
some
parts
may
not
apply
to
a
particular
circumstance.
But
you
know:
here's
the.
If
you
have
every
single
plausible
part
and
name
each
part,
then,
and
then
we
can
say
hey
this
particular
salsa
claim
starts
here,
ends
here
and
then,
if
it
turns
out,
everybody
always
only
makes
the
same
one.
Then
we
can
be
more.
B
We
can
reduce
the
flexibility,
but
no
matter
what,
even
if
we
wanted
to
name
a
particular
thing.
We
would
first
have
to
answer
that
question
that
mark
just
raised,
which
is
the
terminology,
so
that
that
sounds
like
a
useful
way
to
get
forward,
making
that
little
little
diagram.
A
A
Yeah,
the
again
it's
in
the
notes,
it's
issue
235,
so
yeah.
A
Okay,
we're
almost
out
of
time
any
other
topics
before
we
go
or
she,
I
guess
we're
actually,
basically,
out
of
time
now,
yeah.
A
A
I
was
not
planning
to
do.
I
have
other
things
on
my
queue
before
then.
So
if
anyone
wants
to
go
right
ahead
and
if
I
ever
get
around
to
it
I'll
post
something
saying
I'm
starting
it,
I
recommend
anyone
who's
starting
to
work
on
it.
Maybe
just
post
a
note,
saying:
hey,
I'm
starting
to
do
this
that
way,
others
who
want
to
reach
out
and
collaborate
can
that's
probably
a
good
process
in
general
for
any
issue.
If
you're
going
to
spend
significant
time
on
it,
okay,
fair
enough.