►
From YouTube: SSCS Bi-Weekly Meeting - 2022-04-14
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
So
I
just
have
two
items
to
discuss:
they're
really
more,
like
updates,
there's
less
of
a
discussion
that
we
have
to
have
about
them
once
you
have
questions
or
comments,
but
the
first
one
is
so
we
created
the
high
level
direction
page
for
software
supply
chain
security.
A
Really,
the
next
step,
as
I
see
it,
is
to
take
that
and
produce
a
more
practical
and
tactical
road
map
of
where
we're
at
I
know,
at
least
david
has
shown
some
interest
in
getting
status
updates
as
to
how
we're
progressing
on
all
of
this.
A
So
I
went
ahead
and
updated
the
description
of
that
epic,
so
this
is
meant
to
be
the
place
to
track
what
we're
actually
doing
in
the
more
near
term
versus
the
direction
which
is
super
long
term.
It
covers
just
our
high
level
vision
and
probably
is
like
three
years
out
for
gitlab
to
achieve
everything
that
we
talk
about,
if
not
more
than
three
years
on
the
direction
page,
so
any
feedback
that
you
have
on
this
is
welcome.
A
Of
course,
we
don't
have
any
dedicated
software
supply
chain
security
developers,
so
I
am
at
the
mercy
of
the
other
pms
in
the
company
to
prioritize
these
things
and
if
they
don't
prioritize
them,
that's
completely
understandable
because
they
have
a
lot
of
other
things
to
worry
about.
Besides
just
software
supply
chain
security,
but
this
way
we
can
at
least
track
it
and
prioritize
it
from
the
lens
of
software
for
supply
chain
security.
B
Yeah,
I
I
mean
I've,
I've
been
out
and
haven't
been
able
to
track
progress
on
this
stuff
for
the
past
couple
weeks,
but
I
was
impressed
to
see
that
the
it
looks
like
the
adding
the
software
attestations
to
enable
salsa
level.
2
is
already
like
scheduled
for
15
1..
So
I
was
impressed
to
see
that.
A
A
A
So
yeah,
if
you
have
thoughts
on
that,
it's
welcome.
If
you
know
of
other
items
that
would
be
good
candidates
for
that
epic,
please
feel
free
to
reach
out
to
me
or
if
you
see
things
that
you
feel
are
misprioritized
some
of
the
lower
items.
I
didn't
worry
too
much
about
the
priority,
but
hopefully
we
have
the
right
priority,
at
least
for
the
top
five.
A
So
my
only
other
comment
is
that
I've
been
attending
the
salsa
working
group
with
the
open,
ssf
and
participating
in
some
of
those
discussions.
Marshall
I
know.
Originally
we
had
the
question
around
service
generated.
A
Does
that
mean
that
the
get
lab
runner
itself
has
to
generate
it,
or
does
that
mean
that
it
just
has
to
be
scripted
up,
so
that
has
actually
gone
through
some
extensive
discussion
in
that
working
group
lately
and
the
consensus
is
that
the
original
intent
of
that
requirement
was
just
that
it
was
scripted.
Essentially,
you
know
they
described
it
as
salsa
level,
one
they
envisioned
someone
just
opening
up
a
text
editor
and
creating
the
attestation
manually,
whereas
also
level
two.
A
You
know,
reviews
and
approvals
of
source
code
and
then
step
three
was
non-falsifiable
which
starts
to
get
into.
You
know
better
management
of
all
of
the
secrets.
So
that
was
the
intention,
but
they,
the
group,
also
agreed
with
your
take
on
that
role,
which
is
that
as
it
is
written
currently,
it
does
sound
an
awful
lot
like
the
get
lab.
Runner
itself
actually
has
to
generate
that,
and
that
was
not
the
intention,
though
they're
planning
to
re
do
a
revision
and
just
a
rewording
to
make
all
of
that
a
whole
lot
more
clear.
A
We
talked
about
potentially
moving
that
level
of
scrutiny
just
like
salsa
level,
four
anyway,
so
that's
all
being
discussed
very
actively
there.
I
think,
regardless
of
what
salsa
level
it
lands
in,
we
should
still
move
forward
with
having
the
runner
generate
the
attestation,
because,
in
my
opinion,
that's
probably
the
most
secure
way
it
could
be
generated.
A
So
I
don't
know
that
it
affects
our
development
plans
very
much,
but
if
they
do
come
out
with
a
revision,
it
will
impact
our
marketing
because
it
will
make
it
much
easier
for
us
to
claim
support
for
salsa
level
2
and
if
we
can
get
our
integration
with
vault
worked
out.
Hopefully
we
can
even
claim
salsa
level
three
support
soon,
as
well.
B
Yeah,
I
I
agree
with
you
that
I
don't
think
it
would
change
our
priorities
because,
ultimately,
like
it
doesn't
matter
what
level
it
is,
we've
got
to
get
there
anyway
and
also
like
just
in
general.
I
don't
think
that
there's
nothing
to
productize
unless
we
bake
the
functionality
into
the
tool.
You
know
what
I
mean
so,
like
users
being
able
to
achieve
salsa
level
two
without
us
doing
any
like.
We
only
provide
convenience
and
we
only
like
provide
any
real
functionality
by
making
it
service
generated,
so
there's
nothing
to
build
if
otherwise,
right.
C
Yeah
one
thing
is:
I
looked
at
that
discussion
on
github
and
it
seems
that
the
thing
that
they
are
concerned
with
is
not
the
implementation.
C
So
the
the
thing
is
the
thing
that
we
the
requirement
here:
it's
not
implementation
dependent.
It's
just
that
we
need
to
be
able
to
make
it
so
that
the
project
maintainers
can't
sign
anything
besides
the
actual
artifacts
that
they're
going
to
be
shipping-
and
the
thing
is-
is
even
if
we
have
the
runner
generate
these
artifacts.
C
We
kind
of
the
thing
is
you
can
self-host
runners,
so
it's
possible
that
a
maintainer
can
set
up
their
own
runner
and
they
might
be
able
to
get
the
secret
out
of
runner
and
they
might
be
using
the
same
thing.
So,
even
if
we
do
that
with
the
runner
producing
artifacts,
it's
possible
that
it
still
might
not
be
as
a
level
three.
C
So
we
have
to
be
careful
about
that.
I
think
there
was
a
blog
post
about
how
github
implemented
this
recently
and
I
think
what
they
they
had,
a
requirement
that
you
could
only
use,
github
hosted
runners
to
do
it.
I
believe,
and
so
that
way,
github
the
the
github
system.
Administrators,
basically
are
the
only
ones
that
have
access
to
the
infrastructure,
not
the
general
end.
Users.
B
Yeah,
I
think
the
the
one
of
the
biggest
innovations
that
six
store
has
brought
to
the
table
here
is
the
like
keyless
signing
mechanism
that
like
folkio,
provides,
and
I
think
that,
whether
you're,
whether
your
runners
are
self-hosted
or
or
not
us
either
just
hooking
into
the
public
folky
o
instance,
or
running
an
instance
of
folkio
as
part
of
all
gitlab
installations,
is
a
convenient
way
around
all
of
that
right,
because
then
you
have
this
like.
B
Like
sort
of
like
decentralized,
zero
trust
system,
where
the
runner's
just
exchanging
the
jbt
that
it
got
from
git
lab
with
the
focio
instance
to
get
a
temporary
key,
that
it
can
sign,
artifacts
with
and
and
then
like,
we
still
sort
of
retain
control
over
the
system.
That's
generating
those
temporary
signing
keys
and-
and
we
would
be
able
to
not
issue
keys
to
things
that
don't
have
like
a
a
token
right,
like
you'd,
have
to
have
that
signed.
Jbt
as
well.
So
yeah.
A
Yep,
that
makes
sense
I
so
I
agree,
I
think,
that's
the
right
direction
to
head
from
a
marketing
perspective.
I
do
hope
that
they
revamp
these
requirements,
because
I
think
it
will
make
it
easier
for
us
to
market
this
in
the
near
term,
but
if
we
can
keep
building
towards
that
end
solution,
that's
also
going
to
give
us
some
competitive
differentiators
in
the
long
term
as
well.
C
C
B
And
so
help
me
understand
the
the
problem
you're
you're,
trying
to
solve
there
because,
like
I,
I
think
if,
if,
if
we're
all
in
agreement
that
like
we're
going
to
instrument
the
runner
to
do
this,
then
I
I
I
don't
think
that's
necessary
right
because
like
if,
if
the
runner
is
just
gonna
sign
all
the
artifacts
that
it
uploads,
then
it's
it's
happening
outside
the
execution
context.
Anyway,
right.
A
C
Right,
well,
let
me
let
me
just
clarify,
I'm
not
saying
I
don't
think
we
need
to
go
with
the
with
having
like
an
immutable,
cr
job.
I
I'm
just
suggesting
a
possible
different
implementation
that
we
might
be
able
to
do
that
might
possibly
be
easier
than
having
a
runner.
Do
it,
I'm
not
sure
if
it's
the
best
approach,
but
you
know
I'm
just
putting
the
idea
out
there.
A
Yeah,
I
mean
marshall-
I
don't
think
that's
going
to
be
completed
in
15-1.
That
milestone
is
usually
when
development
starts,
and
I
I
think
your
hope
for
what
all
might
be
done
by
15.
One
is
maybe
not
your
expectations
aren't
quite
right,
because
you
know
you're
talking
about
handling
the
signing
through
folkyo.
I
don't
think.
That's
all
included
in
that.
What
we're
talking
about
for
15
1
is
just
an
iterative
step
towards
that
of
having
the
runner
generate
that
metadata.
A
A
A
So
you
know
we
we
do
still
want
to
like
market
and
talk
about
our
software
supply
chain
security
between
now
and
then,
which
is
why
I
was
suggesting.
Well,
maybe
we
talk
about
compliance
pipelines
as
a
way
to
create
it's,
not
an
immutable
ci
job,
but
it's
a
restricted
access,
ci
job,
because
somebody
can
still
configure
it,
but
it
takes
that
control
away
from
the
maintainers
of
the
project.
A
Of
it's
just
those
are
I'm
talking
about
a
marketing
effort,
not
an
engineering
effort,
because
those
are
you
know
just
looking
at
what
we
have
today
right.
We
already
have
compliance
pipelines
if
that
can
help
us
in
some
way,
from
a
marketing
perspective
like
let's
use
that
and
talk
about
it.
Now,
that's
what
I'm
suggesting
sure
I'm
not
suggesting
that
we
give
our
engineering
resources
to
it.
A
B
B
A
A
A
C
I
think
I
think
that's
maybe
for
compliance
pipelines.
I
don't
remember
how
exactly
they
work,
because
you
know
that's
not
usually
something
I
work
on,
but
it
might
be
able
to
fulfill
the
requirement
if
we.
A
C
Right:
okay,
yeah.
I
remember
now
that
that
wouldn't
work,
because
the
the
compliance
pipeline
itself
is
edited
is
editable
by
you
know.
Whoever
owns
the
compliance
policy
project
right,
yeah.
C
A
C
C
A
Yeah
for
sure,
all
right,
so
we'll
probably
not
bother
with
marketing
this.
For
now,
I
guess
was
an
interesting
idea,
though,
thanks
for
bringing
that
up.
A
All
right
anything
else
that
either
of
you
would
like
to
discuss
today.