►
Description
Presented by:
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
Your
hosts
for
today
are
mommy
and
I
shlomi
is
our
application
security,
executive,
shlomi
shaki
joined
github
six
months
ago
to
lead
our
application
security
space
in
region
and
he's
based
in
sydney
shlomi
held
various
technical
as
well
as
business
positions
around
both
software
development
and
security
for
the
last
25
years,
and
my
name
is
fatin
healy,
I'm
a
senior
solution
engineer
at
github
based
in
sydney
as
well.
A
A
Please,
before
we
get
started,
I
just
have
a
couple
of
housekeeping
notes
for
you.
The
first
one
is
around
the
chat
window,
so
you
can
see
at
the
top
right
hand,
side
you've
got
a
chat
window,
so
please
feel
free
to
get
involved.
Say
hi
to
us
tell
us
where
you
are
joining
us
from
as
well
as
I
have
my
colleague
who's
adrian
lee
he's
a
senior
solution,
engineer
as
well
at
github
who
will
be
monitoring
the
chat
window
for
us
this
next
to
the
chat
you
will
see
as
well.
A
The
polls,
so
the
post
will
will
have
a
couple
of
posts
during
the
session.
So
you
want
to
try
to
make
it
as
interactive
as
possible.
So
once
we
have
a
poll,
please
make
sure
that
you
will
cast
your
vote
and
we've
got
a
q
and
a
so
at
that
top
top
right
hand.
Corner
you've,
got
the
q
and
a
section
where
you
can
post
any
questions
that
you've
got
for
shlomi
and
I,
as
well
as
adrian,
will
be
helping
us
with
the
q,
a
section
if
you
are.
A
A
I
just
want
to
give
a
couple
of
tips,
so
you
can
get
the
best
viewing
experience
with
us.
First
of
all,
make
sure
that
you
are
joining
us
from
the
from
a
desktop
using
chrome
or
edge
or
safari.
A
So
whatever
browser
you've
got,
if
you
are
using
firefox,
make
sure
that
you've
got
the
latest
version
and
if
you
there's
any
problem
or
you
can't
see
the
streaming,
maybe
you,
if
you're
on
try
to
refresh
the
page
that
might
help
the
first
troubleshooting
tip
the
second
one,
if
you're
using
vpn,
try
to
disable
vpn,
maybe
and
refresh
your
screen,
try
to
log
off
and
then
log
back
and
using
the
link
that
you've
got
and
another
one
that
if
you've
got
any
other
troubleshooting
issues
with
the
platform,
we've
got
our
moderator
adrian,
as
well
as
the
goku's
team.
A
Who
will
be
more
than
happy
to
assist
you.
We've
got
the
docs
tab
at
the
top
right
hand,
side
that
will
have
some
documentation
to
help
you
with
troubleshooting.
Let's
have
a
great
session
everyone
and
now
to
the
show
we've
got
building
a
frictionless
application
security
program.
I
will
pass
it
to
shlomi
to
get
started
to
you.
Shlomi.
B
Thank
you
very
much
fatim.
I
really
appreciate
it
and
hi
everyone.
I'm
really
really
excited
to
be
here
and,
as
kathleen
mentioned
earlier
over
the
years,
I
worked
both
in
software
development
and
security
in
the
different
companies
like
mercury
and
hp
and
fordify,
and
I've
seen
a
number
of
attempts
to
launching
successful
application
programs.
I've
worked
with
some
of
the
large
banks
and
some
smaller
companies
as
well
and
today.
B
What
we're
going
to
do
is
we're
going
to
explore
how
to
build
application
security
programs
that
that
have
as
little
friction
as
possible,
because
what
we've
seen
is
the
over
the
years
and
talking
to
customers.
We've
seen
quite
a
lot
of
challenges
that
customers
are
facing
when
they're
trying
to
build
application,
security
programs
and
we'd
like
to
share
with
you
some
of
the
most
common
ones.
B
It's
not
all
of
them,
but
at
least
they're
kind
of
the
most
comment
that
we
hear,
and
hopefully
some
tips
as
well-
that
that
you
could
use
potentially
in
your
environment,
to
try
and
streamline
as
much
as
possible
your
application
security
efforts
and
we're
aiming
to
have
this
session
is
a
very
interactive
session.
B
So
we
have
as
fat
and
said
the
q
a
and
there's
also
going
to
be
polls,
and
I'm
really
curious
to
see
kind
of
what
sort
of
questions
are
going
to
come
up
from
the
audience,
so
feel
free
to
put
your
questions
there.
Okay,
so,
ultimately,
when
we're
thinking
about
kind
of
application,
security,
and
when
I
started
application
security
around
2009,
there
were
only
really
a
few
companies
that
acknowledged
that
software
security
is
an
issue.
B
This
is
an
issue
not
in
one
single
team,
but
but
across
the
board
fast
forward
to
today
the
vast
majority
of
organizations,
at
least
that
we
talk
to
already
know
the
consequences
of
breaches.
Maybe
they
might
underestimate
them
a
little
bit,
but
they
also
have
some
risk
management
frameworks
in
place.
They
know
what
they
need
to
do.
There's
some
level
of
application
security
in
place.
It
did
exist
and
when
I
speak
to
customers,
it's
very
rare
to
come
across
people
that
don't
do
anything
at
all
to
secure
stuff.
B
B
So
there's
all
kinds
of
activities
that
already
happen,
but
if
you
look
at
kind
of
fast
forwarding
again
from
about
10
or
11
years
ago,
when
you
go
into
2022
the
job
that
we
have
hasn't
become
easier,
we're
building
more
code,
and
that
means
that
we
have
a
bigger
attack
surface
which
ultimately
gives
the
attackers
or,
in
fact
human
errors,
more
opportunities
and
more
entry
points
to
to
the
application.
B
We
also
have
much
more
interesting
applications
and
then
we
connect
to
our
business
partners,
and
so
that
brings
along
also
more
complexity
and
and
complexity.
I
guess
in
the
security
world
is:
is
the
enemy
of
of
kind
of
good
security?
The
more
complex
your
environment
is
the
harder
it
is
to
protect
it
and
the
harder
it
is
to
protect
your
environment.
So
so,
ultimately,
complexity
makes
the
problem
not
only
bigger
you.
B
In
some
it's
much
bigger
than
others,
and
so
our
job
is
becoming
harder
moving
forward
and
we
need
to
make
sure
that
not
only
do
we
protect
the
new
code
or
the
new
applications
that
we
create,
but
we
also
need
to
look
sometimes
backwards
into
all
the
existing
infrastructure
that
that
is
there
today,
because
that
might
be
the
way
the
entry
point
for
for
attack
is
so
so
that
that
is
making
all
our
jobs,
both
engineering
and
security,
a
lot
harder
to
secure
apps
and
then,
on
top
of
it.
B
When
you
kind
of
look
at
the
cyber
security
landscape,
the
fight
itself
became
a
lot
harder.
So,
if
you
think
about
it,
we're
really
fighting
an
asymmetrical
fight.
The
attackers
really
have
a
lot
of
advantages
over
us,
but
it's
not
it's
not
all
bad
we're
gonna
get
to
kind
of
what
we
can
do
to
to
maybe
try
and
turn
the
tables
around.
But
if
you
look
kind
of
on
the
left
corner
or
the
red
corner,
we
have
the
attackers,
and
the
attackers
have
unlimited
attempts
at
trying
to
get
in
to
our
organization.
B
They
can.
They
can
try
as
many
times
as
they
want,
sometimes
we'll
block
them,
but
ultimately
there's
very
little
attribution
and
retribution
to
to
the
attackers.
Also,
the
attackers
usually
have
some
sort
of
a
mission
whether
it
is
monetizing
the
attacks
or
whether
it
is
to
to
cause
a
particular
harm
or
bring
down
the
infrastructure.
B
They
have
a
particular
mission
all
the
time
and
they
need
to
complete
the
mission.
It's
not
an
ongoing
marathon,
where
you
need
to
keep
on
defending
yourself.
They
also
usually
have
the
coolest
tools
because
one
they
have
the
skills
and
they
have
the
tools
to
be
able
to
build
their
own
custom
tools
specifically
to
be
able
to
exploit
certain
vulnerabilities
or
certain
weaknesses
in
your
environment
and
then
finally,
the
attackers
only
have
to
be
arrived
once.
B
They
only
need
one
single
opportunity
to
to
be
able
to
get
in
and
be
able
to
either
exfiltrate
data
or
exploit
the
application,
or
do
something
with
it
and
there's
so
many
ways
to
get
it.
On
the
other
hand,
the
defenders
are
really
at
the
disadvantage.
In
most
cases,
we
work
under
pressure.
We
have
a
skill
gap.
Ultimately,
in
many
many
of
the
organizations
you're
actually
hiring,
sometimes
new
people
into
the
organization.
B
You
have
to
train
them,
they're,
not
necessarily
people
that
came
in
with
the
mentality
of
defending
the
organization,
and
then
you
still
have
to
deal
with
the
technical
debt
and
also,
at
the
same
time,
the
tooling
that
you
might
have
might
not
be
optimized
to
be
able
to
defend
the
organization.
B
B
It's
also
in
in
to
start
with
a
lot
harder
to
actually
fight.
It's
not
really
stacked
up
correctly.
One
of
the
things,
however,
that
makes
it
probably
better
for
the
defenders
is
speed
of
releasing
stuff,
so
devops
and
we've
basically
been
able
to
release
and
ship
code
much
faster.
That
means
that
the
landscape
for
the
attackers
changes
all
the
time
in
in
the
cyber
security
world.
B
It's
called
moving
target
defense
and,
and
that
makes
it
a
lot
harder
for
attackers
to
be
able
to
do
reconnaissance
and
be
able
to
exploit
applications
and
so
being
able
to
ship
quickly.
In
fact,
in
some
cases
the
security
teams
sometimes
resist
to
it.
But
in
fact
that's
a
that's
actually
a
good
thing,
because
it
actually
helps
to
basically
throw
the
attackers
from
planning
and
be
able
to
attack
you
really
quickly.
B
A
Okay,
so
we're
gonna
open
the
first
port
thanks
johnny
and
I
totally
agree
like
sometimes
if
the
security
engineer
or
the
defenders
are
99
right,
that
one
mistake
is
going
to
be
the
one
that's
going
to
be
the
highlight
of
what's
going
on
with
them.
So
the
first
poll
for
today
is
whose
responsibility
is
it
to
make
sure
that
we
are
shipping
secure
code?
Is
it
the
apsec
team?
A
Is
it
the
engineering
team
as
the
developers
team,
or
is
it
a
shared
responsibility
between
the
abstract
team
and
the
engineering
team
as
like
both
of
them?
I'm
gonna
keep
it
open
for
maybe
a
minute
and
see
how
it
goes
so
far.
We've
got
over
93
percent
with
both
as
like.
It's
a
shared
responsibility
between
the
abstract
team
and
the
engineering
team,
and
then
now
it's
going
a
little
bit
lower,
but
we
will
at
least
90
percent
are
saying
that
it's
a
shared
responsibility,
which
I
agree
with
personally.
A
B
Look
it's
it
in
in
theory.
I
think
most
people
will
answer
both,
but
in
practice
that's
not
always
what
actually
happens
but
many
times
either
either
falls
on
kind
of
engineering
or
only
on
security.
It
depends
on
a
little
bit
of
the
organization,
but
I'm
curious
to
see
what
the
result
is.
A
Yeah,
sometimes
in
reality
it's
not
with
the
same
as,
what's
the
ideal
ideal
solution
that
we
want
or
the
response
right
so
far,
we've
got
87
percent,
as
both
we've
got
around
four
percent
for
engineering
and
eight
percent
for
the
abstract
team.
I
was
hoping
that
it's
gonna
stay
over
90
percent
for
both.
B
Cool,
that's
that's!
That's
really
cool
and
by
the
way,
we're
we're
going
to
explore
some
of
those
models
like
who
actually
owns
it.
But,
but
I
think
you
know
like
in
most
cases
you
cannot
do
it
without
the
security
team,
but
you
can
also
not
do
it
without
the
engineering
team
because
they
own
the
software.
So
ultimately
it's
a
collaborative
effort,
but
the
question
is,
I
guess,
who's
accountable
at
the
end
of
the
day
to
make
sure
that
we're
safe
to
go
into
production.
B
Wonder
who
chose
just
the
app
stick?
It's
probably
engineers
that
decided,
they're
gonna
put
it
on
the
app
sections,
that's
fine
cool,
so
that
actually
is
a
great
segue
to
to
the
next
section,
which
is
kind
of
like
what.
What
do
we
see?
Okay.
So,
when
we
go
and
talk
to
a
lot
of
customers,
we
see
all
kinds
of
situations.
B
Some
of
them
are
in
much
better
places
than
others,
but
generally
speaking,
if
I
kind
of
create,
if
you
will
three
buckets
of
of
maturity
without
with
excluding
the
ones
that
absolutely
don't
care
about
application,
security
at
all
and
they're,
just
creating,
maybe
maybe
early
stage
startups,
where
they
need
to
just
first
of
all
create
something
that
customers
would
love
but
or
create
business
value.
B
B
Guys
is
your:
is
your
application
or
environment
secure
and
someone
might
not
even
be
a
security
person
in
the
organization
again
depending
on
the
size
of
it,
asked
it
that
question
and
that
that
we
call
it
the
kind
of
the
security
gate.
The
ad
hoc
security
gate,
where
ultimately,
either
the
security
team
or
it
comes
up
and
says?
Okay,
we
need
to
be
responsible
for
security
ourselves
and
we
don't
have
the
capability
ourselves
to
do
it.
B
So,
generally
speaking,
we'll
just
hire
some
penetration
testing
company
to
either
come
in
and
hammer
my
application
for
about
two
or
three
days
and
find
all
the
stuff
that
doesn't
work
or
do
some
code
reviews
and
and
sometimes
the
development
team
itself.
The
engineering
team
says
you
know
what
we're
building
this
application.
We
don't
even
have
a
security
person
in
this
company,
but
we're
kind
of
you
know.
We
know
it's
the
right
thing
to
do
so.
Maybe
we'll
hire
some.
B
You
know
either
some
expert
to
tell
us
whether
we're
doing
okay
or
not,
because
we're
not
security
experts
and
also
maybe
we'll
apply
a
couple
of
tools,
maybe
static
analysis,
or
maybe
some
dynamic
analysis
or
fuzzing.
But
it's
done
generally
in
an
adult
way
and-
and
the
challenge
here
is
that,
generally
speaking,
application
security
at
that
point
in
time
is
done.
B
Typically
after
the
fact,
when
it's
after
the
fact,
ideally
not
after
a
bridge,
but
sometimes
it's
either
leading
into
some
sort
of
an
audit
or
maybe
we
need
to
shift
code
into
maybe
to
a
customer
and
the
customer
is
asking
hey
guys.
What
have
you
done
from
a
security
point
of
view
or
or
maybe
we
do
kind
of
an
annual
pen
test?
So
that's
the
first
stage.
B
The
second
stage
is
the
the
more
well-defined
security
gate
and
so
kind
of
after
we've
done
the
first
one.
Typically,
customers
will
say
well,
hang
on
a
second,
we
can't
continue
just
to
hire
someone
from
the
outside
and
come
in
once
a
year
and
tell
us
what's
wrong
that
doesn't
make
sense,
it's
kind
of
like
almost
testing
that
the
car
brakes
work
when
you
haven't
actually
put
the
brakes
into
the
car
in
the
first
place.
B
Of
course,
it's
not
going
to
work
because
there's
no
brakes,
and
so
then
we
can't
go
into
a
more
well-defined
structured
security
gate
and
and
then
basically,
we
hire
a
security
team,
ideally
with
application
security
background
or
even
create
an
application
security
team
and
that
application
security
team
generally
engages
with
engineering
to
to
do
a
number
of
things.
One
is
to
train
around
application
security
to
to
build
some
sort
of
governance
and
and
policies,
there's
all
kinds
of
frameworks
that,
generally
speaking,
are
being
used.
B
For
example,
if
you're
familiar
with
osp
sams
or
the
owasp
project
have
a
very
cool
framework
that
is
focusing
around
application
security
and
it's
called
owasp
sam.
So
security
assurance
maturity
model-
it's
been
around
probably
for
about
10
years
and
it's
been
maintained
by
the
awesome
community,
but
it
gives
you
kind
of
a
framework
to
what
sort
of
steps
should
you
do
throughout
the
software
development
life
cycle,
but
typically
when
people
are
thinking
about
it,
they'll
start
with
again
it's
still
a
security
gate.
B
It's
still
an
assurance
function
that
comes
yes,
it
might
come
in
a
little
bit
earlier
in
the
process,
and
maybe
the
security
team
will
engage
with
the
software
development
team
a
little
bit
earlier,
but
it's
still
done
relatively
late
in
this
sdlc
and
it's
definitely
not
done
in
the
stream
of
your
software
development,
especially
not
in
kind
of
in
a
devops,
agile
manner,
and
so
that
is
kind
of
the
second
stage
and
that,
generally
speaking
at
least
reduces
the
risk.
But
what
it
does
do
is.
B
B
The
engineering
might
might
get
a
lot
of
results
and
the
results
might
come
in
different
ways
that
are
not
in
their
focus
and
also
the
the
usually
a
lot
of
complaints
around
false
positives.
We're
getting
a
lot
of
results,
we
don't
know
what
to
do
with
it
and
it's
just
too
much
noise
and
it's
good
for
about
maybe
half
a
year
or
three
months,
but
we
need
to
remember
again.
Unfortunately,
as
defenders,
we
don't
have
the
opportunity
or
the
the
luxury
of
doing
it
once
we
have
to
think
about
it
as
a
marathon.
B
So
we
have
to
do
something
that
is
sustainable
for
the
engineering
team
that
they
can
continuously
do
and
that's,
generally
speaking,
the
breaking
point
of
basically
engineering
and
security
team
coming
in
and
saying,
look
you
know
we
need
to
find
a
better
way.
B
It's
really
really
important
and
we
see
it
quite
often
so
with
that
I'd
like
to
kind
of
see
with
the
audience
that
we
have
here,
what's
the
kind
of
what's
the
the
take,
what
do
you
guys
think
in
terms
of
your
organizations?
B
A
B
A
In
an
ideal
world,
it
will
be
like
really
streamlined
with
the
development
life
cycle,
but
so
far
we've
got
like
45
percent
as
reactive,
which
is
that's
the
truth.
That's
the
situation
that
lots
of
companies
are
in
at
the
moment
today
and
hopefully
that
will
change
in
the
near
future.
B
Yeah,
I
think
I
think,
there's
there's
a
good
a
lot
of
good
things
that
are
coming
out
today.
I
think
it's
we've
had
for
about
10
years.
I
think
a
lot
of
education
there's
a
lot
more
awareness
now,
so
it's
not
all
bad.
It's
a
lot
of
awareness,
there's
a
lot
more
education,
but
also,
I
think
some
of
the
the
tooling
is-
is
getting
more
appropriate
and
fit
for
purpose
to
to
be
able
to
do
it
quicker
where
the
first
generation
of
tools
that
came
out
didn't
so.
B
What's
the
have
we
closed
the
poll.
A
B
Great,
so
so,
if
I
get
it
right,
I
just
want
to
repeat
it,
so
we
have
40
reactive
about
roughly
about
40,
roughly
about
20
off
proactive
and
then
about
30
or
35
people
take
stream.
Okay,
that's
that's
a
cool
distribution,
yeah
and
again
it.
It
really
depends
on
also
the
organization
itself.
If
it's
a
startup
software
development,
we
just
started
now
it's
a
lot
easier
where,
if
you're
in
a
in
a
large
bank
you
will
you
will
have
to
do
something
because
of
compliance.
B
B
So
as
as
I
mentioned
before,
I
think
we
kind
of
all
figure
out
one
way
or
another
that
even
if
you're
in
a
reactive,
you
would
like
to
generally
move
into
more
of
a
security
by
design
or
built
in
versus
kind
of
after
the
fact,
as
I
mentioned
before,
like
that
kind
of
the
analogy
is
like
a
lot
of
times:
let's
you
know,
throw
it
over
the
fence
and
expect
the
security
team
to
come
in
with
all
kinds
of
magic
stuff
that
doesn't
happen,
especially
now
when
a
lot
of
the
older
controls,
especially
with
architecture,
maybe
in
the
older
days
we
could
put,
we
could
bunch
all
our
applications
as
a
monolith
behind
kind
of
a
data
center
and
maybe
put
some
sort
of
a
web
application
firewalls,
not
that
it's
probably
the
more
secure,
but
at
least
it
provides
some
level
of
protection.
B
B
There
is
no
way
to
actually
put
all
of
that
behind
some
sort
of
perimeter,
and
so
you
really
have
to
build
it
into
the
applications
and
to
do
that,
you
have
to
build
it
into
the
process.
There's
no
other
way.
There
is
actually
another
benefit,
and
I
don't
want
to
spend
too
much
time
on
it,
but
this
is
something
that
probably
many
of
you
have
seen,
and
it's
not
just
by
the
way
that
model
of
cost
per
bug
across
the
size
of
the
software
lifecycle
is
not
something
that
is
unique
to
security.
B
It
depends.
It
applies
to
quality
assurance
as
well.
I
mean
I've
started
my
career
in
software
testing
and
automation
and
and
even
then
kind
of
the
model.
Maybe
the
numbers
were
different,
I
guess
with
inflation.
Maybe
it
went
up
a
little
bit,
but
it's
the
same
model
like
you
did
the
earlier.
You
can
catch
it,
the
better
it
is,
and
so
for
software
security.
The
challenge
with
that
is
that
often
the
only
time
that
you're
gonna
know
that
you
have
an
issue
is
either
at
the
end.
B
When
you
have
a
pen
test
or
unfortunately,
if
you
have
a
breach
and
then
the
cost
exponentially
goes
up,
it's
not
even
like
close.
But
but
if
you
apply
good
practices
for
software
development
and
software
security,
you
have
a
chance
to
to
really
demonstrate
cost
savings.
Now.
B
Obviously,
if
you
don't
do
security,
it's
the
cheapest
is
to
not
do
it
at
all
until
you
get
breached,
but
but
if
you
are
going
to
to
make
sure
that
you
eliminate
all
the
vulnerabilities,
it's
it's
much
better
to
do
it
earlier,
it's
cheaper
and
you
have
less
rework
and
less
frustration
as
well.
B
I
personally
have
seen
a
couple
of
projects
where
we
sat
down.
We
did
the
pen
test.
Unfortunately,
we
had
the
results.
B
The
results
were
not
great
and
it
came
in
the
last
minute
and
then
you're
sitting
down
with
the
software,
the
basically
the
project
team,
the
security
team
and
the
external
pen,
tester,
and-
and
basically
you
have
to
give
the
bad
news
that
you
can't
go
to
production
tomorrow
and,
at
the
same
time
not
going
to
production
is
going
to
cost
the
business
a
couple
million
dollars
a
day,
and
so
you
have
to
manage
that
risk
and
decide.
B
Do
we
take
the
risk
or
not
where,
if
you
did
it
earlier,
it'd
be
a
lot
cheaper.
So
with
that,
I
wanted
to
cover
some
of
the
common
challenges
about
software
security,
so
which
we
all
agree
that
it's
it's
best
to
to
do
software
security
in
a
streamlined
way.
The
vast
majority
of
you
have
said
that
both
software
security,
sorry,
the
security
team
and
software
engineering-
has
to
come
together
to
solve
this
problem,
and
we
all
agree
that
it's
better
to
do
it
earlier.
B
So
the
question
is:
what
are
the
challenges
that
stop
us
from
doing
it
earlier?
So,
let's,
let's
cover
the
probably
the
top
four
that
we've
seen
and
starting
with
number
one
common
challenge.
Number
one
engineering
and
apsec
are
siloed.
That
is
the
most
common
challenge
that
we
hear
when
I
say
siloed
it.
Typically,
if
you
think
about
it,
engineering
really
have
a
basically
a
mission
to
build
up
amazing
applications
and
to
ship
them
quickly
to
customers
and
ultimately
innovate
much
quickly
where
security
is
actually
the
opposite.
B
The
security
team
try
to
slow
things
down
to
to
make
it
more
safe,
not
because
they
want
to
to
be
the
no
department,
but
because
they
are
considering
the
risk
behind
moving
too
fast,
and
so
in
a
way
you
have
two
teams
that
are
that
are
thinking
in
two
different
ways
and
they
have
two
different
opposing
missions.
B
Both
of
them
are
really
important.
It's
kind
of
again
it's
kind
of
like
the
the
the
gas
pedal
and
the
brakes
in
the
car.
You
need
both
of
them
to
drive
around
the
corners
quickly,
but
it's
just
a
question
of
what
sort
of
balance-
and
it's
really
important,
also
to
have
the
right
communication,
fat
and
I'm
curious.
You've
worked
with
a
lot
of
our
customers
over
the
years.
What
what
sort
of
experiences
did
you
see?
Is
that
something
that
customers
really
see.
A
If
you
want
to
call
it,
but
the
most
common
one
and
it's
one
of
the
traditional
one
is
that
the
security
team
will
get
involved
when
something
happens,
so
that
communication
is
very
incident
driven
and
if
either
there's
an
incident
and
the
security
team
is
brought
in
to
work
on
that
or
it
might
be
like
scheduled
every
month
to
just
go
through
what's
going
on
in
the
company
and
that
communication
might
be
done
either
via
email
or
a
long
pdf.
A
One
of
the
extreme
use
cases
that
I
can
share
with
you
is
one
of
the
security
teams
where
they
had
the
scanning
results
and
printing
them
on
like
a
piece
of
paper
and
then
bringing
it
to
the
developer
team
to
share
it
with
them
and
that
that's
an
extreme
one.
It's
not
a
common
or
standard
communication,
but
I've
seen
that
and
that
wasn't
long
long
time
ago,
unfortunately,
but
yeah
true
story.
B
As
also
is
known
as
devsec
paper
ops,
or
something
like
this,
someone
will
need
to
come
up
with
the
right
acronym
for
it.
So
this
is.
This
is
really
common
and
I
think
it's
it's
just
a
breakdown
of
it's
really
that
the
different
teams
misunderstand
the
challenges
that
the
other
team
has
and
they're,
just
not
working
in
the
lying
way,
and
so
the
most
common
ways
that
we
heard
or
or
things
that
customers
that
are
more
kind
of
in
the
streamline
area
have
done.
Is
they
focused
on?
B
And
this
is
this
might
sound
like
a
good
idea?
It's
it's
easier
said
than
done,
maybe,
but
aligning
the
goals
and
incentives
for
both
security
and
engineering,
so
that
both
of
them
have
common
goals
and
they
work
towards
the
same
mission.
And
so,
if
we're
saying
that
security
tries
to
slow
things
down
and
make
it
safe
and
engineering
tries
to
push
things
quickly
and
make
things
that
are
amazing
to
yours
and
great
functionality.
B
If
we
can
find
a
way
to
give
both
of
them
some
elements
of
the
the
goaling
across
the
board,
then
what
that
will
do
is
it
will
bring
those
two
teams
together
and
it
will.
It
will
not,
I
have
to
say
force,
but
it
will
give
them
an
incentive
to
work
together
towards
a
common
goal.
So
imagine
that
the
security
team
had
a
goal
of
look.
We
have
a
project.
The
project
deadline
is
whatever
it
is.
B
If
we
get
to
a
point
where
we
can
release
the
product
and
we
can
show
that
we
ultimately
reduce
or
we
eliminate
any
critical
or
high
vulnerabilities
from
our
code
or
maybe
we
can
reduce
the
vulnerability
density,
which
is
basically
how
many
vulnerabilities
do
we
have
for
every
thousand
line
of
code,
then
we
have
some
level
of
measures
and
some
level
of
incentives
and
goals
that
are
common
and
it
brings
those
two
teams
together.
B
The
other
thing
that
we
hear,
probably
the
best
teams
do,
is
they
really
focus
on
and
and
it's
really
easy
to
get
trapped
into.
I
mentioned
measures.
I've
had
a
really
interesting
conversation
with
with
one
of
the
experts
in
appsec
that
I
worked
with
before
and
in
the
number
of
organizations
in
australia,
and
I
asked
him
hey.
B
How
do
we
do
input
validation
and
output
encoding
if
the
apps
team
engages
super
early
and
helps
them
build
the
frameworks
that
can
help
those
developers
make
sure
that
they're
using
the
right
frameworks
that
that
actually
helps
a
lot
that
that
is
a
big
difference
to
a
lot
of
organizations
and
then
finally,
keep
it
simple,
try
and
and
focus
only
on
the
vulnerabilities
that
matters,
don't
don't
sweat
the
small
stuff
there's
going
to
be
stuff
like
cross-site
scripting,
sql
injection.
B
Amazingly,
they
are
still
a
thing
in
2022
and
we
need
to
focus
on
the
stuff
that
literally
can
bring
down
your
organization
and
and
avoid
focusing
or
boiling
the
ocean
trying
to
fix
everything,
because
you
try
and
do
that.
First
of
all,
you're
going
to
get
a
lot
of
fatigue
in
the
engineering
team
and,
second
of
all,
you
you're
kind
of
your
trading
water
you're.
Doing
a
lot
of
stuff
that
is
meaningless.
B
Plus
there
potentially
is
different
ways:
different
kind
of
compensating
controls
to
to
protect
from
those
vulnerabilities,
so
just
because
take
spring
spring,
for
example,
the
latest
spring
vulnerability
that
was
only
applicable
to
certain
jre
in
production,
and
so
there
are
other
ways
that
you
can
actually
avoid
fixing
or
changing
the
whole.
You
know
the
whole
java
kind
of
the
jdk
that
you're
using,
and
so
that
is
another
way
so
think
about
kind
of
what
what
is
the
most
critical
and
work
in
that
risk
based
approach.
B
Common
challenge
number
two
lack
of
expertise,
and
so,
if
you,
if
you
were
in
engineering
and
you're
thinking-
oh
my
god
this
this
is
really
hard
to
do.
Application
security.
B
Think
about
the
of
the
loan
application
security
engineer
that
you
kind
of
have
and
so
there's
different
different
surveys
that
I've
seen
that
measure
how
many
application
security
engineers
there
are
for
how
many
software
developers
in
in
an
organization.
But
when
we
did
the
research
we
looked
at
it
and
we
kind
of
came
up
to
about
roughly
about
500
or
550
people
per
application
security.
Engineer,
I've,
seen
organizations
with
like
2
000
developers
and
having
one
application
security
engineer.
B
Eventually
they
they
grew
up.
But
it's
it's
outnumbered,
the
just
for
your
knowledge,
the
best
companies
out
there
that
do
replication
security,
and
then
there
is
a
couple
of
measures
that
do
that
that
look
at
the
metrics,
the
metrics
are
for
the
most
streamlined,
probably
most
mature.
I
would
call
it
like
maturity.
Five.
They
usually
have
about
100
developers
and
one
security
engineer
for
for
each
hundred
developers.
B
It
just
doesn't
work,
it's
a
completely
different
domain,
so
you
need
someone
with
engineering
background
that
can't
that
have
a
mindset
for
security
and
they
are
very
difficult
to
come
by
at
least
at
least
good
ones.
So
so
that
is
difficult
and
a
lot
of
organizations
struggle
with
it
and
even
if
they
can
find
the
right
people
very
often
those
people
either
will
get
burned
or
will
move
on
to
a
different
organization
because
they're
gonna
get
poached.
So
what
can
we
do?.
A
A
It's
a
bit
scary,
but
the
idea
here
to
show
that
your
work
is
very
valuable
and
you
want
to
be
able
to
multiply
it
and
make
sure
that
you
are
like
the
most
important
person
that
making
sure
all
of
these
developers
are
writing
safe
code
and
secure
codes.
We're
not
trying
to
scare
any
security
engineer
here.
B
I
think
I
I
think
most
application
security
engineers
do
it
because
they
love
it,
not
necessarily
because
it's
probably
the.
A
B
B
They
they
become
the
person
that
can
then
teach
and
and
enable
security
champions
within
the
engineering
team,
find
those
people
that
do
care
about
security
that
have
a
bit
of
a
spark
that
have
a
bit
of
an
interest
to
it,
not
only
train
them
but
help
them
kind
of
become
the
tier
one
or
support
for
them.
Educating
them,
maybe
creating
even
a
team,
an
application,
security,
kind
of
extended
team
and
then
doing
monthly
meetings
just
around
application
security
and
then
enabling
them
and
then
those
those
kind
of
people.
B
Those
application
security
experts
are
super
super
valuable
to
an
organization
because
they
help
the
organization
scale,
as
opposed
to
just
saying
no,
the
other
thing
that
is
probably
pretty
obvious,
but
the
more
manual
stuff
you
do,
the
more
prone
to
human
error
you
become
and
so
and
then
the
more
cumbersome
it
is,
and
so
try
and
automate
as
much
as
possible
where,
where
where
it
makes
sense,
and
when
you
tackle
application
security
first,
don't
try
and
tackle
the
old
technical
debt,
because
that
that
is
going
to
be
really
difficult
to
do.
B
Try
and
put
automation
to
focus
on
eliminating
new
technical
debt
so
that
all
the
new
stuff
that
you're
creating
is
not
going
to
have
more
holes
in
it
like
you're,
trying
to
make
sure
that
you're
creating
buckets
without
new
holes
as
opposed
to
filling
all
the
holes
in
the
bucket
that
already
exist
and
then,
finally,
with
regards
to
education,
I've
seen
a
lot
of
organizations
trying
to
do
security,
education
in
general
and
also
developer
security,
education
and
there's,
there's
probably
the
two
different
ways.
B
We
need
to
just
make
sure
that
all
developers
have
been
trained
on
how
to
write
secure
java
code
or
php
or
whatever
it
is,
and
it's
once
a
year
and
you
ultimately
click
next
next
next
and
at
the
end
of
the
day,
you
get
a
certificate,
and
you
finish
that
course,
and
you
have
no
new
knowledge
at
all
of
how
to
do
secure
coding,
you're
back
to
basically
on
you're
on
your
own
first
is
and
by
the
way
in
the
last
couple
of
years,
or
maybe
more
of
the
years,
there's
been
actually
quite
interesting.
B
B
Let's
say,
csrf
then
give
the
engineering
a
way
to
go
and
study
just
kind
of
like
a
wiki
where
they
can
click
from
the
vulnerability
and
see
what
is
that
vulnerability?
What's
the
cause
of
it?
What's
the
different
permutation
in
different
kind
of
languages,
ideally
in
the
language
that
they
actually
scanned
and
also
what
are
really
good
ways
to
actually
avoid
it.
B
So
it's
more
education
in
time
based
on
actual
results
based
on
the
code
that
you
write
not
based
on
just
theory,
because
the
theory
it's
it's
necessary,
I
guess,
but
it's
boring,
and
it's
not
really
conducive
to
to
really
educating
people
next.
So
challenge
number
three
is:
even
if
you
got
into
a
streamlined
mode
and
you've
got
your
security
champions
in
place
and
you're
engaging
with
them
early
and
you
have
everything
is-
is
happy
days.
B
Unfortunately,
80
to
90
of
your
code
is
gonna,
be
open
source
and
so
in
security.
World
supply
chain
risk
is
one
of
the
highest
risks.
It's
kind
of
one
of
the
the
biggest
hardest
things
at
the
moment.
We
all
heard
about
look
for
j
and
I'm
sure
some
of
you
have
had
to
go
through
and
find
all
the
libraries
that
have
looked
for
jay.
Do
we
even
have
it?
What
versions
do
we
have?
Where
else
does
it
exist?
What
can
we
do?
Oh
wait.
B
A
second,
we
can't
even
change
something
it
becomes
difficult.
So
supply
chain
is
really
really
important.
It's
really
hard.
There
is
no
easy
ways
around
it,
but
the
main
things
is:
if
you
can
think
about
the
the
libraries
that
you're
going
to
bring
on
board
beforehand,
make
sure
that
you
kind
of
vet
it
or
there's
at
least
a
process
to
vet
those
libraries
before
you
bring
them
into
the
code.
B
And,
ideally
you
go
into
projects
that
are
a
bit
more
reputable,
but
that's
not
a
hundred
percent
guarantee,
but
probably
what
most
customers
do
in
order
to
tackle.
That
aspect
is
true
to
be
able
to
understand
the
dependencies
in
the
code.
No
know
what
you
have
ultimately
easier
said
than
done,
but
I
think
fatim
can
talk
to
you
about
what
are
some
of
the
possibilities
around
this
to
to
try
and
tackle
that,
and
the
final
challenge
that
I'm
going
to
talk
about
is
the
the
tooling
and
so
up
until
now.
B
I
didn't
really
talk
about
at
all
about
tooling
and
in
fact
I
always
think
that
tooling
is
kind
of
the
last
thing
that
you
need
to
think
about.
Even
though
we
are
a
technology
company
and
you're,
most
likely
using
our
tools
to
to
ship
software,
but
processing
and
people
is
really
important,
but
processing
people
again
without
the
right
tools.
B
A
Some
of
yeah-
that's
that's
true.
Some
of
them
might
have
multiple
tools
in
place,
but
the
thing
is
that
they
might
not
be
using
them
properly
or
it
might
be
that
the
security
team
only
has
access
to
these
tools
and
they're
not
giving
the
developers
any
access
to
get
the
results
straight
away.
So
it
might
be
that
they
they're
not
in
sync,
with
the
results
that
they're
getting
from
these
tools.
A
Sometimes
they
might
have
one
tool
in
place,
but
this
tool
is
providing
the
developers
with
the
feedback
straight
away
while
they're
developing,
and
they
might
be
picking
up
things
way
earlier,
and
that's
back
to
the
previous
poll
that
you
had
around
if
it's
reactive,
proactive
or
streamlined-
and
there
was
a
couple
of
things
in
the
chat
about-
is
github
vision
around
being
proactive
and
hybrid
between
proactive
and
streamlined,
which
is
exactly
what
we're
trying
to
do.
A
We're
trying
to
get
the
developer
involved
in
the
security
from
the
beginning
and
while
they're
developing
they
get
the
feedback.
The
same
way
that
they're
getting
the
feedback
from
their
ci
tool
or
from
other
things,
that
they're
using
within
their
development
but
and
the
23
minutes,
it's
so
true,
because
when
a
developer
is
writing
code,
it's
gonna,
take
them
sometimes
longer
or
sometimes
less
to
be
able
to
go
back
and
focus
on
what
they're
doing
so,
it's
really
hard
to
interrupt
them
somewhere.
A
B
Correct
and
and
by
the
way,
the
the
research
that
you
can
actually
google
it
by
gloria
mark
she's,
a
professor
in
the
department
of
informatics
in
university
of
california
interesting
article,
not
necessarily
specifically
about
software
security
or
or
just
software
development.
But
generally
speaking,
if
you
are
doing
something,
and
someone
comes
in
and
interrupts
you
you're
you're
gonna
take
23
minutes
to
get
back
into
the
routine
and
doing
what
kind
of
you
did
get
back
into
the
focus.
B
B
But
if
you're
earlier
than
yes,
we
used
to
have
those
those
basically
big
maps
of
paper
blocks
that
that
fat
and
reminded
me
earlier
where
you
were
driving
and
you
had
to
go
and
stop
kind
of
on
the
side
and
look
up
the
map
and
then
decide
where
you
want
to
go
and
then
at
some
point
in
the
90s
or
maybe
2000.
Really,
we
started
getting
gps's
on
the
on
the
phones,
but
you
still
needed
either
a
holder
by
the
way
those
holders
on
the
cars
they
never
work
anyway.
B
That
means
that
you
have
to
take
your
eyes
off
the
road
when
you're
driving
and
today,
if
you
think
about
it
most
kind
of
most
modern
cars,
maybe
they're
kind
of
the
top
of
the
rangers
coming
with
a
hub
display.
So
that
they
show
you
the
gps
coordinates
and
where
you
need
to
go
and
the
instructions
and
everything
in
front
on
your
windscreen,
so
you
don't
have
to
take
your
eyes
off
the
driving
and
you're
just
driving
and
so
that
that's
kind
of
the
same
analogy:
the
the
the
future
in
application
security.
B
A
That's
the
same
as
having
that
gps
built
in
in
the
car,
which
is
like
having
your
security
tool.
Your
code
scanning
built
in
with
your
development
tooling,
wherever
the
developers
are
using.
A
And
we're
up
to
our
next
poll,
so
the
question
is:
do
you
enable
developers
to
run
security
scan
autonomously?
So
let
me
open
the
phone
and
I
think
it's
open
now,
so
it's
either.
Yes,
the
developers
don't
need
to
contact
anyone
and
they
are
able
to
scan
by
themselves
or
it's
a
no
and
the
abstract
team
needs
to
be
involved
and
they
need
and
scanning
send
scanning
results
back
to
the
developers.
A
A
B
B
It
was
almost
ten
percent
nowadays,
there's
all
kinds
of
tools,
not
only
github
other
tools,
that
kind
of
enable
developers
to
do
the
scanning
and
then,
frankly
again,
you
cannot
afford
to
wait
until
the
last
minute.
Just
before
you
go
live
to
do
that
scan
and
so
a
lot
of
engineers
say
you
know
what
we
just
need
to
build
it
in.
We
need
to
do
it
for
ourselves
so
that
we
don't
get
a
surprise
in
the
last
minute
and
by
the
way
we
also
care
about
the
code
that
we're
right.
B
We
want
to
make
sure
that
it's
safe
that
it's
resilient
and
we
need
to
make
sure
that
we
do
something.
It
might
not
be
perfect,
but
hey
it's
better
than
nothing.
So,
there's
there's
a
lot
of
open
source
tools
in
your
community
and
also
commercial
tools
as
well.
That
have
advanced
quite
a
lot
from
10
years
ago.
A
A
B
And
I
think,
by
the
way,
it's
it's
always
important
to
to
include
the
application
security
team
in
the
scan.
The
question
is:
how
much
of
it
can
the
engineers
do
on
their
own
versus
relying
100
on
the
apsec
team,
and
I
think,
given
that
we
only
have
one
engineer,
security
engineer
to
500
developers
give
or
take,
you
cannot
be
reliant
like
they
cannot
be
the
bolt
neck.
This
is
just
the
future.
Is
it
you
just
the
math?
B
Cool
so
fat
and
over
to
you.
A
Thank
you.
I
thought
that
we
had.
It
was
a
great
session
talking
about
the
common
challenges
and
some
of
the
tips
and
tricks.
I
thought
I'll,
add
three
of
the
main
tips
that
came
to
mind
that
are
quick
to
configure
very
simple,
and
then
you
can
benefit
from
straight
away.
I'm
sure
that
some
of
the
audience
might
have
even
more
security
tips
that
they
would
like
to
share
with
us.
A
So
please
feel
free
to
add
them
to
the
chat
window,
but
the
ones
that
I
wanted
to
highlight
is
the
first
one
enabling
protected
branches.
So
once
you've
got
your
repo,
you
can
go
ahead
and
under
the
settings,
make
sure
that
you've
got
protected
branches
enabled
where
you
can,
for
example,
there's
lots
of
different
rules.
One
of
them
is
making
sure
that
at
least
you've
got
one
or
two
code
reviewers
who
will
check
your
request
before
it
gets
merged
into
the
main
branch.
A
The
second
one
around
dependable
we
saw
shlomi
spoke
about
how
the
modern
application
are
using
80
to
90
percent
of
open
source
libraries
and,
as
you
know,
github
is
the
home
of
open
source
so
making
sure
that
you've
got.
You
are
using
these
open
source,
libraries
or
projects
in
a
secure
way.
It's
very
easy,
very
simple,
to
make
sure
that
you've
got
dependable
alerts
enabled
at
the
organization
level
as
well
as
depend
about
security
updates.
A
So
around
dependable,
it's
going
to
tell
you
if
there's
any
outdated
library
package
that
you're
using
so
you
will
be
able
to
update
to
the
version,
that's
not
vulnerable
and
depend
on
what
security
update
will
give.
You
will
create
it's
a
bot
that
will
create
a
pull
request
for
you
that
will
help
you
guide
you
to
be
able
to
get
to
the
version.
A
That's
not
vulnerable
and
the
last
one
enabling
secret
scanning,
so
secret
scanning
is
enabled
by
like
on
public
reposits
by
default,
but
if
you've
got
github
advanced
security,
enable
secret
scanning
to
make
sure
there's
no
secret.
No
tokens,
no
password,
nothing
like
that
stored
in
your
repo.
So
these
are
my
three
quick
tips
that
I
wanted
to
share
with
you
today.
I
know:
there's
lots
of
other
tips
that
some
of
you
might
share.
B
I
just
I
thought
why
don't
I
finish
up
and
then
there's
there's,
probably
one
question
that
that
I'd
like
to.
I
know
we
answered,
so
we
tried
to
answer
all
the
questions
that
were
there.
If
you
feel
like
reaching
out
to
us,
we
can,
but
there
was
one
actually
really
interesting
question
that
I'd
like
to
do
but
kind
of
as
a
key
takeaway.
B
Really,
if
I
summarize
the
whole
discussion,
there's
a
lot
to
take
in
and
feel
free
to,
listen
to
this
again,
but
the
three
things
that
we'd,
like
to
to
focus
on
is,
first
of
all,
foster
think
about
an
experience
that
gives
the
developers
the
ability
to
run
security
on
their
own,
because
there
is
no
way
for
application
security
teams
to
do
it
on
their
own.
It's
just
not
gonna
happen.
You
don't
have
enough
of
them,
and
even
if
you
did
it's,
it's
gonna
be
too
slow.
The
second
thing
is
from
an
application
security
perspective.
B
You
have
to
in
a
way
almost
let
go,
engage
with
the
developers,
but
let's
go
and
give
the
trust
that
in
the
in
the
autonomy
that
engineers
will
do
the
right
thing,
but
also
retain
the
capability
to
verify
so
sort
of
a
trust
and
verify
model,
and
then
the
tools
are
important,
but
the
process
and
the
plan
around
it
are
super
important.
B
We
cannot
necessarily
comment
about,
what's
gonna
happen
or
not,
but
I
personally
think
that
has
a
huge
potential
to
not
not
incrementally
change
application
security
testing,
but
completely
turn
it
on
its
head.
Like
imagine
that
you
had
someone
sitting
with
you
kind
of
almost
like
an
ar
helper,
that
that
helps
you
bridge
the
570
engineers
to
one
security
expert
and
bridge
that
gap.
That
would
make
a
massive
difference
to
to
people
that
are
writing
code,
so
definitely
something
that
that
I
think
would
would
make
a
big
difference.
A
I
think
it's
going
to
be
there's
a
big
potential
to
help
as
well
developers
to
write
the
queries,
so
they
can
get
co-pilot
to
help
with
that
as
well.
A
Okay,
so,
before
we
wrap
today,
I
would
like
to
remind
you:
we've
got
another
session
happening
tomorrow,
overcoming
common
barriers
to
shipping
code
faster
at
the
same
time,
3
p.m.
Ast,
and
I
will
be
having
daniel
figure
and
adrian
joining
me
as
well
in
the
session
tomorrow,
so
make
sure
that
you
join
us
tomorrow
as
well
before
we
wrap
as
well.
I
would
like
to
if
you
can
please
take
a
minute
or
two
to
share
with
us
your
feedback,
so
you
can
scan
this
qr
code
or
we
can
as
well
use
it.
A
It's
a
very
short
survey
that
will
take
a
minute
or
two
to
tell
us
about
your
experience
today.
The
link
is
available
in
the
chat
window,
adrian
just
posted
it,
as
well
as
in
the
docs
tab
at
the
top
right
hand.
Side.
Thank
you
so
much
for
joining
us
today
and
hope
you
enjoyed
the
session
as
much
as
tommy,
and
I
did
thank
you
if
you
need.
Thank
you
very.
A
Deep
dive
session,
don't
forget
the
request
demo
button
at
the
top
right
hand,
side
thanks
to
me
and
thanks
thanks
a
lot
adrian
as
well,
for
monitoring
the
chat
window.