►
Description
Presented by: Hauwa Otori
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
A
Today,
I
want
to
talk
to
you
about
improving
developer
and
researcher
communication
and
I
want
to
talk
to
you
about
three
specific
points:
number
one:
the
perceptions
open
source,
maintainers
and
security
researchers
have
of
each
other
number,
two,
the
impact
of
these
perceptions
and
how
both
communities
interact
in
the
vulnerability
disclosure
process
and
three
I
want
to
leave
you
with
best
practices
to
implement
for
more
effective
vulnerability
disclosure
process.
So
why
does
this
matter?
A
If
you
can
communicate
better,
it
will
lead
to
better
outcomes,
less
friction
and
what
otherwise
could
be
a
challenging
process
and
getting
to
a
shared
solution
in
a
faster
way,
and
you
might
even
feel
better
along
the
way
today,
the
security
research
Community
lacks
uniformity
and
vulnerability
disclosure.
It's
essentially
the
process
of
reporting
and
communicating
details
of
a
potential
risk
with
the
goal
of
fixing
it
I
previously
had
the
opportunity
to
lead
an
industry.
A
Coalition
and
I
noticed
a
couple
of
things:
number
one
organizations
like
Google
project,
zero,
GitHub
security,
lab
hacker
one
they
all
have
their
own
processes
for
disclosing
vulnerabilities
and
two
oftentimes
industry
focuses
heavily
on
building
security
tooling,
rather
than
focusing
on
the
interactions
and
the
relationships
between
these
two
key
stakeholder
communities
in
a
disparate
system.
Understanding
the
relationships
among
stakeholders
can
lead
to
more
effective
actions
to
remedy
vulnerabilities.
This
understanding
will
ultimately
lead
to
a
safer,
more
secure
and
more
collaborative
ecosystem.
A
Now,
before
we
go
any
further
I
want
you
to
take
a
second
and
think
about
the
last
time
you
had
a
group
project,
any
project
that
required
a
collective
effort.
Maybe
it's
a
cross-functional
project
at
work
or
perhaps
you're
a
GitHub
campus
expert,
and
it's
a
university
project
at
your
campus,
now
think
about
your
relationships
with
your
group
members
before
you
started
working
with
them,
you
may
have
had
perceptions
about
them
before
you
got
to
know
them
in
a
real
way
and
those
perceptions
likely
shape
the
way
you
interact
and
engage
with
them.
A
In
other
words,
how
we
think
and
feel
about
someone
often
sets
a
tone
for
how
we
engage
with
them
and
that's
no
different
for
open
source,
maintainers
and
security
research
communities.
A
few
months
ago,
I
had
the
chance
to
bring
a
group
of
maintainers
and
researchers
from
across
the
globe
together
in
one
space
to
talk
about
their
perceptions,
spoiler
alert,
it
wasn't
all
sunshine
and
rainbows.
What
I
found
interesting
about
those
conversations
was
not
necessarily
how
one
group
perceived
the
other,
but
rather
how
one
group
believed
that
the
other
group
perceived
them.
A
So,
for
instance,
maintainers
said
We.
Believe
researchers
perceive
us
to
be
quote
lazy
or
lacking
willpower
when
it
came
to
their
inability
to
rectify
certain
security
vulnerabilities,
while
researchers
believed
that
developers
viewed
them
as
irresponsible
and
not
wanting
to
understand
maintainers,
but
simply
wanting
to
blow
everything
up
and
these
perceptions,
regardless
of
their
truth,
bleed
into
the
way
these
communities
interact
and
communicate
with
each
other
and
that's
what
we
wanted
to
delve
into
at
the
lab.
A
We
picked
a
process
where
both
of
these
groups
engage
regularly
and
ask
the
following
question:
how
can
we
improve
communication
between
security,
researchers
and
open
source
maintainers
within
the
vulnerability
disclosure
process?
So
I
explained
the
process
briefly,
but
to
give
you
a
visual
overview
here
are
three
key
steps.
Number
one.
The
researcher
identifies
a
vulnerability
and
details
they're
finding
in
a
report
two.
The
researcher
shares
the
report
with
the
maintainer
and
three
they
collaborate
and
work
towards
a
resolution
within
a
90-day
period,
which
is
typically
the
industry
standard.
A
We
had
four
key
goals
that
we
wanted
to
accomplish
with
this
work
number
one:
whether
open
source
maintainers
have
a
established
views
and
Security
in
the
security
research
Community,
whether
maintainers
understand
the
role
of
security
researchers,
whether
they
are
receptive
to
Communications
from
this
group
and,
lastly,
whether
they
understand
the
messaging
used
in
disclosure
reports.
Now
every
good
study
starts
with
a
hypothesis.
Our
initial
hypothesis
was
that
open
source
maintainers
would
Express
dissatisfaction
with
their
interactions
in
communication
with
the
research
Community.
A
Here's
what
we
found
in
terms
of
maintainers,
engaging
with
the
security
research
Community
most
of
the
participants
said
they
had
little
to
no
engagement
within
the
security
research
Community.
This
isn't
great
news,
because
this
simply
reinforces
perceptions
rather
than
basing
their
views
on
Direct
experience
with
that
Community,
but
when
they
do
interact,
Beyond
disclosure
reports,
some
maintainers
mentioned
they
engage
with
researchers
through
other
avenues,
particularly
social
channels
like
Twitter,
slack,
Discord
and
other
conversations
with
friends
and
interpersonal
connections.
Maintainers
said
they
would
appreciate
an
advisory
collaborative
relationship
with
security.
A
Researchers
maintainers
also
reported
that
their
interactions
were
generally
positive
or
Pleasant.
In
fact,
one
maintainer
said
that
their
experience
was
quote
pretty
positive,
mostly
because
I
know
what
the
perspective
is.
In
other
words,
this
particular
person
was
not
only
a
maintainer
but
had
also
been
on
the
research
side
as
well,
so
they
understood
both
communities,
they
understood
both
of
their
roles
and
their
point
of
view,
but
this
wasn't
universally
true.
Some
characterize
their
interactions
with
researchers
as
pretty
obscure
and
running
the
gamut.
Depending
on
the
researcher.
A
One
maintainer
reported
that,
despite
their
attempts
to
interact
with
the
community,
they
felt
excluded,
they
saw
the
community
as
less
inclusive
and
wanted
to
see
the
issue
addressed
now
when
it
comes
to
the
actual
reporting
process
and
receiving
reports,
maintainers
typically
experience
a
range
of
emotions,
including
anxiety
and
stress.
However,
they
are
appreciative
of
constructive
feedback.
One
maintainer
said
my
initial
emotional
response
is:
oh,
no,
how
bad
is
it?
This
indicates
the
immediate
alarmist
response
some
maintainers
feel
after
receiving
a
disclosure
report,
another
maintainer
said
we're
open
to
receiving
constructive
feedback.
A
However,
sometimes
communication
from
researchers
crosses
the
line
and
when
the
line
is
crossed,
this
maintainer
said
that
they
often
set
additional
boundaries
when
these
boundaries
are
set.
The
maintainer
reported
that
oftentimes
researchers
respond
by
expressing
frustration
with
the
process
and
apologizing.
However,
other
researchers
kind
of
double
down
on
their
language,
and
at
that
point
the
maintainer
has
to
decide
whether
to
move
forward
with
the
engagement
or
not
when
we
ask
maintainers
how
they
wanted
to
receive
disclosure
reports,
overwhelmingly
maintain
and
prefer
to
receive
them
privately.
A
One
maintainer
mentioned
they've
experienced
disclosures
coming
from
various
channels,
including
Twitter,
while
a
majority
of
maintainers
would
prefer
that
researchers
submit
reports
privately,
some
researchers
are
trending
towards
submitting
reports
through
public
issues
and
other
social
platforms.
One
researcher
said
it
could
prompt
maintainers
to
fix
issues
faster
in
terms
of
contacting
maintainers
a
majority
of
maintainers
said
they
have
a
designated
Security
contact
via
email.
However,
most
don't
yet
have
a
security
policy.
They
either
don't
have
one
yet
or
plan
to
implement
one
moving
forward,
while
there's
a
general
consensus
that
90
days
is
a
standard.
A
Reasonable
timeline
maintainers
also
want
to
maintain
the
flexibility
with
this
timeline
and
have
a
more
collaborative
process
with
researchers
in
the
event
that
the
potential
risk
could
take
more
time
to
fix
in
terms
of
best
practices.
We'll
start
with
maintainers
first
set
a
designated
Security
contact.
Many
of
you
are
already
doing
that
as
well
as
a
policy.
A
security
policy
allows
maintainers
to
standardize
and
normalize
how
vulnerability
reports
are
delivered
and
how
they
want
to
track
them.
A
Moving
forward
number
two
responsiveness
and
collaboration:
one
researcher
mentioned
that
they
had
found
a
vulnerability
or
potential
vulnerability
in
a
well-known
project.
They
took
the
time
to
detail
their
findings
and
share
that
with
the
maintainer
during
the
90-day
period.
They
followed
up
with
this
maintainer
a
few
times.
However,
they
heard
no
response.
Ultimately,
after
the
90-day
period
was
completed,
the
maintainer
finally
fixed
the
issue.
However,
the
researcher
was
discouraged
because
they
didn't
hear
a
word
from
the
maintainer.
After
all
that
work
they
had
put
into
it.
A
It's
important
to
acknowledge
that
you've
received
reports
and
to
then
move
forward
with
the
collaboration
and,
lastly,
set
boundaries
in
communication.
If
someone
is
crossing
the
line
feel
free
to
let
them
know
and
who
knows,
the
conversation
could
become
even
more
productive
after
that
now,
in
terms
of
best
practices
for
researchers,
the
first
thing
is
use
a
positive
feedback
sandwich.
One
maintainer
said
that
they
appreciated
this
approach.
It's
essentially
starting
by
saying
something
positive
about
the
project,
explaining
the
potential
risk
and
then
closing
with
a
positive
statement
about
future
collaboration.
A
Number
two
view:
reports
as
an
educational
tool.
Maintainers
are
expressed
they're,
not
necessarily
familiar
with
security
topics,
so
include
as
much
detail
as
possible
to
help
tell
a
clear
story
for
the
maintainer.
Some
maintainers
said
that
they
want
to
receive
notifications
in
a
way
that
has
a
few
key
points,
including
a
summary
of
the
problem,
an
explanation
of
the
specific
issue,
the
vulnerabilities
potential
impact
and,
ultimately
remediation
advice
to
the
extent
possible
and,
lastly,
make
it
actionable
and
not
critical
and
finally,
I
want
to
leave
you
with
a
challenge.