►
From YouTube: Commit Virtual 2020: Who’s Watching Your Pipeline? Building In Audit Ready End-to-End Compliance
Description
Speaker: Brandon Dewitt
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
And
fintech,
it's
really
important
to
be
especially
rigorous
in
ensuring
compliance
with
regulatory
requirements.
Graduative
mx
in
who's,
watching
your
pipeline
building
an
audit-ready
end-to-end
compliance
you'll
share
with
us
how
they
ensure
velocity
and
data
transformation
in
mx.
That
leads
to
great
customer
experiences
while
guaranteeing
that
security
and
compliance
requirements
are
met
or
exceeded,
and
that
they're
audit.
B
B
Hi,
I'm
brandon
dewitt,
cto
and
co-founder
at
mx,
and
we
are
in
the
banking
software
space.
We
work
with
more
than
2
000
banks
and
credit
unions
in
the
united
states,
and
we
work
with
more
than
30
million
users
that
are
trusting
their
banking
experience
with
us
at
mx,
and
we
have
built
out
a
continuous
delivery
pipeline
that
allows
us
to
be
audited
and
regulated
while
still
doing
high
delivery
software,
and
so
I'm
excited
here
today
to
talk
about
who's,
watching
your
pipeline
building
an
audit
ready
end
in
compliance.
B
As
I
started
thinking
about
this,
one
of
the
quotes
that
came
to
my
mind
is
the
steve
jobs
quote,
which
is,
I
think,
one
of
the
things
that
really
separates
us
from
the
high
primates
is
that
we're
tool
builders,
and
so,
when
we
set
out
almost
10
years
ago
to
begin
building,
umex
and
begin
building
everything
that
we
have
today
from
a
software
perspective
and
a
process
perspective
starting
from
this
idea
of
being
tool.
Builders,
how
do
you
automate
more?
B
How
do
you
make
things
more
of
a
platform
so
that
you
don't
have
to
hire
as
many
people
as
maybe
have
been
involved
in
the
past,
and
so
you
can
also
stay
small
longer
and
serve
more
people
and
be
more
efficient.
How
do
you
make
that
happen
in
the
world
that
we're
living
in,
and
this?
This
quote
that
steve
jobs
was
talking
about,
was
really
about
the
study
that
was
in
scientific
america.
B
That
was
about
this
man
on
the
bicycle
and
steve
jobs.
Talks
about
this
and
says
you
know,
the
the
man
on
the
bicycle
is
the
most
efficient
mechanism
for
propulsion
that
mankind
has
ever
invented
and,
as
you
can
see
you
know
you
can
see
the
actual
study
here
that
was
published.
You
can
see
you
know.
B
Then
the
computer
is
the
bicycle
of
the
mind
when
I
saw
this
quote
when
I
saw
him
talking
about
it,
and
when
I
heard
about
the
study,
I
actually
thought
a
little
bit
differently.
I
thought
how
interesting
that
the
most
efficient
vehicle
that
we
have
ever
created
our
species
has
ever
manifest.
Is
the
bicycle?
B
What
what
an
interesting
thing?
How
long
did
it
take
us
to
get
to
the
bicycle?
What
type
of
thinking
and
innovation
led
to
this
platform?
That
is
the
bicycle,
and
so
I
started
thinking
about
what
is
a
bicycle:
it's
a
chain
drive
and
it's
a
set
of
wheels
and
it's
a
frame,
and
so
if,
if
we
only
focus
on
the
western
world,
there's
there's
lots
of
other
history
that
you
know
might
be
presented
from
the
eastern
world.
B
In
fact,
the
bicycle
that
you
see
on
the
images
here,
the
bicycle
that
we
know
today
did
not
exist
until
after
the
automobile
existed
about
1885,
it
took
over
400
more
years
after
leonardo
da
vinci
had
every
piece
in
his
lab
for
mankind
to
bring
those
pieces
together
in
the
most
efficient
machine
that
we
could
ever
create,
and
so
the
the
reason
that
I
bring
this
up
is
because
building
a
compliant
software
organization
is
something
that
one
involves.
A
lot
of
complexity.
There's
a
lot
of
pieces
all
over.
B
So,
every
day
we
would
have
a
set
of
documentation
that
we
would
sign
off.
On
saying
this
is
what
we're
lacing
into
production
when
our
editors
come
in,
we
can
actually
show
this
to
them,
and
they
know
that
we're
signing
off
on
what
went
there.
But,
as
you
all
know,
what's
happened
in
the
last
decade
is
there's
been
an
increasing
amount
of
development.
One
iterative
innovation
is
at
the
core
of
so
much
innovation.
That's
happening
out
there.
There's
this
idea
of
continuous
delivery,
continuous
integration
at
mx.
We
call
it
continuous
momentum.
B
We
really
want
to
focus
on
the
fact
that
we
are
delivering
to
production
and
we're
delivering
value
to
our
customers,
and
so,
as
you
increase
the
amount
that
is
going
through
out
into
production,
how
do
you
begin
to
track
all
of
that
for
your
compliance
sake
and
for
your
audit's
sake
and,
more
importantly,
how
do
you
stop
the
things
that
would
be
detrimental
in
your
production
environment?
How
do
you
stop
them
before
they
get
there?
How
do
you
set
up
your
gateways?
B
How
do
you
set
up
your
pipelines
to
make
sure
that
they
all
work
in
concert
so
that
you
can
be
delivering
the
most
amount
of
value
for
those
that
that
you're
serving
out
in
the
market
at
mx?
You
know
this
is
a
a
bit
of
a
snapshot
of
the
last
12
months
of
the
software
that
we've
delivered
so
on
on
any
given
month.
B
B
Although
we
don't
house
credit
card
data,
the
fact
that
we
are
involved
so
intimately
within
banking
infrastructure
makes
it
such
that
pci
compliance
just
makes
it
easier
for
us
to
be
able
to
get
contracts
done
and
business
done.
Therefore,
we
maintain
it
even
though
we're
not
handling
payments
or
credit
cards
across
our
platform.
There's
also
additional
compliance
burden
brought
on
by
things
like
privacy,
ccpa,
gdpr,
other
frameworks
that
are
very
important,
but
they
all
really
come
down
to
there's
some
section
of
them
that
that
involves
your
software
development
life
cycle.
B
B
Rundown
we've
split
those
into
into
two
different
into
two
different
pathways
for
us,
because
one
of
them
involves
needing
to
create
a
regression
spec,
making
sure
that
spec
is
passing
as
it
goes
through
the
pipelines
and
then
getting
queued
up
to
move
through
to
the
environments
and
so
just
to
touch
on
it.
Briefly.
First
and
foremost,
everything
has
to
start
with
a
ticket
or
an
issue
inside
of
get
lab,
and
so
at
the
very
center.
B
The
platform
that
we've
built
on
our
process
on
is
gitlab,
and
so
everything
has
to
start
with
an
issue
in
the
repository
either
initiated
by
product
documentation,
quality
assurance
or
support
has
to
start
with
a
ticket
that
begins
the
that
begins
a
change
that
may
actually
move
into
production
or
it
may
get
closed
before
it.
Moves
into
production
begins
with
a
ticket.
B
We
have
to
create
a
topic
branch
because
we
use
protected
branches
inside
of
git
lab
that
allows
us
to
make
sure
that
people
with
the
software
expertise
that
is
required
are
the
ones
that
are
approving
changes
to
be
pulled
in
to
the
branches
that
are
not
protected
this
to
the
branches
that
are
protected
and
then
go
out
to
environments.
So
we
use
protected
branches.
You
have
to
have
a
topic
branch.
B
B
You
have
to
move
to
sandbox
and
ver
sandbox
verification
in
our
environment.
We
have
a
sandbox
environment,
a
qa
environment,
a
staging
environment,
and
then
we
have
a
production
and
also
an
integrations
environment,
which
is
basically
two
production
environments
that
allows
us
to
to
keep
mirrored
environments
so
that
people
can
do
their
integration
to
us
in
an
environment
that
is,
that
is
just
as
significant
to
us
as
our
production
environment.
B
B
B
B
That
proves
that
one
it
was
initiated
by
someone.
There's
a
there's,
a
documented
initiation
point:
there's
a
documented
change,
a
verification
of
that
change
by
your
quality
department
has
to
be
a
separate
organization
that
is
actually
denoting
the
verification
of
that
change
and
then
also
once
it's
actually
moved
through
environments.
B
So
they
can
see
everything
that
occurred
on
the
way
to
a
production
deployed.
This
is
actually
a
specific
item,
as
you
can
see,
we've
denoted
it
as
impact
low,
but
one
of
the
things
that
we
did
with
the
gitlab
api
is
once
you
actually
put
post
a
a
get
lab,
merge
request
in
here.
The
sabotage
system
actually
links
all
of
the
documentation
of
the
issue.
The
description
of
the
issue
pulls
it
all
into
this,
so
that
our
auditors
only
have
to
go
into
this
view.
B
The
other
thing
that's
interesting,
is
you
actually
don't
have
the
ability
to
move
it
through
the
stages
unless
it
has
passed?
The
previous
gating
items
and
I'll
show
you
that
here
in
a
second,
so
when
you're
in
get
lab-
and
this
is
obviously
the
the
get
lab
interface
for
pipelines
every
s-
you
can
actually
create
with
every
merge
request,
you
can
create
a
pipeline
for
really
anything
that
you
want
to
do.
B
You
can
pretty
much
automate
tons
of
processes
that
maybe
you
may
be
doing
manually
today,
a
few
of
the
things
that
we
automate
at
mx.
Is
we
automate
our
static
code
analysis
for
security?
We
use
a
lot
of
ruby
and
ruby
on
rails.
We
leverage
static
code
analysis
like
breakman
to
determine
that
the
owasp
you
know
25
are
not
being
injected
into
our
rails
code.
B
We
we
use
it
for
static
code
analysis
for
syntax.
We
use
things
like
rubocop
and
we
use
other
syntax
static
code
analysis
tools
that
determine
that
it
passes
our
stylistic
desires
before
we
actually
move
it
to
another
environment.
You
can
have
a
pipeline
fail,
a
merge
request
to
not
move
to
the
next
environment.
Without
you
passing
it.
B
What
needs
to
change
for
this
to
actually
move
forward
to
the
next
environment?
It's
it's
quite
a
fascinating
experience.
All
of
the
automation
that
is
that
has
really
come
into.
You
know
the
software
development
process
in
the
last
10
years.
Another
piece
that
I
wanted
to
show
here
is
you're
not
only
able
to
do
things
like
verifications
and
checking
of
code,
and
things
like
that.
We've
actually
extended
the
pipelines
that
we
leverage
within
gitlab
to
automatically
write
code
for
us
because
we
operate
in
a
polyglot
environment.
B
B
You
can
even
have
these
our
custom
pipeline
here,
which
is
generating
new
bindings
for
our
golang
processes,
automatically
initiating
a
new
release
and
allowing
us
to
keep
our
polyglot
system
in
sync
with
one
another,
so
that
we
know
when,
when
two
services
that
might
interact
with
the
same
database
that
are
in
a
different
language
are
out
of
sync.
We
know
that
automatically
we're
able
to
to
bring
those
two
releases
together
and
push
them
up
at
the
same
time.
B
It's
it's
really
been
one
of
those
amazing
things
that
again,
as
you
might
imagine,
as
you're
managing
you
know,
at
mx,
we
have
almost
500
employees
about
165
of
those
are
on
the
engineering
side
of
the
house,
so
they
fall
into
qa
or
engineering
or
devops
or
infrastructure
in
one
way
or
another.
When
you
have
that
many
people
pushing,
though
that
number
of
releases
and
that
amount
of
code,
you
have
to
have
things
that
you
know
really
help,
you
keep
very
straight.
B
What
is
going
on
in
your
environments,
and
so
one
of
the
things
that
I
talk
with
to
the
team
about
all
the
time
is:
let's
use
computers
for
what
computers
are
good
for.
Computers
are
really
good
at
spending
all
day,
long,
sifting
through
hay
to
find
potential
needles,
and
so
you
can
create
a
pipeline
that
is
just
observing
all
the
changes
determining
if
there's
a
schema
change
and
then
regenerating
code
and
it'll
do
it
all
day
long
and
it
will
always
be
up
to
date
with
where
your
platform
is
it's.
B
That
makes
it
very
simple
for
them
to
go
through
that
process
of
compliance
and
be
able
to
deliver
the
software
to
the
industry,
quite
frankly,
industries
that
need
it.
Industries
that
have
very
typically
been
held
back
because
of
the
compliance
burden
that
is
necessary
are
now
being
enabled
because
of
platforms
like
get
labs,
and
so
we're
happy
to
be
a
get
lab.