►
From YouTube: Security Tooling Working Group (February 17, 2023)
B
B
B
One
was
supposed
to
go
to
the
Amia
one,
but
I
got
sick,
so
I
wasn't
able
to
attend
that
once
I'm
going
to
be
attending
the
one
that
I
believe
is
next
week
and
kind
of
go
over
just
just
some
general
thoughts
there
and
that's
kind
of
where
we're
kind
of
gonna
be
going
for
anybody.
Who's
joining
no
feel
free
to
edger
attention
to
meeting
list
so
that
that's
really
about
it
and
then
open
it
up
to
everybody
else.
For
for
other
topics,
Eric.
C
B
B
D
E
C
C
Happens,
yeah
so
thinking
about
this
a
little
bit
and
some
of
the
work
being
done,
you
know
all
of
the
variant
tools
that
this
group
talks
about.
Has
there
been
any
thought,
maybe
and
I
the
last
couple
meetings
I
think
there
wasn't
enough
people
that
showed
up
to
to
have
the
meeting.
It's
like
myself
and
a
couple
other
people
without
really
a
clear
agenda,
but
you
know
kind
of
moving
forward.
C
Have
you
thought
at
all
about
like
the
frsca
project,
that's
going
on
in
open,
ssf
and
maybe
doing
some
potential
merging
of
of
you
know
these
tools
with
that
project
as
well
thinking
about
a
broader
sdlc
type
of
salsa
implementation,
because
they're
doing
some
of
the
the
framework,
but
not
all
of
it,
to
pull
together
a
number
of
artifacts,
specific
components
like
signing
and
visibility,
some
identity
components,
but
certainly
not
all
the
way
across
the
board.
But
it
seems,
like
a
good
conversation,
point
to
really
be
driving
home.
C
Some
of
you
know
the
The
Core
specs
and
some
common
specifications
to
make
this
more
functionally
capable
for
people.
I,
don't
know.
If
maybe
this
group,
you
know
being
a
tooling
group
and
this
being
a
tool,
something
that's
trying
to
bring
together
some
of
these
components,
maybe
it's
worth
having
that
broader
conversation.
B
Yeah
so
I
I'm
also
a
maintainer
on
the
Fresca
project.
That's
definitely
something
that
we'd
be
interested
in
exploring
further
I.
Think
there's
just
some
practical
elements
of
just
Fresca
right
now
is
is
mostly
myself
and
like
maybe
a
couple
other
folks
who
are
working
on
it.
Some
of
the
original
sort
of
maintainers
had
got
pulled
into
other
projects,
but
if
we
did
get,
you
know
some
folks
who
could
sort
of
contribute
back.
B
Some
folks
have
been
talking
about
yeah
like
what
could
openssf
do
to
sort
of
say,
here's
how
you
secure,
let's
say
Dev
using
something
like
Fresca
or
some
of
these
other
tools.
This
is
how
you
would
secure
build,
and
then
this
is
how
you
would
secure
you
know
ending
up
in
production
or
something
like
that
that
that's
definitely
something
that
that
a
few
you
folks
have
brought
up
recently
and
and
are
very
interested
in
so
I
definitely
would
be
interested
in
that
yeah
I.
B
C
And
I
think
from
you
know:
I
brought
this
up
an
open
ssf
about
a
year
ago.
As
the
you
know,
a
lot
of
the
discussion
around
design
and
schemas
and-
and
you
know,
process
is
great,
but
for
a
lot
of
the
end
users,
people
who
actually
need
to
implement
something
more
secure,
rather
than
build
just
technology
projects
by
themselves.
C
These
are
all
impressive
projects
right,
but
you
know
you're
going
to
have
to
integrate
a
number
of
them
to
make
it
an
effective,
secure
development
environment
so
yeah,
if
you're
going
to
have
those
conversations
and
that
continuous,
please
include
me
on
those
I
think
more
adoption
and
more
more
contributors
will
show
up
if
there's
an
end
user
goal
to
some
of
this
in
an
integration
point.
So.
B
Yeah
yeah
definitely
yeah.
A
few
folks
had
had
brought
up
also
of
not
necessarily
making
Fresca
the
Sterling
tool
chain,
but
making
Fresca
sort
of
like
you
know,
for
folks
who
are
not
super
familiar
with
Fresca
right.
The
idea
behind
Fresco
was
it
was
a
set
of
tools
combined
together,
like
tecton
tecton
chains,
spiffy,
spire
and
and
so
on
and
combined
in
a
way
and
configured
in
a
way
to
turn
it
into
a
secure,
build
system
that
implements
all
of
the
salsa
stuff.
It
also
implements
some
of
the
cncf
best.
B
You
know
supply
chain
security,
best
practices-
it
does.
You
know
it
does
score
a
card,
it
does
All
Star
it
does.
All
the
you
know
tries
to
hit
all
the
the
the
things
both
from
the
perspective
of
as
a
project.
Is
it
doing
all
the
right
things
to
secure
its
supply
chain
to
secure
development
and
then,
in
addition
to
that,
as
a
build
tool,
does
it
help
others
do
similar
things,
and
so
that
so
so?
That
sort
of
thing
seems
to
be.
B
That
goal
is
an
important
one
that
a
lot
of
folks
have
brought
up
as
stuff
that
they
want
to
see
more
of
is
they
want
to
see
more
like
hey?
If
Fresca
is
a
build
tool,
can
we
also
get
a
development
tool
or-
or
you
know,
a
linting
tool,
an
SCA
tool,
that's
open
source
that
you
know
you
can
imagine
hey
when
I
go
to
push
my
code.
This
is
what
that
flow.
B
Should
look
like
to
make
sure
that
you
know
Bad
actors
can't
push
to
our
git
repo
or
whatever,
and
is
there
a
way
to
sort
of
line
everything
up
such
that
it
you
know
with
as
as
much
automation
as
possible?
You
know
somebody
could
get
at
least
get
a
POC
of
a
secure,
end-to-end
sdlc
up
and
running
in.
You
know,
minutes
as
opposed
to
you
know,
tons
of
tons
of
effort
there,
oh
sure
yeah,
so
the
the
Fresca
meeting
meets
every
other
Wednesday
and
I.
B
They
voted
on
making
that
the
priority
for
2023,
but
then,
as
far
as
what
that
you
know,
what
that
actually
looks
like
I
believe
is
still
being
debated.
I'm
trying
to
also
myself
find
out
like
are
these
mostly
closed
meetings
between
the
attack
and
the
governing
board,
or
these
opening
open
meetings,
I,
I,
I'm,
not
sure
yet
and
I'll.
When
I
find
out
more
information,
I'll
post
it
in
Slack.
D
B
So
the
unlike,
let's
say
the
cncf,
where
the
cncf
is
very
particular
about
not
naming
names
for
of
tools
because
they
don't
want
to
pick.
They
don't
want
to
be
king
maker.
They
don't
want
to
pick
winners,
which
makes
sense
right.
You
know,
you
know
these
are
all
open
source
tools
and
some
of
them
compete
with
each
other.
You
don't
want
to
pick
winners.
B
B
So
as
an
example,
this
is
just
like
think
of
it
as
an
end-to-end.
Secure,
sdlc
flow.
So
you
know
just
imagine
you
know:
here's
how
we
are
protecting.
Let's
say
you
know,
developer
endpoints,
here's
how
you
protect
this
this
and
this,
but
then
here
are
the
tools
configured
in
a
way
with
some
baselines
that
folks
could
just
sort
of
deploy
this
now
once
again,
most
likely
your
average
company's
not
going
to
be
able
to
just
sort
of
pick
up
the
tool
and
just
be
like.
Oh
I
can
just
start
using
it.
B
You
pick
up
that
tool
chain
and
just
immediately
start
using
it
right,
because
everybody's
going
to
say
well,
hey
the
Sterling
tool
chain
uses,
you
know,
let's
say
Fresca
as
its
build
system,
but
I'm
very
deep
into
Jenkins.
I
can't
use
that
so
there's
still
going
to
be
areas
where
folks
are
going
to
need
to
plug
in
their
own
stuff
create
Integrations.
B
How
do
you
configure
the
tools
to
essentially
enforce
that
at
the
dev
level,
at
the
build
level
and
at
the
production
level
right
where
you
say?
Okay,
great,
we
can't
run
this
tool
or
we
can't
run
this
thing.
What
sorts
of
stuff
can
you
do
there,
and
so
that's
kind
of
you
know
if
you
take
sort
of
the
Fresca,
you
know
the
the
high
level
vision
of
Fresca
right
is.
B
Obviously
that
comes
with
a
lot
of
caveats,
because
once
you
start
including
you
know,
once
you
start
tying
together,
you
know
a
handful
of
tools.
It
becomes
a
Rat's
Nest,
but
that
at
least
is
is
the
goal
of
of
this
Sterling
tool
chain.
That's
about
as
much
as
I
know
about
it.
I've
been
talking
to
Brian
a
little
bit
on
it.
B
Anyway,
that's
that's
the
Sterling
tool
chain
in
a
nutshell,
the
way
that
salsa
probably
fits
into
it
is,
as
you
can
probably
imagine
like.
Okay,
hey,
we
have
salsa,
so
a
sterling
tool
chain
would
probably
say
well
when
you
get
to
the
build
piece
like
source
source
to
artifact,
you
say:
okay,
well,
whatever
is
happening
in
here
needs
to
be
salsa
compliant,
and
then
you
probably
would
also
say
well.
Dev
tools
might
say
what
I
go
to
do.
B
Ingestion,
let's
say,
pull
down
a
dependency,
for
example
from
npm
you
might
say:
well,
we've
configured,
we
have
a
global
npm
config
that
we
give
all
of
our
developers
that
states
that
you
know
this
must
be.
You
know
the
salsa
config.
You
know
like
the
the
salsa
things
that
we're
looking
for,
like
you
know,
we're
only
picking.
B
You
know,
I'm
just
saying
like
identities
from
these
folks
or
whatever,
right
and-
and
you
know,
when
we
pull
down
s-bombs
and
yeah
yeah,
and
then,
when
it
comes
to
the
build
okay
cool
you
know,
are
we
building
via
Fresco
when
we
pull
independencies?
Do
those
dependencies?
Also,
have
you
know,
salsa
attestations
or
something
like
that
right
where
somebody
can
sort
of
configure
that
policy
and
then,
when
it
comes
to
something
like
a
production
thing,
you
know
for
folks
who
are
familiar
with,
let's
say:
Google's,
binary
authorization
concept.
B
You
know,
for
you
know,
from
an
admission
control
perspective,
whether
that
emission
control
is
purely
you
know
in
kubernetes
or
just
more
generically.
You
know
some
sort
of
gating
mechanism
that
also
validates
like
does
this
thing
have
salsa
provenance
that
meets
our
policy
or
whatever,
before
we
kind
of
let
it
go
into
production
so
that
that's
kind
of
where,
where
some
of
the
salsa
and
salsa
tooling
stuff
would
come
into
play
as
well.
B
C
B
B
Yeah,
so
this
was
the
slides
when
it
was
voted
on.
It
wasn't
called
Sterling
tool
chain
when
that
happened,
but
the
I,
but
from
I
guess
slide
two
there,
where
it
says
overarching
reference
architecture
that
brings
together
existing
efforts
to
Define
our
North
Star
and
derivative
reference
architectures.
That
could
be
implemented
right,
so
they're
they're,
actually
gonna
they're,
calling
it
not
reference
architecture,
because
that's
a
loaded
term
they're
calling
it
like
a
most
likely
demonstrative
architecture,
or
example,
architecture,
but
the
the
idea.
B
Those
sort
of
three
bullet
points
on
slide.
Two
are
the
ones
that
sort
of
then
became.
Oh.
This
sounds
like
we
should
create
a
sterling
tool
chain
like
a
set
of
documents,
that
sort
of
Define
what
should
be
happening
and
then
actual
sort
of
like
these
are
the
tools
that
fit
the
that
those
needs,
and
then
here
are
ways
that
those
tools
could
be
strung
together
with,
like
a
glue
code
to
make
sure
that
they
could
all
be
sort
of
managed.
B
You
know
collectively
right
because,
like
the
the
big
I
think
the
biggest
issue
that
has
happened
in
the
past,
which
is
one
of
the
reasons
why
Fresca
some
folks
have
been
looking
at
Fresca,
is
like
hey
spiffy
Spire
is
actually
not
the
easiest
thing
to
configure
and
and
get
set
up
with
everything,
but
Fresca
has
configured
it
almost
as
if
it's
one
particular
like
it's
all
inclusive
of
of
the
whole
picture.
Now,
once
again,
if
you
were
to
say,
hey
could
I
integrate
Fresco
with
my
existing
spiffy
Spire.
B
That's
actually
a
whole
set
of
things
that
that
might
make
it
a
lot
more
complicated,
but
the
basic
idea
there
being
like
you
can
imagine
right,
hey
my
Dev
tools
should
still
follow
the
same
policy
that
my
build
tools
are
following
should
still
follow
the
same
policy
that
my
production
gating
follows
right.
You
know
if
I
don't
allow
once
again,
if
I
don't
allow
go,
my
Dev
tool
should
prevent
me
from
installing
go.
B
Let's
say
my
build
tool
should
prevent
me
from
building,
or
you
know,
depending
on
Go
stuff,
and
my
my
production
authorization
should
say
hey.
No.
This
is
a
Go
app
I'm,
not
gonna.
You
know,
I'm,
not
gonna.
You
know
deploy
that,
and
so
that's
kind
of
where,
where
at
least
like
this
high
level
goal
of
what
that
would
look
like
now.
B
B
E
E
Policy
quotes
for
salsa,
and
it
looks
like
the
handful
people
that
I
showed
it
to
well.
They
they
think
it's
okay,
and
so
my
next
step
would
be
to
implement
something
to
prototype,
something
that
so
this
is
for.
Npm
ecosystem
is
to
prototype
something
that
wraps
around
the
existing
tools
that
doesn't,
after
the
fact
check,
yeah
dots,
whatever
is
being
installed
that
it
meets
some.
Some
sanity
policy
checks
implementing
it
as
a
enforcement
thing
that
says
I'm
not
going
to
install
this.
That
would
require
a
lot
of
integration
with
npm.
B
B
Yeah
yeah,
no
yeah,
no
problem,
yeah
and
definitely
interested
in
in
that
and
I
know
that
there's
some
folks
who
are
who
are
pushing
a
lot
of
the
there's
still
some
open
questions.
Oh
yeah
there's
still
some
open
questions
about
also
from
like,
like
how
much
of
of
stuff
can
actually
be
verified
by
some
of
the
tooling,
which
is
an
interesting
question
because,
like
obviously
closed
Source
stuff,
it's
going
to
be
a
little
bit
harder
to,
let's
say
verify
compared
to
open
source.
A
E
A
Yeah
we
are
going
along
pretty
good
with
that
I
don't
think
I
can
share
in
a
date
but
fingers
crossed.
We
will
see
it
soon.
Maybe
one
thing
that
might
be
related
to
this
I'm,
not
sure,
but
a
lot
of
you
might
be
aware
of
six
door
and
in
particular
fulsio,
which
is
a
certificate
Authority
that
currently
you
can
integrate
via
some
identity
providers
and
me
coming
from
GitHub.
It's
really
amazing
that
it's
integrated
with
GitHub
actions,
the
workload
identities
we
can
issue
and
some
other
providers
are
coming
along.
A
I
think
build
kite
is
integrated
with
fullsill
now
gitlab
is
definitely
trying
to
get
on
board
and
I.
Think.
The
same
is
true
for
Server
CI,
but
as
part
of
that,
we're
also
looking
into
standardizing
the
claims
that
goes
into
the
certificate
and
the
existing
one
are
kind
of
tailored
towards
the
claims
that
GitHub
actions
exposed
in
the
workload
identity,
but
that
obviously
doesn't
work
for
other
CI
providers
as
well.
So
that
is
pretty
interesting.
A
Work
and
I
think
it's
ready
to
emerged
pretty
soon
and
it
kinda
touches
base
a
little
bit
with
salsa
in
terms
of
like
capturing
build
signer,
Uris
and
Source
configurize
Etc.
So
if
you
are
building
on
a
CI
system,
that's
integrated
with
fools
here
we'll
you
will
get
a
lot
of
related
salsa
problems,
information
in
the
certificate
that
most
likely
will
not
be
forcible
because
it's
coming
or
it's
extracted
from
the
sign
workload,
identity
from
the
ca
provider
and
then
Force.
You
extracts
them
and
inserts
them
as
extensions
into
into
the
certificate.
A
So
everyone
should
have
access
to
it,
but
I'm
not
going
to
take
any
credit
of
it
like
sure,
I've
been
involved
in
it,
but
I
think
it's
relevant
for
this
group
as
well.
If
folks
are
and
building
on
six
store
and
trying
to
do
salsa,
but
they
are
advice
from
npm
yeah
we're
we're
crunching
and
hopefully
we
have
something
to
announce
pretty
soon.
A
B
Yeah
I
know
one
of
the
things
that
that
also
it's
been
brought
up
potentially
and
something
that
we
want
to
talk
to
the
full
CEO
folks
about
is,
for
example,
with
Fresca.
Some
folks
have
said:
hey
if
openssf
spun
up,
let's
say
a
a
build
service,
that's
purely
for
like
some
open
source
projects
within
the
openssf.
B
A
B
What
else
I
will
say
also
some
of
the
stuff
from
the
Fresca
side
is,
is
mostly
hung
up
on
the
tecton
and
tecton
chains.
Folks,
integrating
a
few
pieces.
The
spiffy
spirework,
which
has
been
sort
of
done
now
for
a
little
over
a
year,
is
still
waiting
to
get
merged
because
of
mostly
just
internal
open
source
politics
so
yeah.
If
there's
nothing
else,
we
can
probably
end
it.