►
From YouTube: CNCF Security TAG Supply Chain WG 2021-07-22
Description
CNCF Security TAG Supply Chain WG 2021-07-22
A
B
A
C
B
B
E
B
All
right,
so
I
think
we
have
a
good
number
of
people
and
right
now,
just
a
couple
more
that
still
connecting
and
audio
connected.
So
let's,
let's
get
started
so
just
just
a
quick
update,
I'm
going
to
put
in
the
link
to
the
document
as
usual.
These
are
meeting
notes,
so
we
we
have
a
a
couple
kind
of
high
level
things
to
do
and
update
about,
and
also
I'd
like
to
before
we
dive
into
the
details
as
well.
B
B
D
B
Yeah
so
yeah
we
have
to
brandon
says
over
here
we
have
to
be
a
bit.
It's
gonna
be
a
bit
tricky,
so
another
thing
that
we've
done
so
a
couple
of
us
offline.
We
met
together
and
talked
about
just
between
you
know
the
pms
and
and
a
couple
folks
here
we
talked
about
you
know,
taking
a
look
at
what
we
had
in
terms
of
the
user
stories,
kind
of
drawing
from
all
the
different
presentations
that
we've
had
and
start
to
kind
of
create
an
outline
for
the
document.
B
So
we're
going
to
talk
a
little
bit
about
what
we
have.
So
if
you
scroll
down
a
little
bit,
you
can
see
some
information
about
what
the
overall
structure
of
the
the
reference
architecture
paper
would
look
like,
and
you
can
already
see
in
like
some
filled
in
details,
we're
going
to
go
through
that
in
a
little
bit.
B
But
we
spent
some
time
looking
at
that
trying
to
create
something
where
we
can
start
working
on
and
developing
with
the
hopes
to
to
to
get
something
concrete,
something
there,
because
I'm
moving
forward
with
and
then
towards
the
end.
We'll
talk
about
contributing
a
donk.
We
do
some
interactive
brainstorming
here,
how
we
can
contribute
to
the
the
document
and
all
the
aspects.
So
the
idea
is,
you
know.
Once
you
have
a
good
foundation,
you
can
start
putting
the
reverse
architecture
together.
B
B
B
So
what
we
have
here
is
come.
We
took
the
previous
mission
and
the
scope
that
we
had
and
we
kind
of
brought
it
forward
here
again,
just
a
reminder
what
the
reference
architecture
is.
We
have
this
nice
picture
here
that
you
know
it's
from
the
supply
chain:
security
by
paper
that
we're
going
to
use
in
reference
as
we
are
starting
to
build
all
these
things
together.
B
F
F
D
And
one
point
here
I
think,
like
I
said
it
was
taking
all
the
meeting
notes
and
concatenated
to
actual
like
tasks
like
that's.
I
think
the
our
major
thing
yesterday
that
that
brandon,
michael
and
andres
and
myself
kind
of
did
was
just
make
this
more
of
a
functional
like
almost
summary
of
what
we
need
to
do.
So
that's
it.
B
B
B
Hello:
okay,
cool,
okay,
oh
rsi,
right
so
scoping
in
terms
of
technology
and
gaps.
We
talked
about
so
that
ideas
like
if
something
is
not
not
really
achievable
today
or
there's
a
lack
of
knowledge
in
the
area.
For
the
sake
of
argument,
reproducible
builds
you'll
say
that
you
know,
because
there
are
these
things
which
may
not
be
in
scope.
B
Today,
however,
we
have
this
section
at
the
bottom
that
says
future
considerations
and
iterations
that
talks
about
the
things
that
we
are
going
to
say
for
this
current
reference
architecture
is
our
scope.
Y
is
our
scope,
but
why
the
same
time
we're
talking
about
these
because
they
are
important
factors
that
should
be
considered.
B
Here
are
some
principles
that
we
follow.
Where
you
know
in
terms
of
technology
and
tooling,
you
know
we,
of
course
we
favor,
you
know
cncf
open
source
generic
in
that
order,
and
also
we
have
general
anti-patterns,
like
you
know,
patented
anti-patterns
right.
So
you
should
harden
things
when
it's
possible.
You
should
do
immune.
You
should
do
immutable
immutability
as
much
as
you
can
think
of
that.
B
So
so
this
is
going
to
be
kind
of
like
the
high
level
talks
about
the
document,
and
then
we
have
the
overall
architecture,
goals
and
stories.
So
this
is
really
how
it's.
This
is
going
to
be
the
major
structure
of
the
reference
architecture,
so
we
discussed
a
few
things.
The
main
things
were
providence
for
build
architects.
Things
like
that.
B
B
B
I
think
we
kind
of
found
these
categories
to
kind
of
represent
most
of
what
we
were
talking
about
and
I'm
going
to
quickly
go
through
the
rest
of
the
structure
of
the
paper,
and
then
I
want
to
hand
it
over
to
to
michael
and
and
andrews
and
dan,
to
kind
of
start,
the
brain.
Stopping
the
discussion
of.
Let's
talk
about
some
of
these
things,
whether
we
should
add
things
in
whether
we
should
reword
them.
You
know
what
are
some
things
that
we
may
be
missing:
brandon.
D
B
G
C
A
Yeah
cool
thanks,
I'm
just
sorry
as
a
complete
new
comment
to
this
group.
I
think
this
is
my
second
meeting
yeah.
I
landed
on
the
trailer
board
and
I
wasn't
entirely
sure
where
to
start-
and
I
think,
if
we'd
linked-
maybe
to
this
to
this
overall
plan,
that
sort
of,
as
you
were
saying,
tries
to
give
the
big
picture
of
what
we're
trying
to
achieve
that.
Would
that
would
really
put
things
in
perspective
and
be
really
helpful.
C
And
michael
I'm
in
agreement
there,
but
I
feel
the
reference
architecture
is
much
more
detailed
right.
So
for
this
diagram
up
there,
it
shows
the
overall
cicd
pipeline,
but
all
the
controls
etc,
that
we
need
to
build
around
that.
I
think
we'll
have
a
follow-up
diagram
which
lays
out
all
the
security
controls
and
other
controls
that
we
need
to
lay
on
top
of
it
like.
I
think
it.
D
Was
I
think
it
was
more
like
a
it's
almost
like
a
win,
an
overview
kind
of
slo,
graphic
or
illustration
right,
of
course,
that
that's
not
the
reference
architecture?
I
totally
agree
like
the
idea
here
is
that
once
we
do
figure
out
like
which
components
we're
going
to
actually
use
and
brandon,
if
you
can
scroll
down
to
the
bottom,
I
kind
of
put
a
I'm
I'm
I'm
kind
of
skipping
around.
But
if
you
see
here
right
that
diagram
will
be
based
on
some
of
these
things
right.
D
So
we
have
this
requirement,
and
this
is
whatever
tools
we
do
here
and
the
one
thing
we
want
to
make
sure
is
that
we're
agnostic
right
so
meaning
we
still
have
to
any
reference
architecture
has
to
have
some
type
of
suggested
opponent
component,
but
we
also
want
to
be
able
to
have
an
alternate
component.
If,
like,
let's
just
say
something
is
you
know
specific
to
a
specific
technology
that
a
legacy
technology
can
adhere
to
right
and
so
right
now
to
completely
completely
agree
with
you
that
top
one
was
more
like
window
dressing
to
say
look.
D
D
D
Yeah
we
have,
but
the
things
with
reference
architecture.
We
can't
talk
in
conjecture
of
what
you
know
in
terms
of
what
a
a
we
need
to
be
very
specific
on
a
reference
architecture.
This
isn't
like
a
best
practices,
doc,
we've
already
written
that
for
security.
We
have
to
be
specific
on
which
either
projects
or
products
we're
going
to
be
using
here.
But
that's
why
I
added
that
column
for
alternative
right.
D
C
D
I
ideally
yes
and
then
we'll
also
provide
an
alternate
because
again
like
there
might
be
some
solutions
that
are
very
specific.
The
cloud
native
that
do
not
work
in
you
know
that
don't
work
from
a
legacy
perspective.
That
was,
I
think,
a
concern
that
like
andres,
had
had
as
well.
I
don't
know
if
you
want
to
add
more
context
to
that.
F
I
I
just
rewarded
the
language
around.
The
notes
of
cncf,
where
applicable,
is,
is
the
preference
now
we're
we're
writing
this
at
this
point
in
time,
and
a
lot
of
it
is
temporal
like
software
changes
fast,
a
lot
of
people
are
working
very
interesting
things.
We're
gonna,
try
to
strive
to
say
here
is
the
the
best
reference
that
that
captures
or
performs
this,
but
that
might
change
right.
The
picture,
though,
could
have
several
interpretations.
F
You
could
say:
oh
that's,
the
those
are
the
system
internals
of
a
monolith
that
does
we
don't
want
this
right.
One
of
the
goals
here
is
here
is
not
not
to
be
something
subjective
for
someone
in
any
of
our
respective
organizations
to
hit
us
up
and
say,
hey,
I
I
implemented
your
zero
trust
supply
chain.
Come
have
look
and
you
take
a
peek
as
like.
No
you
did
it.
This
looks
nothing
like
it.
This
doesn't
follow.
This
is
actually
not
secure.
There's
a
lot
of
liability.
F
Here's
I
don't
know
like
we're,
wrote,
what's
we've
implemented,
what's
in
your
in
your
architecture,
so
while
well
we're
not
and
and
the
role
of
compliance
or
conformance
for
an
architecture
that
doesn't
exist
yet
we
should
try
to
make
it
very
clear
and
very
discreet
and
and
well
understood,
and
in
some
areas
there's
going
to
be
explicit
gaps
and
say:
hey
we
we
are.
This
is
how
this
is
like
the
desired
end
state.
There
is
not
a
particular
tool
that
performs
this
today
that
it's
available
upstream,
but
it's
what
we're
trying
to
fill
in.
A
E
I
think
so
what
you're
talking
about
right
is.
We
talked
about
policy
in
that
paper
about
what
we
need
on
what
what
needs
to
be
implemented
right
and
that
might
look
at
some
of
your
controls,
like
fisma
or,
if
you're,
you
know
any
of
your
federal
fed,
ramp
or
whatever
right.
Maybe
we
can
implement
that
as
policy
as
code
in
this
reference
architecture,
where
possible
or
say
that
hey
this,
this
item
would
be
an
administrative
policy
that
needs
to
be
checked
out
about.
B
F
H
I
H
H
F
F
It
is
intended
to
be
modular
and
extensible,
but
perhaps
there's
there's
a
progression
to
get
there
and
I
don't
know,
maybe
we
can
take
a
page
from
kubernetes
because,
like
five
years
ago,
if
you,
if
you
came
into
an
enterprise
and
say,
oh,
you
want
to
modernize
your
infrastructure,
you
just
have
to
do
kubernetes.
They
would
have
said
like
no
talk
to
me
about
the
valley
prop
and
the
benefits
like
how
do
I
get
there?
But
how
do
you
think
about
that.
I
A
Sorry
for
the
most
yeah,
I
would
tend
to
agree,
I
think
there's
only
there
can
be
a
value
in
being
like
all
or
nothing.
It's
the
value
of
example.
You
can
by
showing
something
that's
fully
done
and
fully
complete.
You
can
say
this
is
what
it
looks
like
when
it's
fully
implemented
anything
less
than
this
won't
give
you
the
maximum
security.
You
can
hope
for.
That's
really,
that's
that's
the
only
value
I
can
see
in
that.
But
most
of
the
time
I
think,
walk
you
know.
A
A
D
D
F
E
Yeah
well,
it
begs
the
question,
then:
what
does
that
look
like?
Where
do
you
start
right?
And
I
see
that
it's
comment
about
the
slsa.
I
think
that
that's
a
good
kind
of
document
that's
already
out
there,
that
we
can
take
a
look
at
and
see
how
how
they
did
it
and
what's
what
their
different
levels
are,
and
how
that
maps
to
the
cloud
native
landscape
and
see
if
it
fits
salsa.
D
E
F
B
B
I
think
the
way
we
want
to
do
it
is
really
it's
going
to
be
free
from
initially
where
everyone
just
adds
in
what
you
think
is
going
to
be
a
component
of
what
should
be
essential
actions
of
the
supply
chain,
and
then
you
know
we'll
review
all
of
them.
They'll
go
through
them,
we'll
map
them
back
to
the
overall
architectural
goals
and
stories,
and
that
should
give
us
in
our
basic
structure
we'll
come
together.
B
Yeah,
I
think
for
now:
let's
do
this
document.
Okay,
yeah
right
now
we
have
it
kind
of
unstructured
if
you
put
something
in,
and
you
think
it
maps
onto
particular
stories
of
the
supply
chain.
They're
talking
about,
for
example,
providence
verification,
you
can
kind
of
just
put
a
small
bracket
by
the
side,
that'll
be
helpful
as
well,
but
yeah.
B
D
D
H
I
can
go,
I
think,
honestly,
like
it
makes
sense
to
me.
I
kind
of
agree
with
like
the
major
components
and
kind
of
like
the
high
level
diagram.
I
think
a
lot
of
it
corresponds
like
pretty
well
to
the
demo
I
gave
a
few
weeks
ago,
which
is
why
it
sounds
like
pretty
reasonable
to
me.
Overall,
I
think
this
looks
like
a
great
starting
place.
It
has
a
great
list.
D
Ultimately,
we
want
to
kind
of
put
folks
names
to
this
right,
meaning
like
to
take
a
look
and
do
the
review
and
make
sure
that
everything
is
copacetic
not
only
from
the
implementation
perspective,
but
also
like
from
the
verbiage
and
all
that
fun
stuff,
because
this
should
be
a
natural.
I
think
that
john
mentioned
earlier
some
natural
accompaniment
to
the
document
that
we
have
where
we're
actually
instead
of
saying
this
is
what
you
should
do.
It's
here,
we're
showing
you.
This
is
what
you
should
do.
That
should
be
our
overarching
mission
here.
D
G
Yeah,
I
was
just
going
to
say
I
I
think
one
of
the
things
I
think
that
would
help
myself
and-
and
I
hope
would
help
others
as
well-
is
even
just
sort
of
drawing
up
a
diagram.
Some
flows
of
what
this
thing
should
look
like
you
know,
and
it
can
be
very
high
level
not
talking
about
necessarily
particular
tools
at
this
moment,
but
just
saying
you
know,
I
have
some
source
code,
I'm
doing
some
stuff.
G
It
goes
through
a
process
describe
what
that
process.
Largely
looks
like
based
on
a
lot
of
the
stuff
that
we've
talked
about
in
the
supply
chain,
security
white
paper,
and
it
should,
you
know,
create
this
output,
that
output
being
something
like
a
an
artifact,
with
some
level
of
attestations
associated
with
them
and
and
a
level
of
provenance
and
and
whatnot,
and
then
from
there.
I
think
it'll
help
us
dive
in
a
little
bit
more
to
figure
out.
You
know
what
tools
is.
This
are
going
to
work
with
this.
G
F
This
this
is
just
me,
I
don't
think
it.
It
might
turn
out
to
be
the
case,
but
I
have
the
presumption
that
there's
going
to
be
a
split
of
a
lot
of
folks
wanting
to
jump
into
like
what's
going
to
be
the
byproduct
of
of
this
supply
chain.
So
we're
going
to
talk
about
reproducible
builds,
but
should
should
the
machinery
should
the
robots
that
make
up
the
system,
be
reproducible.
F
So
there's
gonna
be
like
a
split
of
dimensions
of
like
yes,
we're
gonna
like
try
to
dictate
like
the
architecture
by
the
outputs
it
should
produce,
but
there's
also
a
lower
dimension
of
well.
What
are
the
attributes
of
the
components
that
make
it
up?
Should
they
all
all
have
like
commonality
of
like
being
the
way
that
we
secure
these
things?
We
probably
don't
want
to
want
people
like
tinkering
with
a
lot
of
manual
configuration
and
like
manual
hardening.
G
F
Yes,
exactly
because
we're
calling
this
a
a
secure
supply
chain
right,
the
architecture
of
a
secure,
some
others
have
called
it
a
secure
software
factory
right
like
should
that
factory
have
a
readiness
scanner
on
the
front
door.
Should
there
be
like
guardrails
and
fail-safe
mechanisms
on
on
the
like
machinery.
B
Coming
up
with
this
high
level
action
flows,
we
should
consider
those
things
and
I
think
more
more
is
better
for
now
and
then
this
is
something
that
we
can
take.
Take
a
look
at
together
as
a
group
and
then
kind
of
decide
whether
it
should
be
whether
it
should
fit
in
here.
Maybe
we
can
put
into
guiding
principles
and
somewhere
else
right,
but
I
think
what
interest
is
important,
where
I
think,
when
we're
building
these
action
flows,
we
should
as
much
as
possible
take
into
account.
You
know
a
high
level
of
security.
D
So
how
about
make
those,
I
think
those
we
should
make
these
kind
of
concerns
items
on
the
dock
as
of
right
now,
because
again,
this
this
document
can
probably
be
50
pages
long,
but
we
need
an
action
and
that's
create
a
reference
architecture
right.
So,
let's
talk
today
about
what
it
is.
We
need
to
do
chief
architect,
michael
lieberman.
What
do
you
think
we
need
to
do
here,
sir?.
G
My
suggestion-
and
I
think
I
I
mentioned
it
a
few
minutes
ago-
is-
I
would
like
to
just
kind
of
build
a
diagram
with
some
boxes.
Right
with
you
know
what
this
flow
should
generally
look
like,
because
then
I
think
that
helps
out
with
some
of
those
other
questions
we
want
to
answer
like
okay,
how
do
we
secure
those
boxes?
What
should
go
in
those
boxes?
I
think
those
things
will
be
useful
and
also
how
do
we
prioritize,
which
boxes
you
know,
need
the
most
work
right
now
and
and
whatnot.
F
B
Yeah,
so
so
I'm
thinking
that,
just
to
better
illustrate
this
idea
right,
maybe
why
don't
we
kind
of
talk
about
what
one
of
these
action
flows
may
look
like,
and
then
I
think
if
we
can
get
folks
to
sign
up
to
start
developing
action
flows
for
particular
aspects
of
the
overall
architecture
and
and
sorry.
I
think
that
would
be
a
good
progress
for
for
the
week.
G
Not
one
I
can
share
right
now,
but
hopefully
there's
something
I
can
share
a
little
bit
in
the
future.
That
is
relatively
generic,
but
I
think
we
can
probably
just
start.
You
know
getting
started
there.
I
think
so
there
are
some
good
things
from
the
supply
chain:
security
document
that
can
act.
As
you
know,
a
good
sort
of
baseline
for
us
to
sort
of
you
know,
base
vocabulary
on
and
and
those
sorts
of
things,
but.
A
G
You
know
that's
more
or
less,
you
know
what
I'm
thinking
and
somebody
correct
me
if
they
think
that
maybe
more
of
an
action
flow
sort
of
like
an
actual
sort
of
like
a
flow
of
you
know,
a
thing
should
go
here
and
then
here
and
then
here
or
more
of
like
a
architectural
sort
of
like
you
know,
I
pull
artifacts
from
here
and
I
do
these
things
and
you
know
I
sign
this
and
then
push
that
to
that.
You
know
to
a
build
system
and
you
know
whatever
I'm
open
to
either.
D
G
Oh
sorry,
yes,
yes,
yes,
yeah,
no,
and
it
could
just
once
again
be
very
high
level
like
we're
not
necessarily
saying
tekton
per
se.
We
are
saying
cicd
right,
you
know
we're
not
necessarily
saying
you
know,
I
don't
know
like
jfrog
artifactory,
we're
saying
artifact
repository
whatever
you
know
something
like
like
that
in
in
a
document,
and
then
I
think,
it'll
help
us
sort
of
engage
on
what
are
the?
What
are
the
items
that
actually
consist?
G
You
know
what
what
does
a
software
factory
consist
of,
or
what
does
the
secure
plot
supply
chain
actually
consist
of
at
a
high
level?
And
then
we
can
start
poking
around
about
like
what
you
know.
What
sort
of
work
needs
to
be
done
for
the
arrows?
What
sorts
of
component,
what
sort
of
actual
tools
can
be
used
to
fill
those
boxes?
Are
there
any?
You
know
known
general
gaps
like
no
tool
seems
to
fit
this
box
and
we
need
to
write
something
or
we
need
to
think
of
another
way
to
do
it.
B
G
Do
you
does
anybody
think
that
there
there's
a
need
for
even
the
higher
level,
like
just
a
a
like
some
high-level
boxes
like
what
I
think
it
was
john
posted
in
in
slack
there?
Maybe
one
level
below
that
of
just
saying
you
know
a
secure
architecture,
for
this
thing
is
going
to
require
source
source
code
control,
it's
going
to
require
an
artifact
repository,
and
then
we
can
dive
in
it's
going
to
require
a
artifact
repository
with
these
sorts
of
characteristics.
That
are,
I
think,
more
of
that
level.
G
Downflow
of
you
know
from
a
distribution
and
storage
of
artifacts
perspective
and
so
on,
but
even
just
kind
of
highlighting
some
of
those
boxes,
and
it's
probably
going
to
look
very
very
generic.
Just
like
you
have
some
source
code
control.
You
know
you,
you
pull
that
down
you.
You
know
you
run
it
through
some
ci
cd,
you
store
the
artifact
in
an
artifact
repository
and
so
on,
and
then
the
level
down
is
hey.
Yeah
the
artifacts
are
getting
signed.
C
D
Iterate
these
blocks
and
processes
every
week
and
again
make
sure
that
folks
are
chiming
in
this
is
not
like.
It's
also
been
a
asynchronous
stock
that
you
can.
You
know
update
as
as
the
time
goes
as
well,
and
just
I,
what
I
hate
to
see
is
only
like
michael
working
on
the
aspects
of
this
right,
we'd
love
to
see
some
some
input.
So,
if
you're,
not
if
you're,
not
comfortable
kind
of
chiming
in
here,
just
make
sure
that
maybe
either
in
the
slack
channel
or
in
the
docs
a
yellow
on
this.
F
F
B
Also,
we
have
quite
a
we
have
most
of
the
categories.
For
that
I
see
some
that
have
multiple.
I
think,
that's
fine.
I
think
you
can
have
a
discussion
within
yourselves,
whether
you're
on
the
out
how
to
split
things
or
you
know.
I
think,
if
you
have
an
offline
discussion
to
figure
out
whether
you
can
agree
on
some
split
of
the
different
components
or
different
types
of
actions
or
if
you
want
to
get
together
and
work
on
it.
A
F
G
Yep
and
I'm
also
as
far
as
like
specific
stuff,
I've
done
a
lot
of
work
with.
I
have
done
a
lot
of
work
with
securing
build
environments
themselves,
so
I'm
also
comfortable
with
taking
a
little
bit
more
of
a
deeper
dive
there.
But
if
somebody
else
wanted
to
take
that
one
I'd
definitely
be
willing
to
sort
of
you
know,
somebody
else
can
take
it
fantastic.
A
Stuff
that
I
want
to
work
on
is
not
finished
yet,
and
so
it's
like
the
container
image
signing
and
the
artifact
stuff
there's
still
notary.
V2
is
still
in
work.
Artifact,
spec
and
oci
is
still
in
work,
so
I'm
not
sure
how
that's
going
to
apply
to
us
since
it's
still
being
developed
on
the
other
side.
F
A
F
Yeah
things
things
there
are
super
fluid
I've
been
trying
to
keep.
My
finger
on
the
pulse
would
be
good
if
we
like
could,
even
if,
if
you're
up
and
close
to
it,
if
you
could
write
some
language
around
it
like
hey,
this
is
rapidly
evolving,
keep
an
eye
on
like
this
three
things
for
like
these
three
repositories.
F
If,
if
you
provide
like
an
explanation
of
of
the
direction
things
are
heading,
I
think
it
will
help
shape
shape
this
up
nicely
like
what
what
special
considerations
to
pick
to
pay
to
whatever
and
end
ups
become
ends
up
becoming
the
signing
and
verification,
spec
or
standard
an
implementation
go
with
it.
Yeah,
marina.
I
B
H
A
A
Right
right,
so
we
are
evaluating
and
looking
at
building
and
workload
at
the
station
that
actually
validates
and
verifies
the
outcome
of
the
signing
and
all
the
build
process
and
how
to
integrate
that
with
the
runtime
attestation
process
for
for
workload
whenever
they
are
fetching
an
svid.
So
that's
what
we
are
looking
for.
Okay.
Thank
you.
I
like
that.
I
D
F
B
Let's
do
it
so
andrus.
Can
you
shut
up,
or
at
least
like
figure
out
the
organization
for
the
storage
and
distribution
since
there's
a
lot
of
people
there
yeah
and
then
for
the
providence?
I
think
they're,
the
one
providence
for
build
artifacts.
I
can
create
a
chat
with
everyone
and
we
can
figure
out
how
we're
going
to
split
that
as
well.
F
I
I
wouldn't
mind
working
on
the
the
cicd
pipeline
components.
It
wasn't
the
bottom
of
the
define
section,
I'm
not
on
the
dock.
It's
further
down.
I
thought
csd
pipeline
security.
Okay,
you
got
it.
I
can
I,
but
I
can
certainly
provide
input
anywhere,
but
that's
kind
of
an
area
that
I
would
I'd
like
to
work
on.
D
I
D
F
A
Alex
sorry,
I
had
to
find
the
mute
button.
I
I
I
put
my
name
down
around
the
dependencies
question
and
I'm
also
happy
to
help
with
michael
on
the
sort
of
high
level
diagram.
If
he's
looking
for
more
help
on
that,
and
then
I
will
just
kind
of
jump
in
as
as
I
see
places
where
I
think
I
might
be
able
to
contribute
sweet.
A
H
B
F
B
Yeah
so
quickly,
logistically,
I
think
we'll
create
threads
for
each
of
these
topics
within
the
main
slack
channel.
Like,
like
john
said,
you
know,
let's
try
and
keep
everything
public
as
possible,
so
others
can
chime
in.
Let's
see
where
we
are
next
week.
If
we
feel
like
it's
useful
to
spend
the
time
to
just
do
some
work,
we
can
have
some
breakout
sessions
for
next
week's
meeting.
Instead.