►
From YouTube: Automating Security Compliance at Scale - Ravi Devineni, & Michael Pereira, Northwestern Mutual
Description
Automating Security Compliance at Scale - Ravi Devineni, & Michael Pereira, Northwestern Mutual
According to Gartner, “99% of the vulnerabilities exploited by the end of 2021 will continue to be ones known by security and IT professionals at the time of the incident”. This means that most of the vulnerabilities that are exploited are completely preventable. For modern cloud and container-based workloads, Automation in the pipeline can help enforce security and compliance and protect against breaches. At Northwestern Mutual we take security seriously. We will show you how we automated all our security requirements and ensured all pipelines go through security scanning (including containers!), detecting secrets in real time as well as securing the pipeline itself. With a few simple techniques shown here, you can make your pipelines secure and compliant.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Hi
everybody,
my
name,
is
ravi
davinini.
I
have
with
me
michael
pereira.
We're
from
northwestern
mutual.
Our
topic
for
today
is
automating
security
and
compliance
at
scale.
We
work
on
a
team
called
devops
engineering.
Our
job
is
to
create
tools
for
ci,
cd
and
devops,
basically
to
enable
the
teams
to
ship
applications
faster
and
in
a
more
secure
way.
We'd
like
to
thank
cdcon
for
giving
us
this
opportunity
to
present
our
work.
A
A
little
bit
about
our
company
northwestern
mutual
is
a
financial
services
company,
headquartered
in
milwaukee
wisconsin.
We
have
locations
in
new
york,
city
and
minneapolis
fortune
111
america's
best
employers
best
employers
for
women,
best
employers
for
diversity,
veteran
friendly,
lgbt
friendly.
You
can
see
the
team
there
a
very
inclusive
and
diverse
workplace,
in
addition
to
that,
we're
working
on
some
amazing
technologies
and
cloud
and
devops,
and
we
have
some
very
challenging
problems
to
solve
and
we're
trying
to
bring
digital
transformation
to
our
160
year
old
company.
We
have
great
work-life
balance.
A
We
have
a
very
flexible
and
empathetic
senior
leadership.
It's
an
amazing
place
to
work
our
agenda
for
today
is
we're
going
to
talk
about
cicd
pipelines
and
what
it
means
to
secure
a
cicd
pipeline
right
and
we'll
talk
about
concepts
of
software
supply,
chain,
security
right
and
embedding
security
in
the
pipeline
and
some
of
the
tools
that
we
have
created
for
automating
and
enforcing
the
security
controls.
A
Hopefully,
everyone
knows
what
a
cicd
pipeline
is,
but
I'll
quickly
summarize
here
remember
in
the
old
days
right
when
many
years
ago,
when
we
used
to
do
waterfall
development,
we
used
to
do
coding,
testing
deployment
to
staging
user
acceptance
testing
and
on
a
weekend
we
used
to
release
the
production
you
can
see.
This
was
a
lot
of
manual
effort
right.
Replacing
all
of
that
manual.
Effort
with
automation
is
essentially
what
a
ci
cd
pipeline
is.
A
There
are
many
many
benefits
of
doing
ci,
cd
right,
you're
you're,
basically
releasing
smaller
changes.
Changes
are
at
a
in
much
smaller
increments.
As
a
result,
there
is,
there
is
a
faster
feedback
loop.
This
reduced
manual
error
since
a
lot
of
the
testing
and
deployment
functions
are
basically
automated.
You
you
release
to
the
market
faster
and,
as
a
result,
there's
higher
customer
satisfaction.
A
That's
that's
what
cicd
pipeline
is
right.
This
one
is
an
interesting
slide
right.
This
is
the
number
of
cvs
that
are
discovered
every
year.
You
can
see
that
there
is
an
uptick
in
the
in
the
last
four
years
right.
17
000
in
2019,
over
18
000
in
2020
and
same
trend
seems
to
be
happening
in
2021
as
well.
This
averages
to
about
50
vulnerabilities
discovered
every
day
this
is
50
new
vulnerabilities
that
are
being
discovered
every
single
day.
A
A
Useful
tool
called
sugar,
it's
used
to
find
secrets
and
sensitive
files
across
github.
This
is
public
github
in
real
time,
and
you
can
see
here.
We
ran
this
for
about
30
minutes
and
you
can
see
here
there's
a
lot
of
secrets
being
committed
to
github
right
things
such
as
google
cloud
keys,
aws
keys,
private
keys,
usernames
passwords
database
connection
strings.
These
are
essentially
keys
to
the
kingdom
right
and
this
is
a
huge
problem
that
all
of
these
credentials
are
out
in
the
wild.
A
So
the
goal
of
cicd
security
is
to
find
these
issues
as
early
as
possible,
because
the
later
you
find
them
the
more
expensive
it
is
to
fix
it.
There
is
a
study
that
ibm
has
done
and
they
do
it
every
year,
which
basically
says
that
an
average
cost
of
a
single
breach
is
3.92
million
dollars,
and
this
is
the
average
cost
across
the
world
and
in
the
us
it's
even
more
expensive.
As
a
matter
of
fact,
us
is
the
most
expensive
country
for
data
breaches
averaging
over
eight
million
dollars.
Right
and
no
company
is
exempt.
A
You
will
see
equifax
we'll
talk
about
some
case
studies.
There,
yahoo
horizon,
and
even
the
us
government
they
have
been
breached
here
and
some
of
the
security
breaches
here
right
equifax,
for
example.
This
is
a
well-publicized
case
right
about
150
million
people's
personal
data
got
exposed,
that's
basically
every
single
adult
in
the
united
states.
That's
all
of
us
equifax
had
to
pay
1.4
billion
dollars
to
get
out
of
that.
The
reason
this
happened
was
equifax
is
basically
a
java
application
right.
They
use
a
version
of
apache.
It's
an
open
source.
Apache
starts
2.2.
A
They
had
a
vulnerability
that
was
discovered
in
2017
and
you
can
see
the
number
there
and
they
never
passed
it
for
a
whole
year,
at
least
as
a
result,
it
got
exploited
and
xfx
is
in
trouble.
Now
solarwinds
is
another
popular
one.
From
last
year,
solarwinds
is
basically
a
company
that
sells
a
software
called
orion
that
this
orion
platform
is
basically
a
networking
network
monitoring
software
right.
A
They
have
over
18
000
clients
that
that
use
this
software,
including
major
companies
such
as
microsoft
and
deloitte,
and
intel,
and
even
federal
agencies
such
as
homeland
security
and
department
of
treasury.
All
of
their
sensitive
information
such
as
emails
and
personal
confidential
data,
got
exposed
what
happened
right.
A
malware
was
inserted
into
the
software.
It's
believed
that
this
happened
through
a
supply
chain
attack,
basically
right
through
either
one
of
their
build
or
distribution
systems
or
one
of
their
third-party
dependencies
right.
It's
not
clear
what
exactly
happened.
A
One
of
the
systems
were
was
compromised
and
the
back
door
was
inserted
into
orion
now,
once
orion's
updates
made
their
way
to
the
client
servers,
the
hackers
gained
access
to
a
lot
of
sensitive
information.
It
cost
all
right.
Solar
winds,
a
lot
of
money
right,
90
million
dollars
upwards
of
that,
and
not
just
that
right.
A
Each
one
of
these
18
000
clients
who
have
installed
this
update
have
to
go
and
clean
up
this
code
right
this
malicious
code.
So
it's
estimated
that
the
cumulative
cost
could
be
over
100
billion
dollars
and
that's
a
lot
of
money
right,
not
just
these
right
that
there's
a
lot
of
companies,
big
companies
such
as
facebook,
uber
target
that
were
attacked.
So
is
software
supply
chain
security
important?
Absolutely
so,
what's
a
software?
A
We,
our
goal,
is
to
make
sure
our
application
itself
is
secure
right
that
it
doesn't
have
any
vulnerabilities
that
by
making
sure
that
all
of
these
scannings
and
several
stages
in
the
pipeline
are
in
place,
and
that
is
security
in
the
pipeline
right,
but
not
only
that
right.
This
is
a
lot
of
tools
here.
This
is
our
supply
chain.
Basically,
these
tools
have
access
to
your
application
right.
They
have
access
your
environment
variables.
A
They
have
access
to
your
data,
they
have
access
to
your
business
logic
also,
if
any
of
these
tools
were
to
get
compromised,
we're
in
trouble
too,
the
hackers
need
just
one
of
these
tools
to
get
get
compromised
to
insert,
instead
of
malware
kind
of
like
what
happened
with
solar
ones.
Right
making
sure
all
of
these
tools
themselves
are
secure
is
called
the
security
of
the
software
supply
chain.
Basically,
this
is
our
supply
chain,
so
secure
all
the
tools
in
your
cicd
pipeline.
That
goes
without
saying.
A
Some
of
the
principles
we
use
here
are
are
basically
principle
of
least
privilege
right,
essentially
making
sure
that
our
tools
have
only
the
necessary
permissions
or
resources
for
that
matter.
To
do
the
job
it
needs
to
do.
Other
things
include
minimizing
the
attack,
surface
area
right
and
hence
the
blast
radius.
Obviously
you
want
to
ensure
that
all
your
communications
are
encrypted.
You
want
to
ensure
that
your
underlying
operating
system
is
secure
and
those
are
some
of
the
principles
and
you
can
see
some
of
the
examples
right.
A
Ensuring
repository
settings
are
components
gitlab,
for
example,
you
want
to
ensure
that
merge
requests
approvals
are
configured.
Nobody
is
able
to
merge
a
merge
request
without
it
getting
approved
by
somebody
else.
You
want
to
have
a
default
branch
to
be
protected,
authentication
and
authorization.
You
want
to
ensure
that
sso
is
enabled
on
your
applications.
A
A
A
Obviously,
some
rules
do
fail,
and
that
just
means
that
there
is
a
gap
in
our
system
right.
We
and
we
need
to
do
some
extra
work
to
harden
the
security
of
that
particular
tool.
Here's
an
example
of
the
dashboard
that
we
create,
and
you
can
see
here
there
are
some
rules
checking
for
public
projects,
for
example
right
you
don't
want
to
you
want
to
ensure
that
the
code
in
in
your
in
your
source
code
is
only
accessible
to
people
within
the
company
docker
registry.
A
You
want
to
ensure
your
data
is
encrypted,
and
this
basically
is
a
good
way
of
identifying.
All
of
this
data
is
false
data.
By
the
way,
it's
a
great
way
of
identifying
gaps
in
our
software
supply
security,
software
supply
chain,
security
right
so
and
next
one
is
michael,
we'll
talk
about
securing
our
application
itself
and
some
of
the
tools
that
we
have
created
to
automate
our
compliance.
B
We
have
two
main
type
of
security,
scan,
static
and
dynamic,
static
ones,
work
with
just
your
code,
while
the
the
dynamic
ones
require
your
application
to
be
up
and
running,
which
is
more
complicated
to
do
in
some
cases,
as
you
can
quickly
guess,
static
ones
are
easier
to
run.
They
don't
always
provide
the
best
results,
while
the
dynamic
ones
can
be
hard
to
run,
but,
depending
on
your
application,
will
provide
the
most
accurate
result,
because
it's
really
going
to
be
looking
at
your
application
up
and
running,
ideally
the
same
way
that
it
is
in
production.
B
So,
let's
start
from
the
bottom
of
the
stack
first,
we
have
the
os
university
scanning,
while
it's
not
specific
to
the
containers,
it
has
grown
in
popularity
with
the
usage
of
of
of
docker,
because
now
the
task
of
keeping
your
your
base
system
up
to
date
doesn't
fall
solely
on
the
system.
Administrators,
it's
also
new
job,
and
since
we
a
developer,
are
quite
lazy
and
don't
forget
to
do
it,
we
need
to
do
two
scans
to
make
sure
it
happens.
B
Don't
say
that
we
have
now
opened
a
new
attack
vector
for
for
application,
since
we're
putting
code
that
we
haven't
written
ourselves
as
it's
not
feasible,
to
view
the
entirety
of
the
code
on
all
the
changes
made
with
each
and
every
version.
We
delegate
the
work
of
security,
verification
to
a
tool
that
will
execute
this
scan
for
us
and
tell
us
when
we're
trying
to
use
a
library
with
cvs.
B
Finally
we're
getting
to
our
own
code
after
we
make
sure
that
the
base
upon
which
we
are
building
our
app
is
solid.
We
need
to
ensure
that
we're
not
undoing
all
this
maintenance
work
by
writing
a
bunch
of
vulnerable
code.
On
top
of
it,
the
code
of
ntb
liberty
tool
is
going
to
look
at
patterns
in
the
code
to
try
to
detect
things
such
as
sql
injections,
access
control,
xss.
B
B
The
reason
is
that
there's
some
similarities
between
code
security
and
code
quality
if
the
code
is
easier
to
maintain
it's
also
easier
to
understand
and
secure.
If
it's
not
readable,
it's
going
to
be
harder
to
spot
and
fix
issues
so,
while
not
directly
a
security
tool,
it
definitely
helps
to
keep
your
your
code
secure.
B
A
B
Interface
with
your
application-
and
that's
not
really
something
that's
controversial
to
do
when
you're
talking
about
a
rich
local
client
or
a
cli
application.
There
are
many
scanners
available,
but
users
are
not
as
good
as
for
web
applications
as
far
as
I
know,
because
they
can't
send
inputs
in
the
same
automated
way.
B
B
Simple
enough,
we
call
a
docker
image
and
run
the
scripts,
nothing
too
too
specific.
Then
we
are
going
to
be
checking
conferences
next
slide
very
similar.
The
process
we
also
save
the
output
in
artifacts.
We
should
to
make
them
available
to
developers
to
to
look
at
same
thing
for
the
code
varieties
we
embed
most
of
the
complexity
inside
that
is
a
script
have
been
called
and
finally,
you're,
probably
starting
to
to
to
start
to
see
a
button.
B
Here
we
check
for
the
code
query
with
a
very
similar
template
and
it's
it's
only
a
few
templates,
but
it's
already
too
much
to
keep
track
of
for
a
lot
of
developers
there.
Our
job
is
to
focus
on
application
developments
and
all
of
these
checks
that
we
keep
adding
to
the
pipeline.
Just
it's
just
additional,
a
cognitive
load
that
distracts
them
from
delivering
value,
but
they
are
important
to
have
plus
those
tools.
They
are
usually
changing
every
few
years
when
contracting
new,
when
you
will
come
in
when
new
tools
are
upgraded.
B
B
As
you
can
see,
we
don't
have
a
template
for
dynamic
scanning.
It's
not
that
we
don't
do
it,
but
teams
that
are
doing
it
are
tightly
integrating
with
those
tools.
It's
not
easy.
We
haven't
been
able
to
find
a
way
to
make
it
work
for
all
applications
in
in
a
unified
way
that
we
can
offer
as
a
as
a
template,
to
include
so
now
that
we've
done
the
work
to
ensure
that
security
issues
don't
make
it
into
our
app
when
the
apache
is
built.
B
B
Now
that
we
have
all
those
scans,
we
also
need
to
make
sure
that
they
are
present
in
all
pipelines.
We,
we
don't
want
all
of
this
work,
to
be
undone
by
simply
releasing
credentials
in
the
source
code
which,
as
mary
said,
would
be
akin
to
giving
the
keys
to
kingdom
to
whoever
has
access
to
read
the
code.
B
B
If
they
do,
they
receive
a
notification
via
email,
with
a
link
to
the
documentation
showing
how
to
resolve
the
issue
as
well
as
getting
their
commit
marked
as
failed
in
githlab,
because
it's
it's
one
thing
to
want
them,
but
we
also
need
to
kind
of
force
them
to
deal
with
the
situation.
So
if
they
have
this
setting
enabled
to
only
allow
a
request
when
the
pipeline.
B
A
B
Reviews
so
now
we
have
all
the
checks
on
verification
in
the
pipeline.
Next
we
have
a
secret
detector
for
detecting
secrets,
as
the
name
implies
when
commits
are
pushed
to
the
gitlab
you're
going
to
process
them
looking
at
their
content
and
try
to
find
secrets,
I'm
going
to
validate,
as
those
secrets
are
valid,
git
offers
you
several
hooks
into
the
lifecycle
of
a
commit
until
that
committee,
which
is
a
pretty
story,
so
we
start
from
from
the
right
of
the
post
receive
hook.
B
This
means
that
we
let
gitlab
accept
the
commits,
and
then
we
looked
at
its
contents
and
then
we
try
to
make
people
correct
their
mistakes
and,
as
you
can
imagine,
it's
a.
I
tell
you
some
process
because
it's
already
committed
in
the
gita
story,
so
if
they
have
to
rewrite
it,
it's
a
cumbersome
process.
B
We
chose
to
build
our
own
system
because
we
found
that
the
existing
open
source
tools
listed
here
lacked
in
detection
probabilities
or
adds
to
many
false
relatives,
especially
when
they
used
entropy
so
and
since
none
none
of
them
did
any
mediation
of
the
secrets.
We
had
a
very
high
rate
of
force
relatives.
B
This
white
paper
from
ibm
is
interesting
if
you're
interested
in
his
problem.
But
if
security
is
not
your
your
core
business,
I
would
recommend
to
just
go
with
a
commercial
detection
tool
such
as
git
guardian
to
let
your
security
team
focus
on
the
findings.
Instead
of
building
custom
tools
that
need
to
be
maintained
long
term,
this
type
of
tools
were
not
around
when
we
started
doing
this
journey,
but
if
he
typed
in
the
case
we'd
have
thought
twice
before
spending
all
these
man
hours
on,
creating
that
complex
system
ourselves.
B
A
Ready
so
yeah,
I
can
bet
that's
a
great
question
about
security
rules
in
opa.
Right,
if
you
think
about
what
opa
is
right.
Opa
is
open
policy
agent
implemented
by
kubernetes
and
by
definition,
what
that
means
is
you
are
you
have
some
admission
controls
at
the
end
of
your
process,
which
is
which
is
at
your
deployment
stage
right,
which
is
happening
at
the
end
of
your
process?
That
is
great
right,
but
you
do
want
certain
opa
rules
for
certain
scenarios,
but
you
also
want
to
have
feedback
for
some
of
these
supply
chain
vulnerabilities
much
ahead.
A
B
B
What,
when
abilities,
we
have
of
our
applications
on
for
the
os,
but
it's
not
the
the
only
thing
that
we
do.
We
are
also
investigating
and
creating
our
own
tool.
That
looks
more
generally
across
security
issues
to
try
to
to
get
that
extra
information
that
sometimes
doesn't
make
it
true
through
the
vendor.
So
this
way
we
can
kind
of
double
check
that
we
are
getting
all
the
information.
A
A
Whenever
you
choose
a
vendor,
such
as
twitch,
lock,
aqua
security,
there's
a
lot
of
vendors
in
this
space,
you
have
to
ensure
that
their
their
policies
are
compliant
with
your
regulations
too,
and
also
there's
a
lot
of
open
source
tools
that
are
out
in
the
market
for
something
similar,
there's
container
scanning
tools
and
static
scanning
tools
that
are
quite
open
source
too.
If
that,
if
you
were
to
go
that
route,
then
you
would
then
be
responsible
for
for
your
tools
being
compliant.
A
B
And
for
your
more
specific
question
about
specific
library
or
tool,
that's
something
that
again,
you
should
try
to
leverage
the
vendor
to
tell
you
if
the
library
at
all
is
compliant
with
your
security
rules.
So
there
are
some
extra
integrations
like
at
factory
with
x-ray
that
can
block
the
download
of
those
libraries.
So
it's
a
it's
a
balance.
How
much
do
you
verify
after
those
libraries
are
being
put
in
use
or
or
do
you
provide
a
list
of
libraries
that
you
have
pre-selected?
B
A
Next
question
from
andres
mezcan
is:
is
pipeline
enforcer,
a
tool
you
build
yourself
or
is
it
generally
available?
It
is
a
tool
that
we
built
ourselves,
but
it
is
not.
It
is
not
something
that
we
are
open
sourcing
yet
at
least,
but
I
think
we
shared
some
of
the
ideas
that
we
use
and
those
ideas
are
reasonable
enough
that
anybody
can
take
those
ideas
and
build
something
of
your
own
right.
These
are
this
is
not
like
ground
shattering
ideas
or
anything.
A
B
Yeah,
the
idea
being
to
check
that
you
have
those
checks
in
the
pipeline
so
yeah,
it's
not
that's
it
through
some
smartness
too,
because
no
pipelines
are
being
becoming
more
and
more
complicated,
but
yeah.
It's
not
like
an
ai
or
machine
learning
system.
So
definitely
something
that's
that
if
you
can
create
a
web
application,
something
that
you
can
easily
create
yourself
as
well.
A
Next
question
from
dennis
is:
how
do
you
enforce
all
repos
have
the
pre-commit
hook.
You
were
talking
about
earlier
right,
so
an
easier
way
easy
way
to
do.
This
is
using
a
global
system
hook
right
that
basically
gets
triggered
after
every
push
event
happens.
It
is
at
a
system
level,
so
every
repo
is
being
tracked
automatically,
so
you
implement
it
once
and
it's
there
right
at
that
point.
So
git
lab
has
a
nice
way
of
doing
this.
A
You
can
store
the
get
the
prereceive
hook
code
within
your
gitlab
server
itself
and
enable
that
and
all
the
code
is
then
scanned
right
after
a
push,
event
happens,
and
you
can
do
several
things
with
that.
You
can
send
some
notifications
to
a
security
team.
You
can
do
notifications
to
the
the
team
that
is
committing
the
code
itself
right
and
there's
a
lot
of
things
that
we
can
do,
such
as
dashboarding
and
alerting
and
stuff.
B
Yeah
with
kit,
once
you
put
a
appreciable
hook
it,
it
runs
for
all
the
comments
received
by
by
the
server.
So
then
it's
kind
of
up
to
you
to
kind
of
filter
out
if
you
want
to
only
apply
that
to
certain
groups
or
or
something,
but
once
you
put
a
receive
book
on
a
git
server
or
repositories
handled
by
that
server
are
going
to
be
checked.
A
Next
question
is
what
process
would
be
in
place
to
detect
new
vulnerabilities
for
applications
deployed
to
production?
That's
a
great
question
and
I
think
michael
touched
on
it
a
little
bit
earlier
in
the
talk
we
said
every
every
day
there
is
up
to
50
new
vulnerabilities
that
are
being
discovered
right.
That
means
that
an
application
that
we
deployed
yesterday,
which
essentially
had
no
known
vulnerabilities,
could
be
vulnerable
today
because
of
the
fact
that
new
vulnerabilities
were
discovered
and
suddenly
our
application
is
vulnerable
to
get
around
that.
A
We
go
through
some
of
these
tools
that
we
mentioned
and
we
make
those
tools
scan
our
production
applications,
and
then
we
get
the
data
from
production
and
then
obviously
there's
some
slas
for
certain
high
vulnerabilities
and
some
zero-day
vulnerabilities
obviously
will
need
a
hot
fix
and
things
like
that
and
the
process
itself
takes
care
of
that
things
get
into
the
team's
backlog.
And
then
things
are
done
in
that
fashion.
A
B
The
creative
work
is
something
that
we
create,
but
there
are
a
lot
of
open
source
examples
on
how
to
do
it.
So
if
you,
if
you
just
google
for
precive
hook
examples,
there
are
repos
from
github
itself
that
that
show
a
lot
of
examples
of
stuff
that
you
can
check
in
placing
hooks.
So
at
this
point,
it's
up
to
you
to
pick
and
choose
or
create
your
own
version.
B
A
A
topic
for
for
a
discussion
king
another
day,
maybe
dennis,
is
back
there.
I
know
gitlab
does
support
global
pc
for
global
commit
hooks.
You
were
talking
about
later.
Yes,
yes,
so
the
pre-committee,
when
we
talk
about
pre-committee,
we're
talking
about
the
actual
developer
working
on
their
laptops
right,
something
that
runs
on
their
machine.
So
you
need
a
way
to
distribute
your
whatever
your
commit
hook.
A
Process
is
to
all
of
those
laptops
right.
If
you're,
if
you're
working
with
a
massage
company
about
500
developers,
you
need
to
figure
out
a
way
to
distribute
that
as
long
as
you
have
a
central
way
of
distributing
that
I
mean
that
code
is
then
the
same
in
all
of
the
developer
laptops.
So
hopefully
that
should
take
care
of
that
and
not
everybody
and
people
can
disable
it
also
right
and
that's
that's
another
process
issue,
but
having
a
pre
receive
hook
is,
is
going
to
be
a
guard
rail
there
right.
A
B
A
Bet
you
had
one
question:
can
you
share
more
details
about
the
security
rules,
rules
engine
you
used
to
scan?
It
is
something
that
we
built
internally
within
our
company.
It
is
different
from
some
of
the
tools
that
the
vendor
tools
that
we
talked
about
right.
You
have
to
be
able
to
ensure
that
the
security
principles
that
we
laid
out
right.
We,
those
tools,
are
also
being
compliant
right,
so
such
as
encryption
address
such
as
authentication
with
sso
right.
You
want
to
you
want
to
do
something
of
your
own
right.