►
Description
100,000 Different Ways to Manage Secrets in GitOps - Andrew Block, Red Hat
Any GitOps implementation involves managing a wide range of resources. Sooner rather than later, there will become a need to manage sensitive assets, such as passwords or tokens. So, how can these types of assets be handled appropriately so that they are not visible in plain text when stored in a Git repository? Secrets management is a prevalent topic in the cloud native ecosystem and given its importance, tools and frameworks have been developed that can be applied to not only the content itself, but also within GitOps engines. Understanding where, how and when they can be used could make all the difference when employing proper security measures while implementing a GitOps solution. Attendees will learn: * Tools for detecting the presence of sensitive assets within Git repositories * Strategies for encrypting data at rest * Integrations with purpose built secrets management engines * How sensitive assets can be stored and used when working with public cloud providers * The mechanisms for which GitOps engines can aid in the management of sensitive resources Upon completion, attendees will no longer have an excuse to leave sensitive assets unprotected again!
A
A
A
I
have
two
books
out
there.
One
of
them
is
called
learn,
helm.
The
second
one
which
is
coming
out
in
august
is
securing
kubernetes
secrets,
so
be
on
the
lookout
for
that
and
a
little
bit
of
an
easter
egg.
A
little
later
on
the
presentation
coming
up
so
keep
an
on
lookout.
For
that
I
am
also
a
helm,
maintainer,
so
really
interested
in
the
helm,
ecosystem,
understanding
how
applications
are
managed
in
a
kubernetes
environment
so
get
us
principles.
A
They
have.
They
apply
to
a
variety
of
contexts.
They
apply
to
your
infrastructure.
This
is
going
to
be
their
your
vms,
your
static
machines
they're
also
going
to
apply
to
your
applications.
They're
going
to
be,
you
know,
database
credentials,
configurations,
you
name
it,
but
they
also
apply
to
cloud
and
now
non-cloud
assets.
Yes,
get
ops
can
apply
to
non-cloud
assets.
How
many
of
you
have
servers
in
your
data
center
raise
your
hand.
A
Where
are
the
different
ways
that
you
can
manage
get
ops,
you
can
first
manage
them.
You
have
to
then
manage
them
on
your
local
machine.
These
are
going
to
be
using
command
line
tools.
They're
going
to
be
typically
definitely
part
of
your
your
ci
cd
process,
so
they're
going
to
be
in
your
pipelines
and
how
you
manage
them
we'll
go
into
some
of
the
details
a
little
later
on
and
then,
most
importantly,
they're
going
to
be
in
your
operating
environment,
where
you're
actually
using
your
git
ops
principles,
your
values.
How
are
they
being
used?
A
You
need
to
understand
where
and
how
they're
being
used.
So
your
get
ops
typically
involves
the
use
of
sensitive
assets.
Where
are
those
sensitive
assets
coming
from
where
they
relate
to?
First
of
all,
they're
your
source
code
repositories,
you
typically
need
to
talk
to
a
git
repository
or
some
other
source
code
to
be
able
to
implement
git.
Ops
next
is
infrastructure
management.
How
are
you
connecting
to
these
individual
machines
that
you're
trying
to
target
third
is
application
configurations,
as
I
mentioned
previously
you're
going
to
have
your
database
password
you're,
going
to
have
your
external
resources.
A
Where
are
they
coming
from
certificate
management?
Those
are
all
areas
that
you
need
to
be
very
confident
about
when
operating
in
production
and
then
finally
access
to
platform
resources.
So
if
you're
talking
to
aws
google
kubernetes,
you
typically
need
to
authenticate
in
some
form
or
another.
You
typically
have
to
then
manage
that
through
git
or
some
related
system.
A
However,
most
importantly,
improper
management
of
get
ops
can
have
very
serious
consequences
and
how
serious
can
they
be
well,
first
of
all,
what
is
managing
get
ops
the
wrong
way
number
one
we've
talked
about
it
earlier
today:
do
not
in
any
way
put
password
sensitive
material.
You
name
it
as
plain
text
into
git
because
as
soon
as
you
commit
it
to
git,
it's
there
forever
in
most
cases,
also
be
confident
about
the
tooling
that
you're
working
with
understand
that,
if
you
put
passwords,
are
they
going
to
save
in
plain
text?
A
Are
they
going
to
be
encrypted?
What
does
your
tool
support
and
then
next
understand
the
limitations
of
your
tooling?
So
if
they
don't
store
them
in
encrypted
values
or
sensitive
or
you
know,
protected
resources
understand
those
understand,
just
the
limitations
of
what
your
tool
can
provide.
This
goes
beyond
git.
It's
any
type
of
feature
of
your
tool
and
then
don't
do
security
theater.
How
many
of
you
are
familiar
with
security
theater?
A
A
A
Next
is
career
repercussions
or,
if
you
want
it
can
be
a
career
resume,
building
opportunity
if
you
want,
but
in
most
cases
you
wouldn't
want
that
financial
implications.
If
it
happens
to
cause
a
negative
impact
on
your
organization,
you're
working
for
you
may
be
sanctioned
or
fined,
based
on
the
repercussions
and
then
find
finally
brand
casualty.
You
know
we
all
know
of
a
lot
of
organizations
these
days
that
have
had
security
breaches.
A
A
So,
most
importantly,
what
are
the
proper
ways
to
manage
and
handle
secrets
in
get
ops,
so
there
are
three
areas
that
I'm
going
to
touch
upon.
One
is
how
you
store
your
sensitive
data.
Two
is
how
you
access
the
sensitive
data,
the
secrets
and
three.
Once
you
have
access
to
them.
How
do
you
consume
them?
A
A
A
I'm
I'm
an
architect
and
a
consultant.
My
answer
always
is
it
depends,
but
there's
a
lot
of
options
out
here.
I
always
say
see
what
your
organization
feels
the
most
comfortable
with
some
are
in
the
cloud.
Some
are
not
you
have
you
know,
you
know.
Hashtag
vault
is
a
it's
a
corporate
option.
You
know
that
has
self-hosted
and
cloud
management
if
you're
in
one
of
the
three
major
cloud
providers,
each
one
of
them
has
a
secrets
management
tool.
You
also
have
the
ci
tools,
github
gitlab.
They
also
offer
secrets
management
capabilities.
A
One
of
the
benefits
is
some
of
these
tools
do
offer
dual
capabilities
of
being
a
kms,
so
you
can
take
advantage
of
the
key
management
facilities
provided
by
these
tools.
Azure
is
one
of
them,
so
when
you're
storing
values
in
your
repository,
there
are
certain
traits
that
you
typically
are
involved,
one
they're
most
likely
going
to
be
either
cli
or
gui.
Based
you
know
capabilities.
They
do
enable
these,
these
cli
tools
to
encrypt
and
both
decrypt.
A
At
the
same
time
and
I'll
say
it
again,
this
applies
to
kubernetes,
now
we're
all
here,
kubecon
and
in
cncfcon.
It
still
applies
to
non-kubernetes
environments.
So,
even
though
you
may
not
be
in
kubernetes,
it
still
applies.
There
are
tools
out
there
for
you
to
store
your
secrets,
a
big
one
out.
There
is
sops
another
one.
Is
the
sealed
secrets
project
so,
if
you're
using
that
there's
a
command
line
tool
called
cubevale,
there
are
also
other
tools
that
are
not
really
kubernetes
specific,
which
are
ansible
vault
of
using
ansible
for
automation
and
helm.
A
The
second
option
is
storing
those
values.
Externally,
where
do
you
typically
store
those
values
externally
one,
while,
if
you're
using
in
your
ci
infrastructure,
you're,
going
to
use
the
jenkins
there's,
there's
secrets
management
capabilities
and
jenkins
you're
going
to
have
github
actions,
git
lab
there
are
each
one
of
them:
has
a
facility
for
secrets
management
next
is
platform
infrastructure
you're
going
to
have
your
is
solution,
your
open
stacks?
It
has
a
secrets,
management
tool.
A
So
how
do
I
reference
that
once
I
go
ahead
and
store
something?
How
do
I
reference
them?
So
typically,
you
only
want
to
store
the
referenceable
values
inside
your
repository.
What
are
you
actually
storing
in
that
repository?
Well,
there
are
two
primary
er
primary
ways
of
doing
it.
One
is
placeholder
values
or
platforms
of
specific
values,
so
a
placeholder
value
is
gonna,
be
like
an
environment
variable.
However,
if
you're
in
a
certain
platform,
there
might
be
certain
default
values
that
come
out
of
the
box
like
for
github
action.
A
This
could
be
secrets
dot,
whatever
the
name
of
the
value
that
you
stored
inside
the
platform,
so
it
depends
on
what
operating
environment
you're
currently
working
in.
So
that's
number
one
number
two
is:
how
do
I
access
my
values
once
I've
stored
them?
I'm
good
at
storing,
but
can
I
access
them
so
three
things
that
we
need
to
talk
about,
one
which
tools
are
available
for
us
to
be
able
to
access
our
secrets?
A
What
is
the
access
model
that
we
should
implement
and
employ
when
trying
to
access
those
secrets
and
three
you
know
once
we
we
do
have
to
think
a
little
bit
ahead.
How
are
these
secrets
going
to
be
consumed?
Because
if
we
understand
how
they're
going
to
be
consumed,
it
may
determine
how
we
want
to
access
them.
A
So
there
are
various
tools
out
there
for
us
to
be
able
to
leverage
they're
number
one
as
very
similar
to
how
we
stored
our
secrets.
We
can
access
them
via
command
line
tools.
You
have
the
aws
cli.
You
have
cube
veil.
If
you
want
to
use
cl
secrets,
there's
a
lot
of
tools
out
there.
If
you're
using
cube
ctl,
you
can
go
ahead
and
retrieve
the
values
that
way
as
well.
A
Those
tools
can
be
standalone
or
they
can
be
integrated
into
other
tooling.
Now,
cicd
tools
like
jenkins
github,
you
name.
It
has
comparable
tools
to
be
able
to
access
the
values
you
you
have
a
c.
You
have
the
for
github,
you
have
the
github
cli,
but
most
people,
myself
included,
will
just
use
the
ui.
A
A
A
Be
part
of
the
conversation
up
front,
get
your
security
team
involved
because,
as
I
worked
with
many
organizations
over
time,
you
can
get
close
to
production
and
then
oh,
the
security
guy
comes
in
and
says:
oh,
you
need
to
make
sure
you
implement
this
or
fill
out
this
form,
and
then
you
have
to
go
back
and
either
redesign
something
delay.
The
process
of
getting
security
involved
is
very
important
at
the
forefront.
A
Finally,
is
plugins
for
tooling
there's
a
lot
of
plugins
out
there
to
integrate
secret
utilities.
They
are
either
exist,
extensions
of
existing
systems
and
they
also
abstract
and
support
the
life
cycle
of
secrets
management.
There
are
plugins
for
cube,
cube,
ctl
and
helm.
Helm
has
an
extensive
plug-in
system.
Kubernetes
has
one
as
well,
and
also
there
are
package
managers
specifically
designed
for
plug-ins
how
many
of
you
have
heard
of
crew
for
cube
for
kubernetes.
A
It's
a
plug-in
management
system
for
kubernetes
plugins,
it's
pretty
cool
check
it
out
and
if
you
haven't
played
around
with
these
cli
plugins,
the
way
to
do
so
is
to
use
you
know
the
tool
which
is
basically
cube,
ctl
the
name
of
the
plugin
and
then
any
sub
commands
that
be
that
can
be
part
of
the
plugin.
So
if
you
have
a
cube
cube,
you
know
cube
ctl
secrets,
management
extract,
encrypt
decrypt,
I'm
throwing
something
out
there.
It's
just
the
typical
convention
of
how
these
tools
are
integrated.
A
Now
I
mentioned
kubernetes.
There
are
solutions,
purposely
built
around
the
ecosystem
of
kubernetes
to
integrate
secrets
management.
One
is
standard
controllers.
Kubernetes
has
hundreds
of
controllers
built
in
and
extension
throughout
the
community.
These
are
ones
that
manage
different
resources
and
react
to
resources
within
kubernetes.
A
You
can
go
ahead
and
use
a
controller
to
apply
configurations
to
values
that
are
based
on
the
configurations
of
the
resources
in
kubernetes.
Second,
is
web
hooks.
Now
this
is
where
the
dynamic
nature
of
kubernetes
comes
in
you're,
able
to
provide
either
validating
or
mutating
web
hooks
to
change
the
composition
of
your
deployments
or
other
manifest
as
they're
being
created.
So
a
good
example
is
hashicorp
vault
and
their
sidecar
injector.
They
install
a
mutating
webfoot
configuration
when
a
pod
comes
up
and
it
is
or
a
deployment
is,
comes
up
and
is
annotated
with
certain
values.
A
A
Third
is
operators,
and
I
always
want
to
keep
operators
and
controllers
separate
people
say:
well,
it's
an
operator
or
controller.
Yes,
it
is
a
controller.
An
operator
is
distinct
because
there
is
a
custom
resource
definition
that
it
tracks
against.
So
you
would
define
your
configuration
against
that
custom
resource
definition
and
that
controller
the
operator
would
go
ahead
and
reconcile
based
upon
that
configuration.
A
That's
the
key
thing,
so
that's
a
great
way
that
you
can
manage
secrets
and
we're
going
to
talk
to
we're
going
to
talk
through
at
least
one
or
two
projects
that
implement
their
own
customer
resource
definition
for
you
to
then
implement
secrets
management.
So
let's
talk
about
the
three
that
I
always
use
in
the
kubernetes
ecosystem.
One
is
sealed:
secret
seal
secrets
is
probably
the
easiest
fastest
way
to
get
started
with
secrets
management
in
kubernetes.
A
A
It
can
be
a
challenge
because
you
have
one
secret
key
for
the
cluster,
a
project
which
I
do
love
external
secrets.
So
if
you're,
using
an
external
secrets,
management
tool,
a
cloud
provider
secret
management
tool,
a
hashtag
vault,
you
name
it-
this
allows
you
to
integrate
a
controller,
to
grab
resources
and
access
and
manage
those
resources
into
kubernetes
and
then
finally,
a
third
option
out
there
in
kubernetes
that
I
see
widely
being
adopted
is
the
vault
secrets,
agent
injector,
which,
which
is
a
great
feature-rich
plug-in
for
hashicorp
vaults.
A
It
allows
you
to
inject
sidecars
into
deployments
and
pods
as
they
need
to.
You
can
also
then
manage
the
entire
life
cycle
of
secrets
within
your
kubernetes
cluster.
So
if
you're
synchronizing
secrets
from
hashtag
vault
and
you
change
them
in
vault,
it
will
actually
go
in
and
periodically
refresh
the
state
automatically
and
the
same
thing
when
it
comes
to
your
containers
too.
Really
cool
project
as
well.
A
A
So
it's
going
to
be
a
hashtag
vault,
it's
basically
saying
in
the
backend
type
is
going
to
be
vault,
we're
going
to
say
we
want
to
go
ahead
and
reference,
the
aws
key
id
and
the
secret
id
in
secret
key
pardon
me
inside
vault,
and
it's
going
to
put
that
in
a
secret
in
your
in
your
kubernetes
cluster.
How
many
of
you
are
using
any
one
of
these
tools
right
now,
that's
good!
I
mean
it's
either,
not
a
good
adoption
and
b.
A
You
are
using
secrets,
management
tools
and
get
up
so
that's
great
to
see
validation
from
the
community.
Here.
Third,
is
a
get
ops.
Engine
kubernetes
has
really
moved
forward.
How
github's
tooling
works
two
common
projects
out?
There
are
one
flux
and
two
argo
cd
for
implementing
git
ups:
it's
not
the
only
ones
they're,
just
the
two
most
popular
ways
of
implementing
get
ops
in
kubernetes.
A
If
you're
using
flux,
it
has
integrated
soft
functionality
and
by
using
fl
softs,
you
can
then
integrate
an
external
secrets
management
tool
very
easily
or
you
can
use
a
p
a
gpg
pgp,
because
soft
also
supports
that
as
well.
If
you're
using
argo
cd
there's
an
entire
plugin
system
that
argo
cd
provides
and
there's
a
vault
secrets,
management
plugin
for
argo
cd,
so
if
you're
using
argo
cd,
you
can
now
integrate
hashtag
bulk
very
easily
two
great
options:
two
doesn't
really
matter
what
tooling
you're
using
to
allow
you
to
operate
successfully
and
securely
inside
kubernetes.
A
Next,
we
need
to
access
the
credentials.
What
are
some
considerations
that
you
need
to
have
when
setting
up
how
you're
accessing
those
values,
one
understanding,
what
options
and
capabilities
are
provided
by
the
tools
you're
using
you're?
Actually
using
identify
security
boundaries
ensure
that
you
only
create
credentials
and
access
models
that
are
for
your
application.
Only
don't
go
ahead
and
create
a
single
principle.
That's
going
to
use
it
for
all
your
applications
across
your
entire
portfolio.
That's
just
a
breach
waiting
to
happen
because
one
breach
happens.
A
You
have
to
go
ahead
and
basically
rotate
your
entire
ecosystem
watch
out
so
recommendations
for
that.
One
of
them,
as
I
mentioned,
use
that
dedicated
service
principle
two
short-lived
credentials,
try
to
use
them
as
short
as
possible,
have
rotation
on
them,
don't
go
ahead
and
create
a
credential.
Today
and
I
come
back
next
year-
or
we
see
all
you
all
in
detroit-
I
don't
want
to
have
you
talk
to
you
and
say
I'm
using
the
same
credentials.
A
A
What
are
some
common
access
methods
for
talking
and
accessing
your
secrets?
One,
the
simplest
basic
auth.
It
is
what
it
is
they're
just
an
option
out
there,
two
most
common
out.
There
is
bear
token,
that's
how
you
can
talk
to
kubernetes
one
of
the
ways
you
can
talk
to
kubernetes
three,
which
is
really
cool,
assumed
identity,
oidc.
How
many
of
you
are
integrating
oidc
for
how
you're
accessing
your
sensitive
values?
A
Awesome.
Awesome.
Oidc
is
great.
So
if
you're
using
github
actions
and
aws
and
get
left
they're
now
starting
to
support
oidc
for
you
to
access
external
resources,
you
don't
have
to
have
and
store
secrets.
You
can
use
assumed
identities
on
the
platform.
If
you
have
any
questions
on.
This
is
a
kind
of
a
complex
topic.
It's
really
emerging,
I'm
happy
to
sit
down
and
talk
to
you
about
it.
I'm
part
of
another
project
called
six
store.
We
use
that
extensively
in
the
sig
store
project,
so
oidc
and
student
identity
look
into
it.
A
A
Okay,
we
talked
about
how
we
store
the
secrets,
how
we
access
them
now,
the
most
important
part.
How
do
we
have
to
use
them?
You
know,
because
you
know
we
did
all
the
two
of
the
three:
let's
go
ahead
and
start
consuming
them.
That's
two
common
ways
that
you
will
consume
secrets
in
your
get-offs
process:
one
environment
variables
you're
going
to
consume
whatever
it
happens,
to
be
as
environments
variables
and
number
two
through
a
file
system
and
the
simplest
way
to
do
that
is
a
kubernetes
secret.
A
However,
I
will
emphasize
over
and
over
this
week
there
are
limitations
to
kubernetes
secrets.
They
are
base64
encoded,
base64
encoding
is
not
a
security
mechanism.
Don't
think
it
is
you
can
extract.
You
can
basically
decrypt
that
in
about
four
seconds,
not
even
four
seconds
tens
of
seconds,
don't
even
bother
it's
a
great
way
to
get
started,
but
just
great
for
development
or
your
local
machine,
not
for
production
at
all,
so
some
ways
that
you
can
consume
secrets,
one
of
the
most
common
ways
to
do
that
is
a
side.
A
You
have
a
co-located
container
within
your
pod
that
will
manage
the
life
cycle
of
a
secret
and
a
nick
container
will
go
in
and
can
communicate
with
an
external
secret
store
and
provide
those
values
for
your
application
at
startup
or
in
addition
to
a
new
container,
is
a
sidecar
that
is
always
running
in
addition
to
your
operating
container.
This
is
great
if
you
have
a
secret
that
may
rotate
frequently,
and
you
want
to
be
able
to
synchronize
that
state
inside
your
container.
It
will
periodically
go
and
talk
to
your
secrets,
management
tool.
A
That's
the
most
secure
is
to
load
your
sensitive
values
in
memory.
Read
the
read
the
value
from
the
file
system.
Remove
it
then
start
your
container
up
and
basically
start
your
application
up.
So
that
it's
only
available
at
that
initial
initialization
point
and
is
removed
immediately.
So
if
someone
gets
a
session
inside
your
container,
they
can't
actually
access
it
if
it's
stored
in
memory
within
your
application-
and
this,
as
I
mentioned,
is
a
very
common
pattern
to
the
vault
sidecar
another
one
aside
from
sidecar
is
the
kubernetes
csi
driver.
A
This
is
a
good
pro,
a
project
that
has
really
emerged
in
the
open
source
and
kubernetes
ecosystem.
Recently.
It
basically
allows
you
to
not
use
secrets,
not
store
your
sensitive
data
as
secret
values
inside
kubernetes,
but
allows
you
to
mount
a
volume
using
the
typical
in
you
know,
supported
volume,
types
and
kubernetes
to
be
able
to
manage
secrets.
A
It
supports
multiple
back-ends,
the
common
back-ends
that
you're
going
to
have
in
most
operating
environments,
aws
azure,
gcp
vault.
You
can
also,
if
you're
a
developer,
create
your
own.
It's
extensible,
I'm
a
developer.
I
love
developing
and
hacking
on
things.
So
if
you
have
some
other
tool
that
your
organization
is
using,
that
may
not
you
know
be
one
of
these
three
one
of
these
four
or
five.
You
can
create
your
own
and
then,
as
I
mentioned,
it,
avoids
storing
sensitive
assets
as
secrets.
It
will
either
store
it
it'll
store
it
within
a
volume.
A
In
the
container.
There
is
an
option
in
the
csi
plug-in
to
enable
it,
so
it
will
synchronize
to
a
secret
if
your
tooling
does
require
it.
So
there
is
that
option
to
do
both
sort
as
a
csi
volume,
but
also
synchronize
it
as
a
typical
traditional
secret
in
kubernetes,
and
to
implement
that
what
does
that
process?
Look
like
three
steps.
One,
like
we
talked
about
earlier,
we
gotta
store
the
value
somewhere,
configure
the
access.
How
how
is
the
csi
driver
gonna
talk
to
it?
Two
we're
gonna
create
a
secret
provider
class.
A
So
it's
going
to
be
if
it's
talking
to
vault
the
location
within
vault,
that
that
value
is
stored,
the
location
within
azure
secret
manager,
tool
where
it's
stored,
et
cetera,
et
cetera
and
then
within
your
kubernetes
deployment,
manifest
you're
going
to
put
you're
going
to
specify
the
volume
type
of
csi
reference,
the
driver
into
the
csi
driver
and
then
specify
the
secret
value
secret
provider
class
that
you
specified
in
step.
Two.
There
is
your
connection
from
step.
One
connects
to
step
two
to
step
three.
A
A
Don't
raise
your
hand,
raise
your
hand
if
you
haven't
you
lie
we've
all
done
it.
I've
done
it.
I've
had
to
call
github
a
few
times.
I've
gotten
a
couple
nasty
grams
from
my
organization
saying
you
know
we
noticed
something
inside
your
repository.
There
got
a
little
talk.
You
call
them
up,
you
feel
shame
it's
all
donuts!
A
You
have
to
go
in
and
do
all
the
stuff
we
talked
about
earlier
good
news.
There
are
tools
there
to
help
you
detect
when
secrets
are
present,
three
of
them
that
I
found
that
have
been
very
useful
out
there.
The
tech
secrets
project
that
the
yelp
team
has
put
together
aws
has
its
own
secret
to
management
detection
tool.
A
Also,
in
addition,
github
and
aws
has
scanning
utilities
that
are
out
there
already
scanning
repositories
so
github
right
now.
If
you
commit
an
aws
secret,
it
will
probably
be
revoked
automatically,
because
there
are
tools
out
there
to
tech
detect
when
those
are
an
aws
secret.
Try
it
out,
you
know
just
for
in
a
lab
environment
testing,
not
in
production,
just
see
how
that
actually
works,
and
the
great
part
about
this
is
the
security
is
becoming
more
mainstream
front
and
center.
A
So
more
of
these
tools
are
starting
to
become
available,
so
keep
on
the
lookout
for
more
ways
of
being
preventative
to
ensure
you
have
are
protected
in
your
get
out
secrets,
management
and
then,
finally,
I
will
close
saying
that
security
is
continuous.
It's
never
finished
you.
What
you
store
today
might
be
vulnerable
tomorrow,
always
make
sure
you
incorporate
security
from
the
start
implement
across
your
entire
organization.
Just
don't
have
it
be
in
your
little
silo,
make
sure
you
emphasize
security
throughout
every
single
part
of
your
organization,
revise
and
remediate
as
necessary.
A
What
happened
two
years
ago
in
the
ecosystem
is
typical
is
totally
not
the
same
as
it
is
today.
The
secure
software
supply
chain
is
mainstream.
Today
I
guarantee
it
was
nothing
two
years
ago
and
then
finally
identify
everything
you
need
to
do.
I
want
to
thank
you
for
the
opportunity
today.
Hopefully
you
learned
a
lot,
I'm
happy
to
answer
any
questions,
I'm
going
to
be
here
all
week.
Thank
you
for
the
time
today.