►
From YouTube: Automating Industry Regulation (SoX, SoC 2) Enforcement... Balaji Sivasubramanian & Gopinath Rebala
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Automating Industry Regulation (SoX, SoC 2) Enforcement During Software Delivery - Balaji Sivasubramanian & Gopinath Rebala, OpsMx
The development teams in Enterprises are increasingly deploying to environments that need to adhere to various industry regulations like SoX, SoC 2, FedRamp, etc. With the increased frequency of deployments and the need to audit the deployments, it is becoming imperative that these control and enforcement are automated as part of the CI/CD process. In this talk, we will show how to integrate OPA policy integration with CI/CD tools and share sample policies for enforcing compliance rules based on real-world regulatory requirements. Also, we will demo the integration including an audit of the policy enforcement.
A
A
A
A
You
know
whether
you're
a
sas
company
or
your
website
collecting
data
that
you
have
certain
rules
and
regulations
that
you
have
to
follow
for
for
that
for
that
process
and
obviously,
if
you're
collecting
credit
cards,
and
you
have
to
obviously
comply
with
the
pci
if
you're,
even
if
you
know,
if
you're
doing
any
public
company
you're,
probably
familiar
with
sox
compliance,
there's
a
lot
of
regulations
around.
How
do
you
do
financial
reporting,
but
obviously
software
team
also
is
impacted
by
these
regulations.
A
Obviously,
the
iso
27
27001
is
obviously
very
popular
and
pretty
common
for
any
industries.
Both
you
know
via
topsail
max.
We
just
recently
went
through
these
stock2
compliance
ourselves
and
as
well
as
the
iso
22
2001..
So
there's
a
lot
of
things.
That's
besides!
What's
covered
in
this
dock
in
this
presentation,
but
you're
going
to
see
some
commonalities
between
all
of
these
things,
gdpr,
obviously,
is.
A
So,
to
give
you
a
couple
of
this
in
stock,
2
primarily
breaks
down
this
this.
You
see
these
pillars
here,
and
this
is
typically
kind
of
repeating
across
all
of
these
compliance
frameworks,
right
so
meaning,
if
you're
stock,
too
compliant
you're,
probably
partially
compliant
on
on
other
compliance
as
well.
A
Like
I
think
one
statistics
I
said
I
read
was
if
you're
an
ist
compliant
you're,
probably
80,
compliant
iso
27001,
or
something
like
that,
so
there's
always
a
overlap
of
what
you
have
to
enable
and
process
and
and
controls,
and
they
are
very
similar
across
these
things.
There
are
some
variants,
obviously
that
you
have
to
adhere,
and
obviously
you
have
an
auditing
process,
so
the
auditors,
for
that
compliance,
are
going
to
ask
you
specific
things.
A
So
that's
that's
true,
but
if
you
enable
many
of
these
things
as
a
general
practice,
you're,
probably
more
closer
to
getting
compliance
certification,
so
security
is
obviously
protecting
the
information
for
unauthorized
access.
Obviously,
the
disclosure
of
information,
everything
that
you
think
about
security
perspective,
particularly
for
sarc2.
That
is
the
only
criteria
that
you
need
to
comply
with
to
get
the
certification.
The
rest
of
them
is
basically
is
not
part
of
the
compliance
requirement,
but
it
is
something
you
you
would
probably
do
anyway,
like
availability
make
sure
that
systems
are
available.
A
A
If
you
look
at
socks
compliance
very
quickly,
obviously
this
is
purely
from
a
regular
financial
reporting
perspective,
but
from
a
software
team
perspective,
one
of
the
requirements
I've
seen
is
that
obviously
suppression
of
duty
right
people
who
are
creating
and
or
making
changes
to
the
software
cannot
be
the
approvers
of
things
to
the
production,
also
to
obviously
to
prevent
some
malicious
actor
being
able
to.
You
know,
push
incorrect
data
or
or
incorrect
software
to
the
production
systems.
A
So
what
are
the
drivers
for
automation
of
these
compliance
checking
right?
So
the
current
process,
I've
seen
in
one
of
the
large
customers
that
we
work
with,
they
really
create
a
ticket,
and
then
it
goes
to
a
ticketing
system
and
then
there's
a
compliance
team
that
checks
that
you
know
the
compliance
of
the
software
before
they
approve
or
reject
it,
and
you
know
sometimes
they
do
it
on
friday.
That
means
nobody's
checking
it
for
till
monday
morning.
A
So
there's
a
lot
of
basically
time
lost.
So
if
you're
trying
to
do
continuous
delivery,
it
makes
it
very
hard
and
obviously,
though,
the
devops
model,
the
developers
are
pushing
core
to
production
in
some
ways
right
that
is
self-service
as
well.
So
you
want
to
make
it
easy
for
developers
to
be
able
to
comply
to
all
the
regulations.
You
don't
want
to
make
it
there's.
Another
team
is
going
to
look
at
it
ad
hoc
right.
A
You
want
to
be
part
of
the
delivery,
workflow
and
that's
something
is
very
important,
particularly
when
the
frequency
of
deployment
is
increasing.
There's
no
way
to
do
it.
Ad
hoc,
like
we,
are
doing
right
now,
which
is
creating
a
ticket
outside
the
process
and
waiting
for
somebody
to
do
something,
and
also
the
in
order
for
us
to
scale.
You
want
to
make
it
the
the
compliance
policies
and
security
policies.
You
know,
as
the
version
control
best
practice
widely
available
for
the
enterprise.
A
If
you
make
a
change
somewhere,
it's
also
available
quickly
across
the
every
every
argument.
Every
software
deployment
that's
happening,
so
that's
very
important
and
the
last,
but
not
the
least,
is
basically
the
auditing
part.
That
has
to
be
also
be
part
of
this
compliance
automation
because
without
auditability
or
evidence,
collection
you're
not
going
to
be
able
to
get
compliance
from
your
auditors.
So
that's
pretty
important.
A
So
what
are
some
of
the
other
complexities?
If
you
look
at
a
ci
cd
pipeline,
you
know
from
core
to
core
to
production,
basically,
and
you
have
to
secure
the
delivery
process.
So
some
of
the
things
around
is
obviously
the
role-based
access
control
in
terms
of
who
can
access
the
system
itself,
as
well
as
granularly
at
the
application
level
who
can
access
a
specific
application
and
also
specific
approvals
and
stages
and
those
kind
of
things
that's
also
very
important.
A
So
the
granular
level,
the
the
role-based
access
contrast
at
a
fine-grained
level,
not
just
an
application
level
or
pipeline
level,
either
the
exchange
level
and
many
many
things
you
have
to
enforce
this
also,
you
know
in
a
policy
model
so
that,
and
you
have
to
set
up
guardrails
people
will
make
mistakes
right.
They
some
may
not
be
harmful
or
intentional,
but
they
will
make
mistakes.
A
So
you
need
to
make
sure
that
you
set
up
the
guardrails,
the
other
piece
that
we
struggle
with
in
our
company
and
I'm
sure
about
other
companies
is
how
do
you
maintain
the
keys?
You
know
we
have
you
get
a
notification
from
aws
that
your
keys
are
public
in
every
other
day
right,
and
so
we
got
to
make
sure
that
those
things
are
not
happening.
So
again,
that
also
needs
to
be
secrets
of
the
you
know,
infrastructure
that
you're
deploying
to
as
well
as
secrets
that
you
use
for
your
software
itself.
A
Those
has
to
be
maintained
at
scale,
and
we
talked
about
the
the
devops
approval
process.
Essentially,
that's
another
challenge
that
we
need
to
address
is
essentially
it
has
to
be
part
of
the
system,
not
our
outside
evidence,
collection,
and
these
are
called
what
I'm
calling
it
under
the
process
right.
This
is
something
that
you
have
to
enable
and
and
then
application
security.
A
You
have
already
familiar
with
the
already
using
existing
tools,
like
you
know,
sonar
cube
or
other
scanning
tools,
security
scanning
tools,
sassy
dasty
tools
and
those
has
to
be
integrated
as
part
of
the
process,
so
so
that
your
results
are
available
in
line
and
and
if
you
need
a
pipeline
needs
to
be
stopped,
then
you're
able
to
stop
that
right.
There
or
people
are
making
approvals.
They
have
all
the
information
available
to
make
the
right
calls
and
also
you
have
to
look
at
application
risks,
also
in
an
automated
fashion.
So
what
that?
A
What
I
mean
by
that
is,
you
are
releasing
a
new
software.
You
can't
expose
new
ports,
for
example,
or
you
can't
deploy
in
in
for
gdpr
compliance,
for
example,
maybe
deploy
another
region
that
you're
not
supposed
to.
So
those
things
has
to
be
integrated
as
part
of
the
as
part
of
the
compliance,
automation
and
last
part
is
obviously
you
have
to
be
able
to
do
it
at
scale
right.
So
this
is
the
part
where
it's
one.
A
It's
it's
very
easy
to
do
it
at
slow
pace,
but
if
you
have
to
do
it
at
scale,
if
there
is
a
vulnerability
on
one
app
one
application,
then
you
don't.
You
want
to
quickly
figure
out
the
supply
chain
information
and
to
figure
out
what
are
the
applications
that
are
running
in
the
production
that
are
affected
by
these
things.
A
So
we
work
as
a
ops
x.
We
obviously
do
it
for
ourselves,
but
also
we
work
with
a
lot
of
other
clients,
large
large
companies,
and
so
we
have
had
a
lot
of
help.
You
know
experience
expertise
in
trying
to
help
it,
and
I
would
like
to
turn
it
over
to
gopi
who
is
going
to
walk
us
through
how
you
know
we
have.
We
have
seen
it
done
and
we
have
done
as
well
and
take
it
from
there.
B
Thank
you,
you
guys
can
hear
me.
Okay,
thank
you.
So
we
went
through
what
is
the
complexity
in
automating
these
compliance
requirements
right?
It's
part
of
the
problem
comes
because
of
the
speed
of
the
delivery
requirements
and
the
changes
that
are
being
done.
We
also
want
to
have
developers
be
responsible
for
some
of
their
application
delivery,
but
at
the
same
time
we
want
compliance
to
be
applied
centrally,
as
an
organization
requires
now.
The
question
is
these:
compliances
have
many
aspects
to
it.
B
Some
of
them
defines
physical
security,
virtual
security
processes
and
all
of
it,
but
we
are
mostly
focused
on
the
continuous
delivery,
but
even
then
a
couple
of
questions,
how
do
you
map
these
requirements
into
requirements
for
the
continuous
delivery?
The
second
one
is:
how
do
you
automate
these
parts
of
it
without
having
to
be
a
one-time
implementation,
hard
to
change
and
be
a
continuous
living
thing,
so
just
to
give
a
high-level
view
on
most
of
these
compliances
standards?
B
You
know
follow
these
kind
of
confidentiality,
availability
and
integrity
rules,
cia
rules,
so
these
define
guidelines
in
most
cases
in
some
of
the
cases
where,
like
fedramp,
they
get
a
bit
more
prescriptive,
but
essentially
what
they
are
trying
to
do
is
in
the
confidentiality
the
separation
of
duties
are
back
and
making
sure
the
data
is
secure,
both
in
rest
and
in
transit.
Those
kind
of
definitions
will
be
there
in
terms
of
integrity.
B
You
have
the
integrity
of
the
data.
Whoever
can
modify
the
data
only
should
be
able
to
modify
the
data
and
should
not
be
available
for
the
rest
of
the
groups
or
people,
and
you
want
to
be
able
to
provide
the
traceability
of
the
artifacts.
So
you
deploy
something
in
production.
You
want
to
be
able
to
trace,
who
changed
it,
who
approved
it
and
what
was
tested
on
it
etc.
All
of
these.
So
these
are
the
ones
I'm
just
highlighting
a
couple
of
those
availabilities
more
in
terms
of
making
sure
the
system
is
available.
B
You
have
best
practices
for
ddos
attacks,
replica
hindrance,
those
kind
of
things
we
need
to
make
sure.
So
these
are
the
core
issues
that
you
can
automate
as
part
of
your
process
right
now,
if
you
look
at
what
does
it
involve
in
automating
these?
So
we
have
multiple
actors
in
an
organization,
so
the
developers
are
responsible
for
a
few
things
like
code
scans,
code
reviews
and
things
like
that,
and
then
you
may
have
a
performance
analysis
departments
that
are
looking
at
qa
validation,
performance,
analysis
of
those,
and
then
you
have
secops.
B
That's
focused
on
what
is
your
compliance
requirement
specification
of
those
and
approving
the
architecture
that
is
required
for
the
deployment
and
things
like
that
and
the
operations
want
to
make
sure
the
changes
that
are
going
in
is
not
going
to
break
their
production
or
anything
that
changes
needs
to
be
rolled
back.
No
changes
happen
to
save
firewall
rules.
Some
of
these
we
will
see
in
the
demo
later
so.
The
complexity
here
is
the
handover
process
and
also
specification
of
these
requirements
by
the
enterprise
and
making
sure
these
are
followed
right.
B
So
the
core
idea
here
is
that
the
policy
specification
needs
to
be
shared,
documented
version
control
that
can
be
directly
applied
onto
your
data.
We
use
the
open
policy
agent
for
these
policies
and
one
of
the
things
that
you
can
see
the
three
things
I
would
like
to
highlight
right.
So
the
separation
of
these
policies
from
the
data,
the
second
one,
is
being
able
to
specify
your
process
itself
as
code
or
something
like
a
pipe
pipeline
s
code.
B
Our
underlying
delivery
platform
is
spinnaker
in
spinnaker
we
have
pipeline
specification
that
can
be
stored
in
git
version
control.
It
has
certain
number
of
steps
that
you
specify,
but
one
of
the
core
requirements
there
is.
These
steps
are
like
a
metadata.
You
want
to
be
able
to
specify
the
steps
separate
from
actual
execution
of
it.
For
example,
you
have
a
requirement
to
say
dynamic
code
analysis
or
you
require
a
canary
analysis
before
going
into
the
production.
B
You
want
to
be
able
to
specify
these
steps
are
required
as
a
policy
document
and
as
the
pipeline
specification
executes
pipeline
executes
depending
on
the
target
environment.
Let's
say
it's
going
to
production,
then
you
enforce
saying
the
pipeline
process
definition
itself
to
include
the
canary
analysis,
so
these
are
like
guard
rails
of
when
the
developers
are
developing
these
pipelines
for
their
delivery.
B
You
ensure
and
give
them
the
guidelines
saying
these
needs
to
be
there.
So
essentially
these
policies
controlled
by
central
department,
but
actual
pipelines,
are
created
executed
by
the
devops
groups.
That's
one!
The
second
one
is
this
audit
database
right.
So
all
of
this
data
that's
generated
by
different
tools
in
an
organization
you
know
there
are
so
many
devops
tools
right.
Everyone
has
slight
variations
of
those.
B
You
want
to
be
able
to
collect
this
metadata
for
these
tools
in
centrally.
So
then
you
can
apply
these
policies
on
it.
Not
only
that
you
want
to
be
able
to
have
the
observability
so
the
way
one
of
the
simple
use
cases
that
we
use
here
is
the
the
immutable
artifact
in
spinnaker
containers
with
the
shah
or
even
the
amis.
Those
are
immutable
that
we
test
and
then
deploy
to
production.
We
use
the
same
amis,
so
you
have
those
shards
by
simply
tracking
the
shaws.
B
By
having
the
metadata
coming
from
the
code,
scans,
dynamic
analysis
or
vulnerability
scans,
you
we
have
ability
to
point
to
whichever
scans
that
were
done
and
their
results.
So
now
you
can
have
a
policy
document
that
specifies
a
minimum
requirement
for
your
cves,
for
example,
with.
If
they
don't
match
those
cve
requirements,
then
you
stop
that
mission
to
the
production,
okay,
so
very
simple
structure,
but
very
powerful
in
allowing
the
self-service,
the
centrally
defining
these
policies
and
the
developers
have
the
ability
to
create
their
own
pipelines
that
are
confirmed
to
these
policies.
B
B
Typically,
you
may
think
that
machine
learning
analysis
would
generate
the
risk
and
you
basically
control
deployments
based
on
the
ml
analysis,
but
the
way
our
customers
mostly
have
started
using
it
is
you
use
the
ml
analysis
for
the
risk
analysis,
so
there's
a
certain
score,
but
then
use
that
score
as
a
policy
document
that
says,
if
it's
above
the
score
automatically
go,
allow
it
to
deploy
to
production,
but
if
it's
below,
then
they
go
through
a
manual
process.
So
there's
a
two-step
process,
even
with
mml.
B
B
B
It
doesn't
matter
right
because
we
are
now
able
to
collect
the
data
from
each
of
these
stages
into
a
metadata
store
and
providing
the
guard
rails,
allowing
them
to
have
these
stages
in
place.
So
if,
if
a
pipeline
removes
the
dynamic
analysis
and
the
policy
document
says
it
requires
it,
then
they
won't
be
able
to
remove
it.
B
In
fact,
they
won't
be
able
to
save
that
pipeline
document
for
their
execution
and
then,
at
the
time
of
the
production
deploying
to
production,
you
can
do
a
a
admission,
control
kind
of
a
check
that
simply
check
would
be
applying
the
data
from
the
metadata
store
for
that
artifact,
that
we
are
deploying
it
to
the
policy
engine
and
if
it
says
yes,
you
go
forward.
If
it
says
no,
you
have
the
list
of
policies
that
have
violated
or
not
been
executed.
B
So
you
would
stop
and
then
it's
very
easy
to
go
back
and
correct
those
things
right
now,
because
we
are
able
to
create
these
policy
documents
just
for
the
process
itself,
as
well
as
individual
stores.
We
are
able
to
share
this
between
the
developers
and
security
groups
and
operations
very
easily
and
change
for
them.
So
now
we
will
see
some
of
the
demos
for
a
couple
of
these
processes.
A
A
If
you
think
about,
there
are
multiple
players
in
the
in
the
pipeline,
as
gopi
pointed
out,
and
everybody
needs
something
else,
and
some
of
them
are
compliance
related,
and
some
of
them
might
not
be
components
related,
but
many
of
them
are
compliance
related.
If
you
think
about
it-
and
so
these
are
some
of
the
examples
of
pipelines-
things
policies,
people
have
enabled
so
in
the
demo
that
I'm
going
to
show
you,
we
are
using
spinnaker
and
we're
using
opa
as
a
policy
server
for
checking
the
compliance
we
have
collecting
data
sources.
A
Obviously
the
data
data,
the
data
itself,
multiple
data
sources-
are
getting
collected
and
stored
in
a
data
store
like
gopi,
was
pointing
out.
That's
pretty
important
because
you
want
to
be
able
to
have
policies
not
only
on
let's
say
the
spinnaker
or
execution
orchestration.
Think
of
spinnaker
as
an
orchestration
platform
for
this
use
case
right,
meaning
you
could
have
something
else
and
you
could
have
different
things,
but
oppa
essentially
is
collecting
the
the
oppa
will
be
basically
be
the
enforcer,
but
there's
a
data
collection
data
lake.
A
Essentially
you
have
to
collect
the
data
and
store
the
data.
Lake
and
spinnaker
will
be
the
occupational
layer
that
will
trigger
these
enforcement
points
said.
Is
it
alert
or
not?
A
law
right
and
oppa
is
the
one
who
is
making
the
decisions,
and
once
all
of
these
decisions
are
done,
or
it's
happening,
you're
also
storing
it
in
audit
right
now,
you're
storing
all
the
events
from
all
the
data
sources,
but
also
storing
the
results
of
these
compliance
checks.
So
essentially,
then
you'd
be
able
to
satisfy
an
auditor.
A
So
let's
take
a
quick
example
here:
one
is
around
sax
compliance,
which
is
basically
a
separation
of
duty.
I
think
this
is
one
of
the
common
use
case
that
we
have,
but
that
a
few
few
things
one
is
the
person
who
is
triggering
the
pipeline
or
triggering
the
court
check-in,
for
example,
should
not
be
the
one
who
is
approving
it,
approving
the
artifact
of
production
right
or
or
somewhere
else,
or
to
the
next
stage.
A
You
want
to
make
sure
that
there's
a
separation
of
duty
so
that
there's
two
people
who
is
doing
it
and
and
you
can
control
that
through
a
policy
and
or
you
can
have
let's
say
you
have
two
approvals-
maybe
an
approval
from
qa
to
staging
and
another
approval
from
staging
to
production.
You
want
to
make
sure
that
the
approver
that
is
doing
the
qa2
staging
is
not
the
same
approval
for
doing
from
staging
to
production.
A
Okay,
so
there's
there's
these
pipelines
here,
so
the
first
demo,
basically
is
about
suppression
of
duty.
So
if
you
look
at
the
pipeline,
essentially
there's
a
bill,
there's
a
deploy
to
test
and
there's
approval
production.
So
this
we
are
doing
a
suppression
duty
check
here
to
ensure
that
somebody
who
triggered
this
build
process
is
not
the
same
one
who's
going
to
approve
the
production,
and
so
we
will.
We
will
create
this
execution
right
now.
A
It
will
take
a
minute
to
execute
and
in
the
meantime,
what
I
will
do
is
I'll
show
you
the
next
demo
that
I'm
going
to
tee
up,
and
you
will
see
that
also
so
the
next
demo
is
basically
the
next
we
talked
about.
Is
that
two
pro
two
approvals?
One
is
the
the
approvals
here.
This
particular
pipeline
actually
has
two
approvals
verified
to
qa
or
verify
your
staging,
approve
the
staging
and
then
approve
the
production,
so
we'll
here
we'll
show
you
that
you
can't
have
the
same
approver
approving
it
twice.
A
Let's
execute
that
first,
so
here
it's
it's
going
to
go
to
an
approval
and
this
policy
code
we
just
saw
already
in
the
slide.
This
is
an
approval,
so
I
am
the
approver
here,
I'm
going
to
approve
right
now,
so
the
next
it's
going
to
go
to
the
approval
to
production.
Now,
since
I'm
the
same
approver,
if
I'm
going
to
approve,
I
have
access
to
the
approval
or
I
have
the
authorized
approval,
but
just
because
I
have
approved
the
first
one,
I
can't
be
the
same
person
approving.
A
So
if
I
try
to
approve
it
again,
what
will
happen
is
there's
a
policy
check
and
it's
going
to
check
really
quick
and
give
you
a
result
and
say:
okay,
there
you
go
you
kind
of
you
can't
you
reject
it
right.
This
is
an
example
of
ability
to
do
suppression
of
duty
checked
as
part
of
the
pipeline.
So
if
there's
another
state
typically
would
be
a
production
deployment.
If
it
was
different
approvers,
then
it
will
obviously
go
to
the
production
department.
A
Let's
go
back
to
the
previous
one,
the
example
where
I
triggered
the
pipeline,
and
that
means
I
am
the
starter
of
the
pipeline.
I
should
also
not-
I
should
be
not
with
also
the
approver
of
the
pipeline,
so
separation
of
view
again.
Another
another
check
here,
I
I'm
going
to
try
to
continue
here,
which
you
should
fail
there
you
go.
It
failed
immediately
because
I
I
created
the
pipeline
also
another
example
I
want
to
show
you
is:
is
how
do
you
do
process
integrity
check
right?
A
This
is
something
very
important
to
make
sure
that
when
you're
doing
compliance
checks,
if
you
have
certain
process
in
place-
and
you
don't
want
your
developers
to
circumvent
the
process,
for
example,
this
is
a
stock
2
requirement
where
I
have
a
requirement
in
this
case
to
be
able
to
have
deployment
of
production,
go
through
an
approval
process,
so
I
don't
want
to
have
deployments
going
straight
to
an
approval.
This
up
deployment
is
actually
an
approval.
It's
deploying
a
kubernetes
cluster,
as
you
can
see
here.
A
I
don't
want
that
deployment
to
this
cluster,
for
example,
go
straight
without
an
approval
right,
so
I
have
this
approval
stage,
so
let's
say
I'm
trying
to
be
sneaky
and
I'm
going
to
try
to
remove
the
upper
wall.
So
apparently,
let's
say
it's
going
to
some
other,
my
boss,
and
I
don't
want
that
person
to
see
that
I'm
actually
deploying,
and
so
I'm
going
to
try
to
remove
this
stage,
for
example-
and
this
is
essentially
I'm
trying
to
circumvent
the
process
right,
the
process
integrity
is
lost.
A
Now,
if
I
try
to
save
this
see,
I
have
a
policy,
even
though
there's
no
policy
stage,
but
it's
all
always
running
to
ensure
that
there's
a
policy
you
can't
remove
manual
judgment
state
that
this
is
very
useful.
Now
I
can't
save
it
so
I
have
to
really
go
out
of
it
because
there's
no
way
to
save
this
pipeline,
because
I
try
to
commit
a
policy
violation
and
the
last,
but
not
the
again.
You
can
set
up
a
lot
of
things
you
can
set
up.
A
Things
like
I
can
have
a
policy
which,
which
is
which
would
we
can
only
go
to
qa
if
all
the
if
we
go
to
production
only
if
all
the
qr
tickets
are
closed.
High
priority
is
closed.
So
many
different
ways
you
can
define
policies,
but
what
you're
saying
here
is
that
you
want
to
make
sure
that
you
have
the
ability
you
could.
You
could
control
things
and
set
up
the
required
regulatory
policies
as
part
of
the
pipeline.
That's
our
sort
of
our
ask
here
to
you
guys.
A
Another
thing
is
I'm
going
to
check
the
compliance
check,
for
example,
an
application
is
getting
deployed
here
and
an
application
is
getting
deployed.
I
want
to
make
sure
that
we
are
able
to
check
this
this
thing,
so
I'm
scanning
the
deployed,
let's
say
you're,
deploying
to
staging,
and
I
want
to
make
sure
that
the
deployed
artifact
the
developer,
didn't
change
any
new
new
security
ports,
for
example.
A
Let's
see
so
again,
all
of
these
policies
and
more
of
them
are
available
on
this
website,
so
you
can
go
download
it
and,
and
please
people
to
do
a
pull
request.
If
you
have
some
that
you
want
to
contribute
and
you
so
there
you
go,
it
went
through
that
it,
it
pulled
the
deployed,
artifact
and
and
and
here's
a
basically
what
we
found
out
from
the
security
group.
A
The
port
22
is
open,
so
we
we,
our
policy
basically
was
there
to
to
was-
was
to
make
sure
that
it's
not
happening
right.
So
we
have
we.
This
is
what
we
recommend
as
what
you
should
be
doing
to
really
get
automating
the
compliance.
So
that's
our
sort
of
recommendation
here
you
want
to
automate
regulation
during
software
delivery,
make
sure
you
have
all
the
checks,
security
checks
and
tools
as
part
of
a
pipeline.
A
So
there's
nothing
ad
hoc
going
on
this
is
very
important
so
that
you
get
the
data
and
you
use
it
for
traceability
and
auditability
of
your
delivery,
and
you
also
want
to
make
sure
there
are
if
there
are
processes
and
things
that
you
want
to
enable
and
do
it
as
a
policy
so
that
you
are
available
to
audit
it
as
well
as
automate
the
policy,
and
you
have
admission
control
checks,
obviously
to
make
sure
that
you
have
it.
The
policies
are
available
on
this
github
so
feel
free
to
use
it.
A
If
you
have
suggestions,
feel
free
to
suggest
a
pull
request
or
or
issue
on
it,
and
also,
if
you
want
to
use
our
the
demo
that
we
just
showed
you,
you
can
go
download
the
community
edition
of
our
what
we
call
autopilot,
which
is
basically
an
automated
way
to
do:
cd,
validation
checks
and
audit,
etc,
etc.
So
it's
available
as
a
free
download
and
it's
primarily
for
spinnaker
today,
but
we're
also
adding
support
for
argo
in
the
in
the
near
future.
A
A
A
Yeah,
so
so,
first
of
all,
you
need
to
be
able
to
so
we
recommend
something
like
a
spinnaker,
for
example,
to
be
able
to
automate
the
workflow
in
the
first
place
right,
so
you
have
end-to-end
automation,
everything
is
scored
like
pipeline
scored
and
those
kind
of
things
that's
very
important
to
to
do.
That.
Second
part
is
you're.
Integrating
all
these
tools,
like
you,
know
your
build
tools,
your
scanning
tools
and
other
tools.
You
want
to
be
able
to
collect
the
data,
that's
part
of
that
particular
pipeline.
Let's
say
you
take
a
court
check-in.
A
You
want
to
be
able
to
really
trace
the
court
check-in
to
build
to
the
results
from
of
the
build
from
scanning
tools
and
other
tools,
and
then
the
deployments
that
the
the
immediate
data,
the
ports
that
are
open
you
want
to
be
able
to
track
all
of
them.
So
you
want
to
collect
all
the
ingested
information
in
a
data
lake.
Now
you
have
the
data
from
from
the
cd
tool
and
you
have
the
obviously
the
data
from
all
the
tools
in
a
data
lake.
A
Then
you
can
create
these
enforcement
policies
through
an
opa
so
that
you
have
to
feed
the
opera
through
the
lego.
You
have
to
feed
the
oppa
server
the
data
and
the
your
policy.
Then
you
can
do
it,
so
I
would
suggest
spinnaker
oppa,
obviously
the
data
lake
piece.
Obviously
you
may
have
to
build
it.
If
you
don't
have
it,
because
that's
essentially
the
crux
there
and
also
you
want
to
do
audit.
So
you
want
to
take
all
the
events
from
all
the
tools
and
be
able
to
put
an
audit
database.