►
Description
Presented by David Habusha, VP of Product (WhiteSource).
Learn how functions such as vulnerability discovery and impact analysis can help developers focus on real security risks that affect their applications, pinpointing the calls to vulnerable code, down to the pertinent filename and line number. You'll also see how to use security checks in GitHub to tap into the normal SDLC working environment with integrations like the Checks API.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
A
Security
teams-
that's
it
oh
wow!
Okay,
now
those
of
you
answered
that
that
you
are
a
developer.
How
many
of
you
like
resolving
security
issues
in
your
code,
raise
your
hand
come
on
typical
answer,
and
this
is
exactly
the
topic
of
this
presentation:
I'm
going
to
talk
about
how
you
can
secure
your
open
source
components
by
using
the
existing
workflows
in
github,
and
now
you
can
prioritize
security
vulnerabilities
remediation
as
a
background,
and
this
is
something
that
we
all
know
open
source.
It
comprises
more
than
80%
of
any
modern
application.
A
If
you
have
a
hundred
thousand
lines
of
code
in
your
app,
more
than
80
thousand
lines
of
code
will
be
comprised
of
open
source
components
from
third
party
sources
that
you
don't
know.
What's
in
there,
we
are
at
white
source,
generate
an
annual
report
with
regards
to
security,
vulnerabilities
in
open
source
components,
and
the
trend
that
we're
seeing
in
the
last
18
months
is
that
the
number
of
reported
security
vulnerabilities
in
open
source
component
grew
by
more
than
50
percent
year
over
year
from
2016
to
2017.
A
I'm
sure,
that's
not
surprising,
while
doing
that,
we
see
that
dev
team
security
teams
and
devops
teams
invest
a
lot
of
time
money
and
effort
into
resolving
security
issues
in
open
source
components,
but
the
sleep
side
of
it
is
that
there's
no
actually
a
single
process
or
something
that
most
companies
do
to
resolve
these
open
source
issues
and
in
the
same
survey
we
asked
these
companies.
How
do
you
usually
resolve
open
source
security
issues?
A
A
So
that's
pretty
much
not
a
way
to
handle
security
vulnerabilities
in
the
modern
world
and
as
you
as
you
can
see
here
and
based
on
the
answers
I
received
in
the
beginning
of
this
session,
there
is
a
big
friction
between
the
security
teams,
the
development
teams
having
the
devops
teams
in
the
middle.
Although
we
see
trends
such
as
dev
shake-up,
starting
to
rise,
there's
still
a
big
friction,
because
I'm
sure
that
you
as
developers
you
like
to
write
cool
code,
you
like
to
run
the
latest
technologies,
but
really
resolving
security
issues.
A
It's
not
something
you
like
doing
it
doesn't
have
to
be
this
way.
So
the
essence
of
this
talk
is
how
you
can
actually
do
that
in
a
very
little
time,
and
you
don't
have
to
leave
your
ongoing
day-to-day
working
environment,
you
can
do
that
within
github
and
I'll.
Show
you
how
to
do
that.
You
have
to
make
sure
that
you
follow
the
essential
components
that
will
drive
a
correct
security
vulnerabilities
remediation
process.
A
First
of
all,
you
have
to
understand
what
open-source
components
you
have
in
your
pieces
of
software,
including
all
the
dependent
packages
and
transitively
dependent
packages,
because
they
may
be
vulnerable
as
well.
You
have
to
have
a
solution
in
place
that
can
scan
any
programming
languages
used
by
your
software,
any
package
manager
or
any
source
file
that
is
taken
from
the
open-source
community.
All
of
these
needs
to
be
scanned
to
be
able
to
provide
you
with
the
full
picture
of
the
security
risk
associated
with
your
open
source
component,
and
you
need
to
do
it
continuously.
A
You
need
to
make
sure
that
developers
like
yourselves
are
empowered
and
can
receive
the
right
alerts
and
the
right
tools
to
actually
handle
open
source
security
issues.
First
of
all,
when
you
choose
the
open
source
component,
you
need
to
make
sure
that
the
component
is
safe.
After
you
chose
the
component
and
you
start
developing
using
the
component
and
you
start
pushing
code
to
your
development
branches.
You
need
to
scan
this
code.
You
need
to
make
sure
that
you
didn't
introduce
any
new
security
vulnerability
to
your
code.
A
So
if
you
want
to
bake
security
into
your
existing
workflows-
and
you
want
to
do
it
effectively,
you
have
to
make
sure
that
you
address
these
two
things.
One
prioritize
only
the
right
vulnerabilities
focus
your
time
on.
Only
what
matters
and
we'll
talk
about
that
and
second,
you
don't
have
to
leave
your
IDE
and
your
github
interface.
You
don't
have
to
go
to
other
tools,
you
don't
have
to
read
Excel
sheets
or
emails.
You
can
do
all
that
within
github.
A
So
let's
talk
about
prioritization,
a
quick
question
here
again
audience
when
you
have
an
open
source
component
like
Apache,
struts
or
spring,
and
the
new
vulnerability
comes
up
any
idea
how
how
many
of
these
vulnerabilities
are
actually
being
called
by
your
own
proprietary
code,
meaning
do
I,
really
reference
the
vulnerable
lines
of
code
or
the
vulnerable
functions.
Anybody
thinks
that
these
references
may
be
something
like
50
percent
60
percent.
A
A
Okay,
80
good
answer.
So,
if
you
look
at
it,
the
fact
that
I'm,
using
a
certain
open
source
component
and
a
new
vulnerability
comes
up
or
a
set
of
our
abilities
affecting
the
specific
version
that
I'm
using
doesn't
necessarily
mean
the
the
code
that
I
wrote
is
actually
affected
by
this
vulnerability.
And
if
you
look
at
it,
you
can
reduce
the
load
on
your
development
teams
by
a
significant
measure
by
only
focusing
on
the
ones
that
are
reachable
from
your
proprietary
code.
And
this
is
the
modern
way
to
prioritize
security,
vulnerabilities
in
open
source
components.
A
So
back
to
my
question,
this
is
pretty
much
the
number.
Although
we
launched
a
similar
technology
in
white
source
and
from
running
beta
tests
on
dozens
of
customers,
we
found
that
this
number
is
even
higher
it's
more
than
80%
of
the
vulnerabilities
that
are
not
really
effective
and
when
we
see
customers
installing
a
product
running
them
on
modern
applications,
with
probably
hundreds
of
thousands
or
millions
of
lines
of
code,
usually
they'll
end
up
with
dozens
or
hundreds
of
security
vulnerabilities
associated
with
it.
And
you
just
don't
know
where
to
start.
A
So?
You
first
need
to
understand
and
report
the
vulnerabilities
that
actually
can
be
referenced
from
within
your
proprietary
code
and
referencing,
the
open
source,
vulnerable
lines
of
code
or
functions,
and
not
only
that
when
you
have
these
types
of
technologies
in
place,
you
can
also
send
the
full
evidence
to
the
development
teams.
You
can
send
them
the
line
of
code
that
cause
the
vulnerable
code
in
the
open
source.
You
can
send
them
the
full
stack
trace.
A
A
If
we
look
at
an
example
here,
using
open,
SSL
engine
Java
code,
open
SSL
engine
in
the
version
used
by
this
example,
is
actually
referencing
a
vulnerable
code
in
an
open
source
component,
and
you
can,
you
can
actually
get
a
report
showing
you
how
these
CV
is
actually
being
could
be
exploited
by
hackers.
And
now
your
application
is
actually
reaching
these
vulnerable
lines
of
code.
You
can
send
that
to
developers.
They
can
comment
out
the
code.
They
can
bypass
the
code.
A
They
can
upgrade
the
the
the
version
of
the
software
component
there's
many
different
remediation
options
that
could
be
applied
when,
when
using
effective
usage,
analysis
technologies
and
if
we
look
at
what
happens,
if
I
comment
out
the
code,
I
use
a
different
type
of
of
open
SSL
engine
or
any
other
remediation
advice.
I
can
clean
the
system
and
actually
see
that
I'm
not
referencing
the
vulnerable
code.
A
What
I'm
going
to
describe
now
is
the
normal
get
of
workflow
there's
nothing
actually
different
or
change
from
your
normal
day
to
day
the
way
you
actually
interact
with
it
with
other
developers.
The
way
you
build
applications
but
I'm
just
going
to
show
you
how
you
can
make
all
these
security
checks
into
the
existing
workflow
without
leaving
github,
so
normal
workflow
starts
with
commits
on
developer
branches.
Any
number
of
commits
when
any
developer
is
pushing
the
code
to
the
developer
branch.
That's
the
first
step
to
start
scanning
for
security
vulnerabilities
very
early
in
the
process.
A
You
don't
need
to
wait
for
the
run
time.
You
don't
need
to
wait
for
the
build.
You
don't
need
to
wait
for
the
pull
request
to
merge
to
the
master
branch.
You
can
already
discover
most
of
the
issues
in
the
first
push
to
development
branch,
and
you
can
fix
it
early
in
the
process
and
make
sure
that
a
lot
of
time
and
cost
is
being
saved.
By
doing
so,
github
provides
something
called
web
hooks.
Where
books
are.
A
You
basically
subscribed
to
various
events
in
github
pushes
and
pushes
one
of
them
and
you
can
get
a
payload
from
from
github,
with
all
the
details
necessary
on
the
on
the
push
web
book
to
actually
start
and
initiate
a
security
scan.
Github
announced
recently,
something
called
the
checks.
Api
checks,
api's.
Allow
you
to
ask
developers
to
run
checks
before
things
actually
happen
in
in
the
code.
With
regards
to
push
these
checks
happen,
a
synchronously,
they
don't
stop
push,
but
they
can
run
these
checks
and
they
can
report
on
the
success
or
failure
of
these
checks.
A
But
you
can
also
do
other
things
with
that.
So,
whenever
you
trigger
a
check
on
on
a
push
week
on
a
push,
the
the
check
is
being
transferred
into
something
called
a
cute
state.
Because
it's
asking
a
synchronous,
you
can
run
a
security
scan
by
launching
any
tool
that
that
is
a
capable
of
running
these
security
scans.
A
Moving
the
check
to
the
in
progress
state
and
then
you
can
report
if
there's
a
security
vulnerabilities
using
github
issues,
so
you
can
do
the
whole
workflow
from
is
in
get
up
and
I'm
going
to
demonstrate
how
you
do
that
when
you
decided
that
your
code
in
your
development
branch
is,
is
ready
to
be
merged
into
the
master
branch
and
being
built
as
a
full
application.
You
start
running
pull
requests
and
when
you
do
a
pull
request,
you
want
to
merge
your
code
into
the
master
branch
and
start
building
the
app.
A
That's
the
second
place
where
you
need
to
run
the
security
test
and
in
this
case
using
a
push
away
book
and
the
checks
API,
you
can
actually
fail
build.
You
can
stop
the
merge
and
run
a
security
test,
and
if
you,
if
the
security
test
failed,
you
can
report
multiple,
multiple
different
statuses.
You
can
annotate
lines
of
code.
You
can
generate
a
comment
with
the
exact
details
of
different
areas
being
found
and
you
can
open
get
a
visual.
So
that's
an
another
step
of
actually
maintaining
a
secured
repository.
A
A
When
you
want
to
merge
your
code
into
the
master
branch
and
you
can
run
automatic
checks,
as
I
mentioned,
using
the
checks
api's,
but
it
also
requires
a
manual
approver,
usually
by
the
development
team
leader
or
by
someone
who
actually
reviews
the
code,
but
the
manual
approval
happens
after
the
auto
text
and
the
repo
admin
can
actually
override
the
automatic
checks,
even
if
even
if
they
failed,
although
we
don't
advise
you
to
do
so,
the
checks
api's
are
available
to
everyone
who
actually
developed
a
github
app.
They
were.
A
They
actually
announced
last
year
as
getting
our
apps.
They
announced
the
checks
api's
together
with
that
and
it's
free
for
everyone
you
can
be.
You
can
use
that
if
you
develop
a
guild
of
application,
if
you
don't
do
that,
you
have
the
status,
API
switch
or
less
or
reach
in
terms
of
the
the
contents
and
the
statuses.
But
then
you
don't
have
to
develop
an
app,
so
you
can
do
either
status,
api's
or
checks
api's.
A
A
A
His
entry
will
receive
a
check,
sweet
webbook
with
action
call
requested,
and
then
you
can
basically
understand
the
full
payload
and
what's
what's
in
there,
which
requests
and
what
was
requested
by
whom,
as
I
mentioned
you
can,
you
can
return,
which
statuses
not
just
fail
or
success,
but
also
lie
under
take
lines
of
code,
and
you
can
also
kick
off
rerun.
So
if
something
was
fixed
and
the
checks,
api's
can
also
kick
off
a
rerun
automatically,
so
you
can
actually
close
the
loop
inside
the
github
and,
as
I
mentioned
state
guys
are
available.
A
A
A
The
answer
should
have
been
the
same,
so
hopefully
you
know
how
it
works
and
use
it
at
the
same
time.
So
get
officials
are
are
kind
of
a
workflow
from
within
github
to
actually
interact
between
the
teams
and
resolve
issues
stemming
from
anything.
With
regards
to
making
changes
in
the
repository
now,
github
issues
allow
you
to
attach
labels
to
issues,
so
you
can
generate
a
label
called
security
vulnerability.
You
can
even
take
it
into
the
level
of
vulnerability
like
low
medium
high
severity.
A
A
You
can
add
many
things
to
the
github
issue
and
in
that
regard,
most
cases
the
developer,
who
actually
performed
the
action,
will
also
receive
an
email
with
the
issue
contents
right
to
his
inbox
so
and
they
can
click
on
it
and
open
the
issue
in
context,
so
they
don't
even
have
to
get
an
alert
from
within
get
up
to
work
on
the
issue.
In
the
issue
itself,
you
can
provide
all
the
necessary
details
like
what
is
the
vulnerable
library
that
generated
the
CVE.
What
are
the
vulnerability
details?
A
How
you,
how
you
remediate
this
issue
and
definitely
you
can
add
some
more
metadata
like
CBS
s,
core
impact
or
any
other
information.
You'd
like
to
add
to
your
issue
when
you
start
the
workflow,
the
issues
are
being
assigned
to
the
owner
of
the
repo
or
to
a
developer,
and
they
can
be
closed
by
actually
one
of
the
team
leaders
or
the
developer.
The
issue
was
assigned
to
after
actually
resolving
the
issue,
and
then
you
can
kick
off
actually
a
rerun
that
will
close
the
issue
automatically
and
pass
the
pass.
The
bill.
A
This
is
our
past
check,
look
like
in
weezing
the
checks
API,
as
I
mentioned
in
the
summer.
You
can
add
any
information
you'd
like,
but
you
can
see
the
full
lifecycle
of
the
of
the
check,
including
the
the
log
of
the
peep.
The
developer
will
actually
run
the
check
and
clean
it
and
in
case
of
a
failure
you
can
provide
the
rich
status,
the
reason
for
the
sale
and
then
in
the
summary,
you
can
add
a
lot
of
information
why
the
check
has
failed.
A
So
I'm
very
excited
to
announce
white
source
vault
for
github.
We
had
white
source,
help
the
open
source
community
with
various
tools
and
we're
launching
a
free
tool
today,
we're
actually
announcing
it
in
beta,
but
you
can
already
sign
up
and
it's
coming
in
November
this
tool
actually
runs
as
a
github
app
data
map.
All
you
need
to
do
is
just
choose
the
repos
to
apply
it
on
and
what
it
will
do
is
it
will
actually
do
all
this
process
that
I
just
described
it
will
scan
any
push
requests.
It
will
open
github
issues.
A
Your
developers
will
receive
an
email
pertaining
to
the
github
issue
and
this
tool
is
actually
free
and
it
complements
another
tool
that
we
used
to
charge
for-
and
this
is
for
those
of
you
use
what
we
used
to
be
called
Microsoft,
TFS
VSPs,
but
now
called
angel
DevOps,
and
we
made
it
free
as
well.
So
then,
that's
available
today.
So
if
you're
running
a
DevOps
just
going
download
it
for
free,
it
will
also
run
security
scans
in
this
environment.
It
also
generates
a
bill
of
materials
and
it's
free
on
the
Asian
marketplace.
Today.
A
A
What
you
need
to
do
to
actually
cope
with
that
and
to
have
the
right
process
in
place
is
to
baking
the
security
into
the
existing
workflows
into
the
existing
tools.
As
one
of
my
customers
told
me
and
he's
running
a
dev
team
we'd
like
to
work
with
our
ID
and
Geetha,
we
don't
need
anything
else,
so
just
make
sure
that
your
solution
runs
there.
So
that's
that's
the
right
way
to
do
it
and
make
sure
that
you
actually
prioritize
the
work
on
security
vulnerabilities
effectively.
A
You
don't
need
to
focus
on
hundreds
of
different
vulnerabilities
focus
on
what
really
matters,
so
you
can
make
your
deadlines.
You
can
you
can
work
on
cool
technologies?
You
can
keep
on
developing
code
and
actually
resolve
security
issues
as
kind
of
an
ongoing
process,
and
you
don't
have
to
okay,
so
I
have
this
list
again.
What
do
I
do
with
it?
I
don't
want
to
deal
with
it
today.
You
can
just
do
it
effectively
and
you
can
do
that
from
within
github.
So
just
either
develop
these
tools
or
you
know,
download
their
free
tool.
A
A
Okay,
so
I'll
repeat
the
question.
The
question
was
whether
the
pull
requests
need
to
be
manually,
reviewed
or
there's
an
automatic
process.
So
it
depends
on
your
branch
protection
rules.
You
can
do
it
either
or
the
checks
api's
can
return
a
failure,
success
status,
but
you
can
override
that
manually
if
you're
the
admin
of
the
repo.
So
you
don't
have
to
accept
the
results
we
we
recommend
that
you.
If
something
has
failed.
You
know
at
least
manually
review
what
happened
before
and
don't
automatically
approve
it.
A
Okay,
very
good
question:
the
question
was:
where
do
we
get
the
list
of
our
abilities
and
how
agile
is
it?
So?
Actually
one
of
these
ingredients
that
are
required
is
to
get
the
comprehensive
list
of
owner
abilities
from
multiple
different
sources.
It's
not
enough
just
to
tap
into
NV
D
and
get
the
known
CV,
because
not
everything
is
out
there.
There's
language
specific
security
advisories.
There
are
security
issues,
opening
in
public
repositories
like
even
github
in
public
travel,
ticketing
systems
like
in
India
and
there's
multiple
different
other
sources.
A
We
invite
your
support
more
than
a
dozen
of
these
sources
and
we
maintain
a
research
team
that
actually
curates
them,
but
everything
is
pretty
much
automatic,
but
you
have
to
be
on
top
of
that
and
do
that
continuously
all
the
time
to
make
sure
that
you're
on
top
of
every
security
vulnerability
that
comes
up
and
not
just
in
nvd.
Thank
you.
A
A
A
Sure,
okay,
our
great
question
and
definitely
comes
up
a
lot.
The
question
was:
how
long
does
the
scan
take
and
if
he
takes
a
day,
how
can
I
actually
use
it
so
scans
have
to
be
performed
in
the
boundaries
of
the
build
time
and
build
time
couldn't
take
a
day
or
even
an
hour?
Usually
it
needs
to
happen
within
very
few
minutes
or
even
less
than
one
minute.
A
Modern
security
times
on
open
source
components
rely
on
hashes,
so
you
don't
have
to
statically
scan
the
full
lines
of
code,
your
based
on
some
kind
of
digital
hashes,
and
you
compare
these
ashes
with
known
security
vulnerability.
So
it
it's
kind
of
seamlessly
integrated.
It's
definitely
running
within
the
boundaries
of
a
build
and
any
other
solution
that
will
run
longer.
It's
that's
not
acceptable
in
modern
time,
where
CIC
days,
continuous
and
there's
multiple
different
builds
a
day.
Thank
you.