►
Description
DevOps Worked! ...But Why Hasn’t Security Kept Up? - Joni Klippert, StackHawk
Speakers: Joni Klippert
Over the past decade, DevOps solidified itself as the best-in-class way for engineering teams to build, deliver, and operate software. With this proven model, however, application security has not kept up. The current application security model is broken. While operations and QA were “shifting left,” embracing automation and dev-first tooling, application security stayed stagnant. Many application security teams today still rely on infrequent production-only scans, outdated tooling, and internal cultural processes that prevent scaling. Join StackHawk Founder & CEO Joni Klippert as she shares learnings from building DevOps products and where the future of AppSec is headed. Learn how engineering teams can take ownership of security, how security teams can build infrastructure for secure development, and how this can be automated in the pipeline.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
I'm
joni
clipper,
the
ceo
and
co-founder
of
stackhawk.
I've
been
building
software
for
software
developers.
Since
I
graduated
from
my
mba
program
in
2010
and
in
2019,
I
founded
stackhawk
to
bring
application
security
into
the
devops
workflow
by
helping
software
engineers
find
and
fix
security
bugs
in
their
code
before
they
deploy
to
production.
A
A
When
we
do
this,
we
unlock
the
ability
not
only
to
deliver
software
quickly
but
to
secure
software
quickly,
and
our
customers
expect
this
of
us
so
whether
you're
part
of
a
younger
company
that
was
born
with
the
technical
and
cultural
tenets
of
devops
or
part
of
a
more
legacy
enterprise.
That's
undergoing
digital
transformation.
A
I
interviewed
very
quickly
more
than
50
cso
security
professionals,
ctos
vps
of
engineering
and
found
that
there
were
a
lot
of
technical
barriers
to
current
solutions,
as
well
as
some
pretty
meaningful
cultural
barriers
that
we
need
to
address.
In
order
for
this
change
to
happen,
the
most
glaring
thing
that
stood
out
to
me
when
it
came
to
culture
was
the
relationship
between
security
and
engineering
team
being
pretty
deeply
straight.
A
So
we're
going
to
talk
about
why
I
think
that
that
impression
has
happened
and
then
from
engineering.
I
hear
things
like
the
security
is
team.
Is
the
department
of
no
they're
really
hard
to
work
with,
and
you
know
once
in
a
while
once
in
a
quarter?
They
surprise
me
with
a
bunch
of
work
that
I
need
to
rework
or
fix,
and
I've
moved
on
to
other
tasks.
A
The
next
piece
is
about
transparency
and
observability.
So
all
of
these
things
are
really
core
tenants
of
devops
and
it's
something
that's
missing.
In
the
security
discipline
today,
developers
aren't
invited
into
security
software
very
often
and
there's
little
trust
that
developers
should
be
able
to
see
or
action
on
issues
until
the
security
team
tells
them
to
which
is
super
inefficient,
because
they're
responsible
for
solving
the
problems
anyway
and
then
empowerment.
A
A
Next,
these
tools
are
super
difficult
to
configure
and
deploy
so
many,
and
particularly
in
land
of
dast,
where
we
operate,
which
is
scanning
your
running
application,
they're
difficult
to
get
working
in
a
repeatable
manner,
and
it
makes
automation
really
difficult.
They
just
most
tools,
weren't
built
for
it,
and
most
appsec
tools
were
built
with
the
idea
that
a
human
is
going
to
be
manually,
running
tests
against
an
application,
and
the
good
news
is.
This
is
changing,
but
that's
created
a
lot
of
challenge
in
shifting
this.
This
technology
left.
A
Third,
these
tools
tend
to
generate
a
lot
of
noise.
The
output
is
really
verbose
and
it's
written
in
very
like
security
person
language
rather
than
something
that's
easy
for
a
software
engineer
to
quickly
grok
an
action
on,
and
we
all
know
that
a
key
component
of
devops
is
mitigating
noise
and
ensuring
that
a
developer's
attention
is
only
drawn
to
what's
truly
important
and
fourth,
it
just
doesn't
fit
in
with
developer,
tooling
and
processes
and
workflows
today.
A
So
on
the
previous
slide,
we
talk
about
security,
focusing
that
devs
don't
care
about
security,
but
with
this
list
of
challenges,
my
question
is:
how
can
they
afford
to
so
in
a
world
where
software
engineers
are
largely
measured
by
delivering
business
value?
This
cost
of
caring
is
too
high
and
it's
our
job
to
remove
these
barriers.
A
So
we
discussed
that
many
apsec
tools
on
the
market
are
run
built
to
run
against
code.
That's
already
been
deployed
to
production
and
they're,
designed
to
be
operated
by
a
security
professional.
This
orientation
toward
production
and
a
lack
of
involvement
by
the
development
team
at
the
right
time
in
the
right
context
makes
it
impossible
to
modernize
apsec.
A
So
when
we
look
at
the
production
bias,
we
think
of
it
as
having
a
few
components
and
the
first
one
is
people.
Abstech
tools
are
commonly
run
in
production
today
by
the
security
team,
because
that's
where
they
know
the
application,
the
best
or
by
a
pen
tester,
because
that's
their
point
of
access
to
the
application.
A
When
we
think
about
this
context,
it
makes
a
lot
of
sense
that
tools
to
date
have
been
designed
for
this
group.
However,
it's
highly
inefficient
both
of
these
groups
struggle
to
instrument
their
tests,
because
they're
less
familiar
with
how
the
application
actually
works.
So
setting
up
an
engagement
is
often
a
heavy
lift
to
get
a
good
assessment
from
there.
The
primary
values
these
groups
they
focus
on
is
the
finding
of
things
it
was
so
difficult
to
set
up
this
engagement.
I'd
better
find
a
lot
of
stuff
right.
A
So
there's
a
lot
of
emphasis
plays
placed
on
the
number
of
findings
versus
finding
and
fixing
the
right
things,
and
this
is
inefficient
also
because
the
finders
are
not
the
fixers.
So
now
we're
just
in
this
game
of
ticket
shuffling
or
you
know,
making
sure
that
somebody's
recording
something
and
passing
it
off
to
another
team
member,
and
it
reinforces
this
adversarial
relationship
that
we
talked
about
because
the
role
of
the
security
team
becomes
hey.
Look
I
broke
your
stuff.
A
A
A
You
might
know
that
exposure
is
super
limited
and
this
issue
might
be
fixed
in
the
next
sprint,
but
production
should
not
be
the
first
place
that
you
are
checking
if
there
are
any
security
bugs
next.
Let's
talk
about
context,
so
a
check
for
security
bugs
in
production.
You
know
some
period
of
time
after
a
release
is
highly
inefficient.
A
A
A
Now
I
want
to
talk
about
how
security-based
development
should
work.
It's
a
lot
like
any
other
type
of
testing,
and
when
we
look
at
the
developer
workflow,
I'm
just
going
to
read
this
slide,
but
when
a
team
writes
code,
they
know
that
the
syntax
is
wrong
when
it
won't
compile
when
they
merge
code,
they
know,
there's
a
problem
if
it
doesn't
merge
when
they
run
unit
tests.
A
They
know
the
code
is
wrong
if
it
fails
a
unit
test
when
they
run
integration
tests,
they
know
that
something
is
wrong
if
it
doesn't
work
as
designed
when
a
team
introduces
a
vulnerability,
we
need
to
get
to
the
place
that
they
know
because
it
fails
a
security
test,
just
like
the
rest
of
their
testing
suite,
and
at
this
point
I
want
to
emphasize
that
instrument.
Instrumenting,
test
driven
security
is
something
that
engineering
teams
should
feel
comfortable
instrumenting,
even
if
they
don't
have
a
security
team
or
a
function
at
their
company.
A
A
Next
is
about
the
right
timing
and
that's
obviously
in
pre-production,
so
instrumenting
security
tests
into
ci
cd
gives
engineers
feedback
immediately.
Many
of
our
customers
check
for
abstech
bugs
on
every
single,
and
this
is
ideal
because
if
a
security
test
fails,
you
know
you
introduced
a
security
bug
on
your
latest
change.
A
So
when
we
add
the
ability
to
test
locally
now,
engineers
can
quickly
iterate
on
the
fixed
test
loop.
If
a
new
bug
is
identified
so
for
appsec
to
modernize,
engineers
need
to
be
able
to
test
while
they're
writing
code
and
test,
while
they're
building
code
and
security
tools
need
to
play
well
in
both
phases
of
development.
A
And
last
we're
going
to
talk
about
context,
so
the
right
context
for
finding
security
bugs
in
your
code
is
as
you're
writing
it.
When
this
happens,
engineers
can
fix
egregious
security
bugs
in
flight,
so
that's
going
to
result
in
far
less
bugs
making
it
into
production,
or
I
call
them
vulnerabilities
once
they're
in
production
before
that.
It's
just
a
bug
right
and
that's
less
rework
later
next
is
being
in
context
of
the
application,
and
that
comes
with
real-time
security
testing.
A
So
when
the
right
people
are
doing
the
right
jobs,
there
is
a
bridge
built
between
security
and
development.
The
goal
of
the
security
team
becomes
enabling
the
business
to
go
faster,
safer.
They
lay
the
right
foundations
and
they
focus
on
scaling
security
within
the
organization
by
empowering
developers
and
they
serve
to
help
educate
them
around
risk.
A
A
This
is
an
active
scanner,
in
that
it's
actively
attacking
your
app
with
inputs
and
seeking
outputs
that
indicate
present
vulnerability.
The
nice
thing
about
das
is,
since
it
reports
successful
attacks.
There
are
less
false
positives.
You
can
think
of
it
a
little
bit
like
negative
unit
testing.
If
it
passes
the
test,
you
have
a
problem
so
to
get
started.
A
A
A
Hi
everyone.
I
hope
you
enjoyed
the
presentation,
I'm
joanie.
I
am
here
to
answer
any
questions
you
might
have.
So
if
you
do
have
questions,
please
go
ahead
and
put
them
in
the
chat
channel.
Let
me
see
if
there's
anything
in
this
q
a
so
the
chat
channel
would
be
a
good
place
to
start,
and
I
would
be
happy
to
answer
those
questions
for
you.
A
So
for
this
group
we
want
to
make
sure
that
the
scanning
capabilities
work
really
well
either
working
in
our
git
workflow
or
in
the
cicd
process,
and
those
last
two
examples
are
really
good.
There's
a
third
called
sast
that
you
could
definitely
look
into
and
when
you're
trying
to
understand
the
differences
of
the
different
tooling.
A
A
So
a
lot
of
times
the
ways
that
people
will
deploy
this
in
ci
cd
is
they
will,
you
know,
use
docker
to
deploy
the
the
scanning
technology.
They'll
have
a
fixture
database
with
sample
data
that
they
can
spin
up.
Ephemerally
and
attack
used
to
attack
that
app
that's
running
in
pre-production
with
sample
data.
You
don't
really
want
to
use
an
active
dashed
scanner
against
production.
We
talked
a
lot
about
that.
A
Obviously,
it
is
possible
to
run
against
production,
but
it
can
be
a
little
bit
destructive
in
terms
of
changing
data
or
manipulating
data
as
part
of
its
test
for
for
a
security
scan.
So
you
definitely
want
to
instrument
that
pre-prod
and
there's
a
ton
of
great
information
out
there
on
how
to
scan
like
we
talked
about
apis,
graphql
endpoints
and
your
web
app
for
those
bugs
before
you
deploy
again.
That's
actively
testing
the
code
that
you
wrote
right
or
code
that
you've
brought
into
your
code
base
earlier
in
pipeline
when
we're
looking
at
sca.
A
A
A
That
is
the
bonus
of
dast,
because
because
the
test
passed
it,
it
does
indicate
that
that
issue
is
exploitable,
so
you're
going
to
get
less
false
positives,
but
those
are
great
technologies
that
you
should
definitely
consider
looking
into
in
your
organization
if
you
don't
currently
have
access
to
them
or
if
that
isn't
part
of
your
typical
workflow.
Today,
let's
take
a
look
here.
A
Yeah,
okay:
this
is
a
great
question.
Jonathan
says
that
often
times
if
you
discover
a
vulnerability
in
a
library
and
some
tools
like
we
really
think
that
sneak
is
awesome.
They're
a
great
partner
with
us
dependable,
also
has
this
capability,
where
sometimes
you
can
automate
the
fix.
So
it
will
programmatically
update
that
library
to
the
new
version
and
for
many
very
good
reasons,
you
may
not
be
in
a
position
to
upgrade
that
version.
Maybe
it's
a
good
reason.
A
Maybe
it's
not
a
good
reason,
but
as
we
build
software
a
lot
of
times,
we
can
end
up
customizing
frameworks
to
build
a
feature
or
capability
that
we
desire
that
that
framework
doesn't
quite
handle,
and
the
repercussion
of
that
is
when
you
go
to.
If
you
need
to
upgrade
because
of
a
security
vulnerability,
you
may
have
to
unwind
what
you
did
in
order
to
patch
and
you'd
have
to
rewrite
likely
that
code
in
a
way
that
still
allows
the
app
to
perform
in
the
way
that
you
want
to.
A
I
knew
that
I
will
now
in
future
have
examples,
but
there
are
a
lot
of
methods
of
developing
applications
that
can
make
that
easier
to
transition
to
in
terms
of
updating
the
underlying
code
of
that
framework
or
open
source
piece
of
code
without
having
to
undo
all
of
the
things
that
you
custom
wrote
on
top
of
the
application,
that's
definitely
like
a
best-in-class
type
of
behavior
that
I
actually
don't
hear
of
that
that
often
they
should
pick
a
talk
on
that.
That
would
be
really
good.
A
Well,
if
you're
interested
in
learning
more,
this
is
not
intended
to
be
a
specific
product
pitch,
but
our
company
is
stackhawk.
We
are
a
dynamic
application
and
api
scanning
provider.
We
are
built
for
devs,
so
free
trial,
free
product,
offering
tons
of
awesome
documentation
and
integrations
with
all
the
top
ci
cd
providers
out
there.
So
if
this
is
something
that
you
are
curious
about,
I
encourage
you
to
take
a
look.
A
You
can
self-serve
a
ton
of
information
on
our
website
without
having
to
speak
to
a
human
is
designed
that
way,
and
should
you
be
interested
in
learning
more
or
it
seems
like
it
might
be
a
good
fit
for
your
company
check
out
the
free
version
or
definitely
reach
out
to
us.
My
team
is
awesome.
They
are
technical
humans
that
can
answer
your
technical
questions.
So
don't
be
shy
to
ask
any
questions
that
you
might
have
about
this
different
tech
and
definitely
feel
comfortable,
giving
it
a
try.