►
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
A
B
Hey
my
name
is
Ryan
wheat,
and
this
is
the
first
time
I'm
joining
this
meeting.
I
was
invited
to
join
because
one
of
the
projects
we're
talking
about
today
is
called
copacetic
I
run
the
the
Azure
open
source,
incubations
team
and
copacetic
was
an
incubation
that
we
put
together
in
our
group
and
it's
graduated
and
it's
now
being
run
in
production
at
Microsoft
and
I'm.
Just
super
happy
to
see
it's
moving
along
this
path,
so
just
happy
to
be
observing
and
in
today's
session.
A
D
E
A
A
I
can
provide
a
little
update
on
that.
The
zero
trust
project
leads
have
sent
out
an
email
to
the
whole
tag.
They're
they're
publishing
a
zero
trust,
Cloud
native
security
white
paper.
They
have
sent
that
out
for
review.
So
if
you
could
please
review
it
and
put
your
comments,
that'll
be
much
appreciated.
A
F
F
A
F
A
G
So
if
there's
a
group,
that's
done
a
self-assessment
that
wants
to
have
a
joint
assessment
on
I
think
that
now
is
a
great
time
to
mention
that
I've
just
been
going
through
the
queue
and
looking
at
issues
and
trying
to
see
if
anybody
seems
ready.
Also,
the
security
book
has
been
sent
off
to
folks
in
the
LF.
It
seems
to
be
ready
to
go.
H
H
Let
me
start
off
by
saying
you
know
the
everybody
you
know
at
least
I
assume.
Most
of
you
have
been
hearing
about
the
software
supply
chain,
security
attacks
and
those
sorts
of
things
that
have
been
going
on
recently
and
you
know:
hey
it's
making
a
big
impact,
yeah
yeah,
you
know
normal
stuff.
So
what
the
tag
security
did
of
starting
a
few
years
ago,
they
started
a
working
group
called
the
software
supply
chain,
security
working
group.
H
F
H
H
H
And
it
is
a
it's
a
guide
that
we
wrote
up
talking
through
a
lot
of
the
software
supply
chain.
Security
challenges
specifically
how
they
relate
to
Cloud
native,
and
so
the
basic
idea
right
is
a
software
supply
chain
attack
is
really
an
attack
against
your
software
delivery
life
cycle
and
when
we're
talking
about
Cloud
native,
we
are
talking
about.
You
know
stuff,
like
containers
stuff,
like
zero
trust
and
and
that
sort
of
thing.
H
So
how
can
we
sort
of
apply
Cloud
native
best
practices
to
securing
our
supply
chain,
and
so
it
goes
into
all
the
different
areas
of
the
supply
chain,
so
we're
talking
about
your
source
and
dependencies.
So
how
am
I?
How
am
I
sure
that
I'm
pulling
in
secure
Source,
how
am
I
sure
I'm
pulling
in
Secure
dependencies?
How
am
I
secure
you
know,
and
then
it
kind
of
moves
on
to
things
like
building
and
and
actually
developing
the
code
internally.
H
These
you
know
in
certain
cases
like,
for
example,
with
the
build
it's
keep
your
build,
granular
and
and
try
and
make
sure
that
you
can
reason
about
individual
steps
quite
succinctly.
So
if
a
step
goes
wrong,
you
know
you
can
start
to
point
some
of
those
things
out
and
there's
a
lot
of
suggestions
in
here
that
are
involve
a
lot
of
you
know.
Cloud
native
focused
Technologies,
like
pecton,
like
in
Toto,
like
tough
and
and
those
sorts
of
things,
and
so
I
recommend
folks
checking
it
out.
It's
a
pretty.
H
You
know
pretty
rigorous
there.
You
know
it
goes
into
stuff
like
s-bombs
goes
into
stuff.
Like
you
know,
securing
your
build
goes
into
stuff
like
how
you
could
potentially
securely
deploy
using
xero
trust
through
things
like
spiffy,
spire
and
and
that
sort
of
thing
it's
not
an
implementation
guide,
but
it
does
provide
some
of
those
high
level
things
before
moving
on
from
that
to
the
secure
software
Factory.
Does
anybody
have
any
questions
about
that
document
or
about
anything
that
we've
worked
on
there.
H
B
H
Been
some
there's
been
some
drama
in
open
ssf
that
I've
been
dealing
with
as
a
tech
member,
so
cool.
So
now,
after
that,
there
is
the
secure
software
Factory,
and
so
that's
also
underneath
and
most
of
this
stuff
is
involved
here
and
I'll
also
talk
about
the
the
compromises
afterwards,
but
most
of
the
stuff.
I
H
H
The
secure
software
Factory
is
a
focus
on
the
build
piece
of
the
software
supply
chain.
So,
as
we
kind
of
looked
at
in
the
sort
of
best
practices
guide,
once
again,
it's
the
software.
You
know
software
supply
chain.
Security
is
mostly
about
from
you
know.
How
do
I
make
sure
that
I
am
developing
and
ingesting
software
in
a
secure
way
right.
H
How
am
I
sure
that,
like
my
actual
build,
is
secure
because
the
build
is
one
of
the
most
critical
pieces,
because
it's
very
hard
to
reason
about
and
the
reason
why
I
say
that
right
is,
is
if
I
look
at
a
set
of
dependencies.
I
know
I'm
pulling
down
a
set
of
files.
I
can
do
something
about
that.
I
know.
H
I
should
only
be
pulling
down
a
set
of
files,
but
if
I
look
at
a
build,
a
build
can
often
do
stuff,
like
compilation
and
other
things
like
that,
which
you
are
taking
a
bunch
of
potentially
like
text
files
along
with
other
binaries,
doing
some
operation
against
them.
And
now
you
have
a
new
binary
and
that
sort
of
thing
can
be
very
hard
to
reason
about.
H
So
that's
where
you
know
that
was
sort
of
the
impetus
for
creating
the
secure
software,
Factory
and
I
recommend
folks
also
checking
this
out.
The
basic
ideas
here
once
again
are:
how
do
we
secure
the
build
in
a
cloud
native
way,
so
that
means
applying
zero
trust,
applying
sort
of
devsecops
applying.
H
H
The
first
is
how
do
I,
how
am
I
sure
that
I'm
securing
the
actual
pipeline
definition
so
like
when
I
go
and
say
I
should
be
building
it.
In
this
way,
I
should
pull
down
the
code.
I
should
generate
an
s-bomb
from
The
Source
I
should
then
run
a
build.
I
should
then
run.
Let's
say,
SCA
scan
against
the
build,
and
finally
I
should
publish
it.
How
am
I
sure
that
I'm,
actually,
that
the
definitions
I
am
doing
are,
are
within
a
security
policy?
H
H
One
of
the
concerns
and
that
we've
seen
this
right
with
things
like
tecton,
but
we've
seen
this
with
other
things,
is
hey
an
admin
to
the
cluster,
can
go
in
and
say:
yep
you're
running
this
build,
but
now
I
want
you
to
run
a
different
build
and
it's
very
hard
to
detect
that.
That's
actually
what
happened.
H
So
that's
the
second
piece
and
then
finally,
the
third
piece
is
okay.
Now,
if
we
take
a
actual
microscope
to
what's
happening
in
the
build
itself
in
this
case
when,
in
the
cloud
native
perspective,
usually
something
like
a
container,
how
am
I
sure
that
that
container
isn't
compromised
in
some
way
right-
and
you
know
somebody
is
executing
into
the
Container
or
that
somebody
is
or
that
the
container
like
the
base
image
that
the
container
build
is
running
was
somehow
has
malicious
software
in
it
right.
H
H
Looking
at
things
like
ebpf
to
explore
for
runtime
visibility
into
what
the
actual
container
is
running
and
to
make
sure
like
hey,
is
this
container
starting
to
poke
around
in
random
places
and
memory?
Is
it
is
it
you
know?
Are
you
exacting
things
you
know?
Is
it
seemingly
downloading
things
and
then
executing
them
when
it
should
only
be
running
compilation,
that
kind
of
thing
and
then
separately?
H
Looking
at
policy
Frameworks,
you
know
policy
engines
like
oppa
as
well
as
kuberno,
to
go
and
essentially
enforce
that
both
the
policies
we
are
giving
to
a
cicd
system.
Sorry,
the
the
pipelines
we
are
giving
to
a
CI
CD
system
are
within
policy
and
then,
in
addition
to
that,
also
ensuring
that
only
the
that
only
like
approved
images
are
allowed
to
be
part
of
the
build
pipeline.
So
that
means
both
from
a
build
workload.
So
hey
is
this.
H
Is
this
image
that
I'm
about
to
use,
as
as
the
base
image
for
my
build?
Is
that
safe?
Is
it
good?
Is
it
you
know?
Is
it
within
policy
as
well?
As
you
know,
the
pipeline
itself
am
I
running.
It
approved
sorry,
the
pipeline
tools
so
like
your
tecton
am
I
actually
running
tecton
that
came
from
the
tecton
maintainers
or
did
I
download
a
malicious
image
right,
that's
kind
of
the
big
pieces
there
and
then.
H
Finally,
you
then
have
a
signed
image
at
the
end
that
you
know
often
with
the
metadata
associated
with
it
so
stuff,
like
a
salsa
attestation,
stuff
like
an
s-bomb
and
those
sorts
of
things,
and
then
you
could,
which
you
can
then
use
Downstream
in
a
similar
way,
to
enforce
that.
Yes,
I'm
only
allowing
the
use
of
of
software
that
is,
has
been
built
through
something
like
a
secure
software
Factory.
H
So
that
was
the
next
big
piece
of
work
coming
from
the
CNC
from
the
the
secure
sorry,
these
software
supply
chain
security
working
group
before
moving
on
to
the
next
oops.
That's
not
the
right
one!
That's
my
local
thing!
This
is
the
right
link
to
that
before.
Moving
on
to
the
next
one,
do
folks
have
any
questions.
H
Sure
so
one
of
the
big
pieces
for
admission
control
and
why
it's
super
important
for
software
supply
chain
security
right?
Is
you
wanna?
You
know
it
and
it
kind
of
ties
into
zero
trust
and
really
like
a
lot
of
supply
chain.
Security
is
zero
trust,
but
not
for
your
users
and
not
for
your
servers,
but
for
the
artifacts
right,
like
you
know,
it's
it's
zero
trust
to
essentially
say
is
this
thing
I'm
about
to
run
this
piece
of
software
a
container
image?
That
kind
of
thing
is
it
allowed
to
run?
H
What
does
it
have
permissions
to
right
and-
and
it's
about
essentially
always
verifying
that
that's
the
case,
so
you
know
they're,
you
know
just
as
an
example.
The
recommendations
we
all
obviously
provide
are
things
like
you
should
be
pinning
to
hashes
of
images.
Do
not
use
tags
right
because
tags
can
be
replaced,
and
you
know
all
it
takes
is
a
tag
you
know.
Let's
say
if
you're
on
latest
all
it
takes
is,
and
if
you
just
say,
hey,
I,
pull
whatever
down
that's
the
latest.
H
All
it
takes
is
for
somebody
to
compromise
the
registry.
They
push
out
a
new
image
and
then
the
next
time
you
run
a
thing.
You'll
pull
down
the
latest
version
of
that
image.
It's
now
you're
pulled
down
a
compromised
version
of
that
image
as
opposed
to
hey.
We
ran
a
bunch
of
checks
against
this
particular
digest
of
an
image
and
we
determined
that
that
image
is
good
and
we
believe
it
to
be
safe,
and
then
we
use
that
image,
and
then
we
have
that
and
we
we
have
a
policy
against
that.
H
So
the
way
that
policy
engines
like
kiverno
and
opa
work
within
a
kubernetes
framework,
but
this
is,
is
it
essentially
just
sort
of
looked
at
the
various?
You
know
the
various
resource,
yamls
and
those
sorts
of
things.
It
looks
at
the
resources
that
get
pulled
in
and
then
is
able
to
sort
of
tease
out
the
different
elements
and
is
able
to
go
and
say
Yes.
H
You
have
defined
that
this
should
be
running
this
image,
and
you
know,
is
this
image
within
the
policy
I
understand
and
there's
lots
of
different
ways
to
define
the
policy
you
can
Define.
The
policy
based
on
you
know
a
query
to
another
database
to
say:
hey
I,
looked
up
in
my
my
list
of
approved
images
database
is
in
my
list
of
approved
images.
It
could
be
in
just
a
you
know:
a
config
map,
there's
all
sorts
of
different
ways
to
manage
that.
H
But
the
general
idea
is,
you
can
kind
of
have
a
you
know.
You
can
have
a
set
of
queries
that
could
be
run
to
essentially
say
yes,
this
is
good
or
no.
This
is
bad
and
it
shouldn't
be
allowed
and
it
could
be
in
you
know
most
cases
right
now.
It's
used
something
like
an
image,
but
it
can
also
be
used
against
things
like
you
know:
tecton
resource
definitions,
so
you
can
say:
hey
I
have
a
tecton
pipeline,
which
is
once
again,
you
know
kubernetes
yaml
right
and
you
can
say
well.
B
Hey
this
is
Ryan
I
had
a
question
sure
and
I'm.
Not
the
expert
in
the
space
like
you
are,
but
is,
is
rollback
ever
part
of
the
way
that
you
think
about
your
secure
software
Factory
in
the
sense
that
something
did
get
all
the
way
through
the
pipeline,
and
it
still
turns
out
that
it's
wrong,
and
so
you
need
some
sort
of
way
to
roll
back
to
kind
of
a
last
known,
good
image.
H
Yeah,
so
that's
actually
a
key
bit
of
this
is.
Is
we
believe
that
you
need
to
have
something
like
this
to
do
secure
rollback,
sorry
to
do
rollback
in
a
good
way,
because
by
keeping
track
of
all
the
different
components,
it
makes
it
much
easier
to
identify
when
something
has
gone
wrong,
as
opposed
to
it's
just
another
build
and
when
you
go
back
and
you
go,
hey
wait
a
second:
what
happened?
What
what
actually
went
wrong?
H
This
s-bomb
are
all
cryptographically
tied
to
this
image,
as
opposed
to
just
what
we
see
a
lot
right
now
is
yeah
I
have
an
s-bomb
and
I'm
claiming
it's
about
this
thing,
but
I
have
not
a
lot
of
ways
to
actually
check
whether
or
not
that's
actually
the
case,
whereas
in
this
assuming
you
trust
the
secure
software
Factory,
you
can
do
that,
which
then
makes
it
much
easier
for
when
you
go
and
you
say,
hey
wait.
We
discovered
something
in
at
runtime.
H
We
discovered
a
problem
and
we
think
that,
like
this
is
actually
compromising
it
actually
made
its
way
past.
All
these
other
checks
right.
You
can
then
go
back
to
then
say
great.
We've
rolled
it
back
now.
Let's
actually
look
through
the
salsa
attestation,
the
s-bomb,
the
build
logs,
the
ebpf
report
and
say:
is
this
like
what
happened?
Is
there
evidence
of
some
malicious
behavior
or
do
we
need
to
add
something
new
or
hey?
Did
our
actual
secure
software
Factory
get
compromised
like
that?
H
B
No,
it
sure
did
look
I'm
I'm
much
more
on
this
operating
big
service
side
of
things
and
rollback
is
such
a
critical
part
of
oops.
We
did
something
bad,
a
very
well-intentioned
25
year
old
made
a
bad
check-in,
and
now
we
need
to
get
back
as
quickly
as
possible
to
you
know
previous
known
States.
So
if
you
answered
the
question
great,
thank
you
for
for
explaining
that
yeah.
H
And
and
when
it
comes
to
the
actual
implementation,
what
a
lot
of
folks
do
is
they
do
a
like?
They'll
often
have
the
ability
to
add
additional
metadata
to
an
image
so
like
through
stuff,
like
tags
or
whatever,
so
that
you
can
pretty
much
say:
hey
look,
I
have
this,
you
know
I'm
I'm
pulling
in
the
latest
signed
image
within
our
own
environment,
and
you
know
I
pinned
that
hash,
but
I
can
always
go
back
and
say
great.
This
has
now
been
pinned
as,
like.
H
It's
been
tagged
as
essentially
as
nope
no
good
and
through
our
policy
engines
we
can
go
in.
You
know
whether
it's
a
database
or
whatever
you
can
go
back
and
say
great
I'm,
going
to
go
away
and
essentially
deploy
the
last
known
good
one
and
there's
a
bunch
of
different
things
that
people
have
been
doing
on
on
that
end
and
it's
yeah
awesome.
Thank
you.
H
Okay,
cool
yeah
and
just
so
folks
know
like
there's
this.
This
document
itself
does
not
really
talk
about
implementation,
specific
things,
it
kind
of
keeps
it
a
high
level
architecture.
But,
for
example,
there
is
an
openssf
project
that
does
just
sort
of
as
more
of
an
example.
Architecture
called
Fresca,
frsca
I'll
just
type
it
here.
It's
it's
not
really.
A
few
of
us
who
are
maintainers
on
it
are
that
you
know
I'll
just
put
this
here,
build
sec.
H
H
All
right
and
then
the
next
thing
is:
where
is
this
a
supply
chain
security
compromises?
So
this
is
an
ongoing
thing
that
we've
been
working
on,
and
this
is
just
stuff
that
people
can
submit
to,
and
actually
this
is
probably
the
first
thing
that
came
out
of
a
lot
of
the
the
supply
chain.
Security
work
from
TAG
security,
but
there's
a
bunch
of
stuff
here,
I
recommend
taking
a
look
at
it.
H
It's
just
stuff
like
hey,
you
know,
math.js
had
had
a
you
know,
a
supply
chain,
security
attack
and
it's
just
a
list
of
various
supply
chain
security
compromises.
Most
of
them
are
Cloud
native,
but
we
also
include
a
lot
of
things
that
are
not
particularly
Cloud
native
as
well
and
then.
Finally,
a
thing
that
is
currently
being
worked
on
is
we're
building
out
a
sort
of
an
executive
summary
paper
around
trying
to
kind
of
one
of
the
big
things
that
people
have
been
asking
for
is
hey.
H
H
You
know
how
s-bomb
best
practices
when
it
comes
to
some
of
these
things,
we're
also
looking
at
potentially
pulling
in
other
cntf
projects
to
see
if
we
can
actually
help
out
their
supply
chain
security
and
things
like
that,
and
so
there's
a
bunch
of
different
things.
There
come
check
us
out
where
our
meetings
are
on
Friday.
Sorry,
Thursday.
Sorry,
our
meetings
are
every
Thursday,
it's
on
the
cncf
calendar
and
it's
also
within
our.
D
Cool,
so
what
is
copacetic
so
copacetic
is
is,
by
definition,
is
means
in
excellent
order.
Interview
basically
merged
in
Co
is
in
container
and
then
pass
and
patching,
and
then
that
made
copacific-
and
this
is
our
GitHub
URL.
If
anybody
wants
to
find
it,
but
in
in
general
Copa
and
we
called
it
by
short,
Copa
Copa
is
a
simple
tool
that
helps
us
fix
security
issues
in
container
images
quickly.
D
I
know
that
we
have
a
contribution
that
includes
a
different
scanner
today
and
then
Copa
parses
the
vulnerability
report,
information
in
the
corporate
processes,
the
the
needed
update
packaging
using
the
applicable
package
managers
tools
like
apt,
APK,
yum
and
others,
and
then
finally,
copper
applies.
The
resulting
update
to
The
Container
image
using
buildkit,
creating
a
patch
layer.
D
D
If
you're,
relying
on
third-part
images
that
you
don't
maintain,
they're
update,
update,
cadences
might
not
meet
your
slas
and
copper
allows
users
other
than
the
image
Publishers
to
also
patch
container
images
and
image.
Publishers.
Don't
need
to
create
new
workflows
for
container
patching
since
copper
supports
patching
container
images
using
the
security
update
packages
already
being
published
today
and
copper
reduces
the
storage
and
transmission
costs
of
redistribute
redistributing
patched
images
by
only
creating
an
additional
bash
layer
instead
of
rebuilding
the
entire
image.
And
then
this
can
be
cached
and
then
so.
D
D
And
then,
let's
look
at
a
demo,
so
for
this
demo
we're
just
going
to
look
at
a
real
life
example.
I
just
pulled
this
from
Docker
Hub.
This
is
like
an
obviously
an
old
nginx
image.
This
is
1.18.0,
so
we're
just
gonna
look
at
the
vulnerabilities
in
this
package
and
then
specifically
on
this,
the
PKG
package,
which
is
a
critical
vulnerability
again.
This
is
like
an
old
old
image,
so
it's
it
is
going
to
have
a
lot
of
boundaries,
as
you
can
see
in
the
docker
Hub
yep.
D
D
And
then
in
the
next
step,
so
now
we
have
the
Json
file.
We
are
going
to
just
output
the
total
number
of
vulnerabilities
to
see
how
many
total
number
of
vulnerabilities,
including
critical.
So
now
we
have
240
total
vulnerabilities
with
44
being
critical
and
then
let's
look
at
this
dpkg
package,
just
as
an
example.
D
D
So
we'll
run
build
kit
as
a
container
locally,
but
we
just
added
functionality
that
you
can
do
this
directly
with
Docker
or
using
one
of
the
buildx
build
kits
and
then
so
you
don't
have
to
run
this
container
separately
and
then
starting
with
Docker
24.
It
will
be
supported,
natively
using
containerdy
snapshotter,
and
then
we
are
going
to
use
copper
to
patch
this
image.
D
D
D
Oh,
that
was
the
demo
and
then
piazzo,
then
the
caller
to
action.
Please
try
out
copper
if
you're
interested
in
the
report,
the
bugs
that
you
find
I
mean
if
you
have
any
contributions,
you're
very
welcome
to
submit
any
issues
and
rprs
and
then
our
future
work
is.
We
just
released
GitHub
action,
support
and
Docker
build
X
support,
Indian,
Docker
native
support.
A
D
There
yeah,
we
would
itself
doesn't
do
any
testing,
I'm
gonna,
make
sure
I'm,
not
gonna.
Yeah
copper
itself
doesn't
do
any
testing,
because
Cooper
doesn't
really
know
any
of
the
the.
What
what
the
the
images
do
say
like
nginx
copper,
verifies
the
the
packages
that
it
got
patched,
but
it
doesn't
know
anything
about
nginx.
So
it
would
be
up
to
the
to
the
to
the
teams
that
are
using
in
consuming
these
images
to
do
their
testing.
K
Yeah,
this
reminds
me
of
all
the
promises
of
build
packs
but
implemented
completely
differently.
So
it's
it's
an
interesting
take
on
it,
I'm
curious
when
you
start
to
build
out
these
layers.
You
add
a
new
patch
layer
on
top
of
the
image
whenever
you
make
a
change,
what
happens
when
the
next
week
goes
by
next
week?
Are
you
just
going
to
go
back
and
start
from.
D
D
K
I'll
throw
one
more
out
there,
which
is
I'm
curious,
where
you're,
seeing
that
of
demand
these
days
for
this
kind
of
tool,
because
usually,
when
I
think
about
these
things,
I'm
used
to
seeing
places
just
say
just
rebuild
it
from
the
beginning
start
back
over
and
go
back
through
our
entire
pipeline.
That
way,
it
hits
the
test
and
all
the
other
stages
of
the
CI
pipeline.
I
Team
we
have
a
couple
questions
in
the
chat,
I
added
one,
because
I
saw
something
in
the
demo
that
made
me
a
little
confused,
so
maybe
I'm
just
not
used
to
looking
at
that
output,
but
I
was
excited
to
see
original
image
and
then
image
Dash
patched,
but
I
saw
in
the
demo
what
looked
to
be
the
same
two
year
two
year
and
I
thought
wait.
It
just
got
patched,
wouldn't
that
date
have
changed
or
unless
that
doesn't
refer
to
that,
and
it
refers
to
something
else.