►
Description
Presented by Mike Hanley, Chief Security Officer
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
In
that
mission,
we
really
need
to
leverage
the
collective
power
of
the
open
source
community
of
vulnerability,
reporters
of
security,
researchers
of
open
source
project
maintainers
working
together
to
make
sure
that
vulnerability
reports
are
really
resolved
as
quickly
and
as
completely
as
they
possibly
can
be,
and
at
github.
We
believe
that
coding
is
social,
but
so
is
the
security
work
that
happens
behind
the
scenes
to
protect
those
broader
ecosystems.
A
Now,
we've
taken
the
time
to
go
back
and
actually
look
at
hundreds
of
vulnerability
reports
that
have
cleared
through
our
security
lab
and
our
research
team
and
disclosed
to
open
source
projects.
You
know
every
every
single
year
and
we've
conducted
a
fair
amount
of
research,
also
going
out
actually
just
talking
to
maintainers
about.
What's
the
experience
of
the
vulnerability
disclosure
process
from
their
perspective
and
what
do
those
interactions
with
vulnerability?
Reporters
actually
look
like
whether
it's
on
github
or
somewhere
else
and
through
those
conversations
that
analysis
the
data
we've
collected.
A
We
found
really
a
lot
of
opportunities
to
improve
the
way
that
the
security
research
community
and
who
are
reporting
vulnerability,
vulnerabilities
to
projects
and
also
doing
that
original
discovery.
Work
can
work
together
with
open
source
project
maintainers
to
achieve
achieve
that
shared
goal
of
getting
to
a
good
security
fix,
and
in
this
talk,
I'm
going
to
take
you
through
a
couple
of
the
tips
there
just
to
help
assure
that
there's
a
positive
experience
on
both
ends
of
this
conversation
and
that
we
quickly
address
those
security
vulnerabilities
when
and
as
they
are
discovered.
A
So
let
me
just
start
with
the
the
first
rule,
and
I
think
this
is
probably
one
of
the
most
important
ones
and
that's
just
to
establish
the
rules
and
norms
of
collaboration
and
on
the
maintainer
side.
This
is
probably
in
the
form
of
a
security
policy
and
on
the
reporter
side,
this
is
probably
in
the
form
of
a
disclosure
policy.
A
This
can
actually
result
in
basically
dropping
a
zero-day
vulnerability
through
a
public
issue
or
a
public
pull
request
on
github
as
a
platform,
you've
got
the
opportunity
to
actually
go
set
a
security
policy
for
your
project
pretty
easily
and
try
to
take
as
much
of
the
ambiguity
out
of
this
process.
As
you
possibly
can
this
lets,
you
express
your
preference
on.
You
know
where
and
how
you
want
to
receive
security
reports
and
you'll
find
that
most
security
vulnerability.
A
A
A
Now,
if
you
define
and
publish
your
disclosure
policy
just
clearly
state
again,
how
do
you
intend
to
interact
with
the
maintainers
the
resolution
that
you're
seeking
your
publication
timeline
on
when
you'd
like
to
be
able
to
disclose
again
it
doesn't
need
to
be
complicated?
I
think
short.
A
One
thing
that
I
want
to
highlight
is
you:
should
try
to
be
flexible
and
accommodate
the
reality
that
there's
a
variety
of
situations
that
you're
going
to
encounter
on
open
source,
be
open
about
your
needs,
but
also
seek
to
try
to
understand
the
needs
or
the
limitations
or
the
challenges
or
the
situations
that
the
maintainer
might
find
themselves
in
as
well,
and
I
think
when
you
can
take
that
empathetic
approach
of
working
together
toward
a
common
goal
of
getting
to
a
fix,
it's
a
little
bit
easier
to
find
that
shared
ground
to
work
on,
and
that's
a
good
segue
to
the
next
point,
which
is
again
getting
to
that
common
goal
of
working
on
an
effective
report
and
a
clear
and
durable
fix
as
quickly
as
possible.
A
Now
as
the
vulnerability
reporter
be
aware
of
a
few
things,
one
maintainers
are
often
working
on
their
projects
on
personal
time
with
no
funding,
two
maintainers
or
receiving
end
of
security
vulnerabilities
can
be
upset,
stressed
out,
producing
anxiety.
A
So
as
a
reporter,
I
think
just
having
a
cognizance
and
appreciation
and
empathy
for
that
situation
and
experience
can
go
a
really
really
long
way
in
terms
of
working
effectively
and
collaborating
on
some
of
these
issues
and
a
mindset
that
I
would
encourage
you
to
take
going
into
this
is
think
of
a
vulnerability
report
as
a
contribution
like
in
this
capacity.
You
are
acting
as
a
contributor
to
a
project.
A
This
is
as
important
as
the
mindset
that
you
would
take
to
a
feature
or
pull
request,
or
any
other
improvement
to
a
project
and
thinking
about
that
as
a
contributor
and
if
you're,
a
maintainer
thinking
about
vulnerability.
Reporters
as
contributors
can
go
a
long
way
to
helping
set
that
relationship
off
on
the
right
foot.
A
What
can
vulnerability
reporters
do
to
make
a
good
contribution
right,
like
it's
helpful,
to
probably
think
through
a
certain
set
of
things
that
make
that
better
for
the
from
the
maintainers
perspective,
and
really
it's
all
about
having
a
very
actionable
report,
that's
easy
to
verify
triage
to
fix.
I'm
going
to
take
you
through
a
quick
example
to
show
you
what
that
looks
like
we're.
A
Looking
at
a
report
from
the
github
security
lab
and,
first
and
foremost,
let's
start
with
impact,
have
the
impact
clear
and
upfront
so
that
the
maintainer
knows
what
they're
looking
at
and
can
start
the
process
of
assessing
risk
and
prioritizing
resolution.
Here
we
see
you
know:
we've
got
a
pre-auth
rcd
bug,
that's
probably
pretty
serious,
being
clear
and
up
front
with
that.
Helps
the
maintainer
bump
that
one
to
the
top
of
the
priority
list
in
terms
of
working
on
second,
is
having
a
poc
or
proof
of
concept.
A
A
That
can
be
quite
helpful
if
for
no
other
reason
to
just
drive
consensus
on
what
is
the
impact
working
together
on
that
now,
during
this
phase,
the
reporter
and
the
maintainer
are
both
going
to
discuss
the
impact
and
both
parties
again
just
need
to
keep
in
mind
that
you
know,
if
I
think,
it's
more
important
than
you
think
it
is
like
just
working
on
establishing
that
shared
understanding
of
criticality
and
again
using
the
poc,
and
the
impact
statements
can
really
help
with
that.
A
A
Third,
again
as
a
contributor
think
about
what
can
I
offer
that
help
helps
make
this
easier
to
resolve
and
one
of
those
things
can
be
pointing
out
the
specific
incriminated
code
and
providing
a
helpful
suggestion
on
remediation.
Now,
it's
important
to
remember
that
the
maintainer
is
immersed
in
this
code,
all
the
time
and
probably
has
a
different,
or
you
know,
a
differing
perspective
on
how
to
best
remediate
it.
A
That
may
be
unique
to
you
as
having
a
security,
research
background
and
perspective
from
that
from
that
particular
role
set.
Fourth
again
going
back
and
referencing
the
disclosure
policy
that
you
have
again
just
to
set
clarity
on
the
norms
and
expectations
that
you've
got
for
the
rest
of
the
engagement
five,
I
think
proposing
your
help
so
proposing
to
review
the
fix.
A
Last
but
not
least,
ask
for
a
private
patch
environment
on
github.
The
maintainer
can
create
that
private
github
security
advisory
and
they
can
invite
the
reporter
to
collaborate
on
that
in
private,
so
that,
when
things
are
ready
to
disclose,
the
reporter
will
have
reviewed
and
tested
the
patch
and
been
able
to
confirm
for
the
maintainer
that
everything
is
good
to
go.
A
So
those
are
some
lessons
on
creating
an
effective
report.
Now.
Third,
big
tip
is
really
all
around
notification
and
downstream
communication
in
a
really
effective
and
clear
way.
This
tip
is
primarily
for
maintainers,
but
if
you're
on
the
vulnerability
research
side,
I
think
it's
important
to
understand
this
part
of
the
process.
I
said
earlier
that
collaborative
disclosure
doesn't
end
with
the
report
and
it
actually
doesn't
end
with
pushing
a
patch
either.
A
It's
really
it's
really
ending
when
you've
got
broad
community-wide
awareness
and
notification
that
the
patch
is
available,
it's
critical
and
what
it's
trying
to
actually
address
in
the
ecosystem,
so
notifying
users
of
the
vulnerability
giving
them
that
path
to
upgrade
to
the
patched
version,
giving
them
that
clarity
on
what
the
underlying
issue
is
and
why
it
matters
to
them
is
really
important.
You
cannot
assume
that
the
downstream
consumers
of
your
project
are
always
just
sort
of
blindly
running
the
latest
version
of
the
product.
A
Now
I'm
going
to
show
you
the
github
security
advisory
again
here,
because
it's
important
to
note
that
on
github
you
can
publish
the
security
advisory
that
was
private
until
this
time,
so
github
is
a
cna,
meaning
we're
a
cv,
numbering
authority
and
the
cve
allocation
process
for
a
security
advisor
is
actually
really
really
straightforward
and
it
takes
typically
just
a
few
days
to
go
through
it.
A
From
start
to
finish,
and
when
you
publish
the
security
advisory,
your
security
advisory
becomes
available
to
the
wider
github
advisory
ecosystem
through
the
advisory
database,
as
well
as
to
the
wider
open
source
security
software
ecosystem
through
the
cve
number.
Now
don't
forget,
of
course,
to
credit
the
vulnerability
reporter
for
their
contribution
to
your
product.
A
Just
like
you
would
any
other
feature
contributor
who
who
provided
something
to
your
project
now
on
dependable,
if
you're
in
a
supported
ecosystem,
whether
it's
go
or
an
npm,
your
public
security
advisory
will
actually
automatically
trigger
a
series
of
dependable
alerts,
and
the
benefit
of
this,
of
course,
is
this.
A
Does
a
lot
of
the
legwork
of
notifying
your
projects
downstream
consumers
about
the
exposure
and
for
projects
that
have
enabled
dependent
bot
security
updates
dependable
will
actually
also
create
the
pr
that
will
do
the
update
for
you,
so
you
can
just
review
the
update
see
what's
getting
patched
makes
it
really
really
easy
for
developers
to
adopt
that
latest
and
greatest
and
limit
the
long-term
proliferation
of
the
vulnerable
versions
of
that
code,
so
to
just
kind
of
bring
things
to
a
wrap
up.
You
know
really
a
couple.
A
Last
but
not
least,
just
the
notifications
piece,
notifying
everyone
who's
using
the
project
and
giving
credit
to
the
reporter
or
critical
steps
and
closing
that
out
on
the
research
side.
Similarly,
being
clear
about
your
disclosure
policy,
be
clear,
but
also
be
flexible
and
part
of
being
flexible,
again,
really
just
means
adopting
a
maintainer
first
approach.
A
That's
one
of
empathy,
flexibility
being
helpful
understanding
that
maintainers
are
probably
doing
this
along
with
a
lot
of
other
jobs
and
just
staying
focused
on
the
goal,
which
is
patching
the
vulnerability
and
working
in
collaboration
with
the
maintainer
to
get
to
that
outcome.
Now
let
me
just
look
forward
to
what's
next
two
things.
I
want
to
touch
on
here.
First
off
I'd
love
to
come
back
to
you
before
next
year
and
tell
you
disclosure
doesn't
end
with
the
notification
of
the
vulnerability
in
your
project.
A
Now
we
provide
codeql
as
github
as
a
free
tool
for
open
source
and
we
also
open
source
all
of
our
queries,
so
they're
usable
by
everyone
through
github
code
scanning,
and
we
also
provide
codeql
training
from
the
security
lab
to
help
achieve
this
particular
goal.
Last
point:
really:
around
private
disclosure.