►
From YouTube: Supercharge the power of your security team
Description
At GitHub, we know that open source data empowers the entire software development industry. That’s why we open source much of our security data, including the GitHub Advisory Database and CodeQL queries. Join Shlomi Shaki, Application Security Executive at GitHub, and Brent Wagener, Field Security Specialist at GitHub, for an interactive forum on how to scale DevSecOps and reduce friction by using GitHub’s natively embedded security tools.
Stay up-to-date on all things GitHub by subscribing and following us at:
YouTube: http://bit.ly/subgithub
Blog: https://github.blog
Twitter: https://twitter.com/github
LinkedIn: https://linkedin.com/company/github
Instagram: https://www.instagram.com/github
TikTok: https://www.tiktok.com/@github
Facebook: http://fb.com/github
About GitHub
It’s where over 100 million developers create, share, and ship the best code possible. It’s a place for anyone, from anywhere, to build anything—it’s where the world builds software. https://github.com
A
A
In
my
experience
with
application,
security
and
application
development
is
about
20
years,
I
start
off
as
a
developer,
building
security
software,
so
software
used
by
organizations
to
secure
their
systems
and
eventually
moved
into
software
security.
Helping
companies
improve
the
security
of
their
software
overall,
so
I've
seen
I've
seen
it.
You
know
the
software
security
game
for
a
very
long
time
for
a
couple
decades
and
I'm
very
excited
to
to
have
this
conversation
today.
I'll
hand
it
over
to
shlomi
who
is
joining
me
today.
A
Okay,
thank
you
shlomi,
so
yeah
just
get
some
of
the
the
housekeeping
bits
out
of
the
way.
So
if
you
have
any
questions
there
is
a
q,
a
tab,
there's
a
text:
q,
a
and
there's
a
live
q.
A
let
me
just
make
sure
a
video
q
a
so.
If
you
have
any
questions,
go
ahead
and
put
it
in
the
Q.
A
the
chat
is
for
any
sort
of
any
questions
you
may
have
about
how
to
use
the
system.
A
A
You
know:
video
conferencing
troubleshooting
snaps,
if
you're
still
having
trouble
under
the
docs
tab
on
the
right
there
is
a
troubleshooting
guide.
So
please
refer
to
that.
You
know
this
will
be
an
interactive
session.
We
do
hope
that
we
can
get
people
up
on
stage
with
us
to
share
their
experiences.
A
A
A
Yeah,
so
it
looks
like
the
poll
is
going
so
here
this
is
just
a
fun
poll.
Would
you
rather
fight
since
duck
size,
horses
or
one
horse-sized
duck?
It's
not
application.
Security
related
I
just
want
to
make
sure
people
are
connecting
and
everything's
working.
As
expected,
we
are
getting
a
few
votes
in
I'll.
Just
leave
it
for
another
five
seconds,
just
to
see
how
things
go
and
it
looks
like
we're
about
I,
don't
know.
Even
so
I
guess
that's
a
good
sign.
It's.
A
All
right
well,
thank
you,
so
it
looks
like
everything's
working
I
think
we'll
go
to
our
first
topic,
which
is
just
around
the
the
state
of
security
in
general,
so
in
shlomi
I'd
just
like
to
ask
for
your
thoughts
on
you
know.
What
do
you
think
is
the
overall
state
of
security,
not
just
application
security,
but
just
in
general
in
the
cyber
security
realm
Market.
B
And
by
the
way,
before
I
get
to
that,
we
have
28
votes
to
dock
size.
The
horses
and
the
vast
majority
is
whole
sized
duck,
so
I
think
that
wins,
but
from
a
cyber
security
perspective,
I
think
it's
look.
It's
been
challenging.
We
we
hear
a
lot
about
different
breaches
out
in
the
media
and
I
still
think
a
lot
of
the
kind
of
the
the
incidents
happen
due
to
simple
phishing
attacks,
and
so
so
we
kind
of
hear
about
that,
and
often
that
is
kind
of
the
entry
into
organizations.
B
But
but
generally
speaking,
cyber
security
is
difficult,
because
the
attackers
ultimately
have
a
mission.
They
they
have
a
goal
and
they
have
the
best
tools
they
are
well
equipped.
They
have
really
good
knowledge
around
what
they
need
to
do
and
ultimately
they
have
to
be
right
only
once
they
have
unlimited
attempts
and
once
is
enough
for
them
to
get
in
when
the
Defenders
have
a
much
harder
Challenge
on
their
hands.
A
Yeah
I
mean
I
agree,
so
the
limited
resources
I
think
that's
something
I've
seen
since
you
know
for
for
for
many
many
years,
I
mean
forever,
and
you
know
particularly
around
cyber
security,
I,
think
a
lot
of
the
resources
have
been
going,
some
more
of
the
reactive
side
of
cyber
security,
so
incident
response
and
security
operations,
centers
monitoring
tools
and
I.
Think
a
lot
of
organizations
have
a
lot
of
good
visibility
on
their
overall
environments
and
security
posture.
A
B
One
more
thing,
I
think
I
mentioned
fishing
attacks
and
again
application
security
is
very,
very
difficult.
It's
probably
very
challenging,
but
still
you
know,
phishing
attacks
is
the
easy
way
in.
For
those
who
don't
know,
we've
actually
just
made
it
mandatory
to
use
multi-factor
authentication
to
help
reduce
I,
guess
the
the
chance
of
it.
A
B
Yeah,
that's
that's
a
good
question
and
and
largely
to
be
fair.
I
mean
I've
been
an
application,
is
good,
probably
for
about
10
years.
I
haven't
we're
still
dealing
with
the
same
challenges.
We
still
see
some
of
the
the
same
issues
that
we've
seen
10
years
ago.
It's
just
that
today,
the
velocity
of
software
is
much
faster.
B
We
deal
with
a
lot
of
more
Partners,
there's
a
lot
more
apis,
there's
a
lot
more
software
that
is
being
developed
and
much
faster
as
well,
and
the
solutions
I
guess
that
we
came
up
with
over
the
last
10
years,
haven't
really
changed
much
it's
it's
been,
let's
put
a
developer
through
some
training
upfront
when
we
onboard
them
for
four
or
five
hours.
Usually
they
just
click
next
next
next
and
then,
hopefully
they
retain
some
of
it
and
then
don't
get
me
wrong.
B
It's
really
important,
but
the
the
challenge
is
once
you
actually
do
that
often
they're
going
back
into
kind
of
the
day-to-day
activities
and
they
have
to
deal
with
engineering
whilst
they
have
to
deal
with
milestones
and
all
this
stuff,
and
so
so
that
becomes
really
difficult
and
then,
finally,
we
kind
of
run
some
security
tools,
often
after
the
fact-
and
we
tell
the
engineers
that
they
haven't
done
the
right
thing,
and
so
so
I
think
that
is
a
challenge
and
honestly,
we
need
a
better
way.
We
need
a
different
way.
B
A
A
And
then
you
know
maintaining
you
know
after
it's
already
been
put
into
production,
but
I
think
the
one
area
that
never
really
got
that
much
attention
was
the
coding,
part
and
and
I
think
at
the
time
it
was
mainly
because
of
tools.
You
know
the
tools
just
weren't
as
mature
as
they
needed
to
be.
There
were
a
lot
of
false
positives
developers,
just
basically
said
notes
and
to
all
of
them
and
I
actually
think
that
a
lot
of
the
organizations
I
see
today
are
kind
of
still
in
that
same
phase.
A
They
do
it,
they
do
sort
of
risk-based
penetration
testing
for
their
most
critical
applications.
They
may
do
some
sort
of
like
outsourced
code
reviews
or
maybe
some
limited
code
reviews,
but
yeah
I,
think
I.
Think
the
code
controls
the
code
level.
Controls
are
still
still
a
lot
of
room
for
improvement.
A
D
Yeah
so
I'm
called
cornford
I'm,
the
founder
of
a
application,
Security
consultancy
in
Sydney,
Australia
so
being
around
the
bush
for
a
little
bit
helps
poke
out
with
building
application,
Security
Programs
across
governments
and
telcos
and
big
Banks,
and
so
on.
Around
Australia,
so
yeah
happy
to
jump
on
give
some
thoughts,
so
I
think
the
the
topic
we're
talking
about
shlomi
was
about
what
are
we
seeing
as
the
current
state
of
appsec
right.
B
D
Yep
so
I
think
it
that's
like
basically,
two
kind
of
ecosystems
that
we
operate
with
a
lot
is
the
startup
and
scale
up
ecosystem
and
the
big
Enterprise
ecosystem
and
I
think
we've.
They
both
have
very
different
challenges,
because
the
startup
scale-up
ecosystem
is
how
do
we
enable
ourselves
to
be
secure
while
also
getting
to
Market
quickly
and
not
wasting
time
on?
You
know
all
these
other
things
that
we
need
to
care
about
and
I
think
the
good
thing
about
that
kind
of
ecosystem
is
platform
engineering
patterns
having
a
paved
Road.
D
All
those
kind
of
approaches
that
you
see
over
in
the
US
they
work
really
well
there.
You
can't
take
those
kind
of
approaches
and
put
them
into
a
big
Enterprise
scenario,
so
we
I
think
that
if
the
the
real
area
within
Australia,
it's
really
problematic
is
how
do
we
go
about
dealing
with
big
companies
that
have
large
Legacy,
Tech
bases
and
moving
them
onto
a
devops
journey?
So
they
can
start
implementing
app
set
controls
throughout
the
stlc.
B
D
Yeah
so
shift
I
find
shifting
left.
Is
it's
a
bit
overused
lately?
You
know
back
in
the
day
when
we're
talking
Chef
left,
it
was
always
like.
Oh
yeah,
you
know.
If
you
fix
something
early,
then
it's
gonna
be
like
so
much
cheaper
to
fix
it
than
like
later
on
in
the
life
cycle
right,
but
we're
in
a
world
where
devops
enables
us
to
be
deploying
code
like
20
to
30
times
per
day
right.
D
So,
if
you're
doing
something
like
that,
the
the
cost
of
making
a
change
is
actually
pretty
small
overall
right,
so
the
cost
benefit
of
Shifting
to
the
left.
For
a
lot
of
these
things,
is
it's
not
that
much,
but
at
the
same
time,
I
also
think
that
if
you
shift
too
far
to
the
left,
then
you're,
basically
slowing
Engineers
down
and
making
them
focus
on
like
Tour
results
and
stopping
them
from
being
able
to.
D
You
know
just
build
features
proactively,
so
I'm,
a
big
fan
of
when
we
do
think
about
the
concept
of
shift
shift,
left
thinking
about
architectural
patterns
and
like
creating
Pathways
for
people
to
move
forward
with
that,
like
a
pave
Road
on
getting
the
yes,
that's
what
I
think
if
you
have
to
move
off
of
this
road,
then
you
need
to
think
about
it's
going
to
be
slow.
It's
going
to
be
bumpy
you're
going
to
have
to
have
all
these
different
types
of
Security
checks
in
place.
D
But
if
you
stay
on
the
road,
that's
the
highway,
let's
get
you
to
prom
and
I'm,
seeing
a
lot
of
the
bigger
institutions
think
about
how
do
we
get
there
and
edit
GitHub
certainly
enables
that
with
actions
and
the
GitHub
Advanced
Security
Suite,
but
yeah?
It's
it's
an
interesting
Journey!
It's
it's!
It's
good
to
go
along
this
way
from
what
I've
seen
in
the
past,
where
we've
got
you
know
stage
Gates
blocking
everyone
moving
the
prod
so.
B
E
Yes,
cinnamon
is
Peter
Freiburg
application
security
consultant
also
from
Australia,
so
I
know
Cole
and
Swami
for
a
for
a
bit
of
a
time.
But
yeah
worked
in
a
lot
of
banking
in
large
corporates,
Rolling
Out,
appsec
programs,
folks
around
Automation
and
so
forth.
So
yeah
I
thought
I'd,
probably
piggyback
on
some
of
those
topics,
and
is
that
if
that
works,
for
you
guys
yeah.
A
B
One
one
question
that
I
think
one
question
that
I
always
had
a
challenge
with
in
application:
security
is
who's
really
more
responsible
for
application.
Security
is
engineering
or
security
Now.
Obviously,
in
a
in
a
Ideal
World,
we
want
to
do
both
well,
both
of
them.
Everyone
is
responsible
for
it
or
just
like
our
ciso
says.
Everyone
basically
is
on
the
security
team,
but
if
you
have
to
choose
one
who
would
it
be?
So,
let's
we've
opened
the
poll
who
should
be
more
responsible
for
application
security.
A
B
B
B
B
E
D
D
I
think
this
is
interesting
in
my
experience.
A
lot
of
Engineers
just
say
straight
away
that
this
is
a
security
responsibility,
because
the
security
should
be
outlining
what
we
need
to
do
as
Engineers.
Well,
we
need
to
the
policies,
the
procedures
and
the
processes
that
we
need
to
follow
so
that
we
build
applications
in
a
secure
way
and
I
tend
to
agree
with
them,
but
because
the
problem,
but
the
problem
we
have
in
the
Market
at
the
moment,
is
that
very
few
Security
Professionals
are
trained
software
Engineers.
D
So
the
thing
I
like
to
see
is
when
you
get
security
folk
who
are
trained
software
Engineers
as
either
satellite
resources
in
teams
or
at
least
working
within
a
platform
or
security
function,
to
build
components
that
Engineers
consume,
because
if
you
are
building
a
logging
framework
as
a
security
team-
and
you
tell
all
your
engineering
teams
that
they
have
to
use
this
login,
it
goes
back
to
that
pay
for
Road
idea
right
if
you've
got
an
authentication
function,
that's
built
by
a
software
engineering,
security
team
and
everyone
must
use
this.
Then
you
know
that
It.
D
Ultimately,
this
is
account
the
responsibility
of
the
security
team
to
provide
a
really
important
piece
of
infrastructure
and
as
a
developer,
you
don't
need
to
stress
about
knowing
all
this
kind
of
stuff
right,
but
at
scale.
This
is
really
difficult
to
do
and
you'll
see
Mish
Master
Solutions
all
over
the
place
because
of
it.
B
E
I
I
think
when
you
say
a
large
organization,
it's
not
at
an
organization
level,
it's
at
a
team
level
or
maybe
even
a
division
level
that
this
sort
of
works
at
so
I
think
we
say
a
large
organization.
If
they've
got
5
000
developers,
it's
real
unrealistic
to
think
you
can
uplift
5
000
people
at
the
same
time,
so
I
think
when
I
just
didn't
go
on
what
Carl's
saying
there
are
different
aspects,
whichever
application
security.
E
So
you
should
be
logging,
then
you
need
a
centralized
logging
platform
for
developers
to
consume
and
use,
but
they
might
not
be
able
to
spin
that
up
themselves.
So
there's
one
aspect
there,
but
coming
back
to
I,
guess
the
developer
and
the
security
champions
I
think
there's
actually
a
crossover
I
think
Carl
mentioned
this
before.
If
you've
got
a
really
good
Tech
lead,
they
will
understand
the
technical
impacts
of
security.
So
uplifting
someone
like
that
to
understand
it.
You
don't
necessarily
need
to
have
a
security
Champion.
E
It
may
be
that
your
good
tech
leads
are
already
that
person.
So
how
do
you
actually
collaborate
with
them?
And
that's
maybe
more
of
the
SME
approach
that
you've
got
someone
who's
really
good
at
code
reviews
working
with
tech
leads
and
I.
Don't
think
you
necessarily
need
to
Define
them
explicitly
that
you've
got
a
security.
Champion
you've
just
got
someone
who
can
liaise
with
smes
as
you
need
it,
and
thinking
of
it
almost
in
am
database
mode.
E
So
that's
why
it's
tricky
because
you
go
a
team
might
be
awesome
in
one
division:
same
technology
stack
somewhere
else
with
different
management.
Different
motivations
may
actually
have
a
completely
different
security
outcome
based
on
that
team's
capability.
So
I
don't
want
to
answer
your
questions
for
me
other
than
it's
almost
it
depends.
I
live
around
the
company,
but
I
think
it's
actually
focusing
on
the
capabilities
versus
a
specific
label.
If
that
makes
sense,.
A
I've
started
to
jump
in
I'm,
going
to
add
another
person
to
the
the
stage.
If
that's,
okay,
absolutely
and
I'll
just
say
before
before
you
introduce
yourself.
Let's
say
you
know:
people
are
waiting
on
the
video
q.
A
I
am
keeping
my
eye
on
it,
so
yeah
I'm,
just
looking
for
a
good
time
to
jump
in.
So
that's
that's
all.
B
C
C
A
And
a
question
from
the
Q
a
for
the
panel
here
somewhat
related:
this
is
from
n
Stevens.
How
do
you
go
about
challenging
business?
Stakeholders
is
poor
understanding
of
security,
best
practices
when
you're
implementing
security
features
I'll
just
throw
that
out
there.
This
is
from
the
audience
honestly.
B
After
so
so,
I'll
I'll
do
something
short
and
then
I'll,
let
you
guys
also
add
on
to
it,
but
in
over
so
so
I've
been
doing
security,
Hands-On,
I,
started
actual
insecurity
and
so
on,
and
then
I've
done,
probably
about
10
or
12
years
for
the
last
last,
the
last
12
years,
working
with
different
customers
about
it-
and
this
is
probably
one
of
the
number
one
challenges
in
our
industry.
A
lot
of
people
are
coming
from
security.
B
They
love
kind
of
the
the
area,
they
love
the
technology,
they
love
the
element,
but
often
they
we
lack
the
ability
to
communicate.
Clearly
what
is
the
value
of
security
and
it's
it's
it's
difficult,
and
everyone
knows
what
the
value
of
security
and
when
something
happens,
when
you
have
a
bridge,
it's
easy.
B
What
are
the
ramifications
of
not
doing
enough
of
their
controls
and
what
are
the,
what
and
also
basically
being
really
clear
to
I
think
the
board
members
and
and
down
what
are
the
activities
that
we
can
do
within
reason
to
reduce
that
risk
that
that's
my
kind
of
thought
process
rushan.
Do
you
have
any
any
thoughts
about
this.
C
B
You
Peter:
what's
your
thoughts,
I
mean
I,
know.
I,
know:
you've
worked
with
a
number
of
organizations
to
help
them
figure
out
how
to
get
more
stake,
I
guess,
stakeholders
to
approve
and
also
put
the
funding
around
application
security.
What
would
you
recommend
customers
when
they
thinking
about
or
people
when
they're
thinking
how
do
I
actually
go
and
get
more
funding
to
put
more
people
in
application
security
and
get
the
more
the
you
know
more
education,
more
tooling?
What
would
you
recommend
them
to
do.
E
Yeah,
okay,
so
there's
there's
a
couple
things
which
are
unfortunate
realities,
I've,
seen
a
lot
of
programs
be
kicked
off
by
breaches,
so
the
funding
comes,
like
you
said
after
the
facts,
something
bad's
happened.
How
do
we
stop
that
from
happening
again?
I
think
a
lot
of
compliance
falls
into
that
bucket.
I.
E
The
CSO
says
everyone
should
be
doing
this
by
six
months.
Time
and
I
think
that
drives
the
behaviors
for
organizational
rollout,
I.
Think
back
to
coalsing
before
when
you
talk
about
shift
left
early
adopters
will
always
do
this.
They'll
always
grab
the
latest
tech
make
their
process
better.
Then
you've
sort
of
got
that
early
majority
or
what
is
the
the
early
adopters
and
then
the
and
then
the
the
middle
and
then
you've
got
laggards
and
I.
Think
it's
important
to
look
at
that
that
not
everyone
is
devops.
E
So
how
do
you
roll
out
for
different
modes
of
delivery,
but
with
different,
if
you
like,
focuses
on
how
they
actually
deploy
code?
So
if
someone's
still
doing
annual
maintenance
releases,
it's
very
hard
to
get
them
to
uptake
new
ways
of
working,
so
mandates
are
good,
but
just
bearing
a
minor
tape
might
take
a
year
or
two
and
then
I
think
the
other
thing
about
to
your
point
showing
about
funding.
It
is
really
about
looking
at,
what's
cost
effective
to
get
that
outcome
and
I
think
we're
asking
a
lot
of
platform.
Consolidation.
E
F
Yeah
I'm
I'm
from
Wipro
I'm
handling,
devsec
Ops
for
the
internal
Enterprise
GitHub
Azure
devops.
It's
a
very
large
Enterprise
platform
that
I'm
handling
shift
left
is
what
I
was
interested
in
and
I
wanted
to
jump
in
there.
We
do.
You
know
SAS
the
dust
end-to-end
in
cicd
pipelines
we
are
trying
to
because
we
have
a
large
platform.
We
try
to
adopt
as
much
as
possible
on
the
shift
left
side.
I
I
do
agree
with
the
whole.
F
You
know
there
are
plus
and
minuses
on
when
we
do
that,
but
for
a
larger
Enterprise,
when
we
have,
you
know
in
the
same
vertical
700,
800
000
developers,
which
are
under
one
Security,
Group.
Okay,
what
I
wanted
to
just
point
out
when
I
wanted
to
come
into
this
discussion?
Was
one
I
wanted
to
point
out
to
us
on
the
Lighter
Side.
You
gave
an
option
of
the
responsibility
of
developers
and
security
team.
We
should
have
a
third
option.
F
You
know
tools
and
processes
right,
so
the
tools
like
automation
on
the
pipelines
and
that
should
be
there.
It
should
be
mandatory.
That's
one
thing:
people
try
to
jump
lines.
Okay,
by
saying
things
are
delaying
which
Cole
was
might
have
tried
to
say
that
okay
developers
are
not
really
your
might
be
getting
out
of
focus
on
developing
features
and
then
trying
to
do
this
additional
things,
but
that
is
required.
Okay
as
part
of
the
security.
That
is
one
thing.
F
Second
thing
is:
if
real
simple
shift
lefts
are
done,
like
you
know,
moving
from
SAS
scanning
on
the
pipelines
than
to
have
IDs
integration,
and
you
know
on
every
commit
and
things
like
that.
That
will
resolve
a
lot
of
problems.
80
percent
of
real,
you
know,
I'm
not
talking
about
false
positives,
but
the
real
vulnerabilities
will
be
resolved
at
that
that
side.
So
I
just
wanted
to
ask
all
again
on
on
that
part
of
the
of
your
thought:
I'm
not
saying
that
I'm
against
this
I
actually
wanted
it
to
adapt.
F
But
I
know
there
is
a
balance
between
how
much
left
shift
you
can
do
and
not
just
left
shift
I'm
a
little
new
to
the
term
left
shift.
I
just
know
that
it
has
to
be
done
early.
So
what
are
the
other?
Some
more
ideas
about
left
shift
and
early
mitigation
of
the
risk
is,
is
what
I
wanted
to
ask,
and
this
is
my
take
because
we
are
doing
it
at
a
very
large,
Enterprise.
Okay,
we
are
now
adapting
GitHub.
B
I'm
just
going
to
basically
say
one
thing
and
then
I'll
pass
on
to
your
call,
I
I
think
look
on
paper.
It's
it's
a
great
idea.
Why
don't
we
do
everything
on
the
idea
in
reality,
what
we
find
is
that
if
you
do
a
lot
of
scanning
on
the
IDE
or
one
you
don't
have
a
lot
of
contacts
and
two
you
might
throw
so
many
things
on
the
developer
and
you're
going
to
distract
them
and
ultimately
think
about
this
way.
B
If
you
have
to
choose
if,
if
I'm
an
engineer-
and
anyone
can
maybe
disagree
with
me,
but
if
I'm
an
engineer,
my
first
priority
is
to
cut
code
that
is
going
to
work
and
sometimes
I'm
cutting
code.
That
is
not
even
you
know.
It's
not
production,
I'm
just
doing
a
POC.
So
if
I
worry
about
Security
First,
it's
just
not
realistic.
My
first
priority
is
get
the
functionality
right
make
something
that
works
now,
if
you're
running
it
in
the
ID,
you
might
distract
the
developer.
B
C
D
At
being
able
to
do
partial
analysis
of
code
results
right,
they
usually
try
to
take
the
entire
ecosystem.
I.
Don't
think
that
that's
very
helpful
if,
like
an
engineer,
is
trying
to
do
something
and
then
they
want
to
run
a
scan
to
see
if
they've
made
a
like
introduced,
a
security
for
and
even
if
you
try
to
use
the
more
simpler
ones
that
aren't,
as
you
know,
exact
they're,
going
to
just
find
a
lot
of
false
positives
and
noise
and
I.
D
If
you
have,
if
you're
an
engineer,
and
you
have
a
thousand
things
pop
up
saying
that
you've
got
tabs
here
instead
of
spaces.
Next
to
it
is
you're
using
parameterized
queries
in
the
wrong
place
and
then
you've
got
to
you
know:
you're
going
to
be
overwhelmed,
you're
going
to
have
alert
fatigue,
and
that
scares
that
scares
a
lot
of
people,
and
you
just
don't
want
to
participate
in
that
so
yeah.
You
can
introduce
these
in
CI
itself
and
I
think
that
shifting
left
it
does
make
a
lot
of
sense.
D
If
you
choose
like
the
right
types
of
technologies
that
mitigate
entire
classes.
But
if
we're
going
to
be
looking
at
using
IDE
scanning
I
would
make
sure
that
you
have
an
appsec
expert
jump
in
and
the
very
first
thing
they're
going
to
be
doing
is
tuning
this
scanner
for
the
res,
the
environment
that
the
engine
is
operating
in,
so
that
what
they
get
is
high
signal
vulnerabilities.
Does
that
help
answer
your
question.
F
To
this
topic,
yes,
what
you're
saying
is
correct,
but
there's
always
a
fight
between
the
engineer
and
the
people
who
are
identifying
false
positives
and
so
on.
I'll
give
my
example,
wherein
you
know
when
the
vulnerability
scan
happens.
There
are
thousands
of
false
positives
just
because
there
are
Library
version
restrictions
and
so
on.
As
an
example,
we
use
angular
okay
in
many
of
the
applications
in
the
front
end,
and
there
are
certain
libraries.
C
F
You
know
just
at
that
point
of
time
or
for
some
time.
Okay,
then
there
is
a
tussle
between
these
two
parties
on
whether
it
can
go
okay,
it
can
be
marked
as
a
risk.
So
this
is
the
point
wherein
I
was
saying
if,
if
this
was
a
left
shift
shift
left
and
it
could
have
been
understood
at
the
beginning-
and
there
was
a
compromise,
as
you
said,
you
know,
the
tool
can
be
taught
a
little
bit
better
again.
I
would
ask
a
practical
example:
how
to
teach
the
tools
a
little
bit
more.
F
B
E
Just
I
guess:
there's
a
few
things,
because
I've
heard
the
false
positive
argument
for
as
long
as
I've
been
using
SAS
tools,
which
is
15
years
right,
so
I
think
it's
accurate
in
some
ways,
but
there's
probably
a
few
things.
We
need
to
think
about
one
consider
the
scope
of
what
you
actually
want
to
scan
and
look
at
I.
Remember
asking
this
for
one
of
the
banks:
I
worked
with
what
would
actually
cause
a
step.
E
One
incident
command
injection
SQL
injection
are
probably
it
so
if
you
want
to
ignore
a
whole
lot
of
other
bunch
of
classes,
which
is
what
Cole
was
talking
about
before
start
your
process
on
your
minimum
gate
is,
we
should
have
reviewed
and
actually
tune
the
results
for
two
vulnerability
classes
that
are
Heavy
Hitters.
That's
what
the
developers
can
then
focus
on,
and
your
security
team.
If
they're
doing
some
sort
of
analysis
can
look
at
the
broad
amount
of
it.
Some
of
the
tools
used
to
do
this.
E
They
had
a
developer
View
and
then
they
had
the
security
auditor
view.
So
this
has
been
around
for
a
little
while
so
figure
out
what
is
actually
most
important
for
you
and
some
of
the
customers.
We've
worked
with.
We
had
triage
guidelines,
you're
a
tier
one
app.
You
should
triage
these
vulnerability
classes
and
then
once
you've
done
that
they
will
not
appear
in
the
next
scan
because
you've
already
triaged
them
and
there's
comments
as
to
whether
it's
a
false
positive
or
not.
So
it
is
a
bit
painful,
but
that's
one
thing
around
the
false
positives.
E
The
other
one
I
wanted
to
talk
about
IDE
tools
as
well.
Having
worked
in
organizations
with
massive
diversity
of
tech
stack,
not
all
idea
is
supported
and
also
going
on
what
Cole
said.
If
you've
got
an
old
Tech
stack
and
it's
running
I
don't
know:
I've
worked
on
applications
that
are
classic
ASP
for
10
years.
E
You
can't
use
a
newer
developer
IDE
and
you
can't
use
a
newer
framework
unless
you
read
available
thing
the
whole
stack,
so
there
are
some
times
you
just
have
to
deal
with
that
so
and
it's
not
right
and
or
wrong,
and
the
other
probably
last
points
are
end
up
in
so
there's
a
comment
there
from
Sharp
is:
there
are
some
things
that
are
vulnerable,
but
not
exploitable,
and
this
comes
into
your
wrist
triage
process.
You
may
have
a
library
that
is
vulnerable.
You
mentioned
that
before
with
either
angular
or
so
on.
E
Are
you
using
a
vulnerable
method
which
would
then
make
it
exploitable
and
that's
part
of
your
risk
management
process?
There
is
no
silver
bullets
for
this,
but
there
is
a
bit
of
process
for
then
assigning
and
tracking
things
that
could
be
an
issue
and
then
being
able
to
track
what
is
not
an
issue
for
this
release
and
that
I
think
is
where
a
lot
of
the
tools
have
suffered
from
being
able
to
put
that
Fidelity
around
that
information
to
actually,
you
know,
have
a
release
rather
than
if
it's
a
risk.
C
C
A
Thank
you.
Thank
you.
Just
moving
on
to
the
next
topic.
I
want
to
talk
about
secrets.
So
shlomi,
you
know,
I
think
this
is
a
fast
growing
attack.
Vector
I
think
it
might
even
be
the
the
largest
attack
vector
and
we
see
more
and
more
stories
about
public
Secrets
being
publicly
available
and
compromised.
So
you
know,
can
you
talk
a
little
bit
about
I?
Guess
the
state
of
of
this
area.
B
Yeah
absolutely
so
I
think
in
recently,
I've
mentioned
it
in
one
of
the
other
security
forums
that
we
had.
But
if
you
look
at,
if
you
look
at
a
lot
of
the
breaches
out
there
they're
not
using
very
sophisticated,
you
know:
SQL
injection
cross-site,
scripting
Etc,
even
though
it
does
happen,
it's
much
easier
to
log
in
and
steal
credentials
and
log
into
infrastructure.
And
obviously,
when
you
put
username
password,
you
can
use
MFA
and
so
that
there
are
ways
to
at
least
try
and
protect
with
it.
B
But
secrets
in
the
code
is
is
something
that
is
is
easy
for
attackers
or
it
yields
a
high
return
on
the
investment
that
they're
gonna
make.
And
so
it's
enough
that
a
developer
is
going
to
go
and
clone
the
repo
into
a
public
repo
by
mistake
or
because
they
want
to
work
on
it
at
home.
Not
not
maliciously,
just
as
an
accident
or
in
fact,
not
even
by
accident.
They
just
want
to
do
their
job
and
it's
just
an
easier
way
for
them
to
do
it.
B
There
was
a
multi-factor
authentication
actually
and
they
used
a
multi-factor
authentication
exhaustion
attack
on
one
of
the
suppliers
once
the
attacker
managed
to
get
in.
They
found
the
Powershell
script,
which
really
is:
is
that
kind
of
code
that
your
developers
are?
Writing?
No,
it's
kind
of
one
of
your
systematics
might
be
using
and
in
that
Powershell
script
it
had
a
token
to
the
privilege,
access
management
solution
so
that
that
is
really
critical
and
the
impact
is
going
to
be
YouTube.
B
B
As
part
of
your
development
life
cycle
by
introducing
those
kind
of
things
into
things
like
copilot,
so
as
an
example,
get
up,
co-pilot
now
has
a
way
to
look
at
and
and
try
and
identify
certain
hard-coded
passwords
so
that
when
the
developer
is
writing
think
about
like
almost
like
a
personal
assistant
where
they
actually
help
the
developer,
identify
those
issues
before
you
even
put
it
into
a
commit
or
push
it
into
the
repository.
So
that's
my
personal
kind
of
opinion
of
ID
scanners
versus
something
else.
Peter
go
ahead.
It.
E
I
think,
hopefully,
two
quick
ones.
So
one
thing
I've
seen
a
couple
of
breaches
and
compromises
are
forking
forking
of
repos
across
things
say
folks
are
public
and
they
remain
public.
Then
people
actually
change
a
config
file
and
put
a
password
in
it
right.
So
that's
some
and
people
just
don't
think
about
it.
When
it's
happened
so
I've
seen
that
a
couple
of
times
they've
forked
it
for
some
reason,
just
forgetting
the
context
of
it's
remaining
public
right.
E
So
there's
a
little
bit
of
just
understanding
that
and
that's
also
part
of
how
you
might
configure
your
repos.
Do
you
even
allow
forking
so
there's
some
setup
there,
the
other
one
too,
is
around.
We
talk
about
patterns,
but
in
large
orgs,
it's
like
where,
where
do
you
store
secrets
so
yeah?
Some
people
will
have
the
AWS
stuff,
there's
the
GitHub
secret
stuff.
They
might
have
hashy
court
Vault.
That
could
be
platform,
specific
things
and
I.
Think
that's
where
back
to
clothing.
Blessed
path
is
like.
E
Here
is
three
ways
of
actually
storing
secrets
and
I.
Think
the
stuff
that
you're
talking
about
salami
is:
do
we
have
Push
protection,
so
the
secret?
Never
makes
it
into
the
repo
if
it
is
in
the
repo
do
we
know
how
to
actually
check
that
it's
now
not
compromised
was
that
production
do
we
have
a
process
around
it?
C
So,
just
to
add
there,
like
it's
it's
fun,
to
talk
about
this
topic,
because
this
was
one
of
the
topics
that
we
very
recently
tackling
in
our
organization
as
well
and
and
the
thing
about
secrets-
and
this
is
also
for
the
audience
who
is
here.
Other
thing
about
Secrets
is,
if
you
add
it
to
a
commit
and
if
it
somehow
reaches
the
internet,
there's
no
way
for
you
to
go
and
change
back
the
history.
C
So
the
only
way
to
tackle
that
is
to
revoke
the
tokens
or
the
passwords
that
you
already
have
now
again.
I
I
completely
like
the
idea
where
GitHub
is
working
on
work,
the
code
never
or
the
secret,
never
making
it
to
the
depot,
which
is
very
important
because
I
mean
most
of
our
organizations.
Bug
bounties
are
also
from
these
secrets
right
and
we
we
do
have
some
really
good
stories.
C
I'm,
not
sure
how
much
of
it
I
can
tell,
but
of
where
a
secret
book
was
never
meant
to
be
be
published
and,
and
surprisingly,
it
was
again
it's
it's
not
always
malicious.
Rather
it's
more
of
a
common
mistake.
So
these
guidelines,
which
are
put
in
and
especially
with
the
push
protection
and
things
it's
it's
really
good,
because
it's
one
of
the
most
like
it's.
It's
not
primarily
a
mistake,
but
it's
more
of
a
easily
done
mistake
that
that
is
happening
throughout
the
tech
industry.
C
So
as
long
as
there
is
a
good
set
standard
in
an
organization
that
we
use
this
one
tool
to
store
secret,
it
makes
it
easier.
But
yeah
I
mean
it's
it's
one
of
the
things
that
even
if
you're
starting
now
in
your
organization,
I'm
sure
there
would
be
at
least
100
plus
tokens
that
are
out
there,
that
we
need
to
identify
First
and
remove
which,
of
course,
we
are
doing
as
well.
D
A
B
A
E
D
E
Back
to
a
lot
of
organizations,
I've
worked
in,
they
haven't
had
a
choice.
It's
like
I,
don't
have
like,
if
you
think,
pre
AWS,
secret
storage
or
GitHub
Secrets
they,
where
did
you
put
them?
It
was
in
the
Ops
Team,
who
actually
then
put
the
credentials
in
the
payload
for
production,
so
I
think
there's
actually
a
design
pattern
issue
here,
depending
on
when
which
goes
back
to
the
easy
thing,
but
I
I
think
when
an
app
was
built
10
years
ago.
It's
a
different
conversation
too.
If
you
built
an
app
today.
B
B
You
now
that
when
we,
when
we
started
with
secret
scanning
as
an
example
to
to
offer
it
and
and
organizations
implemented
it,
what
we
found
is
that
initially,
even
though
we
scan
for
for
secrets
and
we
identify
those,
we
found
that
people
didn't
actually
fix
it
and
when
we
went
back
and
started
doing
a
poll
and
basically
surveys
with
the
people.
As
you
look,
we
told
you
kind
of
even
in
the
push
protection
that
you're
about
to
enter
a
secret
into
your
code
about
to
push
it.
B
Why
did
you
not
kind
of
get
rid
of
it
and
the
answer
was
we?
We
actually
didn't
know
how
to
fix
it.
So
exactly
to
what
you're
saying
Peter
often
people
know
that
they
probably
shouldn't
do
it,
but
they
don't
know
what
the
way
the
right
way
is,
and
so,
interestingly
enough,
in
the
secrets
we
we
kind
of
now
starting
to
put
some
guidelines.
B
So
when
it
at
least
when
it
tells
you
that
you're
about
to
push
a
secret
into
into
the
code,
it
will
give
you
some
high
level
guideline
which
can
be
edited,
but
at
least
it
gives
the
developer
some
form
of
I.
Guess
awareness
at
that
point
in
time
of
what
is
it
that
they
need
to
do
to
to
not
make
that
mistake,
so
we're
trying
to
make
it
easy
for
them
to
do
the
right
thing
and
I
think
that
is
really
kind
of
the
Crux
of
application
security.
B
It's
about
what
I'm
seeing
is
developers
want
to
do
the
right
thing,
but
they,
if
you
make
it
easy
for
them,
and
you
know
when
you
don't
add
too
much
friction
they'll
do
the
right
thing,
but
if
they
don't
know-
and
you
make
it
hard
of
course,
they
won't
do
it
so
interesting,
interesting
results.
Let's
close
this
lack
of
awareness
and
then
it's
easy
I
think
it's
a
combination
of
things
together,
but
lack
of
awareness
seems
to
win
by
by
a
mile
cool,
very,
very
interesting.
B
E
Okay,
so
I
think
it
was
touch
number
four
collaboration
is
usually
two
very
different
domains.
So
does
your
security
person
know
the
tech
stack
that
you're
trying
to
develop
and
deploy
and
does
the
yeah?
Does
the
developer
actually
understand
the
security
implications
of
maybe
privacy
regulations,
or
you
know
the
types
of
authorization
mechanisms?
So
there
is
a
domain
between
the
two
I
I
do
think
this
is
just
how
people
interact
I
think
sometimes
people
get
frustrated
in
organizations.
E
So
we
look
at
Tech
skills
a
lot
in
people,
but
good
communication
skills
are
kind
of
Paramount
to
having
good
collaboration
between
those
two
teams
and
I
think
some
shared
goals.
It's
not
about
it's
the
collaboration
versus
the
criticism,
that's
what
we
really
need
to
I
think
focus
on
when
we're
sort
of
building
good
relationships
between
security
and
development
teams.
E
Well,
I
want
to
just
quickly
touch
on
with
the
education
is
I,
think,
there's
lots
of
opportunities
for
education,
so
we've
seen
formalized
training,
that's
cool,
there's,
different
training
platforms,
online
trading
platforms,
I,
think
security
tools
provide
just
in
train
in
time.
Training
I
found
a
bug.
This
has
told
me
that
I've
got
a
file
path,
traversal
vulnerability,
I've,
never
heard
of
that
before.
Here's,
what
it
is,
here's
how
to
fix
it.
It's
very
contextual!
It's
now
it's
the
problem
of
the
code.
E
I've
got
not
something
that
I
learned
three
months
ago,
that
I've
probably
forgotten
so
I
think
that's
the
tool
usage.
If
the,
if
the
they
work
well,
they
can
provide
education
there
and
then
for
domain.
Specific
stuff
is
when
you
get
the
collaboration
like
a
pen
tested
found
something
where
oauth
token
was
logged
and
it
was
part
of
how
the
developer
implemented
some
sort
of
function.
Then
that's
something
that
I
think
is
a
good
collaboration.
E
B
C
So,
yes,
we
did
and
the
way
how
we
tackled
it
in
our
organization
is
primarily
through
having
some
cross
training
sessions
where
the
developers
and
the
security
team
we
have
them
sit
together,
and
the
security
team
sometimes
explain
the
processes
that
they
go
through.
The
developers
explain
sometimes
the
processes
that
they
go
through.
So
the
reason
for
this
is
to
make
the
other
team
understand.
What
are
the
processes
that
in
general,
either
the
developers
or
the
security
team
follow.
C
Some
of
these
sessions
are
targeted
towards
how
this
vulnerability
was
found
and
what
would
be
the
impact
and
explaining
it
a
bit
more
in
detail
to
the
developers,
whereas
this
could
also
be
like
an
interactive
session
where
the
developers
also
explained
that
during
the
development,
why
was
this
action
chosen
just
so
that
yeah
there's
it's
it's
not
to
point
a
blame
at
anyone,
but
just
to
understand
the
point
of
view.
So
this
is
more
about
education
and
bringing
the
teams
together,
like
the
better.
C
A
D
I'll
yeah
I'll
be
nice
and
quick,
so
I
think
there's.
So
a
few
things
is
the
getting
to
yes,
I
like
to
start
with
that
kind
of
model.
When
we're
talking
to
development
teams,
traditional
security
is
usually
about
hey.
What
you're
doing
is
a
bit
silly.
We
can't
have
it
happen
here
right
and
instead,
I
want
to
flip
that
around
and
say
like
we
want
to
get
you
to
like.
We
know
you
want
to
achieve
this.
D
How
do
we
get
you
to
yes,
and
that
means
that
you're
building
collaboration
into
like
your
entire
workflow
and
people
want
to
work
with
each
other,
because
there's
a
shared
goal
that
you're
trying
to
achieve
so
I
think
that
that's
really
important.
As
for
the
developer
education
stuff,
if
you
keep
that
lens
in
mind,
you
have
to
think
about
the
customer
experience
of
engine,
so
they
can
get
to
yes.
D
So
I'm,
a
fan
of
instead
having
us,
be
accessible
for
engineers,
so
that
they're
willing
to
come
to
us
and
learn
with
us,
so
shared
slack
channels,
regular
lunch
and
learn
sessions
where
they
can
ask
the
appsec
team
anything
and
just
giving
them
a
good
customer
experience.
So
they
actively
seek
out
professionals
instead
of
going
and
trying
to
find
stuff
themselves
right.
B
A
A
This
is
the
the
final
session
for
the
second
day
around
security
please
tune
in
tomorrow
for
two
sessions,
around
collaboration,
we'll
be
talking
in
the
first
session
on
how
to
increase
developer
productivity
by
investing
in
more
efficient,
tooling
and
then
in
the
afternoon
about
streaming
your
devops
tool
chain.
Thank
you.
Everyone
again
for
for
joining.
A
B
Final
thoughts
really
I'm
I
know
application.
Security
can
be
challenging,
but
I
think
if
you
looked
at
some
of
the
stuff
that
is
coming
out,
for
example,
with
GitHub
copilot
X
I
think
there
are
things
that,
from
a
technology
point
of
view,
can
help
engineers
make
the
right
decisions
and
then
free
up
the
application
security
team
to
really
work
with
the
engineers
on
the
kind
of
the
hardest
stuff
and
and
on
collaboration.
So
watch
this
space,
but
yeah
I'm,
pretty
excited
and
again
feel
free
to
reach
out.