►
Description
Speaker: Liran Haimovitch
Do you have experience with security in your software development process but none at all with compliance? Join this session to hear our journey as we set out to become SOC-2 compliant.
Armed with very little public documentation on how to become SOC-2 compliant, we built SOC-2 procedures around Agile software development and DevOps patterns such as CI/CD and GitOps. Although it typically takes about a year to complete SOC-2 compliance, we obtained certification in less than six months.
You will learn how Agile processes and DevOps can address and outperform traditional methods for managing security and compliance. This talk will empower you to tailor your enterprise compliance needs to your desired software development process.
Get in touch with Sales: http://bit.ly/2IygR7z
A
B
B
Workout
is
a
secure
platform
for
live
data
collection
and
debugging
using
root
cause
non-breaking
breakpoint
engineers
can
connect
to
their
source
code
as
it's
running
remotely
in
the
cloud
on-prem
and
staging
even
in
production
and
collect
any
piece
of
data
on
the
fly
without
writing
more
code
without
redeploying
without
restarting
just
click
on
the
button
and
get
the
data
you
need
to
do
that.
You
install
rook
out
sdk
and
you
load
your
source
code
from
github
or
other
source
providers,
then
just
throw
a
non-breaking
breakpoint.
B
B
I'm
saying
that
it's
engineering
leaders
who
are
worried
about
security
are
usually
coming
it
from
one
of
two
angles:
the
first
they
are
leading
a
small
organization,
that's
growing
and
needs
to
achieve
more
compliance
and
so
they're
trying
to
learn
about
compliance
and
see
how
they
can
adopt
it,
while
maintaining
their
growing
and
agile
the
development
team.
The
other
approach
is
often
from
engineering
leaders
in
larger,
more
established
firms
or
trying
to
adopt
devops
and
agile,
while
still
maintaining
their
existing
compliance
needs,
and
both
cases
are
about
figuring
out
how
the
two
can
coexist.
B
B
Who've
gone
through
stock
to
type
2
at
various
companies,
and
we've
met
with
our
auditors
and
we
kind
of
came
up
with
a
plan
of
how
can
we
make
it
both
of
them
happen
together
now,
to
give
you
some
context,
governance
compliance
is
mostly
about
governance.
It's
about
proving
that
u.s
engineering
leaders
know
what's
going
on
within
your
organization
and
can
prove
it
to
the
auditors
and
to
your
customers.
B
Our
own
research
has
found
that
an
organizational
culture
that
optimizes
for
information
flow
trust,
innovation
and
risk
sharing
is
predictive
of
software
development
organization
performance.
So,
if
you
want
devops,
you
should
go
for
trust.
You
should
go
for
risk
sharing,
but
if
you
want
governance,
you
might
end
up
with
this
quote
saying
in
business,
we
often
use
the
more
political
list
to
term
governance
instead
of
control.
B
B
B
B
B
B
Maybe
it
cannot
be
stolen
me?
I
don't
know,
but
if
you
feel
this
is
not
a
significant
risk,
then
you
often
can
document
it
document.
This
is
an
acceptable
risk
and
you
can
live
with
it
and
there
is
a
good
chance.
You
can
convince
your
auditors
and
other
relevant
stakeholders
that
you
know
what
you're
doing,
and
this
can
be
acceptable
now
going
through
this
process.
We
ended
up
with
three
main
pillars
of
compliance
at
workout,
so
I
want
to
share
with
you
them.
B
I
want
to
show
them
with
you
and
go
through
them
one
by
one.
First,
we
have
automation
now
this
is
a
devops
conference
and
you're
going
to
be
hearing
a
lot
about
automation
through
gitlab
and
other
tools
today,
but
for
now
we're
focusing
on
the
value
of
automation
for
security
and
the
value
of
automation,
for
security.
B
B
It
can
be
deploying
stuff
to
kubernetes,
it
can
be
changing
our
cloud
configuration,
it
can
be
spinning
machines
up
and
down
whatever
it
is,
implement
those
tools,
and
then
employees
can
invoke
them
as
needed
with
the
entire
process
audited
into
logs.
So
you
know
we
access
this.
You
know
who
accessed
the
system,
you
know
what
you
did.
B
Now
there
are
many
automation
candidates,
some
of
them
include
deployments
and
releases
which
we're
going
to
talk
about
more
in
a
bit.
It
includes
provisioning
and
de-provisioning
of
environments,
it
includes
system
integration,
tests,
maintenance
and
cleanups
and
backups
and
restores
now
in
automating
for
security.
You
have
to
keep
in
mind
the
principle
of
fleece
privilege,
which
of
those
operations
showing
up
here
or
otherwise
are
executed
by
many
of
your
engineers,
which
of
those
operations
require
a
lot
of
privileges
to
sensitive
stuff.
B
If
you
can
find
a
handful
of
tasks
that
by
automating,
you
can
revoke
sensitive
access
from
engineers
and
they
no
longer
need
it,
then
that's
those
are
excellent
tasks
to
automate,
and
so
it's
much
easier
to
prove.
You
know
what's
going
on,
because
the
engineers
aren't
accessing
the
environment
directly,
they
don't
have
access
to
and
anything
that's
happening
through.
The
portal
through
the
automation
is
well
audited.
B
Gitlab
has
many
tools
for
a
ci
cd-ops
and
whether
it's
a
the
gitlab
ci
tool,
the
gitlab
cd
tool,
merger
quest
and
so
on,
and
then
from
a
security
perspective.
It's
all
about
shifting
left,
it's
all
about
baking,
security
into
the
process
we
already
have
so
that
we
write
and
develop
secure
code,
secure
applications
in
the
first
place,
rather
than
trying
to
write
the
applications
first
and
then
make
them
secure.
Second,
some
of
the
benefits
for
taking
this
approach
for
securing
applications
include
that
you
get
a
single
source
of
truth.
B
Everything
gets
deployed
through
cicd,
so
you
know
what's
deployed
by
going
through
the
ci
logs
by
going
through
these
vlogs.
By
going
through
the
git
commit
history,
you
know
exactly
what
went
where
and
when
you
also
get
the
benefit
of
shifting
left.
You
are
empowering
your
engineers
to
secure
code.
Security
becomes
a
deeper
part
of
the
system
and
you
are
achieving
it
much
better
now.
B
This
brings
us
to
merge
requests.
Merge
requests
are
an
existing
gating
mechanism
within
modern
software
development
that
your
engineers
is
already
familiar
with
by
adding
any
compliance
requirements
you
have
to
the
merger
quest.
You
ensure
that
by
the
time
the
co,
the
code
makes
it
to
the
main
or
master
branch.
It's
already
secure,
it's
already
compliant,
so
you
can
go
ahead
and
add
dependency,
checking
security
scanning
manual
reviews,
anything
you
need
as
prerequisites
to
the
merge
requests
and
then
once
the
code
is
merged,
once
those
checks
pass,
the
code
can
be
merged
and
it's
compliant.
B
B
B
B
Understandability
is
a
term
borrowed
from
the
financial
industry,
and
so
it's
measuring
how
hard
or
easy
it
is
for
an
engineer
to
comprehend.
The
system
is
working
on
so
that
you
can
efficiently
and
effectively
fix
bugs,
add
features
and
so
on,
and
we're
gonna
touch
on
why
it's
so
critical
in
a
bit.
B
Monitoring
is
the
basis
you
once
you
deploy
to
production
once
you
deploy
to
other
compliant
environments.
You
should
be
monitoring
your
software.
You
should
ensure
it's
up.
You
should
be
sure,
ensure
it's
operating,
and
you
need
to
be
able
to
show
that
to
your
auditors
and
in
some
cases
to
your
customers.
B
B
They
tend
to
ask
the
different
questions
every
time
as
they're
working
on
different
pictures.
They
are
working
on
different
parts
of
the
system
and
they're
trying
to
achieve
different
tasks.
They
have
different
questions
and
if
they
have
to
redeploy
a
version
of
the
application
every
time
to
get
a
new
piece
of
data,
it
can
be
very
tiresome
very
annoying
and
we
definitely
don't
want
them
ssh
into
our
servers.
Just
to
get
answers
to
those
questions.
B
The
data
they
are
looking
for.
The
state
information
is
often
very
sensitive.
They
might
not
need
access
to
specifically
the
sensitive
information,
but
those
environments
are
containing
a
lot
of
sensitive
information,
and
so
we
don't
want
developers
wandering
around
poking
trying
to
get
the
data
they
need
blindly
just
to
on
the
one
end.
B
We
do
want
them
to
empower
them
to
do
their
jobs,
but
we
can't
give
them
unlimited
access
to
those
environments
and
so
at
rook
out,
we
found
that
it's
important
to
have
monitoring
tools
such
as
logging,
including
elasticsearch,
apn
tools
for
metrics
or
tracing
error,
tracking
tools
and
business
intelligence
tools
to
feed
and
provide
information.
All
the
stakeholders
need,
but
it's
also
very
useful,
to
have
rookov
deployed
so
that
we
can
collect
additional
data
as
needed
to
empower
engineers
to
better
understand
the
system
and
better
know
what's
going
on
when
they
need
to.
B
A
big
impact
has
on
the
data
you're
trying
to
collect
on
the
data
you're
processing
and
on
the
access
you're
asking
for
taking
record,
for
example,
earlier
in
the
process,
we
found
that
there
are
two
key
factors:
organizations
are
worried
about
when
discussing
adapting
workouts.
The
first
is
their
source
code.
B
Some
organizations
don't
want
to
provide
look
at
their
source
code,
while
other
organizations
prefer
to
not
provide
workout
with
their
application
data
by
finding
ways
to
develop
rook
out
in
a
way
that
we
don't
require
this
data,
but
we
can
operate
without
source
code
and
without
application
data
we
avoided.
We
avoid
much
of
the
resistance
from
our
auditors
and
from
our
of
from
the
security
departments
at
our
customers,
because
they
don't
have
to
trust
us
as
much.
B
The
burden
of
proof
is
lower
if
you're
not
crossing
as
much
sensitive
data,
and
so
I
encourage
you
to
think
of
your
own
use
cases
which
pieces
of
data
can
can
you
do
without
which
access
can
you
do
without
it
might
make
your
product
just
slightly
less
useful?
It
might
make
your
product
just
like
it
as
powerful,
but
it
might
make
it
10
times
easier
to
adapt.