►
From YouTube: CNCF SIG Security Supply Chain Security 2021-03-05
Description
CNCF SIG Security Supply Chain Security 2021-03-05
B
C
C
C
Okay,
so
for
those
of
you
that
are
just
joining
us,
jonathan
will
be
unable
to
make
today's
meeting.
So
I
am
going
to
step
in
and
assist
so
bear
with
me.
We've
been
making
really
good
progress
on
the
content
for
the
paper.
I
would
like
to
point
out
a
couple
of
things
worth
noting
and
I'll
drop
them
in
the
channel
later
for
items
that
are
specific
recommendations.
C
C
So
we've
got
a
lot
of
really
good
content
in
here.
There's
a
couple
of
areas
that
do
still
need
to
be
cleaned
up,
but
overall
we're
on
the
right
track.
So,
according
to
our
schedule,
by
next
friday,
we
should
be
finessing
the
content
and
we
should
have
most,
if
not
all,
of
the
commentary
cleared
out.
So
any
active
discussions
need
to
be
resolved
associated
with
comments.
Any
suggestions
that
were
placed
in
the
document
need
to
be
reviewed
and
accepted
so
over
the
course
of
the
next
week.
C
If
a
discussion
were
to
highlight,
for
instance,
that
something
isn't
exactly
clear
or
we're
focusing
too
heavy
on
web
applications,
for
instance,
which
is
actually
the
area
that
I've
been
checking
out
this
morning,
so
I
will
type
all
of
that
up
and
drop
it
in
the
channel.
So
everybody
has
notes
for
it.
Does
anybody
have
any
items
for
open.
E
E
There
is
both
pros
and
cons
for
both
authentication
mechanisms,
and
I
I
don't
really
get
why
the
is
a
bit
more
over
for
the
ssl.
That's
why
I
mentioned
some
threats
related
to
personal
access,
token
right
so
yeah.
So
there
is
a
we
mentioned
about
implementation
of
rotation
policy
for
sshk,
but
the
why
you
know
I
I
don't
understand
why
we
don't
need
some
kind
of
flotation
policy
for
a
path
right.
So
path
is
from.
My
from
my
anderson
is
a
shared
secret
and
it
can
have
more
security
risk
compared
to
the
ssh
key.
E
B
Yeah
we
know
thank
you
for
your
question.
I've
tried
to
clarify
this
thing
on
the
comments
as
well.
So
so,
when
we
are
talking
about
pat
right,
we
have
to
understand
that
it
is
a
token,
but
it
the
automated
agents,
do
not
maintain
that
token.
B
Used
to
get
a
oauth
token,
it
itself
is
used,
it
is
not
maintained
by
the
agent,
so
agent
will
not
keep
it
right.
It
is
just
used
to
get
a
oauth
token
and
then
oauth
token
is
used
to
basically
get
get
any
requests
right
or
any
any
kind
of
operation.
Git
related
operation
is
then
performed
by
that
oauth
token,
the
personal
access
token
itself
is
not
maintained
by
the
by
the
agent
or
the
runner.
Okay,
but
again,
the
point
that
I'm
trying
to
emphasize
is
that
we
are
recommending
policies
right.
B
B
B
E
Yeah,
I
completely
get
your
point.
I
said
I.
I
only
have
that
particular
issue
when
we
recommend
one
over
another
like
so
I
was
commenting
where
it
was
a
we
therefore,
you
know
personal
access.
Token
should
be
preferred
over
such
when
we
make
such
a
statement
right.
So
I
think
we
should
have
that
level
of
assurance
why
we
are
doing
that.
Yes,
one
of
the
challenge
I
see
with
the
personal
access
token.
B
But
yeah
so
oauth
works.
This
way.
Oauth
has
two
tokens.
Okay,
once
you
have
received
the
oauth
token,
you
also
get
a
refresh
token
okay.
So
there
are
two
tokens:
okay,
normally
for
every
communication,
you
will
use
your
oauth
token,
okay,
but
before
the
oauth
token
expires,
you
will
use
the
refresh
token
to
get
the
new
token.
You
never
again
use
the
patch
to
get
it.
If
you
have
a
continuously
running
cicd
pipeline.
Of
course
now
can
there
be
out
of
band
processes
that
you
do
not
use
refresh
token?
E
That's
why
I'm
I'm
my
understanding
or
the
personal
access
token
is
similar
to
epic.
It's
not
fought
in
github
or
bitbucket
right
for
all.
There
is
a
client
identity.
There
is
a
client
authentication
in
order
to
get
a
refresh
token
right,
like
there
is
an
initial
authentication
when
you
get
an
access
token
and
the
first
token.
D
Okay,
before
this
turns
into
one
of
those
terrible
like
city
council
meetings
that
happened
on
zoom,
can
we
move
this
to
like
a
thread
inside
of
slack,
and
I
think
it
needs
to
be
a
thread
inside
of
slack,
because
these,
I
will
say
these,
google
doc
comments-
are
not
they're,
not
easy
to
follow.
If
you
can
just
do
a
thread
inside
of
slack,
if
you
write
this
down,
we
don't
have
to
keep
thinking
or
remembering
what
was
said
on
the
call
nobody
has
to
watch
recording
either.
D
C
F
C
Is
I
don't
want
this
to
turn
into
who's,
got
the
best
ide
argument,
because
a
lot
of
that
gets
gets
very
heated.
So
we,
it
is
our
responsibility
to
ensure
that
we
are
presenting
both
cases
and
allow
the
reader
to
make
an
informed
decision.
So
realistically,
if
that
means
adjusting
the
recommendation
to
be,
you
need
to
use
something
and
here's
two
options,
and
here
are
the
conditions
under
which
you
might
use
this
and
here's
the
conditions
when
you
might
use
a
different
one.
C
But
I
would
also
state
that,
just
for
the
record,
personal
access
tokens
in
this
context
need
to
be
explicitly
clear
as
to
how
we're
intending
them
to
be
used
because
pats
can
be
used
in
other
applications
in
different
environments
in
different
cloud
service
providers.
So
it's
one
of
those
items
that
we
need
to
be
very
clear
in
what
we're
talking
about
yeah,
but
I
agree
it
should
be
moved
to
a
thread
in
slack.
I.
D
Think
that's
a
if
you,
if
you
could
vinaid
yeah,
definitely
like,
let's,
let's,
let's
hash
it
out
there.
B
Cents,
so
so
just
to
end
this
discussion
right.
So
if
you
look
at
the
recommendations
right
now,
we
have
recommended
both
ssh
keys
and
also
personal
access.
Token,
it's
not
like.
We
have
completely
disregarded
ssh
keys,
we're
just
saying
that
for
developers
this
will
be
make
more
sense
right
now
and
for
ci,
cd
pipelines
or
agents
access,
token
make
more
sense,
and
then,
in
this
paragraph,
if
you
read
it,
we
have
given
our
arguments
right
and
you
have
to
read
those
arguments
that
why
we
are
preferring
it
over
ssh
right.
B
Shared
concern
is
not
the
only
thing
there
is
expiration
attached
to
a
personal
access
token
and
they
are
randomly
generated
okay.
So
there
are
these
things
which
basically
gives
pet
more
ability
to
operate
more
in
a
least
privileged
model.
Okay,
and
this
is
why
this
recommendation
is
being
both
of
them
are
being
given.
So
I
have
not
taken
any
side
right,
but
I
just
not
can
randomly
say
well,
there's
shared
secret.
There.
G
D
I
mean
okay
yeah,
I
mean,
I
think
I
think.
Ultimately,
one
of
the
things
we
got
to
get
to
is
like
getting
the
gist
so
mike
is
on.
The
call
mike
enzo
is
on
the
call
you
were.
You
were
involved
with
the
the
software
supply
paper
from
google,
I'm
massively
curious
how
you
figured
out
what
what
made
it
into
the
paper
in
terms
of
recommendations
versus
what
fell
on
the
you
know,
floor
of
the
editing
room.
H
Sure
I
think
a
lot
of
it
was
passing
around
so
I
I
wrote
the
paper
pretty
much
the
entire
thing,
and
so
what
I
ended
up
doing
is
like.
I
had
a
lot
of
things
additionally,
that
didn't
make
it.
H
What
I
did
is
I
I
originally
just
put
everything
together
and
started,
passing
it
around
to
the
rest
of
you
know,
colleagues,
and
and
even
some
outside
of
the
company
and
and
had
them,
you
know
kind
of
vetted
like
do
you
also
believe
in
these
things
too,
and
so
whenever
I
had
a
lot
of
the
controversy,
those
are
the
things
I
end
up
pulling
out,
because
you
know
even
in
this
scenario
here
like,
I
don't
believe
that-
or
at
least
I'm
not
entirely
sure
that,
like
access
tokens
are
always
you
know
the
same
between
all
the
source
repositories.
H
What
happens
when
you
don't
use
the
git
repository
stuff
like
that
you're
going
to
have
differences,
so
I
tend
to
like
I
tend
to
pull
those
things
out
and
I
didn't
use
them
as
as
a
I
didn't
put
those
in
as
a
hard
recommendation
of
any
type.
So
I
I
kind
of
thought
like
hit
the
80
20
rule
where
you
know
it's.
If
it's,
if
it's
everybody,
you
know
largely
said,
yeah,
that's
totally
makes
sense
and
I
left
it
in.
D
F
F
I
think
what
we're
doing
here
right,
we're
taking
a
secret
and
we're
tying
it
to
an
identity,
so
so
that
is
what
we
need
to
talk
about,
rather
than
the
specific
method
and
how
we
do
it
right.
F
Hey
these
are
the
implementation
methods
of
doing
that,
but
but
this
is
what
we're
doing
we're
identifying
that
workload
to
pull
that
git
repository
right
or
we're,
saying
hey!
This
person
has
the
ability
to
do
that
right,
so
we're
giving
them
a
secret
to
do
it
so
we're
tying
secret
to
identity.
There's
a
lot
of
different
ways
to
do
that,
depending
on
where
your
risk
club
was.
E
Yes
completely
so
rich,
I
agree
with
your
point.
I
I
definitely
will
continue
discussion
in
the
slack,
even
I'm
not
that
active
in
slack,
so
so
yeah.
So
in
my
opinion,
there
won't
be
always
have
one
thing
for
all
the
problems
right
like
there
won't
be
a
silver
bullet
for
all
that
thing.
So
maybe
there
can
be
a
situation.
E
We
have
to
leave
it
out
one
or
two
or
three,
but
I
am
definitely
we
shouldn't
give
six
seven
ten
options
that
that
make
people
confused,
but
at
least
you
know
there
might
be
pros
and
cons
for
each
and
everything.
I
don't
think
we
should
go
in
details.
I
agree
with
faisal
that
we
should
mention
all
the
key
management,
all
the
problems
and
all
the
threats
and
all
the
counter
measures.
I
think
this
paper
will
go
too
much,
but
you
know
instead
of
that,
maybe
we
can
give
them
two
or
three
options.
E
H
I
kind
of
heard
there
as
well
that
you
know
you
you,
basically
I'm
sorry
I
didn't
see
who
was
speaking,
I'm
still
a
little
bit
new
to
resume,
but
but
I
liked
what
you
said
there
where
it's
like
you
know,
we're
tying
a
a
profile
to
a
secret
or
an
identity
to
a
seeker,
or
something
like
that
so
like
having
that
explanation
before
you
try
to
say
here's
the
recommendations,
it's
more
like
you're
setting
up
the
principle
in
the
interface
for
what
you're
trying
to
describe
and
then
the
implementations
you
can't
have
multiple
of
them
after
that,
because
you've
described
what
that
problem
was,
and
then
here
are
some
ways
you
can
solve
it.
C
No,
actually,
that
was
something
that
we
discussed
previously,
is
the
formatting
of
the
different
sections
which
I'll
I'll
repost,
that
in
the
zoom
or
in
the
slack
channel.
That
way,
everybody
is
aware
of
what
we're
looking
for.
So
the
discussion
on
pat
and
ssh.
Please
move
that
to
the
slack
channel
thread
it
that
way
it
doesn't
blow
up
the
feed
we
need
to
get
that
resolved
before
march
12th.
So
if
that
means
providing
dual
recommendations
or
moving
the
recommendation
to
a
higher
level
and
discussing
those
conditional
options,
let's
go
ahead
and
make
that
happen.
G
We
cannot
do
a
disservice
to
people
who
are
trying
to
put
software
into
places
and
say
saying
we're
going
to
do
it
this
way
and
on
even
take
the
identity
thing
sure,
like
map
identities,
identities,
to
secrets,
call
right
on
that,
but
even
the
order
of
like
well,
which
one
do
you
do
first,
because
if
you're
just
distributing
tokens
to
anything,
that's
been
identified,
you're
back
in
square
zero.
So
how
do
you
test
for
identity
in
first
place?
If
you
put
secrets
first
you're
going
about
it
wrong?
G
D
I
can
I
ask
that
for
the
controversies,
if
I
think
we
should
thread
all
the
controversies
and
I
think
we
should
label
them
I'll,
find
some
sort
of
cute
emoji
to
make
that
happen,
and
I
think
all
of
us
should
weigh
in
one
of
the
things
I
think
we
we
really
should
do
and
andrew
andres.
You
had
a
good
point
about
this.
D
It
should
pass
our
sniff
test
first
and
then
the
I.
The
real
sense
of
satisfaction
should
come
if
outside
security
folks
read
our
recommendations
and
don't
go,
what
are
they
talking
about?
Because
that's
that's.
I
think.
Ultimately,
the
goal
is
to
to
be
concise.
Am
I
wrong
on
that?
Should
we
I
I
I
kind
of
crowd
source
some
of
I.
I
have
a
a
a
big
devops
slack
that
I'm
part
of,
and
I
go
to
some
of
my
my
close
counterparts.
I'm
like
do
you
guys
do
this?
Has
anybody
used
pats
for
for
developers?
F
D
Pats
for
cicd
tools,
fine
but
developers
know
so
just
is
that.
Does
that
sound
like
something
we
should
do?
First?
All
of
us
should
kind
of
agree
that
this
is
a
sensible
recommendation
and
then
eventually
we
we
expose
it
to
the
greater
that
way
when,
when
it,
when
it
does
get
released,
people
aren't
caught
off
guard.
B
So
so,
just
to
add
to
this
point
rigid,
so
we
have
to
under.
So
this
is
my
point
of
view
right.
We
as
a
community
are
gathered
here,
okay
and
we
all
have
different
backgrounds
right.
You
might
be
a
developer
in
the
open
source
community
right
and
you
act
as
a
developer
right,
I'm
more
on
the
enterprise
side
right
and
the
idea
is
that
we
take
recommendations
from
each
other
and
then
incorporate
in
this
document
when
we
say
that
well,
I
go
to
some
place
or
I
have
not
seen
this
thing
right.
B
B
So
if
people
do
not
know
about
something
they
know
about
it.
If
somebody
has
been
using
things
wrong
for
10
years,
we
cannot
say:
okay,
great
job
continue,
11th,
12th
and
13th
here
on
this
one
as
well,
so
we
have
to
combine
opinion
from
both
enterprise
side
and
also
from
the
development
side
and
then
give
these
recommendations.
B
B
Recommends
that
no
so
this
is
where
I
will
tell
you
right.
This
is
where
you
will
take
my
recommendation
right
because
I
come
from
enterprise.
People
do
set
up,
project
templates,
build
packs
and
they
do
define
using
post,
pre,
hooks
and
post
hooks
in
git
repositories
what
what
developers
can
commit.
This
is
what
I
do,
and
I
am
telling
you
if
this
thing
is
not
out
there.
B
I
am
telling
you
because,
based
on
my
experience
in
a
similar
way
as
a
developer,
you
will
tell
me
in
development,
I
use
ssh
keys
more
and
that's
why
we
have
given
the
recommendation
for
ssh
keys
for
developers
right,
but
you
when
you
say
that
I
have
not
seen
it
or
my
community
has
not
seen
it
right.
Then
I
have
no
argument
against
it
right
because
I'm
like
well.
I
have
not
seen
in
total,
for
example,
so
does
that
mean
it
does
not
exist?.
D
Right
right
and
those
of
us
who
work
in
the
enterprise
know
that
there's
a
whole
variety
of
maturity
levels.
The
question
is:
who
do
we
want
to
offend
more?
You
know
like:
do
we
want
people
to
be
looking
at
it
and
saying
this?
Doesn't?
This
is
just
an
added
process
that
makes
sense
in
the
enterprise,
but
maybe
not
for
my
small
open
source
project
and
how
do
we
parlay
that.
C
So
I
would
make
a
recommendation
that
for
instances
of
discussion
or
recommendation
and
justification
within
the
paper
where
there
is
a
particular
enterprise
viewpoint
where
the
impact
is
significant
for
software
producing
shops,
and
that
is
their
goal
and
objective
that
we
need
to
make
sure
that
we
are
clear
in
couching
that
and
associating
the
assurance
and
the
risk
level.
And
if
that
means
that
we
need
to
break
the
recommendation
into
two
corresponding
areas.
C
We
can
certainly
do
that,
while
it
is
still
in
draft
and
then
revisit
upon
a
final
community
review,
because
ultimately,
we
can
have
the
best
most
brilliant
ideas
documented
within
this
paper,
and
we
can
get
it
to
a
semi-final
state.
But
if
it
does
not
hold
up
to
a
community
review-
and
we
cannot
objectively
adjudicate
those
comments
and
suggestions
from
the
community,
we
will
have
to
revisit
the
topic
area
in
question.
C
If
there
is
a
viewpoint
that
is
specific
to
enterprise
or
global
level,
security
for
supply
chain
versus
open
source,
specific
development
or
I'm
just
a
lonely
developer
working
on
a
fun
project,
we
need
to
be
clear
and
the
recommendation,
the
justification
and
the
associated
assurance
and
risk
levels.
That's
why
we
have
that
level
of
assurance
and
those
risk
categories.
So
we
can
separate
those
line
items.
B
So
I
have
to
drop
everyone
yeah,
so
so
please,
just
last
thing
do
check
this
assurance
level
and
risk
categories
with
pets
as
well
so
yeah
and
we'll
follow
the
discussion
up
in
slug
channel
yeah.
Thank
you.
I
have
to
drop
yeah
sorry
about
that.
Thank
you.
Thank.
C
E
Areas
I
think
that
can
be
potentially
another
one,
but
I
haven't
received
anything
so
far.
Yet
right
there,
it's
with
the
software
bill
of
material,
I'm
not
sure
it
is
also
something
you
know
may
not
be
actively
used
in
the
old
enterprises.
So
for
now
we
I
mean,
at
least
in
the
document
I
have
put
both
the
spdx
and
cyclone
dx
right,
but
I'm
not
really
recommending
one
over
another.
So
so.
C
It's
interesting
that
you
bring
that
up,
so
I
had
a
lovely
conversation
with
alan
freeman
from
ncia,
who
is
heading
up
the
s-bomb
effort
concerning
some
of
the
topic
areas
in
the
content.
So
I
have
engaged
with
him
and
requested
that
he
provide
some
insight
and
feedback.
There
are
some
organization,
specific
endorsements
associated
with
one
format
over
the
other
that
we're
going
to
dig
into
probably
offline
to
figure
out.
G
G
I'm
not
inclined
to
do
the
latter
honestly,
because
we're
just
perpetuating
status
quo
and
just
reconfiguring
existing
pieces
versus,
like
hey,
guys,
see
the
light,
and
I
don't
think
anyone
here
is
like
a
lonely
developer
working
on
on
a
fun
project.
Everyone
has
like
a
ton
of
valuable
unique
experiencing
like
a
lot
of
like
large-scale
deployments
working
with
a
bunch
of
other
people,
so
we
should
make
a
determination
on
that.
Well,
I
would
defer
that
to
the
group
to
decide
as
a
whole.
C
Yeah
and
the
community
review
will
actually
help
resolve
a
lot
of
those
items,
especially
if
they're
reading
through
it
and
something
seems
out
of
place
in
some
cases
or
in
previous
documents.
I've
worked
on
we've
provided
a
disclaimer
around
a
few
line
items
where
there
might
be
considerable
differences
for
an
enterprise.
That's
doing
software
software
production
versus
a
shop
that
has
that
is
fully
cloud
native.
So
just
something
to
consider.
G
Yeah
and
like
let's
have
the
debate
on
paper,
make
a
copy
of
the
doc
as
if
you're,
making
a
fork
make
the
edits.
You
want
to
see
and
then
share
that
back,
it's
often
easier
to
come
with
someone
like
hey
here's,
how
we
think
we
can
frame
this
better
rather
than
trying
to
get
someone
to
rewrite
what
they
already
wrote.
That
may
be
personally
attached
to.
C
So
a
quick
reminder,
and
again
I'll
put
this
in
the
slack
channel
that
we
should
be
working
towards
clearing
out
the
commentary
on
the
document
as
well
as
finalizing
any
last
minute
content.
That
needs
to
go
in
and
smoothing
it
out
or
judging
it
to
make
sure
that
it
reads
correctly
that
it's
not
an
incomplete
thought.
C
March
12th,
just
an
initial
first
pass,
not
looking
for
you
to
spend
two
hours,
writing
a
justification
on
an
area.
That's
controversial
to
you
more
just
to
make
sure
that
we've
got
everything
buttoned
up
and
that
we're
not
missing
an
assurance
or
a
risk
level,
or
that
we're
missing
a
format
error
somewhere.
Just
a.
F
F
Please
then,
if
you
could
emily
just
kind
of
slack
me
what
those
individual
tests
are,
so
I
can
make
sure
I
stay
on
track.
I
don't
get
distracted.
H
You
can
jump
in
and
help
make
a
pass
as
well.
If
is
there
a
style
guideline
out
there
to
make
sure
that,
because
I'm
just
new
to
this,
I
don't
want
to
like
try
to
make
recommendations
that
I'm
not
sure
about
either.
C
Yep,
it
will
be
in
the
slack
channel,
so
you
all
have
something
to
go
with.
C
F
You
know
I've
been
I've,
been
thinking
about
this
and
I
think
there's
some
themes
that
we
need
to
pull
out
of
this
and
kind
of
start
thinking
about
the
executive
summary
I
mean
to
start
tying
everything
together
and
I
think
the
theme
of
verification
is
really
important
right.
How
does
everything
tie
back
to
verification
verification
that
the
software
that
the
code
came
from
where
we
know
where
we
think
it
came
from
the
things
were
built
away?
F
We
think
that's
all
the
guidance
that
we're
kind
of
seeing
coming
from
mitre
and
some
of
these
other
places
that
are
putting
out
reports.
I
think
we
should
continue
to
follow
that
and
really
tie
that
all
together,
so
each
one
of
these
points
right,
if
there's
a
way
that
we
can
tie
that
back
into
verification.
F
Let's
work
on
doing
that
like
to
get
some
feedback
on
that
that
train
of
thought,
I'm
not
positive,
I'm
correct,
but
I
think
I
might
be
going
along
the
right
route.
I
Yeah,
I
actually
had
a
somewhat
related
thought
when
looking
at
the
distribution
sections
yesterday,
where
we
have
this
like
separate,
called
out
section
for
how
to
verify
metadata,
but
it
seems
like
that
would
almost
make
more
sense
when
you're
describing
what
the
metadata
is
to
kind
of
tie
that
whole
end
to
end.
You
create
it
here.
You
verify
it
here
process
or
at
the
very
least
just
like
calling
out.
You
know,
no
matter
what
you
generate
or
sign,
or
whatever
make
sure
you
verify
all
of
those
pieces.
F
Like
like
right
now,
we
verify
left
right.
We
verify
like
with
the
cicd
process.
I
think
we
want
to
move
that
to
the
right
as
much
as
possible
and
verify
as
close
to
the
execution
of
that
workload
as
possible,
and
that's
just
kind
of
some
of
my
thinking
that
I
have
going
to
that.
So
that
could
be
like
a
theme
of
this
paper
and
how
do
we
do
that?
How
do
we
have
these
tools
in
these
these
recommendations?
How
does
that
help
support
that?
That
effort.
H
See
I'll
tell
you
one
of
the
things
that
I
did
so
I
heavily
leveraged
our
binary
authorization
concept,
the
idea
that
you
have
like
these
signed
attestations,
and
so
when
you
create
any
of
your
you
know,
so
you
do
the
verification,
the
pipeline
and
you,
you
know,
run
through
some
sort
of
rigor
and
then
you
create
an
attestation
for
that.
As
long
as
that,
artifact
doesn't
change
you
can.
At
least
you
know,
you
know
that
you
got
the
immutability
and
then
your
trust
can
stay
in
there.
H
So
then
the
verification
is
kind
of
a
the
attestations
or
groupings
of
those
are
kind
of
the
proxy
for
that
at
the
execution
time,
and
so
I
did
the
same
thing.
I
just
didn't-
do
a
whole
series
of
them
in
a
in
the
environment.
You
know
I
relied
on
the
attestations
and
the
buildup
of
that
to
transfer
that
trust.
H
H
All
that
kind
of
stuff
is
bundled
into
these
attestations,
and
then
you
can
have
a
policy
that
allows
you
to
you
know
it
allows
you
to
couple
extra
things
too,
like
if
you
do
need
that
break
glass
scenario
like
look,
I
just
got
to
get
something
out
right
now.
You
can,
you
know,
create
a
quick
policy
in
placement
to
replace
that,
and
rather
than
going
in
and
hitting
every
single
tool
to
say
not
only
recheck,
the
validation
software
you
can,
it
gives
you
a
little
bit
easier,
a
point
to
make
changes
for
so
right.
F
F
We
don't
do
any
validation,
out-of-band
validation
of
that
pipeline
and
the
artifacts
and
metadata
from
that
to
make
sure
that's
correct
right,
we're
placing
trust
in
some
administrator
that
configured
a
pipeline,
which
we
all
know
right
as
good
as
we
are
doing
this
stuff,
we
always
make
mistakes,
so
I
really
want
to
emphasize
that
in
this
white
paper-
and
it
sounds
like
either.
Some
agreement
is
consensus
on
that.
So,
if
we
can
push
for
that,
I
think
it
would
really
bring
the
whole
thing
together
and
make
it
more.
H
Cohesive
so
yeah
I
like
it.
In
fact,
that's
actually
one
of
the
areas
that
I
didn't
get
to
address
my
paper,
because
I
don't
have
a
good
answer
for
and
now
that
there's
a
really
cool
community.
I
can
ask
it
at
some
point
here,
but
it's
the
I
can
easily
get
around
things
in
a
cic
pipeline.
If
I
have
access
to
it,
I
can
literally
just
redefine
something
and
override
it
and
just
bypass
all
the
security
things.
H
C
C
F
And
I
think
we
should
maybe
do
a
poll
see
how
many
hours
we
have
next
week
to
work
on
it,
and
you
know
people
on
this
call
and
then
kind
of
make
a
decision
from
there.
So
right
now
I'll
start
I
have
six
hours
blocked
out
on
wednesday
for
that
and
zero
the
rest
of
the
week.
E
Emily,
I
just
want
to
add
right:
there
are
some
areas
which
are
not
still
a
still
missing
main.
You
know
items
like
a
distribution
of
s
bomb.
I
don't
know
who
took
ownership
of
that
like
couple
of
weeks
before,
but
there
are
few
items
like
that.
I
think
we
need
more
content
and
I
don't
know
if
someone
else
is
interested
to
jump
in
and
help
with
that
content.
Maybe
you
know.
C
E
E
I
did
reach
out
to
some
other
people
as
well
in
the
background,
but
you
know
everybody's
busy
right.
So
that's
the
problem.
I
also
asked
some
other
people,
but
I
think
there
were
a
few
other
individuals
during
the
call
like
two
three
weeks
ago
from
eon
channel
or
you
know
they.
They
told
that
they
can
help
but
seems
like
they
may
be
busy
or
they
are
not
available
at
the
moment.
But
you
know
if
someone
else
is
still
interested
in
those
areas.
Maybe
if
you
can
have
some
content
that
have
things
ready.
C
C
E
C
All
right,
let's
try
to
get
that
done
if
there
are
areas
during
your
reviews
and
commentary,
cleanup
that
are
grossly
lacking
in
content,
go
ahead
and
highlight
them
yellow,
and
I
will
make
sure
that
I
add
that
into
the
notes
from
today
and
drop
it
in
the
slack
channel.
That
way
we
can
get
that
taken
care
of
right.