►
From YouTube: secure.AllTheThings() - Make Security Accessible to Everyone! - Christian Bromann & Justin Dolly
Description
Security signals are critically important to ensure the quality and stability of code, especially in production environments (or in CI/CD pipelines). A lack of visibility into security weaknesses in code can represent a significant threat. Wouldn’t you want to know about potential security flaws in your code as early as possible?
While tooling in various areas flourishes, from static code analysis to unit and functional testing, security frameworks often have been limited to subject matter experts, rarely used by developer and QA teams and audits, if at all, run at the very end of the software development lifecycle. With the shift-left spirit we believe this has to change. Adding security checks early to your pipeline can save time and brings awareness and exposure of vulnerabilities to developers which ultimately is the silver bullet for security in your company.
In this session, Justin Dolly, Chief Security Officer, and Christian Bromann, Staff Software Engineer of the Open Source Program Office at Sauce Labs, will give exclusive insights on a new platform and a new set of tools designed to test the security of your applications in a simple, effective and very accessible way.
A
A
Why
am
I
standing
in
front
of
you
as
a
security
professional?
Well,
I'm
standing
in
front
of
you
because
I'm
responsible
for
the
security
of
sauce
labs,
which
includes
not
only
our
company
and
our
users
and
our
networks,
but
also
the
platform
and
services
that
our
customers
use
24
hours
a
day
been
leading
security
of
public
and
private
companies
for
more
than
20
years.
But
I
have
something
to
admit
to
you,
and
that
is
I
am
a
tester.
A
I've
always
regarded
myself
as
a
tester.
If
you
think
about
it.
The
act
of
testing
is
a
pretty
big,
important
part
of
any
security
program
because
it
provides
you
with
results
and
those
results.
If
they
are
treated
in
the
right
ways
can
provide
deep
insights
to
be
able
to
allow
you
to
make
risk
decisions.
A
We
aim
to
change
that
situation
by
providing
you
with
security
signals,
alongside
all
of
the
rest
of
the
signals
that
we
provide
as
you
go
through
your
current
testing
routines.
So
the
quality
of
your
software
can
be
as
good
as
it
can
possibly
be.
After
all,
security
issues
are
just
simply
an
outcome
due
to
a
lack
of
quality.
A
B
As
a
devops
engineer,
we
are
living
by
three
very
important
mantras,
which
are
increase
automation
within
the
software
development
lifecycle,
therefore
allow
faster
delivery
of
features
and
software,
which
is
essentially
shipped
with
high
quality
and
therefore
contains
as
less
bugs
as
possible,
and
we
see
that
more
and
more
responsibilities
are
moved
towards
the
developer.
We
see
that
in
testing.
We
see
that
in
devops
instead
of
having
one
team
that
builds
a
feature,
one
that
tests
it
and
one
that
deploys
them.
B
It
not
only
saves
time,
but
also
a
lot
of
resources.
Now
we
we
see
the
same
now.
The
same
desire
now
happen
in
the
security
space
rather
than
having
a
dedicated,
dedicated
security
team
auditing
software
fail
favor
at
the
end
of
the
software
development
lifecycle.
We
want
the
majority
of
that
work
done
in
an
automated
fashion
early
in
the
development.
B
It
applies
to
the
same
difference,
shift
left
principle
as
we
see
in
other
disciplines
now
as
a
developer.
The
question
is
when
and
how
do
I
have
to
test
the
security
of
my
application
as
with
all
types
of
tests
within
security?
There
are
various
approaches
for
different
areas
within
the
software
development
life
cycle,
starting
from
threat
modeling,
which
is
a
process
to
identify
potential
threats
such
as
structural
vulnerabilities
or
the
absence
of
appropriate
safeguards
way
before
the
development
even
starts.
B
Then
we
come
into
the
cess
area,
which
is
as
which
stands
for
static
application,
security
testing,
which
is
an
approach
similar
to
what
we
know
as
unit
as
code
code,
linking
where
you
scan
your
code
to
try,
discover
problems
in
this
case
security
problems
like
all
indic
tools.
This
offers
fast
feedback
and
allows
to
detect
a
lot
of
issues,
but
the
value
of
those
signals
is
often
very
low,
and
you
see.
Do
you
get
a
lot
of
false
positives.
B
B
Dust
in
this
area
is
the
security
entrant
approach
that,
as
opposed
to
provides
much
more
valuable
signals
for
us
as
developer
to
act
on
now.
Why
is
this
interesting
for
us?
Weird
saws
have
been
thinking
about
this
over
the
last
couple
of
months
and
and
we
we
thought
that
it
we
see
in
this
space
that
security
testing
is
not
really
accessible
to
everyone
at
sauces.
B
We're
running
over
three
million
tests
every
day,
which
is
a
very
large
number,
and
this
gives
us
a
huge
advantage
compared
to
any
other
competitors
in
the
market,
because
we
know
your
application
from
the
in
and
out
based
on
your
functional
tests.
We
know
where
you
log
in
and
which
credential
you
may
use
now.
We
know
the
process
of
your
checkout
flow,
which
steps
and
pages
are
involved
and,
most
importantly,
what
data
is
being
transmitted
from
one
form
to
another.
B
All
these
information
help
us
to
properly
analyze
the
application
on
the
test
to
provide
you
insightful
and
meaningful
signals.
That
said,
this
solution
cannot
only
be
it
on
sauce
labs.
It
can
be
deployed
on
all
running
tests
across
all
vendors
or
even
locally,
because
one
of
the
big
problems
we
have
here
in
the
security
space
in
general
in
the
security
tooling
space,
is
that
the
people
have
to
implement
scanners
to
into
to
understand
your
application.
B
Those
scanners
need
to
be
able
to
go
through
a
login
to
access
a
secure
area.
Running
functional
tests
already
solves
that
problem
for
you
by
accessing
that
through
functional
commands
through
webdriver
or
newer
tools
like
cyprus.
So
with
your
functional
test,
you
can
already
prepare
everything
that
you
need
to
analyze.
The
security
of
your
application
thoroughly.
B
B
B
Oslab
is
not
only
open
source
and
part
of
the
os
foundation.
It
is
a
trusted
tools
by
security
experts
with
a
long
development
history.
I
think
its
first
release
was
somewhere
around
2010
and
it
has
been
always
developed
in
the
open
since
then,
and
there
are
also
some
very
interesting
similarity
to
to
webdriver,
which
is
the
protocol
that
you
know
is
driving
functional
tests
from
the
begin
with
which
is
it's
built
with
an
api
first
in
mind.
B
B
The
way
zap
works
is
that
you
can
use
it
for,
for
instance,
crawling
your
page
to
analyze
what
the
browser
is
doing
to
analyze
what
the
browser
is
requesting
and
receiving
doing
the
exploration.
There
are
two
types
of
scanners:
one
is
a
headless
approach
where
zap
is
doing
requests
on
your
behalf
and
scans.
The
html
response-
and
you
know,
pause
those
links
and
see.
B
Another
way
to
explore.
An
application
is
also
by
using
zap
as
a
proxy,
which
is
a
really
fantastic
future
feature
here
by
automating
it
through
webdriver,
using
selenium,
webdavio
or
other
tools,
and
you
can
use
them
to
write
automated
tests,
automated
functional
tests
to
explore
your
application
in
an
automated
fashion.
B
B
B
B
Then
you
apply
the
appropriate
proxy
capabilities
in
your
webdriver
setup
so
that
the
browser
is
started
in
a
way
that
it
automatically
proxies
the
request
through
os
lab
the
nice
thing
about.
This
is
that
you
can
enable
this
for
all
browser
tests.
Applying
proxy
settings
is
part
of
the
webdriver
protocol
and
therefore
works
across
all
the
browsers.
B
So,
besides,
these
small
settings,
pristine
can
keep
keep
running
the
test
the
same
way
as
she
did
before
now.
While
her
tests
are
running
now
and
christine
is
getting
a
coffee
which
gives
me
some
time
to
explain
the
options
that
you
have
after
your
functional
tests
are
done,
so
many
of
you
will
have
different
kind
of
security
requirements.
I
had
conversation
with
folks.
B
What
you
see
here
that
it
comes
ultimately
down
to
what
your
team's
requirements
are
and
every
team's
requirements
can
be
different
and
adding
security
tests
to
your
pipeline
will
have
some
implications
to
it.
For
instance,
scanning
for
vulnerabilities
will
definitely
add
some
additional
time
and
therefore
might
be
slow
down
your
pipeline
overall,
and
you
know
with
that.
You
know
slow
down
the
time
that
you
can.
You
know
test
and
deploy
new
features
to
production.
B
However,
when
you
run
everything
in
the
cloud
you
can
start
analyzing
and
scanning
for
vulnerabilities,
while
your
functional
tests
are
already
run,
are
still
running,
so
our
goal
should
be
to
to
always
opt
in
for
security
tests,
because
because
we
can
run
them
in
an
efficient
manner
in
parallel,
while
some
other
checks
are
still
being
executed,
and
security
in
itself
is,
you
know
also
very
difficult
to
describe.
Security
does
mean
different
things
to
different
people
right.
B
B
These
vulnerability
scans
completely
automatically
by
using
by
downloading
this
app
session
from
the
bucket
and
using
the
zap
client
to
trigger
these
security
scans
zap
as
a
tool
comes
with
a
lot
of
utilities.
Equipped
to
give
you
a
nice
overview
about
all
the
vulnerabilities
that
I
exist
in
your
application.
B
Now,
if
you
manage
this,
of
course,
within
the
cloud
platform,
you
can
make
this
much
more
simpler
by
just
having
a
click
on
a
button
or
you
know
providing
a
cli
client
that
does
everything
for
you
now
for
the
last
build
christine
found,
10
new
vulnerabilities,
some
of
them
are
related
to
things
like
missing
security,
headers
or
a
secret
key
in
one
of
the
javascript
files,
or
you
know
something
really
simple
and
common.
These
things
are
really
easy
to
fix.
B
Christie
knows
her
application
and
she
knows
how
to
fix
how
to
apply
patches
to
fix
those
issues.
However,
with
she
needs
help
with
one
critical
bug
that
she
has
seen
that
she
hasn't
seen
before,
nor
anyone
in
her
teeth
with
the
help
of
a
geo
integration
that
she's
using
she
is
sending
that
security
vulnerability
to
one
of
her
security
engineers
working
at
her
company.
B
That
security
engineer
can
now
download
the
same
zap
session
and
can
use
the
zap
gui
to
inspect
what
happened
during
the
functional
test.
So
he
downloads
the
session
drags
and
drops
it
into
the
os
app
ui
and
introspect.
All
the
requests
and
responses
finds
the
vulnerability
and
message
christine's
back
with
all
the
information
she
needs
to
mitigate
that
problem
in
the
future.
B
Now
I
said
in
the
beginning
that
there's
no
silver
bullet
for
security
and
well,
the
closest
thing
that
gets
to
it
is
awareness
within
developer
and
qa
teams.
So,
to
sum
up
this
little
workflow
example
with
overstep
and
and
functional
testing
using
web
driver
and
selenium
you'll,
be
always
you
will
be
able
you
are
able
to
analyze
the
vulnerabilities
of
your
application
by
using
your
functional
test
with
overslab
under
the
hood
you
can
create.
You
can
create
some
deep
analysis
on
the
most
common
vulnerabilities
that
exist.
B
In
addition
to
that,
you
can
store
that
data
and
keep
in
the
story
backlog
of
the
information
that
or
security
packs
that
you
know
have
occurred
during
your
have
occurred
when
you
have
been
developing
on
that
application
and
and
learn
from
the
the
mistakes
that
you
have
done
in
the
past.
To
start
to
mitigate
this
happening
in
the
future.
B
Now,
while
this
talk
really
doesn't
provide
you
any
step-by-step
guide
to
install
or
deploy
this
in
your
application,
I
hope
it
inspires
you
to
that
with
just
open
source
and
open
standards.
You
can
deploy
such
a
system
in
your
organization.
We
feel
like
with
this
approach.
You
can
make
security
really
accessible
to
everyone
and
to
test
it
early
in
the
development
life
cycle
and
again,
every
organization
does
this
differently
we
at
thoughts.
A
Thank
you
so
much
christian,
it's
very,
very
informative
and
very
interesting.
I
think
christian's
point
is
a
great
one.
I
can
tell
you,
having
been
in
security
for
such
a
long
time
that
the
silver
bullet
that
christian's,
referring
to
about
the
just
the
simple
awareness,
a
little
bit
of
education
inside
of
the
areas
of
our
companies,
where
the
development
occurs
and
where
the
ideas
are
are
spawning
from
where
the
ideas
are
spawning
is
is
really
the
silver
bullet.
A
Is
that
that
we're
actually
aware
of
some
of
the
choices
that
we're
making
and
some
of
the
security
implications
to
those
choices?
I
think,
with
everything
else.
One
of
the
promises
of
open
source
in
particular
and
the
open
source
standards
is
that
we
can
all
adopt
them
and
adopt
them
quickly
and
they're
flexible
enough
to
be
able
to
support
our
businesses
and
any
other
initiatives.