►
Description
Everyone wants to shift security left, but how? Security scans are unwieldy and don't fit an iterative, agile development cycle. We will step through the developers’ workflow and show exactly where application security can be embedded and automated - and best practices for optimal results.
This approach will benefit developers and security pros alike. See what can be achieved with a brief demo of an actual developer pipeline then ride along for the perspective of the security team. Learn how your app sec can become iterative, automated and embedded into the automated DevOps processes.
www.gitlab.com
A
Hello,
everyone
and
a
very
warm
welcome
to
all
of
you
to
this
webinar
session
with
us
and
our
business
partner
gitlab
on
the
topic
of
achieve
software
development
velocity
without
compromising
security
and
risk.
My
name
is
Chandan
mala
and
I
will
be
your
moderator
for
this
session
today,
I.
First
of
all,
sincerely
thank
you
for
your
participation
in
this
webinar
and
I'm
keenly
looking
forward
to
an
engaging
session.
Let
me
first
introduce
our
speaker
for
today.
A
Cindy
Blake
Cindy
is
a
senior
security
evangelist
at
github
and
is
also
the
author
of
the
book
ten
steps
to
securing
next-gen
software.
The
book
combines
nearly
a
decade
of
cybersecurity
experience
with
a
background
in
lean
and
software
development,
to
simplify
the
complexities
of
today's
software
evolution
into
pragmatic
advice
for
security
programs.
Cindy
also
collaborates
around
best
practices
for
our
integrated
dev
sac,
ops,
application
security
solutions
with
major
enterprises
prior
to
get
labs.
Cindy
worked
as
a
strategic
planning
consultant
covering
OPSEC
endpoint
security
and
security
information
and
event
management.
A
A
little
bit
about
today's
session.
Cindy
is
gonna
talk
to
us
today
about
what
can
be
eve
in
regards
to
a
convenient
security
framework
on
the
basis
of
an
actual
developer
pipeline.
She
will
focus
keenly
on
the
perspective
of
the
security
team,
and
so
the
webinar
today
is
intended
to
give
us
the
understanding
of
their
application.
Security
can
be
embedded
and
automated
on
a
developer's,
workflow
best
practices
for
optimal
results,
for
developers
and
security
experts
alike
and
how
apps
that
can
become
operative
and
embedded
into
the
automated
DevOps
processes.
A
Just
a
couple
of
last
minute
house
rules
before
we
get
started
here,
all
of
us
are
going
to
be
muted
during
the
presentation
and
only
Cindy
will
have
the
rights
and
access
to
present
information.
Cindy's
presentation
is
going
to
last
for
roughly
about
25
to
30
minutes,
and
then
we
will
open
the
floor
for
questions.
A
Of
course,
if
you
do
have
some
questions
beforehand,
do
not
hesitate
to
use
the
question
tab
on
the
right
side
panel
on
your
screen,
and
you
may
type
in
the
questions
and
I
will
take
a
note
of
the
same
and
we'll
ask
Cindy
for
an
answer
during
the
Q&A
part.
In
the
end,
assuming
you
have
good
internet
connectivity,
this
whole
session
should
run
smoothly
without
any
impediments.
A
However,
if
you're
finding
any
difficulty
during
the
session
kindly
make
him
know
sort
of
okay
on
the
on
the
chat
tab
on
the
right
side
of
the
screen
panel,
we
will
instantly
get
in
touch
with
you
to
potentially
help
solve
any
issue
now
without
any
further
delay.
I
hand
the
floor
over
to
Cindy
to
run
us
through
her
webinar
geo
software
development
velocity
without
compromising
security
and
risk
Cindy
over
to
you
great.
B
B
B
Applications
are
a
prime
target
of
attack,
so
it's
really
really
important
and
increasingly
important
to
produce
secure
code
and
to
secure
it
in
production.
But
but,
like
I
said,
it's
not
easy
and
it's
getting
harder
now
the
way
that
a
lot
of
companies
enterprises
approach,
applications
security
is
kind
of
a
laser
focus,
so
you
might
say
I
really
need
to
protect
my
mission-critical
applications.
B
Well,
that's
fine,
but
what
about
all
of
the
other
ones
that
are
less
protected
and
hackers
know
that
attackers
are
gonna,
focus
on
the
weak
link
and
they're
going
to
go
after
that
open
window
instead
of
that
locked
door,
so
you
might
be
doing
really
in-depth
application
security
testing
on
your
mission-critical
apps,
but
you
might
still
be
very,
very
exposed
from
a
risk
standpoint.
So
we're
gonna
talk
about
how
you
might
change
that
today
now,
at
the
same
time,
the
other
challenge
is
the
growth
of
DevOps,
and
so
with
DevOps.
B
One
more
complicating
factor
here
is
that
kind
of
hand
in
hand
with
DevOps
is
also
the
growth
in
cloud
native
and
with
that
brings
use
of
containers
and
like
docker
and
so
forth.
Orchestrators,
like
kubernetes
and
micro
services,
which
is
you
know
it's
really
about
taking
these
large
projects
and
breaking
them
down
into
smaller
standalone
applications,
I
say
stand
alone.
They
made
that
more
like
building
blocks
so
you're
using
and
reusing
these
building
blocks
or
these
micro
services.
And
what
happens
is
the
micros
services
now
call
one
another?
B
So
you've
got
you
know,
growth
in
things
like
I
did
any
management,
because
you've
got
not
only
I
leave,
people
that
are
using
the
systems
but
of
applications
that
are
calling
other
applications,
and
so
all
of
this
kind
of
makes
it
for
the
perfect
storm,
and
what
we
find
is
that
these
new
attack
surfaces
really
require
thinking
about
security
and
a
little
bit
different
different
way
and
adding
some
elements
that
you
might
not
have
had
before.
So,
for
example,
my
prediction
is
that
you
know
historically,
patching
has
been
the
biggest
exposure,
basically
or
lack
thereof.
B
Lack
of
patching
software
I
think
going
forward.
Miss
configuration
is
going
to
be
on
par
with
patching,
there's
just
too
many
pieces
in
this
new
environment.
So
you
know,
if
you
look
at
containers
and
orchestrators
those
and
your
cloud
provider,
all
of
those
have
levers
that
you
can
pull
and
settings
that
you
need
to
be
aware
of
for
security
settings
and
the
default
settings
are
not
always
the
most
secure
by
the
way.
B
So
how
understanding
what
those
levers
are
that
you
can
pull
and
how
they
work
together,
is
really
complicated
and
that's
what
leads
to
the
Mis
configuration.
So
when
you
think
about
application
security,
you
need
to
think
through
these
new
attack
surfaces,
this
new
process,
so
iterative
development.
How
do
I
fit
my
security
scanning
process
into
that
iterative
development
process
and
then
the
fact
that
you've
got
app
to
app,
not
just
people
to
app
interaction.
Now,
all
of
that
said.
B
They,
the
number
of
developers,
will
always
outnumber
the
number
of
security
people,
particularly
at
Kayson
security,
and
so
you
need
to
find
a
way
to
scale
your
application
security
program
and
I
like
to
when
I
think
about
it.
This
is
the
image
that
comes
to
mind.
You
know
there's
always
more
of
them
than
there
are
of
you,
so
you
need
to
lead,
follow
or
get
out
of
the
way
from
an
application
security
standpoint,
because
DevOps
and
development
is
really
pushing
to
be
more
nimble
and
deliver
value
faster
and
security
cannot
be
a
roadblock.
B
So
I'm
going
to
talk
to
you
today
about
how
you
can
be
more
of
an
of
a
an
enabler
and
it
really
comes
down
to
harnessing
the
development
process
and
enabling
the
developers
to
find
and
fix
vulnerabilities
so
that
the
security
team
can
focus
more
on
the
exceptions
and
setting
policies
and
making
sure
that
those
policies
are
automated
and
enabled,
and
I
love
this.
This
quote
this
was
actually
from
not
this
year's
RSA,
but
last
year's
RSA,
the
CEO
of
VMware,
said
your
most
secure.
B
Most
important
security
product
won't
be
a
security
product
and
he
really
gets
it
that
you've
got
to
think
about
security
as
an
outcome,
not
as
the
department
or
as
a
role
and
and
think
about
how
you
create
that
that
security
element
within
the
software
Factory.
Now
the
key,
isn't
what
scanner
you
use?
There's
you
know
I
was
with
fortify
for
many
years.
I've
got
a
lot
of
experience
with
a
lot
of
different
tools
and
you
know
even
even
open
source
tools.
B
It's
not
what
you
use
it's
what
you
do
with
the
results
and
I'm
going
to
explain
that
going
forward.
It
kind
of
goes
back
to
that
picture
of
putting
all
the
locks
on
one
door.
You
know
if
you
use
the
most
expensive
scanners,
but
you're
only
scanning
a
portion
of
your
code
out
of
your
entire
portfolio
leo
then
you're
still
very,
very
much
at
risk,
so
the
key
is
making
Anna
taking
an
approach
of
embedding
security
scanning
and
the
finding
and
fixing
of
the
results
in
your
software
factory.
B
So
if
you
haven't
read
Jane
Kim's
Phoenix
project
and
if
you're
in
development
you
probably
have,
if
you're
in
security,
you
may
not
I
really
recommend
it
because
it,
it
explains
how
you
need
to
have
more
of
a
repeatable
process,
and
so
that's
where
you
know,
if
you
think
about
the
way
application
security
is
done
now,
I
run
a
scan.
What
if
I,
find
10,000
vulnerabilities,
I'm
scanning
the
you
know,
typically
I'm
scanning
the
entire
application
and
I'm
doing
it
in
a
test
environment
where
lots
of
developers
changes
are
all
merged
together.
B
So
I've
got
a
test
environment
now
that
I'm
that
I
want
to
to
look
for
vulnerabilities
I
find
a
bunch.
Why
do
I
do
with
them?
Well,
the
security
person
can't
actually
fix
them.
The
security
person
has
to
go
back
to
development
and
get
it
triaged
and
prioritized
if
your
security
person,
how
much
time
do
you
spend
evaluating
findings
prioritizing
them
triaging
them
getting
them
back
to
on
the
development
developers,
Kanban
board
or
their
next
sprint,
and
then,
because
that
represents
a
risk
and
you're
responsible
for
risk
following
up
every
now
and
then
to
see.
B
B
Now,
when
an
individual
developer
checks
out
their
code
and
they
they
either
add
to
the
codebase
or
they
make
changes,
you
want
to
do
your
application
security
testing
on
their
on
their
work.
That
they're
doing
on
the
feature
branch,
so
a
feature
branch,
is
the
piece
of
work
that
they're
working
on,
and
this
is
golden
and
the
reason
why
is
if
you
can
do
that
it
gives
the
feedback
to
the
developer
that
actually
made
the
change.
So
as
a
developer,
I
made
a
change
in
code.
B
My
test
shows
that
I
created
this
vulnerability,
so
it
wasn't
Suzy
two
doors
down
or
it
wasn't
something
that's
been
sitting
in
production
lurking
for
years
and
I
just
happened
to
be
the
one
that
is
lucky
enough
to
stumble
upon
it.
I
created
the
vulnerability
I'm,
the
one
that
can
fix
it
and
I'm
and
I
can
fix
it
before
it
gets
introduced
back
to
the
master
branch.
B
So
before
it's
merged
with
any
of
my
other
code,
and-
and
so
this
is
really
like
I
said
golden
because
from
an
accountability
standpoint
from
a
simplicity,
standpoint,
I'm
I'm
in
there
working
I'm
the
one
that's
best
suited
to
make
that
change.
So
the
role
that
the
security
person
should
have
is
helping
set
these
policies
in
the
automation
that
goes
with
it,
so
that
you
can
enable
the
developers
to
do
this.
You
know
I
did
a
focus
group
about
a
year
ago,
with
a
bunch
of
developers
and
I
asked
them
what
motivated
them
around
security.
B
I
was
kind
of
looking
for.
Is
it
a
carrot
or
stick
and
what
I
found?
Is
they
all
deeply
care
about
security,
because
what
motivates
them
the
most
is?
No
one
wants
to
be
the
one
that
brought
their
company
down
because
they
introduced
a
vulnerable
piece
of
code,
so
they
take
it
very
very
seriously,
but
they
don't
feel
like
they
have
the
tools
they're
not
enabled
to
to
make
that
change.
B
So,
let's
talk
about
how
you
can
do
that
so
in
there
see
ICD
in
the
pipe
in
their
pipeline
when
they
commit
the
code
and
those
scans
are
run,
all
of
those
scans
can
be
run.
All
of
those
tests
can
be
run
before
the
application
changes
are
merged
back
with
anyone
elses.
Now
you
might
wonder:
how
do
you
do
so
dynamic
application
security
scanning?
It
typically
requires
a
running
application
to
see
if
there's
warmer
abilities
well.
The
way
that
we
do
it
with
get
lab
is
as
part
of
our
CI
CD
process.
B
We
spin
up
a
review
app
and
that
review
app
is
a
fully
functioning
app.
That
shows
that
reflects
the
changes
that
were
just
made
and
we
run
the
dynamic
scan
against
that
so
static
analysis,
dynamic
analysis,
dependency,
scanning
container
scanning.
All
of
that
can
happen
with
that
individual
developer
before
the
code
ever
leaves
their
hands,
and
so
what
happens
is
if
you
follow
this
sort
of
workflow,
then
your
security
scanning
becomes
equally
iterative
your
development
process.
B
So
going
back
to
that
picture
of
the
the
feature
branch
as
a
developer,
I
check
out
my
feature:
branch
I'm,
going
to
work
very
iteratively
on
that
and
I
get
it
where
I
want
not
just
from
a
security
standpoint
but
from
a
functional
standpoint.
So
I'm
gonna,
you
know,
make
changes.
I'm
gonna,
look
at
my
review
up,
I'm
gonna
see.
Did
they
turn
out
the
way
I
thought
you
know
didn't?
Does
this
I
don't
want
to
say
compiled?
That's
my
own
COBOL
days,
but
you
know,
does:
does
this
come
together?
B
B
At
the
same
time,
my
security
team
needs
to
be
involved
and
have
a
viewpoint
as
well.
So
if
I'm,
if
I'm,
empowering
and
enabling
my
developer
to
iteratively,
find
and
fix
vulnerabilities,
there
will
be
some
things
that
they
can't
so
maybe
they
they
believe
it's
a
false
positive.
So
they
dismiss
it
as
a
false
positive
and
that
usually
raises
the
hackles
on
the
back
of
the
neck
of
the
security
people.
Oh
my
gosh,
we
can't
have
developers
dismissing
it.
They'll
dismiss
everything
as
a
false
positive.
B
So
with
this
you
know
the
other.
The
other
thing
that
can
happen
as
a
developer
can
can
fix
a
lot
of
these,
and
so
or
maybe
they
see
that
it
needs
to
be
fixed,
but
they
don't
have
the
time
to
do
it
in
this
sprint.
So
they'll
create
push
the
button,
create
an
issue
capture
that
information
so
that
it's
automatically
included
in
in
the
next
work
effort.
B
All
of
that
then
goes
to
the
security
team
so
that
the
vulnerabilities
that
can't
be
remediated
by
the
developer
can
be
inspected
by
the
security
team,
and
so
they
can
look
at
you
know
what
was
dismissed.
What
are
my
critical
vulnerabilities?
How
am
I?
What's
my
risk
profile,
how
am
I
trending
over
time
and
and
all
of
that
can
be
aggregated
across
projects
for
that
security
person.
B
Now
the
advantage
of
this
approach-
and
most
of
these
advantages
are
for
the
developer,
but
I'll
touch
on
the
advantages
for
security
as
well.
You
know,
if
you
think,
about
integration,
you
can
integrate
by
plugging
a
bunch
of
things.
Together,
you
can
kind
of
build
to
get
pull
together.
A
Frankenstein
approach
of
you
know
a
pipeline
that
has
scripts
that
goes
out
and
calls
different
security
tools,
but
those
things
are
inevitably
fragile
and
not
the
best
approach.
B
You
know
if
you
think
about
an
analogy,
which
is
your
your
cell
phone,
that
most
people
carry
all
the
time
versus
a
camera.
When
was
the
last
time
you
use
a
camera,
you
know
with
a
camera,
it
usually
has
a
fresh
memory
and
then,
if
I
wanted,
you
know
if
my
goal
is
to
take
pictures
and
share
them
with
my
friends
and
family.
Now,
I
got
to
find
something:
that'll
read
the
flash
card
and
then
I've
got
to
find
whatever
can
read.
B
The
flash
card
may
not
be
hooked
up
to
the
Internet
may
not
be
hooked
up
to
my
social
media,
so
there's
lots
of
steps
and
trouble
along
the
way
and
lots
of
times
you
take
these
beautiful
pictures
with
your
beautiful
camera
and
never
share
them,
and
that
was
your
goal
in
the
first
place.
So
if
your
goal
is
to
find
and
fix,
vulnerabilities
consider
an
integrated
built-in
approach,
it's
where
it's
in
then
the
developers
native
workflow.
B
Now
from
a
security
standpoint.
Not
only
can
I
empower
my
developers
to
fix
a
bunch
of
stuff
before
it
ever
reaches
me,
but
if
I'm
using
the
single
application
for
the
entire
DevOps
lifecycle,
so
I'm,
you
know
for
a
source
code
management
for
CI
CD
for
security.
I
get
this
wonderful
single
conversation.
Single
source
of
truth
gets
everybody
on
the
same
page
and
from
an
auditing
standpoint.
Auditors
love
that,
because
you
can
see
end
end
through
the
entire
software
development
lifecycle
who
changed
what?
Where,
when?
B
This
is
not
like
a
second,
you
know:
second-class
citizen
here.
Gitlab
is
one
of
the
industry-leading
CI
providers.
So
if
you
look
at
the
Forrester
wave
and
CI
both
last
year
and
the
most
recent
one
or
2018
and
2019
we're,
we
are
the
your
path
of
least
resistance
from
a
security
standpoint.
So
if
you
want
to
harness
a
CI
process
with
security
scanning,
this
is
your
path
of
least
resistance,
because
it's
a
popular
tool,
development
loves
us
and
loves
gitlab,
and
so
it
can
be
an
easy
way
easier
way
of
adding
in
security
and
I've.
B
Seen
I've
seen
people
trying
to
build
very
complex
tool
chains
and
and
pulling
scanners
into
their
CI
scripts
I've
also
seen,
sadly,
people
trying
to
get
developers
to
use
fortify
and
ver
code,
and
some
of
these
really,
you
know
kind
of
Cadillac
products,
and
that's
that's
really
not
the
best
way.
If
you
could
scan
all
your
code
every
time
and
make
it
very
seamless
as
part
of
the
developers
workflow
using
fewer
tools,
not
more
I'm,
getting
everybody
on
the
same
page
and
making
auditors
happy.
Would
that
be
something
that
you
would
be
interested
in?
B
B
This
is
jumping
into
the
developers
native
workflow,
okay.
So
this
is
what
a
pipeline
report
looks
like
for
the
developer.
So
to
give
you
context
and
perspective
on
where
this
falls
in
the
workflow
I've
checked
out
some
code,
I've
made
a
change
in
my
code
and
so
I
can
I
can
look
here
and
see
what
changed
this,
the
you
can
see
what
code
was
changed
and
this
is
where
the
developer
natively
works.
So
in
here
I've
got
a
summary
of
my
security
findings.
Okay,
so
there
were
some
that
were
new.
B
There
was
some
that
were
fixed
and
so
think,
auto
remediation
fix,
let
the
tool
fix
what
it
can
and
which
kind
of
goes
back
to
the
patching
and
six
dismissed
vulnerabilities
here.
So
I'm
I
can't
those
are
still
captured,
though
so
I
can
see
what
they
are
and
while
I'm
here
I've
got
license
compliance.
At
the
same
time,
some
people
put
that
in
security,
some
people
don't,
but
it
represents
a
risk.
So
we
we
kind
of
think
of
them
together.
Now
I
can
expand
that
view
and
look
at
the
results
from
each
of
my
scans.
B
So
here
are
my
my
static
scans,
my
dependencies
vulnerabilities
that
are
found
in
the
dependencies
container
scanning
and
my
dynamic
scanning
and
also
as
I
said,
I
can
come
down
here
and
look
at
license
compliance
if
I
wanted
to
do
that
as
well.
Now
this
view
think
about
this
view
when
we
go
to
the
security
persons,
view
of
things
and
you'll
see
that
it
looks
pretty
similar
these
ones
that
are
have
the
line
through
them.
Those
are
the
dismissed
vulnerabilities.
B
They
didn't
go
away
they're
still
here
and
that's
really
the
the
important
part,
because
I
can
filter
them
out
so
I
don't
want
to
look
at
them
again
and
deal
with
them
again.
But
what
I
hear
from
the
security
people
is
that
they
care
more,
maybe
more
about
the
dismissed
ones
than
the
and
the
others,
but
really
want
to
be
able
to
view
this.
So
it's
still
here,
I
can
see
who
dismissed
it.
I
can
even
look
at
the
pipeline
of
what
they
saw
and
why
they
dismissed
it.
B
I
can
see
that
David
here
created
an
issue
from
this
which
I
can
pop
over
to
that
issue
and
actually
see
I'm
going
to
open
that
in
a
different
link.
So
that
I'm
not
cluttered
here
and
forget
where
I
am
but
so
I
can
pop
over
to
that
and
look
at
the
issue
and
see
what's
the
status
is
somebody
assigned
to
it
is
somebody
working
on
it?
Is
it
affiliated
with
a
particular
milestone,
so
I
don't
have
to
like
search
through
other
systems
to
try
to
figure
out
what's
the
status
of
this
vulnerability?
B
All
of
that
information
is
is
right
here
now,
I
can
also
look
at
when
here's
one
that
hasn't
been
dismissed.
Somebody's
already
created
an
issue
if
it
hadn't
I'd
have
an
issue
button
down
here
and
I
could
just
click
the
button
and
it
it's
Auto
populated.
So
all
of
that
information
that
is
in
that
issue-
that's
created,
is
Auto
populated
for
you,
so
you
don't
have
to
do
that.
But
then,
like
I
said
it
said
it's
a
live
real
issue,
so
you
can
see
who's
assigned
to
it.
B
This
is
the
DES
security
dashboard.
So
this
is
what
the
developer
sees
and
it
can
be
filtered
here
by
severity
by
report
type.
So,
if
I
only
wanted
to
look
at
static
or
dynamic
or
containers
or
whatever
I
can
filter
it
by
project,
so
you
know
don't
want
to
look
at
everything,
just
maybe
a
particular
project,
but
this
is
all
of
my
vulnerabilities,
how
they're
trending
over
time
and
one
of
my
favorite
parts
here-
is
this
risk
profile.
B
So
if
I
want
to
see
what
which
of
my
projects
so
again,
this
is
looking
across
across
developers
across
projects
that
developers
are
working
on
and
across
groups
of
projects.
Thinking
about
this
hierarchically,
if
I
want
to
look
broadly
across
my
groups
and
see
what
projects
represent
the
most
risk,
I
can
come
here
and
see.
Well,
these
are
the
ones.
B
These
are
the
projects
that
have
the
critical
vulnerabilities
in
them,
and
so
this
can
help
me
narrow
my
focus
on
where
I
want
to
spend
my
time
and
because
I
have
enabled
the
developer
to
find
and
fix
vulnerabilities
wherever
possible.
I
can
focus
more
on
those
those
areas
that
need
help,
and
one
of
the
things
I
forgot
to
mention
as
well,
was
remediation
and
out
of
remediation.
So
if
we
find
a
vulnerability
in
a
container
or
or
a
dependency
that
a
third.
A
B
Open-Source
code
library
that
has
a
more
recent
library
available,
we
can
automatically
download
that
now,
where
we're
going
eventually.
So,
if
you
know
get
lab,
we
work
in
minimal,
viable
change
as
well,
and
we
were
very,
very
iterative.
So
the
first
part
of
that
was
hey,
there's
a
more
current
library
available,
and
then
we
improved
it
to
downloading
it.
B
For
you
and
now,
the
next
step
would
be
actually
setting
up
a
separate
feature:
branch
downloading,
that
new
library
on
a
feature,
branch
and
running
it
to
see
if
it
works,
because
one
of
the
reasons
why
people
don't
patch
is
they
break
patches,
break
things
right
and
everybody's
concerned
about?
You
can't
just
apply
a
patch
and
expect
it
to
be
perfect.
Let's,
let's
run
it
and
make
sure
it
actually
works.
B
B
We've
talked
about
the
development
side
of
things,
but
I
want
to
make
sure
that
you
don't
forget
about
the
operational
side
of
things.
As
well
and
the
in
production,
so
you
know
where
this
presentation
has
been
very
focused
on
finding
and
fixing
vulnerabilities
and
shifting
left
doing
it
early
in
the
development
cycle.
You
need
to
make
sure
that
you're
also
monitoring
production
and
we
we
call
that
defense.
We
call
this
secure
on
the
proactive
side,
defend
on
the
defensive
side
and.
B
But
you
can
check
our
website
for
what
we're
doing
on
the
defense
side,
for
more
suggestions
and
and
ideas
on
what
you
can
do
just
to
make
sure
you
have
a
full
end-to-end
program
which
reminds
me
in
addition
to
that
proactive
and
reactive
elements
of
development
and
production
policy,
compliance
and
auditability
is
huge,
and
this
is
an
area
that
I
think
security.
People
are
going
to
need
to
focus
on
more
and
more
so
you
can't
inspect
in
a
very
iterative
development
environment.
B
So
what
you
need
to
do
is
think
about
what
guardrails
do
I
need
to
put
in
place
what
policies
automate
those
so
that
there's
less
variance
in
terms
of
following
them
and
then
what
you
can
inspect
is
the
exceptions
and-
and
one
of
the
things
that
some
people
have
found
is
that
when
they
automate
their
existing
policies,
everything
becomes
an
exception,
and
so
you
have
to
that's
a
careful
balance.
You've
got
a
you've
got
to
have
something
that
works
and
you
you've
got
to
do
some
process
improvement
along
those
lines.
B
One
last
thing
is
make
sure
that
your
platform
for
software
development
is
secure,
whether
it's
get
lab
github
bitbucket,
Jenkins
JIRA.
We
could
go
on
and
on
circle,
CI.
All
of
those
different
elements.
If
you're
stitching
together
a
very
complicated
DevOps
tool
chain,
you
need
to
make
sure
that
all
of
those
elements
are
secure
and
don't
introduce
vulnerabilities
as
well.
So
that's
my
final
thought
there
I
would
encourage
you
to
check
out
my
book.
It's
free
online
we've
got
that
tiny
URL
for
seaso
ebook
to
get
to
it
easily.
A
Excellent
Thank
You
Cindy.
This
is
chundan
back
again.
Your
moderator
for
the
session
I
have
received
a
few
questions
directly
as
a
chat
message
to
me,
so
I'm
gonna
weed
those
out
and
in
the
meanwhile.
If
somebody
wants
to
ask
questions,
you
could
either
directly
send
it
to
me
or
type
it
in
the
questions.
Tab
on
the
right
side,
panel
of
the
webinar
screen
Cindy
the
question
number
one
for
you.
B
Chicken
and
the
egg
actually
I
would
say
a
culture
and
tooling
both
depend
upon
process
and
workflow,
and
you
need
to
define
that
process
and
workflow.
First
then
pick
the
tool
that
that
enables
that
workflow,
while
at
the
same
time
working
on
on
culture,
but
if
you
can
get
a
single
source
of
truth
and
get
everybody
on
the
same
page,
that
culture
is
easier
to
promote.
B
They
tend
to
get
very
defensive
about
what
they're
looking
at
and
and
then
you've
got
that
whole
translation.
Well,
here's
what
I'm!
Seeing
what
are
you
seeing
and
do
these
things
match
and
how
did
they
track
and
so
think
about
workflow
think
about
tools
that
enable
the
workflow
and
then
bring
the
culture
together
around
that
workflow.
A
B
Automation
is
really
the
key
there
if
you
automate,
if
you
automate
a
policy,
there's
less
room
for
human
error.
The
only
way
you
know
if
you,
if
you
say
that,
let
me
give
a
very
simplistic
example,
but
if
you
say
that
our
policy
is
not
to
introduce
critical
vulnerabilities
into
production,
so
code
should
not
progress.
That
has
a
critical
vulnerability
in
it.
You
can
automate
that
policy
to
fail
your
your
merge
if
there's
a
critical
vulnerability.
A
Ok,
we
have
a
few
questions
on
the
questions
tab,
so
one
of
the
first
ones
is:
will
the
slides
be
sent,
provide
it
to
the
participants?
I'm
gonna
answer
that
myself,
yes,
get
lab
team
is
gonna,
get
in
touch
with
you,
with
the
recording
of
the
webinar
and
possibly
also
the
slides,
I
guess
Cindy.
Is
that
right?
Mm-Hmm?
Yes,
okay,
super!
The
next
question
is,
if
I
add
a
third
party
or
open-source
scanner
for
dependency,
container
security,
D
ast,
which
version
returns
Jason
as
output?
A
B
Yes,
there's
a
lot
to
unpack
in
that
question.
So
yes,
if
you
have
a
JSON
file
that
can
be
pulled
into
the
get
lab
CI
CD,
we
are
working
on
making
that
easier
to
do
with
an
API
and
and
focusing
a
little
bit
more
in
the
coming
months,
on
simplifying
the
integrations
one
example
of
a
vendor
who
has
done
that
a
lot
of
the
vendors
have
have
chosen
to
do
those
integrations
on
their
own
one
who's
done
it.
B
It
shows
that
that
pipeline
view
that
I
was
showing
you
for
the
developer
when
the
results
there,
with
an
attribute
that
it
came
from
white
source,
for
instance,
and
then
in
the
dashboard
that
the
security
person
uses
same
thing,
it'll
show
that
the
vulnerabilities
source
was
was
from
white
source.
So,
yes,
the
integrations
can
be
done.
B
B
A
B
Yeah,
that's
related
to
the
the
question
that
I
just
answered
the
that,
but
the
advantage
of
doing
your
scans
on
that
feature
branch
is,
it
can
be
the
individual
developers
code
not
merged
with
anyone
elses,
and
so
that
accountability
is
super
clear.
You
know,
I
made
a
change.
I
created
the
vulnerability,
it
wasn't
somebody
else
and
and
that
that's
something
that
you
don't
get
if
you're
scanning
on
the
master
branch
after
things
are
merged
together
and
a
lot
of
the
scripting.
B
It's
usually
not
done
before,
merges
it's
usually
done
after
the
merge,
so
you
lose
that
accountability
and
clarity
it,
whereas
with
get
lab
because
it's
a
single
tool
and
and
because
white
source
has
done
the
integration
in
a
very
sophisticated
manner.
You
know
their
results
or
our
own
scanners.
I,
don't
want
to
imply
that
you
have
to
use
white
source.
We
have
our
own
scanners,
whichever
scanner
you
use.
The
results
then
come
to
the
developer
in
that.
In
that
mr
pipeline
view.
B
So
it's
an
opportunity
to
tighten
them
or
it's
an
opportunity.
There's
two
two
levers:
you
can
pull
there
right.
One
is
I
want
to
restrict
things
more
carefully
and
the
other
lever
is
I
want
to
apply
those
policies
more
broadly.
So,
if
I'm
only
applying
the
policies
to
my
mission-critical
applications,
I'm
leaving
this
whole
other
set
of
applications
exposed.
So
the
question
is:
do
I
do
I
tighten
down
on
what
I
already
have
I
would
say
no
you're
you're,
better
off,
focusing
on
the
wasp
top
ten,
in
wit,
and
casting
a
much
broader
net.
B
You
know
when
you
look
at
Verizon.
Does
a
an
annual
threat
report
for
if
I
used
to
do
one
there's
a
bunch
of
different
companies
that
look
at
what
have
been
the
pattern
of
exploits
over
the
past
year
and
they
generally
are
the
same
things
that
get
exploited
over
and
over
and
they
generally
fall
in
the
top
ten.
So
you
can
go
super
super
deep,
but
I
think
broad
is
a
better
answer.
A
Okay,
thank
you.
We
have
one
more
question
coming
in
here
is
your
workflow,
basically
applicable
for
the
whole
range
from
cloud
down
to
tiny
IOT
devices.
For
example,
I
often
face
that
embedded
software
development
with
strong
hardware
dependencies
are
not
properly
considered
in
automated
environments.
Maybe
I
need
to
get
a
better
feeling
for
the
scanners.
You
mentioned.
B
Yeah
so
any
kind
of
software,
whether
it's
you
know
web
mobile
IOT,
it
really
doesn't
matter.
The
language
is
probably
the
greater
limiting
factor
or
determining
factor,
but
the
the
key
really
is
scanning
your
applications
and
the
dependencies
dependencies
have
grown
in
your
write.
A
lot
of
people
have
not
included
dependency
scanning,
but
it's
it's
a
huge
risk
area,
because
the
I
forget
the
statistic
on
it's:
this
huge
portion
of
software.
Now
that
includes
third-party
code
and
it's
growing,
because
why
reinvent
the
wheel?
B
You
know,
testing
that
something
or
looking
at
something
on
the
screen
or
returning
a
particular
value
or
whatever.
Why
reinvent
that?
If
I
can
go
out
and
grab
it,
and
you
can't
just
assume
that,
because
more
people
use
it
it's
safe,
and
so,
with
the
growth
of
dependency
scan
dependencies,
you
really
need
to
do
to
also
grow
your
dependency
scanning
and
so
and
I
know.
Iot
uses
a
lot
of
that.
A
lot
of
third
party
code.
So
absolutely
if,
in
terms
of
where
to
go,
you
know
led
you
to
the
book.
A
Okay,
we
have
one
more
question
that
is
talking
about
selling
it
internally,
so
it
is.
It
is
super
understandable
for
developer
and
security
teams,
but
how
could
someone
sell
the
extra
expenses
conquering
with
the
edge
right
tools
already
in
place
so
Cindy?
Can
you
recommend
some
stats
or
links
that
can
be
leveraged
for
the
C
level
discussions
internally.
B
B
There
are,
if
you
contact
your
get
lab
sales
person,
they
have
some
ROI
tools
that
are
kind
of
tailored,
based
on
what
you
have
to
show
your
own
unique
ROI,
but
there's
not
only
the
cost
of
the
tool
but
think
about
them
and
power
that
you
spend
women
power
person,
power,
trying
to
be
politically
correct
here,
the
that
you
spend
managing
and
maintaining
the
interfaces
among
all
those
tools,
and
they
can
be
very
fragile
as
well
so
there's
there
are
some
really
good
case
studies.
The
other
thing
to
Google
might
be
get
lab.
B
A
Alright
excellent,
thank
you
so
much
I
think
those
are
the
questions
that
we
have
received
so
far.
So,
first
of
all,
thank
you.
Cindy
for
for
this
lovely
presentation
today
and
for
taking
time
off
to
speak,
speak
to
the
attendees.
So,
as
we
said
in
the
beginning,
the
session
is
going
to
be
recorded
and
and
the
--get
lab
team
is
gonna,
get
in
touch
with
you,
with
more
updates
and
and
also
of
the
recording
and
the
slides
from
Cindy.
A
A
So
we
can
pass
that
past
the
question
or
the
comment
over
to
the
github
team
for
for
further
answers,
but
thank
you
to
each
and
every
one
who
did
register
and
participate
in
attend
this
webinar
today,
and
we
sincerely
hope
that
all
of
you
are
doing
safe,
well
and
sound
during
this
this
interesting
times,
and
also
thank
you
very
much
to
Cindy
once
again
and
the
good
lab
team
entirely
for
making
this
happen.
For
all
of
us.
Thanks
guys
and
see
you
guys
soon
on
another
webinar
session,
take
care,
bye,
bye,.