►
From YouTube: End Users Working Group (March 16, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1KQalBRzfRBvsqh73JUYfp1KG-AJdXcv2Z8LTIFoQP8c
B
C
B
E
D
D
D
Now,
if
anyone
has
anything
specifically
I'd
like
to
add
to
the
agenda,
please
do
so.
It
is
pretty
light
at
the
moment.
I
haven't
had
a
great
deal
come
through.
The
general
idea
of
talking
to
a
couple
of
people
was
that
we
would
look
at
the
architectures.
We've
been
reviewing
and
use
this
as
a
working
session,
but
I'd
like
to
put
things
in
front
of
that
in
terms
of
any
updates.
First.
A
D
D
C
D
Let's
go
through
it,
then.
So,
since
we're
going
to
do
a
working
session,
that's
one
of
the
items
on
it.
I
thought
we'd
start
with
updates
from
the
from
the
group,
any
particular
working
groups
that
people
have
been
to
since
last
session.
That
was
instructive
and
would
like
to
talk
to
the
rest
of
the
end
User
Group,
about
any
any
updates
from
anyone.
G
G
E
And
to
to
chime
in
a
little
bit
on
this
issue,
it
or
Chrome
got
stuck
in
some
weird
s-bomb
politics,
and
so
I
did
not
want
sisa
to
weigh
in
because
there
were
some
weird
people
that
were
brigading
in,
but
essentially
our
take
is
there's
two
key
talking
points.
One
is
that
sisa
does
like
csaff
for
vulnerability
announcements
right,
it's
as
we.
E
This
working
group
is
willing
to
make,
and
so
that's
that's
our
take
on
this-
we're
still
going
to
be
pushing
csaf
as
the
bigger
vulnerability
model.
If
the
cloud
native
world
says
we
want
to
generate,
you
know
a
Vex
a
minute,
and
so
we
need
something.
That's
super
lightweight
and
not
as
clunky
great
as
long
as
anyone
who
cares
can
intake
this
and
intake
other
formats
and
cross-pollinate.
G
H
Oh
yeah
I
just
wanted
to
give
well
when,
when
the
time
comes,
I
want
to
give
an
update
for
this
group
about
what's
happening
in
s2c2f.
But
but
if
we're
comment
on
this,
it's
a
caveat
to
what
both
Chrome
and
Alan
just
said.
You
know:
I've
been
I've,
been
in
in
both
places
and
I
and
I'm
right,
I'm
right
there,
with
with
crawl
with
with
the
issue
and
the
fund
that
has
been
sued,
I'll
just
say,
and
it's
the
caveats
without
just
there's.
H
G
D
H
This
working
group
on
those
efforts,
as
well
just
to
make
sure
that
the
eyes
are
dyed
and
T's
across
in
terms
of
what
end
users
would
want
to
want
to
see
and
training
modules,
as
we
finalize
our
outline
to
go
before
SKF
to
for
the
modules
to
be
developed.
So
you
know
you
know,
our
meetings
are
on
the
calendar.
H
It'd
be
great
if,
if
we
get
people
to
attend
once
inside
of
that
to
attend
and
then
help
us
further
develop
and
and
then
dot
eyes
and
cross
teams,
but
once
we
get
to
a
finalized,
State
I
would
like
the
opportunity
to
bring
before
this
working
group
as
individuals.
That
would
probably
be
the
best
group
of
of
people
to
to
take
the
training
to
say,
hey
this
works,
but
this
doesn't
work
so
I
wanted
to
bring.
F
H
H
Yeah,
absolutely
so
I
saw
it
like
I,
said
SK
up
and
SKR
fox
said:
I
also
attend
the
best
practices
working
group
so
that
we
have
an
SKF
singing
that
working
group
on
Glenn,
Randall,
Tom
and
he's
in
division
of
the
ones
that
Adrian
and
I
have
been
speaking
to
and
also
we've
brought.
This
before
are
sick
and
have
and
had
you
know,
a
lot
of
a
lot
of
Hands-On
in
the
state
to
develop.
H
The
outline
I
think
it
would
be
great
for
this
working
group
depending
on
on
that
as
well,
just
just
to
make
sure
that
all
eyes
are
gone
and
T's
across,
and
you
know
everyone
is
aware
of
of
what's
going
on.
What's
going
on
with
that.
So
that
is
a
call
to
action
from
this
working
group.
Please,
you
know
join
in
and
then
I
I
will
be
formally
asking
to
present
to
this
working
group
so
that
this
working
group
is
abreast
of
the
training
and
can
have
a
weigh-in.
H
Since
we
have
the
resources
weigh
in
on
what
type
of
whether
or
not
there's
certain
elements
that
aren't
there,
that
should
be,
or
if
there
are
too
many
elements
there,
that
we
can
leave
out
for
later
on
training
right,
so
we're
considering
an
introductory
Level
Training
and
then
an
advanced
training
later
on.
What
does
that?
I
D
E
The
next
step
is
when
to
issue
a
vex
short
answer
is
whenever
you
want
to,
but
we
want
some
guidance
around
hey.
These
are
some
things
that
will
help
you
krobe
is
helping
with
that,
because
we
also
want
to
sort
of
acknowledge
it.
There
are
some
differences
between
proprietary
and
open
source
without
privileging
one
or
the
other.
The
we
heard
from
on
on
Monday
the
sharing
group
about
d-bomb,
which
is
now
a
Linux
Foundation
project.
E
It's
an
access,
control,
overlay,
Network
for
moving
supply
chain
data
around
and
they're
just
trying
to
walk
through
some
of
the
use
cases
there
and
then
the
on-ramps
and
adoption
has
been
focusing
on
some
guidance
for
procurement
or
acquisition.
Depending
on
how
you,
your
organization,
uses
it,
the
Cloud,
the
Cloud
team,
is
starting
to
think
about
attestations.
E
So,
if
we're
not
going
to
share
s-bomb
data
live,
how
do
you
say
that
I
have
things
and
what
things
do
you
want
to
say
that
you
have?
This
is
a
big
issue.
It's
a
messy
issue.
It
sails
very
close
to
the
wind
for
executive
order,
14028,
so
we're
trying
to
make
sure
there's
a
little
firewall
there
and
the
tooling
working
group
is
talking
about
s-bomb
quality.
How
do
we
make
sure,
or
how
do
we
start
to
say
that
an
s-bomb
is
not
an
s-bomb?
E
E
Oh
and
the
last
thing
sorry
is
plug
fests,
which
is
probably
not
as
relevant
to
hear
but
sort
of
showing.
This
is
in
a
an
exercise
to
show
interoperability
between
the
outcomes,
outputs
of
different
types
of
s-bomb
tools,
and
so
right,
a
lot
of
your
organizations
are
going
to
be
getting
tons
of
data
from
different
tool
providers.
It's
gonna
be
a
real
pain
in
the
ass.
If
you
have
to
do
anything
manual
or
even
pre-automatic
pre-digestion.
So
we
want
to
make
sure
that
there's
some
harmonization.
A
Were
you
on
the
end
of
that
Friday's
public
policy?
Were
you
on
that
session
because
I
missed
the
end
of
it?
So
I'm
not
sure
what
the
next
steps
were
right.
Last
Friday
yeah
that
that
public
policy
working
session
to
look
at
putting
together
some
some
feedback
on
both
both
the
the
CRA
and
the
new
us
fed
cyber
security
policy.
G
A
A
B
A
A
I
was
working
with
Uber,
but
it
sounds
like
there's
been
some
changes
and
I'm
not
sure
who's
driving
the
hospital
to
Uber.
They
were
interested
a
while
ago,
so
I'll
try
and
Revitalize
that
when
I
know
who
the
new
person
is
I
thought
Morgan
Stanley
was
going
to
be
here.
Declan
O'donovan
has
committed
he's
VP
of
security
architecture
at
Morgan,
so
he
and
he
said,
he's
committed
and
his
team
to
participating
in
this
on
a
regular
basis.
So
hopefully
that'll
that'll
start
the
next
session.
So.
A
Progress,
another
area
where
we
really
need
to
to
make
some
progress
on
membership
is
around
Healthcare.
So
if
any
of
you
have
contacts
in
large
Healthcare
institutions,
I'm
I'm
hap,
if
you
can
reach
out
or
I'm
happy
to
reach
out
to
them,
but
I
think
it'd
be
great.
We
need
as
many
kind
of
Highly
regulated
industry
members
here,
as
as
we
can
get.
D
B
D
B
D
J
Thank
you
so
I
apologize
if
I
did
it
incorrectly
or
or
correctly.
Oh
thanks,
Crow
I
posted
over
in
the
slack
earlier
this
week
a
link
to
the
document.
If
you
wanted
to
take
a
look
at
it
and
it's
over
in
the
minutes
right
now,
but
basically
the
secure
software
guiding
principles
are
are
complementary
to
what
was
discussed
last
week,
I
think
with
Brian
with
his
open
source
consumption
Manifesto.
J
The
idea
is
that
consumer
sorry,
producers
of
software,
whether
open
source
or
proprietary,
would
would
take
a
pledge
to
follow
these
guiding
principles
and
that
in
living
up
to
them
or
in
executing
the
actions
that
are
described
in
the
principles
would
end
up
securing
or
helping
to
improve
the
the
overall
security
of
the
software
supply
chain.
This
is
something
that
that
I've
been
drafting
sort
of
in
collaboration
with
a
bunch
of
other
companies.
J
If
all
of
you
could
take
a
look
at
the
draft
and
make
any
comments
in
that
Google
doc,
let
me
know
if
you
have
any
questions.
Let
me
know
if
you
have
any
recommendations
on
how
to
get
this
in
front
of
the
the
governing
board
or
make
a
contribution
to
the
openssf
project,
but
yeah.
That's
that's.
Basically
it
I'm
kind
of
excited
about
it.
E
So
one
Jessica,
if
you're,
willing
I'd
love
to
bring
you
in
to
talk
to
sort
of
our
senior
staff
about
what
you're
working
on
and
then
two
we
can
sort
of
talk
about.
If
this
does
move
forward,
how
we
can
harmonize
it,
because
certainly
This
lends
itself
quite
nicely
to
Sis's
interest
in
helping
out
in
any
way
we
can
without
being
intrusive
in
the
open
source
world.
J
J
D
D
A
good
outcome.
Excellent.
Thank
you
very
much
all
right
next
item
on
the
agenda
right,
so
the
the
working
through
the
architecture
and
I
think
it's
probably
with
a
little
bit
of
a
reminder
on
what
this
was,
so
that
this
formed
part
of
The
Proposal
that
we
as
a
working
group
presented
to
the
tech
some
time
ago
on
how
we
would
look
at
pulling
together
a
couple
of
sample
architectures
for
end
users
and
then
look
at
the
threats
that
we
see
in
the
in
the
industry,
from
a
supply
chain.
D
You
know
I
think
we
have
one
for
a
small
organization,
one
for
large
organization,
and
the
idea
really
is
use
this
as
a
sort
of
test
case,
so
that
we
can
try
and
figure
out
what
some
of
the
supply
chain
approaches.
How
did
it
actually
perform
and
how
that
mitigate
some
of
the
attacks
that
we
had
so
if
I
can
share
my
screen
by
the
way.
This
also
there's
a
little
bit
of
a
sort
of
night
nudge
to
the
diagram
of
society
as
well.
D
D
There
we
go
right,
so
I,
don't
think
we've
done
a
working
session
here
before
so
I
think
it's
a
free-for-all
as
to
how
we
can
construct
this
session.
But
let's
see
how
we
go
right.
A
little
bit
of
reminder,
then.
So
this
is
where
we're
at,
and
this
is
a
huge
amount
of
work
by
the
way
from
Henrik
Henrik
Platt
from
Endor
Labs
who's
put
these
diagrams
initially,
together
with
input
from
myself
and
also
I.
Think
yourself,
Abdullah,
and
here
we
have
it.
D
D
D
D
D
In
a
source
contributor,
we
had
that
in
there
as
well.
That
was
a
update,
oh
and
this
is
worth
pointing
out
as
well.
We
had
multiple
different
actors
when
we
think
about
supply
chain.
We
had
a
PreSonus
document
that
persona's
document
highlighted
multiple
different
members
in
the
supply
chain
scenario.
D
Most
of
this
didn't
actually
touch
the
didn't,
actually
touch
the
sdlc
or
the
machine
itself.
You
know
instant
response
teams,
sres
administrator,
but
we
decided
to
add
them
to
the
diagram
anyway
and
just
to
bring
in
this.
This
is
whole
Suite
of
additional
capabilities
that
are
in
there
as
well
they'll,
be
part
of
that
sdlc,
but
not
necessarily
putting
into
that
diagram.
C
B
C
D
D
This
is
our
sample
architecture,
so
this
is
basically
it's
not
really
a
recommendation
around
supply
chain.
It's
really
just
an
example:
high-level
architecture
of
an
end
user
that
we
could
then
go
and
look
at
how
supply
chain
capabilities
you
know
can
map
to
this.
This
isn't
a
suggestion
of
how
you
should
build
a
large
Enterprise
by
the
way.
I
Okay,
well,
the
so
I'll
just
I'll
just
drop
my
thought
to
to
close
it.
But
the
thing
that
stood
out
to
me
is
if,
in
a
controlled
organization
you
have
your
developers
pulling
directly
to
their
workstation,
so
that
top
red
arrow
that
you
have
you
are
introducing
risks
there
from
anything
that
can
attack
the
workstation
and
that's
something
that
we've
been
catching
a
lot
in
the
last
year.
So
just
just
wanted
to
say
that
if
this
was
a
recommendation.
I
D
I
I
think
that's
totally
putting
in
guidance
and
advice
right,
and
this
is
really
the
Highlight
look.
It
could
be
a
website,
it
could
be
a
package,
repo
could
be
a
Marketplace,
it
could
be
the
private
repo
and
you
could
shut
that
off.
I
think
your
concerns
are
absolutely
violated.
It's
just
more
about
how
people
are
doing
it,
not
necessarily
what
they
should.
Maybe
that's
the
distinction
we
should
highlight
on
the
diagram.
Actually,
this
is
what
happens,
not
necessarily
what
you
should
do.
G
Two
points
first
off
I
would
recommend
wherever
possible.
We
want
to
try
to
remain
vendor
and
Tool
agnostic
scene
is
trying
to
advertise
for
a
particular
vendors,
so
perhaps
adding
EG
in
front
of
any
tool
names.
So
we're
not
saying
you
should
use
Jenkins
only
and
then
to
your
earlier
Point
around
the
Box
up
top
about
ir
and
Bone
management
and
those
folks
you
might
want
to
consider
representing
how
kind
of
Maintenance
and
incident
response
impacts
this
workflow.
F
Yeah,
maybe
John
in
this
case
I
think
that
will
vary
depending
on
the
organization
size,
because
I
guess
for
large
organization.
It
wouldn't
be
the
case
of
incident
response
really
patching
the
applications
they
we
have
kind
of
like
application
owners
and
all
that
kind
of
like
wording
in
between.
So
probably,
we
need
to
clarify
it,
depending
on
the
on
the
diagram
right.
D
Yeah
you're
right.
Actually,
that
brings
also
an
additional
point
is,
is
and
I
think
this
is
what
we
struggle
with
a
little
bit
last
time
is
what
organization
is
this?
We
were
trying
not
to
stay
yeah,
it's
a
large
one,
but
it's
like
well.
Does
it
actually
help
making
like
a
backstory
for
a
sample
organization
or.
G
F
D
Yeah
I
think
I
think
that
was
we
brought
that
up
as
well.
I
was
like
well
do.
Do
we
want
to
regulated
organization,
or
do
we
want
an
unregulated
organization?
Should
we
have
both?
Does
it
matter?
What
do
we
think
I
mean
because
there
are
regulated
organization?
You
know
this
wouldn't
quite
hang
together
for
a
regulated
organization.
D
It
needs
quite
a
lot
more
lines
right,
but
we
drove
ourselves
into
the
ground
trying
to
abstract
that
right.
I
think
it's
clear
that
that
this
abstract
organization
is,
it
doesn't
resemble
any
one
of
our
actual
entities
we
come
from,
but
trying
to
make
a
regulated
organization
that
would
be
that'd,
be
some
squiggle.
Do
we
think
we
should
we.
G
Sorry,
no
I
I
would
say
that
we
don't
want
perfect
to
be
the
enemy
of
good
enough
I.
Think
that
might
be
a
nice
nice
next
step
to
have
the
nuances
of
regulation,
but
we
just
want
to
try
to
provide
an
example
architecture
and
then
it's
up
to
that
security
architect
to
figure
out
how
that
applies.
Their
organization
I
think
this
is
probably
good
enough
to
start
get
more
writer
feedback
and
then
we
can
add
the
unregulated
regulated,
yeah.
D
Maybe
we
suggest
quite
clearly:
this
is
not
the
regulated
entity
because
it
really
isn't
anywhere
near
right.
Instead
of
your
backstory
we
yeah
and
we
we
could
create
a
regulated
one.
But
at
the
moment
this
is
the
unregulated
one
and
we
could
have
some
backstory
to
it.
Okay,
very
cool,
all
right,
some
good.
F
F
K
K
This
is
Tracy
Reagan.
This
is
my
first
time
on
here
and
the
first
time
seeing
these,
but
from
my
perspective,
I,
don't
really
believe
that
it
has
much
to
do.
I
mean
there
is
some
these
pipelines
all
there's,
so
many
different
pipelines.
Let's
let
me
just
start
it
from
there.
Pipelines
are
often,
though,
based
on
the
architecture.
K
So
are
we
talking
about
an
artifact?
That's
a
Java
artifact.
What
about
database?
Art
attacks
artifacts?
What
about
just
file
systems,
jar
files
and
they
all
have
a
very
different
flow,
and
then
we
have
to
consider
the
higher
level
architecture.
Are
we
looking
at
a
monolith?
Are
we
looking
at
Cloud
native,
where
we
have
microservices
that
are
being
pushed
across
and
we're
no
longer
statically
linking
the
supply
chain
into
a
single
binary,
and
instead
the
supply
chain
is
being
linked
dynamically
during
runtime,
which
causes
a
lot
more
complexity.
K
K
D
And
if
I
can
sort
of
pull
in
that
little
so
so
is
the
is
the
guidance
that
you'd
have
I
mean
clearly
there's
different
architectures
depending
upon
your
deployment
platform
and
what
you're
building
microservices
is
monolith.
But
you
you'd
recommend
digging
into
those
specific
details,
they're
trying
to
draw
out
the
details,
because
I
I
think
we
were
trying
to
keep
it
abstract
but
you're
pointing
out
that
actually,
because
of
that,
we're
missing
some
of
the
the
detail.
That's
putting
into
the
supply
chain.
F
K
K
On
the
CDF
side
of
the
house.
There's
a
lot
of
discussion
around
this
around
CD
events,
so
that
you
could
build
more
agile
Pipelines.
So
let's
say
you
want
to
you
know:
switch
out
Nexus
and
jfrog.
You
can
do
it
easily
and
not
have
to
have
a
a
single
Jenkins
work
file
that
you
have
to
go
update,
hundreds
of
them
so.
K
F
B
K
And
if
we
can
really
clearly
call
out
what
those
compliance
levels
are
at
each
one
of
these
blue
boxes,
potentially
that
would
be
very
helpful
for
organizations
to
understand.
So,
for
example,
let's
see
here's
a
simple
one
in
a
monolith
when
you
do
a
build,
you
create
a
release.
Candidate
and
everything
we
do
is
based
on
that
release
candidate
and
in
microservice
you
don't
have
a
release
candidate
anymore.
You
have
a
single
component,
that's
a
release
candidate,
but
what
happened
to
the
application
release.
B
B
K
C
C
D
D
And
then,
when
you
get
to
the
true
implementation
level,
whether
it's
microservices
rolling
up
dates,
databases,
whatever
definite
implementation,
details
and
differences
within
that
level,
without
a
shadow
of
a
doubt
that
aren't
perhaps
even
even
being
talked
about
necessarily
yet
probably
we
need
to
hit
both
but
I.
Think
at
the
moment
we
haven't
got
a
clear
picture
of
where
those
compliance
pieces
fit.
D
D
Right
I
mean
I
mean
one
piece.
Perhaps
of
of
pulling
this
together.
Right
is
well
there's
an
architecture
for
large
Dev.
Whatever
that
really
means
that
looks
like
a
you
know,
do
a
God
forbid
a
three-tier
web
app
and
then
secondly,
do
a
micro
service,
kubernetes
deployment
within
the
architecture,
see
what
that
looks
like
see
the
threat
model
across
the
top
of
that
and
see
if,
where
it
differs
clearly
within
kubernetes,
it's
going
to
be
wildly
different,
but
that
could
that
high
level
security
level
is
that
is
that
similar
or
not.
D
I
mean
the
question.
The
question
for
me
at
the
moment
then
is
based
on
that
comments
is,
do
we,
you
know,
do
the
large,
the
small
in
terms
of
the
organization
side
or
jump
into
trying
to
build
out
multiple
different
pipeline
architectures
within
those
organizations
that
I
can
see
that
expanding
quite
rapidly.
F
K
I,
don't
I'm
happy
to
share
a
white
paper
I,
just
co-authored
about
where
different
open
source
tooling
fits
into
a
general
life
cycle
not
being
specific
to
any
type,
but
the
the
truth
of
the
matter
is
is
that
we
all
have
the
answers,
because
we
all
have
all
of
us
on.
This
call
have
probably
very
difficult
just
slightly
enough
different
environments,
that
we've
done
something
different
to
our
pipelines
and
how
we
begin
Gathering
that
and
sharing
that
across
organizations
I
think
will
be.
Ultimately
our
task.
D
Okay
sounds
good:
okay
right,
certainly
Food
For
Thought.
So
if,
if
we
move
now
from
the
the
large
to
the
small,
this
I
think
is
where
we
have
a
real
a
bit
of
a
mismatch
and
a
problem
in
what
we're
drawing
up.
I.
Think
quite
a
few
of
us
are
from
Fairly
large
organizations
and
therefore,
whilst
heavily
abstracted,
this
made
a
bit
of
sense.
D
K
B
C
Yeah
yeah
I
I
only
bring
that
up
because,
yes,
I
think
in
the
sense
of
maturity,
I
I
guess
when,
during
a
correlation
between
the
size
of
the
organization
and
the
degree
to
which
they
feel
they
have
the
bandwidth
to
climb
that
maturity.
Tree
I
I
am,
however,
cognizant
of
the
risk
of
creating
another
leveled
system
within
the
open
ssf.
When
we
have
salsa
and
S2
c2f,
which,
which
you
know
have
an
integrated,
I,
think
this
this
I
see.
C
This
is
more
of
pick
the
one
that
you
most
resemble
and
use
that
to
give
you
entree
into
the
the
world
on
open
ssf.
So
that
helps
you
to
discover
what
salsa
is
what
S2
c2f
is,
and
then
you
figure
out
how
they
apply
to
your
situation
and
where
your
gaps
are
even
even
something
like
this
can
help
an
organization
in
its
very
early
stages.
C
K
K
And
I
understand
what
you're
saying
about
we
don't
need
to
be
the
whole
compliance
thing
is
already
being
defined
in
these
other
groups,
but
what
I
have
people
ask
me
is
great.
They
gave
me
a
list
of
the
things
I
should
do,
but
how
the
hell
do
I.
Do
it.
What
gets
me
there?
What
tools
should
I
be
putting
in
what
places?
That's
the
kind
of
questions
that
we
get
that
that
come
our
way,
you
know,
can
you
you
know?
Can
you
tell
me
how
I
can
get
to
this
level?
K
D
D
You
know
I
mean
it's
it's
like
and
that's
I
think
what
we're
trying
to
cross
to
start
with.
You
know
if
you
are
a
low
maturity
organization,
a
small
organization
where
there's
literally
two
people
on
staff
and
you're
bringing
in
software
and
switching
it
on
what
does
that
look
like
and
then
think
about
your
supply
chain?
There
I
mean
you
know:
do
you
really
care
about
saucer
at
that
point?
D
There's
only
one
of
you
or
two
of
you,
you're,
better
off
focusing
on
ingestion
or
on
you
know,
pulling
it
from
a
a
trusted
resource
and
I
I.
Think
that
the
the
maturity
thing's
interesting
right,
because
it
you
know,
maybe
it's
not
the
size,
but
it's
the
maturity.
What
what
does
a
low
maturity
architecture
organization
look
like
when
you've
got
like
a
two-person
shop
for
it?
D
G
No,
no
back
in
days
of
your.
There
are
many
examples
of
products
that
were
initially
open
source
and
then
sold
as
commercial
products
that
the
whole
development
environment
build
system.
Everything
lived
on
a
developer's,
laptop
I
I
have
many
historic
examples
of
that
of
many
of
the
popular
tools
you
may
be
using
today.
D
K
J
K
K
Even
somebody
working
from
a
laptop
can
do
that
you
can
exercise
those
basic
practices
and
they
can
do
it
in
Google
Cloud
fairly
easily.
You
know
so
I
think
that
the
you
know,
maybe
what
we
should
be
structuring
is
this
is
here's
a
bare
bones
and
here's
a
more
complicated
to
deal
with
these
different
kinds
of
issues,
I'm,
not
sure,
but
I
can
promise.
D
K
D
Right
and
the
reality
is
that
maybe
that
isn't
served
with
salsa
or
C2
c2f,
and
certainly
not
ssdf.
But
what
do
we
do
because
we
need
to
secure
those
Supply
chains
as
well,
so
that
is
sort
of
the
third
architecture
we
haven't
got
through
to
it'd
be
good
to
get
some
examples
of
different
companies
that
were
like
that.
So
we
can
talk
to
those
individuals
and
perhaps
create
an
abstract
architecture.
But
that's
going
to
look
I
think
very
different
configuration
at
best.
D
All
right,
well,
look
I,
think,
there's
a
good
few
changes,
we're
going
to
need
to
make
to
the
high
maturity
or
the
the
larger
organization,
and
you
know,
let's
come
back
to
the
the
smaller
the
smaller
maturity.
One
we'll
see
what
I
get
from
two
from
there
all
right.
So
it's
five
two
and
something
out.
Is
there
any
other
business?
Anyone
wants
to
raise.