►
From YouTube: Kubernetes SIG Security Tooling 20210921
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
B
I
guess
I
can
introduce
myself
I
I
know
I've
been
to
a
few
of
these,
but
I
can't
remember
if
I
ever
formally
introduced
myself,
so
my
name
is
wes
panther.
I
work
at
google
on
gk
security,
so
I'm
primarily
focused
on
patching
patching
base
images,
container
image
security.
That
kind
of
thing
so
happy
to
be
here.
A
Hey
great
to
be
here
great
to
have
you,
we've
interacted
a
bit
in
the
past
glad
to
see
you
and
hope
you
enjoyed
the
session
today.
A
Okay,
I
think
we
can
get
started
if
people
trickle
in
that's
fine.
We
have
recording
on,
we
have
live
transcript
on
and
we
are
under
the
code
of
conduct
for
cncf
and
kubernetes.
So
take
it
away.
We
have
until
9
15
so
about
40
minutes
more.
C
A
C
So
well,
first
of
all,
thank
you
for
for
having
me
and
inviting
me
to
to
chat
about
this
effort.
My
name
is
saludo.
Garcia,
usually
go
as
puerto
and
most
everywhere-
and
I
am
one
of
the
tech
leads
with
siege
release
for
the
release.
C
Engineering
soft,
so
pj
asked
me
to
come
and
speak
a
little
bit
about
the
bill
of
materials
that
we
are
currently
producing
for
kubernetes,
and
I
thought
it
was
important
that
to
frame
it
in
a
little
bit
bigger
context
that
we're
trying
to
to
to
push
so
what
I'm
going
to
show
you
right
now
is
like,
like
a
sneak
pick
up
the
the
two
talks
that
we
are
going
to
have
on
in
kubecon
around
this,
these
efforts,
which
basically
involve
how
to
try
to
improve
the
the
supply
security
for
kubernetes,
specifically
in
the
release
process
that
we
run
to
cut
each
of
the
releases.
C
So
so
the
first
thing
I
wanted
to
talk
is
super
quick
introduction
to
this
salsa
framework
that
probably
some
of
you
have
heard
of
it.
So,
first
of
all,
disclaimer-
I
am
my
background-
is
more
of
a
programmer
and
I'm
trying
to
incorporate
and
learn
of
all
these
efforts
as
we
are
going.
So.
C
This
is
why
it
is
a
primary
interest
of
me
to
come
here
and
chat
with
about
these
topics
with
you,
because,
probably
among
you,
there
are
more
people
which
are
much
more
knowledgeable,
not
knowledgeable
about
this.
These
topics
than
me,
but
just
wanted
to
give
a
like
a
super,
quick
introduction
to
salsa
and
how
and
why
we
are
trying
to
frame
our
efforts
around
it.
C
So
the
first
one
is
that
salsa
is
a
framework
that
allows
organizations
to
assess
their
release
their
their
supply
chain
and
release
processes
in
a
in
a
in
a
framework
to
assess
how
secure
they
are
it.
It
offers
several
levels
of
of
of
compliance
with,
obviously
for
being
the
more
the
most
secure
of
them,
and
so
this
is
like
a
the
the
we
are,
since
we
are
going
to
try
to
give
an
update
on
how
we
are
compliance-wise
with
salsa,
with
our
release
processes
at
kubecon.
A
Okay,
but
also
should
we
ask
questions
in
between
or
we
want
to
wait
for
the
end
yeah
if
you
want,
of
course,
okay.
So
maybe
one
question
for
folks
who
are
new
to
salsa,
how
does
it
well
like
what
does
it
stand
for
and
how
does
it
kind
of
place
itself
in
the
whole
linux
foundation?
Cncf
is
its
part
of
it
or
is
it
a
different
entity?
A
C
It's
a,
I
think,
it's
a
different
entity.
I
think
it
was
first
proposed
by
by
google
and
then
a
little
bit
formalized
and
then
the
linux
foundation
took
it.
I
don't
know
the
status
if
it's
currently
inside
of
the
of
the
actual
linux
foundation
or
if
it
has
been
transferred
to
the
to
the
supply
chain
foundation.
I
don't
know
how
it
is
the
status
of
it
right
now
so
and
it
stands
for
software.
A
Okay
and
it's
a
nice
pronunciation
also
so
that's
fun.
C
C
So
the
first
thing
I
want
to
note
is
that
if
you
see
the
little
square
below-
and
I
put
like
a
stronger
green
color
to
it-
because
well,
we
have
some
some
things
that
you
could
maybe
insert
them
into
compliance
most
and
most
of
the
topics
can
be
improved
for
the
kubernetes
release
process.
So,
for
example,
if
you
see
here
so
to
to
comply
with
salsa
level,
four
you
need
code
and
changes
are
reviewed
by
two
persons.
C
So
in
theory
we
could
have
that,
since
we
have
like
a
someone
to
look
good
to
me
and
an
approver,
but
sometimes
it's
the
same
person,
so
we
are
kind
of
near
it,
but
not
ideally,
but
most
of
the
topics
can
be
can
be,
are
in
that
state.
So
in
so
source
code
wise,
we
are
looking
pretty
good.
So
far.
We
have
version
control,
we
have
a
verified
history.
C
We
have
by
the
way
there
is
like
on
the
salsa,
which
is
salsa.dev
website.
There
is
like
an
explainer
of
each
of
the
requirements
and
if
you
have
doubts
on
any
of
them,
we
can.
C
We
can
maybe
stop
briefly
and
discuss
them,
and
so
source
codes
was
kind
of
like
looking
okay,
I
retained
indefinitely,
so
the
git
history
for
kubernetes
goes
back,
probably
all
of
the
history,
and
we
also
retain
the
actual
source
code
and
environment,
not
the
actual
environment,
the
build
environment,
but
the
artifacts
and
the
source
called
darbles
and
everything
that
we
used
to
cut
the
releases.
C
We
archived
that
so
we
we
were
pretty
looking
somewhat
within
that
on
that
front,
then,
regarding
the
wheel
environment,
so
this
is
kind
of
some
things
are
better
than
others,
so
we
have
a
scripted
build
so
everything
that
runs
when
we
got
this
kubernetes
release.
It
started
by
and
managed
by
a
automated
process.
We
have.
We
have
it
running
inside,
of
a
build
service,
which
is
a
google
cloud
build,
so
we
comply
with
that.
We
have
like
a
certain
kind
of
build
as
code,
but
not
entirely
so.
C
There
is
currently
an
effort
that
we
may
define
a
kubernetes
field
from
a
manifest
that
tells
the
build
process.
What
to
build.
We
currently
have
a
build
tool
that
takes
some
some
instructions
as
what
will
so
it
can
be
improved
on
that
side.
We
have
the
ephemeral
environment.
We
comply
with
that,
so
everything
runs
in
virtual
machines.
This
is
this
console
to
us
for
free
from
google
cloud.
Build
then
isolated
builds.
I
think
they
are.
C
They
are
isolated.
So
what
what
that
means
is
that
if
you
have
like
two
wheels
of
the
same
project,
they
cannot
influence
each
other.
So
we
currently
when
we
got
a
kubernetes
release.
For
example,
we
got
all
the
batch
releases
in
parallel
and
they
do
not
influence
each
other
and
we
have
provisions
then,
when,
for
example,
when
committing
changes,
they
can
safely
do
them
at
the
same
time.
C
Basically,
so
we're
we're
finding
that,
but
there
are
things
that
we
haven't
tested
yet,
for
example,
what
happens
if
I
run
to
release
processes
for
the
master
branch
at
the
same
time
it
it?
It
is
designed,
and
it
should
be
fine,
but
still
it's
not
really
tested
that
well
or
probably
never
have
spilled.
A
Also,
one
question
on
the
chart
is
the
ones
the
blocks
that
are
filled
are
the
requirements
for
that
level,
so,
like
salsa,
one
is
only
require
scripted.
Build
salsa
2
would
require
that
and
build
service,
and
are
the
colors
representing
how
far
kubernetes
has
come
in
terms
of
accom
getting
compliant
with
that
particular
requirement.
For
that
particular
level,
exactly.
C
C
It
means
that
we
have
at
least
a
starting,
or
at
least
a
little
bit
of
effort
around
that
and
which
can
be
improved.
Some
of
these
are
in
that
color
because
we
don't
have
like
a
very
deep
assessment
of
that,
for
example,
the
most
important
thing
here
is
the
blue
one
right
there
below.
I
marked
the
blue
because
so
salsa
level
four
requires
you
to
have
builds.
You
know
that
are
reproducible.
C
So
if
you
run,
if
you
were
to
run
the
same
release
process
with
the
same
at
the
same
git
commit
point
with
the
same
arguments,
everything
exactly
the
same,
you
should
get
exactly
the
same.
Artifacts
are
we
there?
I
if
you
were
to
ask
me
without
testing,
which
is
I
I
don't
know
somewhere
somewhere.
If
someone
somewhere
has
tried
this,
but
I
haven't
seen
it,
I
would
say
we
would
not
get
the
same.
Artifacts.
C
But
it's
just
by
your
hunch
feeling,
so
we
have
to
test
that.
So
this
is
all
of
the.
This
is
why
this
is
an
early
assessment,
so
I'm
I'm
trying
to
take
each
of
these
points
test
them
as
soon
as
much
as
I
can,
or
at
least
go
to
experts
on
that
particular
part
of
the
project
and
ask
them
what
their
what
what
they
think
about
there
are
areas
that
currently
have
problems.
C
So,
for
example,
when,
if
you
see
the
yellow
part
there,
which
is
that
the
build
environment
has
to
be
hermetic,
part
of
that
requirement
demands
that
the
build
environment
cannot
connect
to
the
outside
world.
I
mean
it
doesn't
have
internet
access,
we
that
that
is.
We
have
several
processes
that
currently
cannot
live
without
the
internet,
so
we
pull
dependencies
and
we
pull,
for
example,
the
licensing
information
from
outside
and
some
that
we
push
the
tax
to
github,
etc.
C
So
we
have
to
think
about
ways
if
you,
if
we
at
some
point,
were
to
try
to
achieve
such
a
level
four
compliance,
we
all
have
to
think
around
those
services.
So
this
this
in
general,
we
have
at
least
efforts
that
dodge
around
those
requirements
a
little
bit,
but
where
we
are
currently
not
looking
that
good
is
in
provenance
so
provenance.
What
does
prominence
mean
in
the
supply
chain?
C
C
What
it
means
is
that
you
should
be
able
to
take
an
artifact
or
yeah
an
artifact,
and
this
doesn't
have
to
be
the
final
artifact
that
doesn't
have
to
be
the
actual
cube
ctl
that
you
download
from
the
rocket,
but
even
any
of
the
interim
artifacts
that
we
keep
on
from
on
handling
all
across
the
cicd
pipeline.
You
should
be
able
to
take
any
of
them
and
have
a
verifiable
and
immutable
and.
C
Actually,
in
absolute
certain
way
to
make
sure
that
where
that
artifact
came
from
so
if
you
were
to
take,
for
example,
we
in
a
part
of
the
process
we
produce
the
patch
for
the
release,
notes
which
is
going
to
be
used
to
be
in
the
end
of
the
release
process.
We
are
going
to
use
that
to
send
the
email
notification
to
kde,
for
example,
if
you
were
to
take
that
that
file,
you
must
be
able
to
track
which
system
produced
at
what
time
and
make
sure
to
that.
C
C
So
in
the
materials
you
have
a
list
of
everything
we
produce,
so
it
gives
you
some
pointers
to
this.
The
will
of
materials
does
not
substitute
the
provenance
compliance
in
salsa,
but
it
helps
because
it
lists
and
gives
you
some
information
which
you
can
use
here,
maybe
as
a
program,
so
this
is
still
under
investigation.
This
is
very
new
for
me
and
we
do
not
have
any
efforts
going
on
there.
So
we're
going
to
talk
about
terence
of
where
you
can
help
this
is
this
could
be
one
of
them.
C
So
if
you,
if
you
see
so
currently
nothing
there
and
the
final
one
is
the
the
common
requirements
which
is
security
access
and
which
users
can
so
security
and
access.
Those
come
for
free
from
the
google
cloud
wheel,
environment
and
the
super
users
which
can
actually
trigger
a
kubernetes
release,
are
the
release
managers,
so
even
not
even
the
release
management
manager
associates
can
trigger
one.
Whenever
one
of
the
associates
wants
to
participate
in
according
our
release,
we
have
to
give
them
extra
permissions,
so
they
can
participate
so
well.
C
My
idea
here
is
that
I
wanted
to
give
like
an
overview
of
what
we're
trying
to
achieve
how
we're
trying
to
make
sure
that
our
supply
chain
environment
is
secure
and
we're
trying
to
at
least
frame
it
in
against
salsa,
and
but
this
is
like
.001
version
of
this
effort,
so
I
hope
you
take
it
with
a
grain
of
salt.
Some
of
these
things
may
change
most.
Some
of
this
information
may
not
be
as
green
as
I
painted
here.
Okay,
then,
okay,
now
moving
on
to
the
bit
of
material.
C
So
just
a
super
quick
introduction.
What
is
the
bill
of
materials?
This
is
the
like.
The
formal
definition,
formal
record,
containing
the
digital
supply
chain,
relationships
of
various
components
using
a
building
in
building
software,
so
the
bill
of
materials
is
basically
a
list
detailing
things
that
you
want
to
account
for.
So
if
you
want
to
make
sure
and
what
things
that
you
want
to
account
for
and
the
in.
A
C
C
C
And
it
has
the
ability
to
be
expressed
in
several
encodings
json
yaml
raf.
I
think
you
can
even
invalidate
it
in
in
spreadsheets.
I
think,
but
the
one
we
use
is
the
proprietary
I
mean,
but
it's
not
proper
right,
because
it's
an
open
standard
but
the
its
particular
tag,
value
formats
that
the
standard
defines
and
what
it
does
is
that
it
you
can
express
files
packages
and
then
how
those
things
are
related
between
them.
C
So,
to
give
an
example,
you
could
see
add
a
zip
file,
for
example,
handle
it
as
a
package
and
then
have
a
list
of
files
which
are
contained
in
them.
Okay,
so
that's
an
example
of
our
relation
and
I
wanted
to
give
you
a
little
bit
of
an
overview
of
how
we
are
structuring,
currently
the
bill
of
materials
for
kubernetes.
C
So,
first
of
all-
and
the
first
thing
I
wanted
to
to
give
you
an
overview-
is
how
we
are
expressing
the
container
images.
So
we,
the
linux
foundation,
recently
the
comparison
among
several
bill
of
materials,
producing
tools,
and
I
submitted
hours
to
to
compare
how
our
output
differs
or
matches
other
tools
that
are
writing.
Spdx
fields
of
materials
and
we
are
more
or
less
interpreting
the
standard
and
producing
the
documents
in
a
similar
way,
and
so
the
base
look
for
the
images
that
we
are
using.
C
Currently
we
have
the
images
separated
each
each
of
them,
so
we
we
produce
for
a
for
each
of
the
components
in
kubernetes.
There
are
several
images
for
each
of
the
architectures.
C
We
do
not
currently
do
that
and
I
am
planning
on
changing
the
wheel
of
materials
at
some
point
to
reflect
that,
but
currently
we
have
each
of
them
each
of
the
images
for
each
architecture
separated
by
themselves
now,
so
we
produce
two
bill
of
materials,
two
s-bombs
for
kubernetes,
one
which
is
named
the
release
and
one
which
is
named
the
source
code
spawn
the
reason
I
chose
to
do.
That
was
because
the
actual
document
is
really
large.
So
it's
around,
I
think
the
last
ones
were
16
megabytes.
C
So
if
you
were
so,
the
reasoning
behind
it
was
if
I
wanted
to
download,
for
example,
a
binary
which
is,
I
don't
know,
100
megs
and
verify
the
that
binary
against
the
bill
of
materials,
I
would
have
to
almost
download
a
bill
of
materials
almost
the
same
size,
so
I
thought
that
splitting
them
would
be
like,
like
a
better
way
to
handle
them,
because
you
can
have
like
a
leaner
bill
of
materials.
Do
the
verification
and
use
them
at
the
time.
C
I
don't
think
it
was
received
very
well,
but
since
our
first
iteration
until
the
linux
foundation,
event
that
took
place
last
week,
I
think
other
people
are
trying
to
see
value
in
that
and
splitting
your
s
bombs
is
that
I
at
least
is
my
appreciation.
From
from
the
event.
Is
that
splitting
the
s
bombs
would
be
the
way
to
go
so
we're
good
on
that.
A
C
Yeah,
that's
what
I
that's
why
I
I
put
this
this
this
image
before
so
currently,
the
way
our
bill
of
materials
is
structured,
the
we
do
not
go
into.
We
have
the
capability
and
the
software
allows
to
do
that,
but
I'm
going
to
explain
you
why
we
don't
do
that
currently
so
inside
inside
of
the.
C
If
you
take
a
look
at
the
bill
of
materials,
we
only
go
up
to
the
tar
table.
We
don't
go
into
inside,
of
the
terrible
of
the
layers,
expand
them
and
list
the
things
we
the
code
is
written
and
it's
just
a
flag
away
to
enable
it,
but
we
we.
So
if
you,
if
you
take
a
look
at
how
it's
structured,
it's
just
the
container
package,
which
is
the
the
the
reference
a
cube,
api
server,
linux,
md
et
cetera,
et
cetera
and
then
containing
the
tables,
and
that's
it-
we
don't
go
in
there.
C
And
so,
if
you
take
a
look,
how
it's
structured,
you
will
see
each
of
these
containers.
I
don't
know
if
you
can
see
my
mouse
or
not,
but
each
of
each
of
these
container
packages
are
listed
separately
instead
of
the
lead
of
materials,
and
you
do
have
the
binaries
listed,
but
this
is
a
as
a
separate
artifact
separate
from
the
images,
so
you
have
cube
ctl,
you
have
api
server,
each
of
the
binaries
are
listed
in
there,
but
separate
now.
Why?
C
Why
didn't
I
enable
this
because
of
the
separation
and
the
and
splitting
of
the
s1?
That
should
be
happening.
Hopefully,
if
I
have
time
before
before
during
123.,
so
we,
our
images
and
the
images
we
produce
in
kubernetes
are
based
mainly
in
well.
They
have
other
base
images,
so
they
extend
all
their
bases.
C
We
produce,
for
example,
a
go
runner
image
in
in
in
release
engineering,
which
is
the
base
image
for
some
of
the
projects
that
we've
been
talking
about.
So,
for
example,
I
think
if
memory
doesn't
fail,
I
think
api
server
is
based
on
go
runner
and
go.
Runner
itself
is
based
on
the
distroless
distribution.
C
So
the
first
approach:
when
opening
when
I
wrote
the
code
to
open
the
layers
and
analyze
the
files
in
them
was
okay.
C
My
current
idea
is
to
produce
a
bill
of
materials
at
image
field
time.
So
whenever
we
do,
a
new
version
of,
for
example,
go
runner
of
the
go
runner-based
image.
I
think
what
what
we're
going
to
do
is
that
when
we
do
the
promotion
of
this
image,
which
promoting
it
means
making
it
available
for
other
projects
to
consume,
I'm
going
to
do
the
bill
of
materials
generation
right
there
and
publish
it
along
the
image.
C
And
that
way
we
can
have
like
a
nice
chain
of
of
bill
of
materials
which
each
reference,
the
the
chain
up
stream
until
the
original
image,
which
should
be
distributed,
for
example.
But
this
is
in
the
future
still
and-
and
that
is
why
the
images
currently
in
the
in
the
bit
of
materials
look
like
this
and
we
don't.
We
don't
go
into
the
the
artifacts.
C
So
that's
that
so
in
the
kubernetes
release,
we
have
three
main
things:
the
images,
the
binaries
and
the
targets
for
each
of
the
that
we
produce
with
each
of
the
images
and
then
the
other
bill
of
materials,
which
is
the
the
big
one.
And
what
by
big
I
mean
in
the
size
of
the
thing,
is
larger
and
we
have
the
source
code
build
of
materials.
C
These
two
are
linked
by
the
by
the
by
features
inside
of
spdx
themselves,
so
speedy,
x,
speed
x,
allows
you
to
inside
of
the
documents
say
this
one
was
built
from
the
other
from
from
the
thing
described
by
this
other
bill
of
materials.
So
if
you
take
a
look
inside
of
the
bill
of
materials,
you
can
you
can
have
it
there
and
inside
of
the
source
code
bill
of
materials.
C
We
have
the
source
code,
which
lists
everything
inside
of
there
we'll
see
how
many
it's
like
20,
000,
plus
files
and
all
of
the
dependencies
to
build
a
list
of
dependencies.
What
we
do
is
we
as
go
to
generate
all
of
the
all
of
the
gold
dependencies
of
the
projects
and
then
actually
go
and
clone
all
of
the
repositories.
C
C
So
some
facts
about
their
the
artifacts
that
we
are
described
inside
of
the
bill
of
materials.
So
we
have
231
dependencies.
I
think
I
took
this
from
kubernetes
122.2.
I
think
so
20
231
dependencies,
which
are
20,
which
are
basically
the
other
gold
packages
that
we
we
pull.
One
billion
kubernetes
release.
A
C
Yeah
yeah,
the
first
iteration
I
I
I
did
was
reading
from
the
gold
mall
and
I
was
quickly
slapped
in
the
hand
by
the
by
the
community
so
but
currently
seems
to
be
working,
and
so
part
of
this
is
getting
out
in
the
open
use
it.
And
if
you
see
anything
wrong,
just
file
issues
or
even
yet
even
better
help
help
fix
them.
C
Then,
on
the
that's
on
the
source
code,
23,
000
source
code
files
and
then
on
the
releases,
we
have
like
the
25
container
images
for
all
the
architectures
68
banners
and
the
33
tables
that
are
produced
which
are
server,
clients,
conformance
and
I'm
testing.
And
I
don't
remember
the
other
one
now
for
future
plans
for
this.
So
if
you
remember,
I
talked
about
first
framing
our
release
process
into
salsa
and
then
the
other
one
is
the
actual
s1
work
that
we
are
planning
the.
C
So
what
are
the
future
plans
for
the
yes
one?
So,
first
of
all,
splitting
the
the
bit
of
materials
into
more
usable
manifests
and
this
this
could
have
like,
like
a
very
nice
human
discussion,
because
we
it
is
more
of
a
strategy.
So
how
if
you
were
to
produce
a
series
of
pillow
materials,
how
would
they
be
consumed
downstream?
C
How
do
you
expect
the
actual
users
of
them
would
would
they
use
them
to
inventory,
are
released
to
make
sure
it's
complete,
wouldn't
use
them
would
would
they
use
it
more
for
securities
for
both?
How
often
so,
if
you
are
going
to
do
one
verification
and
then
do
your
own
fork
or
clone
or
free
distribution
of
the
package?
C
Then
we
another
project
that
we
have
to
start
is
the
building
of
the
villa
frontiers,
for
the
base
images
for
governor
for
debian
so
etc.
C
Then
we
there's
still
a
need
to
add
the
file
types
into
the
build
of
material,
so
spdx
has
provisions
to
say,
for
example,
this
is
a
c
file
and
this
is
a
binary
and-
and
this
is
I
don't
know,
go
code-
we
don't
have
that
yet
no
and
then
keep
is
missing,
and
this
is
because
it's
it's
an
eternal
effort
of
how
we
are
handling
the
rpm
and
the
packages
that
we
produce.
The
both
rpm
and
dev
packages
that
are
published
with
each
kubernetes
release
are
not
currently
described
in
the
group
of
continuous.
C
We
have
to
add
code
for
that.
There
is
still
sorry,
there
is
still
no
no
plans
and
no
ideas
on
either
how
to
describe
them
and
how
to
add
them.
So
there's
a
another
way.
You
could
help
on
this
ever
and
then
I
am
currently
working
on
verification
tools.
So
what
if
I
have
a
bill
of
materials?
C
I
want
to
make
sure
that
I
want.
Then
I
can
at
least
with
my
own
tools,
because
since
the
standard
is
very
open,
different
tools
interpret
things
in
different
ways.
So
there's
currently
an
effort
to
join
and
unify
the
interpretation,
but
currently
there
is
there
isn't
a
single
way
to
to
do
that.
So
I
mean
I
can,
of
course
validate
the
wheel
of
materials
of
one
file
against
one
file
or
an
image
kind
of
against
an
image,
but
how
those
things
are
expressed.
C
Do
I
package
them
as
packages
or
files
or
the
relationships
against
them?
There
is
still
varying
outputs
among
all
of
the
tools,
but
I
want
to
make
sure
that
our
tool
can
produce
a
bit
of
materials
and
then
consume
it
back
in
and
make
sure
that
the
release
is
complete
so
that
I
think
that's
the
most
basic
thing
that
we
should
be
supporting.
C
Currently,
this
is
stopped
because
there
is
a
plan
that
we
may
merge
the
kubernetes
bill
of
materials,
tool
and
code
with
the
linux
foundation
code,
so
there
so
we're
exploring
ways
that
to
unify
efforts
in
order
to
stop
duplicating
things.
So
so
our
verification
code
is
still
very,
very
green.
So
probably
it
would
make
sense
to
maybe
in
that,
in
that
case
use
theirs,
but
but
still
a
work
in
progress.
C
C
So
if
you
can,
if
you
can
use
our
tool
and
and
yeah,
I
forgot
to
mention
so
all
of
this
code
that
we
wrote
to
produce
the
kubernetes
bill
of
materials
is
available
in
a
public
general
purpose
tool
which
you
can
use
to
build
your
own
bit
of
material.
So
I
have
the
link
in
the
last
slide,
and
so,
if
you
can
use
it
find
and
report
and
or
help
fix,
those
bugs
would
be
really
appreciated
and
our
tool
is
in
our.
Not
all
of
our
code
is
specifically
built
to
analyze,
go
code
bases.
C
C
But
the
idea
of
opening
it
up
was
because
a
lot
of
cloud-native
stuff
is
really
good
and
then
on
the
supply
side
chain
of
land.
So
we
we're
currently
analyzing
trying
to
develop
a
roadmap
to
see
if
it's
possible
to
achieve
all
of
these
also
levels
and
actually,
I
think,
salsa
levels.
One
and
two
can
be
achieved.
C
I
mean
not
easy,
but
it's
achievable
so
would
be
working
on
on
an
efforts
to
produce
like
a
like
a
plan
and
a
good
roadmap
to
achieve
the
compliance
and
polish
it
all
in
an
umbrella
issue.
So
if
I
were
to
choose
when
I
would
like
look
to
see
that
happening
at
the
end
of
the
124
cycle,
hopefully
and
then
the
provenance,
the
provenance
efforts
that
I
talked
about,
so
this
is
still
very
new
to
me.
C
I'm
still
trying
to
wrap
my
head
around
what
it
takes
the
different
technologies
around
it
and
projects
that
we
can
use
or
how
we
can
fit
it.
If
you
have
expertise
in
provenance
regarding
software
supply
chains
by
all
means,
come
and
join
us,
we
could
certainly
use
your
help
and
yeah
and
finally,
just
a
bit
some
some
links
that
you
may
find
useful.
C
So
the
salsa
framework,
our
bomb
utility,
which
you
can
go
and
use-
and
we
currently
are
looking
at
the
in
total
project
to
to
achieve
the
provenance
information
across
our
our
supply
chain
processes
and
yeah.
And
if
you
have
questions,
I
would
like
to
join
or
whatever
and
join
the
seek
the
release,
engineering
and
seek
release
channels.
And
you
can
find
me
as
puerco
almost
everywhere.
A
A
I
know
we're
out
of
time,
but
I
am
sure
you
will
enjoy
getting
questions,
so
I
request
everyone
to
put
your
questions
in
six
security,
tooling,
slack
channel
tag
me
or
pierco
or
both
of
us
and
then
we'll
try
to
find
the
right
answer.
Whenever
we
can.