►
Description
This panel is tackling one of the thorniest problems in open source: how to make vulnerability reporting simple, secret, and stress-free. Learn about the complex—and sometimes confrontational—relationship between security researchers and the OSS community, and new ways to streamline the reporting process.
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
Foreign
and
welcome
to
today's
panel,
where
we
are
trying
to
find
a
better
answer
than
we
have
so
far,
can
we
fix
vulnerability,
reporting
in
open
source.
My
name
is
Eric
Tooley
I'm,
a
hubber
I,
look
after
supply
chain
security
as
a
product
marketer
I'm
here
with
a
panel
of
GitHub
colleagues
and
some
industry
experts
who've
been
dealing
with
the
pain
of
this
issue
for
a
while
and
by
the
end
of
it.
We'll
have
some
new
answers
and
some
new
information
and
we'll
also
have
a
chance
for
you
to
ask
questions
of
the
panel.
A
B
Thanks
Eric,
first
of
all,
let
me
just
say
I'm
so
excited
to
be
with
you
all.
Today.
My
name
is
Haba
otori
I
am
a
staff
researcher
at
the
GitHub
security
lab,
where
I
lead
our
socio-technical
research
and
really
explore
the
relationships
between
developer
and
security
research
communities,
starting
with
the
vulnerability
disclosure
process.
B
D
E
A
C
Well,
it's
been
a
long
time
since
I
started
about
15
years
ago.
We
were
more
worried
about
you
know
being
sued,
so
that
has
changed
for
good,
but
still
there's
a
lot
of
room
for
improvement.
I
think,
most
of
the
time
you
end
up
giving
up
because
of
the
lack
of
response
from
the
vendor
and
overall,
most
of
the
time.
One
of
the
major
issues
that
I
have
reported
model
is
will
be
that
you
get
ghosted
right.
C
Maybe
the
reporting
could
be,
but
you
have
to
understand
that
as
a
security
researcher,
you
have
limited
time
to
invest
on
doing
this
for
free
pretty
much.
If
you're
not
the
reason
I
do,
it
is
because
I
want
the
vulnerability
to
get
fixed,
so
I'm,
not
really
that
interested
on
the
Bounty
itself.
Although
it's
nice,
but
it's
not
my
main
motivation,
yeah
most
of
the
time
I
my
worst
story,
I
guess,
is
when
I
reportable,
netability
I
know
it
was
vulnerable.
I
showed
some
proof
of
concept
code.
C
They
told
me
it
didn't
meet
the
security
bug
bar,
so
he
wasn't
going
to
get
fixed
I
released
a
tool
to
generate
malicious
macros
in
iOS,
so
I
was
able
to
escape
the
application
sandbox
using
certain
techniques.
Certain
functions
that
could
be
abused
and
I
was
told
that
it
wasn't
going
to
get
fixed.
I
went
back
to
it
a
few
months
later
reinstalled
office
in
my
computer
and
when
I
tried
it
it
just
didn't
work
anymore.
So
I
was
surprised
that
it
got
patched
silently
I
sent
him
an
email
and
they
was
like.
C
A
E
Never
deliberate
right,
A
lot
of
it
is
like
communication
problems
like
on
one
side,
it's
ghosting
on
the
other
side,
it's
sometimes
the
communication
comes
through
the
wrong
venue,
like
we've.
Had
lots
of
reports
come
through
from
like
Twitter
and
like
that's?
Never
really
what
you
want
to
receive
a
security
part,
because
you
wake
up
and
you
see
like
trending
your
project
and.
E
E
So
sometimes
the
reports
come
through
other
programs,
and
then
you
end
up
with
this
like
communication
barrier,
because,
like
someone
reports
it
to
a
bug
banning
program
at
a
company
and
then
it
ends
up
with
the
open
source
project
and
you're
like
communicating
like
through
another
company
to
the
researcher,
and
this
whole
communication
barrier
is
like
just
slow
and
bad
and
it's
hard
to
give
updates.
Even
if
we
wanted
to
yeah.
A
B
No
I'm
really
glad
that
we
had
a
chance
to
hear
from
both
Paulino
and
Sam
and
I'm
glad
that
Sam
touched
on
the
communication,
so
both
of
your
stories
are
really
what
we've
heard
from
both
open
source,
maintainers
and
researchers.
So
when
we
started
our
project,
what
we
really
wanted
to
understand
was
how
can
we
improve
communication
within
the
vulnerability
disclosure
process
between
both
of
these
communities
right?
So
we
learned
a
couple
of
things
coming
out
of
that
work.
Number
one.
The
quality
of
communication
really
depends
on
the
quality
of
the
relationship
right.
B
So
what
we
learned
from
maintainers
and
researchers
is
that
outside
of
the
disclosure
process,
they're
not
really
interacting
right,
they
have
limited
to
no
interactions
with
each
other
outside
of
this
process.
So
really
their
relationship
is
based
on
for
perceptions,
and
so
what
I
mean
by
that
is
not
necessarily
how
one
group
is
perceiving
the
other,
but
really
in
terms
of
how
one
group
believes
the
other
person
is
perceiving
them
right.
B
So,
for
instance,
Paulino
mentioned
hey
I'm,
being
ghosted,
Sam
is
saying:
hey
it's
a
communication
issue
and
that's
really
what
we
learned
from
the
interviews
and
the
conversations
we
had
with
both
groups
right
so
one
maintainers
said:
hey
I,
think
researchers
really
see
us
as
lazy
or
not
trying
to
address
the
issue.
When
really
it's
a
it's
a
resource
issue,
I,
don't
I,
don't
have
the
ability
I
don't
have
the
time.
B
I
don't
have
the
understanding
necessarily
but
I
want
to
do
something
about
this,
but
that's
not
really
how
the
researcher
is
receiving
them
and
on
the
other
side,
researchers
said:
hey.
We
think
maintainers
are
looking
at
us
they're,
simply
trying
to
blow
up
our
projects
and
just
kind
of
cause
trouble
right,
which
you
know,
regardless
of
you,
know
those
intentions
and
not
necessarily
being
based
in
truth,
that
really
sets
the
tone
for
the
relationship
when
they
engage
in
the
process
and
outside
of
that
they
said
hey.
B
You
know
when
we
do
get
into
this
disclosure
process
and
we
are
communicating
both
groups
said
we
do
prefer
to
do
this
privately
right.
So
what
was
top
of
the
wish
list
was
hey.
We
want
private
vulnerability,
reporting
on
GitHub
to
be
able
to
do
this
in
a
in
a
more
efficient
collaborative
way.
So
that's
really
what
we
learned
coming
out
of
that
research
project
that.
D
Yeah
so
I
showed
up
at
GitHub
about
a
year
ago
and
how
his
research
was
the
first
thing
anybody
sent
me
so
very
early
in
the
process.
I
started
to
learn
about
this
kind
of
explosion.
Point
where,
like
security,
researchers
and
maintainers
just
try
to
talk
to
each
other,
and
it
all
goes
wrong,
and
so,
when
we
were
building
a
feature
to
address
this,
we
distilled
it
down
to
three
problems,
which
was
it's.
D
It's
got
to
be
direct,
it's
got
to
be
private,
it's
got
to
happen
behind
closed
doors
and
it
has
to
be
ongoing
so
that
the
security
researcher
knows
what
the
status
is
beyond
one
First
Response
email
and
we
brought
it
all
together
with
an
awesome
new
feature,
called
private
vulnerability
rewarding.
So
now,
if
you
are
the
maintainer
of
an
open
source
repository,
you
can
go
to
your
settings.
A
So
we
all
have
experience
in
trying
to
communicate
across
organizations
and
between
different
functions,
and
there
can
often
be
friction
because
what
might
be
urgent
to
me
might
be
at
the
bottom
of
your
priority
list.
So
how?
How
are
we
making
the
communication
channel
easier
for
people
to
get
on
the
same
page?
You
know
to
establish
a
best
practice
for
determining.
Is
this
worth
addressing
it
and
how.
A
Yeah
that
makes
that
makes
perfect
sense,
and-
and
this
is
this
is
a
new
thing.
You
know
you
can't
do
this
type
of
process
unless
the
maintainer
is
enabled
private
vulnerability,
reporting
on
their
repo
and
so
a
lot
of
our
old
habits.
Well,
they
need
to
change
and
if
we
have
best
practices,
I
know
Madison,
that's
been
one
of
your
focuses
now:
we've
got
new
options.
F
So
I'm
involved
in
the
open
software
security
foundation
and
their
vulnerability,
disclosure
working
group
and
we've
recently
released
a
guide
for
reporters
and
finders,
specifically
of
vulnerabilities
and
best
practices
for
them,
and
how
to
report
these
two
maintainers.
So
now
that
this
feature
is
released,
I'm,
hoping
that
we
can
add
this
as
a
potential
recommendation,
if
you're
reporting
to
a
package
or
a
project
that
is
hosted
on
GitHub,
that
this
is.
This
is
a
way
that
you
can
give
this
information
to
maintainers.
F
A
D
So
we're
we're
launching
this
feature
as
a
public
beta.
We
know
it's
not
perfect
right
now.
We
think
it's
a
really
good
start,
like
we've,
we've
managed
the
MVP
here
of
like
this.
This
is
a
value
add
as
it
is,
but
we
need
your
feedback
to
continue
building
this
together
right
now,
there
is
no
Finance,
no
finances
involved
in
any
of
this.
It's
only
on
open
source,
it's
only
free
we're,
leaving
the
door
open
for
the
future.
We
want
to
hear
from
our
users.
We
want
to
evolve
this
in
Tanda
with
our
users.
E
All
the
entire
electron
org
has
the
has
the
feature
enabled
now
so
in
theory,
we
can
dispose
of
our
security
at
email
address,
which
will
make
me
very
happy.
No,
no
one
likes
checking
their
email,
so
I
look
forward
well,
I
say
look
forward
to,
but
maybe
we
changed
that
it'll
be
a
better
experience
when
it
comes
through
GitHub
security,
vulnerability,
reporting
than
having
to
check
that
email
constantly.
So
I
look
forward
to
the
first
time
that
happens.
Yeah.
D
D
I
yeah,
so
so
the
good
news
is
that
if
folks,
like
electron,
are
opting
into
this
feature,
they're
sort
of
making
a
statement
of
we
care
about
this,
we
want
to
hear
from
you.
We
don't
want
to
ghost
you
like
it's
sort
of
just
by
enabling
the
feature
at
all
you've
taken
a
step
in
the
right
direction
and
sent
that
message
to
the
community.
D
If
you're
not
getting
a
response,
you
still
do
have
some
power
in
your
hands
because,
since
you're
still
on
the
advisory
after
the
submission,
you
can
comment
yeah,
you
can
comment,
we
don't
have
a
Facebook
poke
button
or
anything,
but
you
can
add
more
information.
Etc
in
terms
of
Arbitrage
I
know
that's
a
fantastic
service
that
other
folks
offer
again,
not
not.
Starting
with
that.
We
are
blade.
We
are
completely
neutral.
E
Honestly,
the
mole
like,
given
that
you
now
fill
out
that,
like
GHSA,
like
form,
the
more
of
that
that's
filled
out,
it's
way
easier
for
us
to
deal
with
like
if
the
report
comes
through,
and
it's
like
here
is
the
problem
and
there's
like
no
reproduction,
not
even
like
the
versions
that
are
impacted.
It's
really
hard
for
us,
because
we
start
playing
whack-a-mole
and
guessing
which
version
might
they
might
be
dealing
with
like
we've?
E
Definitely
like
looked
at
a
screenshot
they've
sent
before
and
like
guessed
what
version
it
was
based
on
the
screenshot
they
sent
and
given
that
it's
like
a
structured
form,
that's
really
going
to
hopefully
improve
the
quality
of
the
reports.
We're
getting
as
well
like,
and
you
don't
have
to
fill
out.
Everything
which
is
like
a
deliberately
good
choice
because,
like
you,
should
prioritize
getting
the
report
in
quickly
and
then
like
adding
the
information
later
but,
as
Kate
said,
like
they're
still
involved,
they
can
add
that
information.
A
D
Because
GitHub
is
where
you
resolve
it,
so
that's
where
all
of
our
developers
are
already
working
every
single
day
they're
in
there.
That's
where
the
code
is
that's
where
they're
going
to
fix
the
problem,
so
by
keeping
it
all
in
one
place.
That
means
you
don't
have
to
check
20
different
platforms.
You're
not
like.
Oh
one,
browser
open
here,
another
browser
here,
it's
just
it's
all
there.
It's
all
in
the
same
place
and
the
goal
there
is
like.
Let's
resolve
this
faster,
let's
resolve
this
with
more
accuracy.
A
Perfect,
we've
got
a
number
of
people
here,
live
in
the
room
and
we've
got
plenty
of
time
for
Q
a
with
our
panel.
So
keep
in
mind
if
there's
a
question
that
you
have
for
anybody
here
in
a
few
minutes,
we'll
go
ahead
and
open
up
q
a
but
next
off.
Since
this
is
a
new
thing,
it's
in
GitHub,
it's
in
public
beta.
A
D
We
want
your
feedback,
so
much
so
go
ahead
and
enable
it
right
now
and
then
you
can
head
to
github.com
community
discussions
and
post
any
feedback
there.
You
can
also
just
tweet
at
me.
My
Twitter
handle
is
at
Kate.
Catlin
I
might
regret
this,
but
we'll
follow
up
and
a
lot
of
times.
What
I
love
to
do
is
just
get
users
on
the
phone
and
spend
30
minutes
talking
to
you.
So
by
all
means.
Please
please
send
us
our
send
us
all
your
feedback.
We
we
love
it.
It's
all
loved
yeah.
D
A
Right,
it's
a
great
example
of
how
the
community
intelligence
and
experience
can
contribute
to
a
solution
that
actually
is
in
service
of
the
community,
because,
ultimately,
you
know
we're
looking
for
the
win-win
outcome
here.
What
makes
it
an
easier,
more
trustworthy
process
both
for
the
reporter
and
the
maintainer?
You
know,
there's
really,
no
reason
not
to
do
it
this
way.
Is
there
a
reason
not
to
do
with
this
side?
Why
wouldn't
this
be
a
best
practice?
Madison
I
mean.
Can
you
think
of
a
scenario.
F
Just
if
you're
not
on
the
platform,
if
you're,
if
you're
using
GitHub
as
a
as
a
researcher
as
a
maintainer
as
any
sort
of
community
user
you're
already
there.
The
goal
of
this
particular
feature
release
was
to
make
this
as
easy
as
possible.
If
we
lower
the
barrier
to
entry
to
reporting
the
vulnerability
to
to
the
folks
that
really
need
to
fix
it
to
the
folks
that
need
this
level
of
information
which
isn't
always
necessarily
the
security
team
itself,
but
the
developers
that
actually
are
fixing
this.
F
A
Great
okay,
so,
let's
move
on
to
q,
a
I!
Imagine
that
anybody
who's
here
in
this
room
has
had
some
experience
on
one
end
of
the
other
of
this
process,
and
if
you
have
a
relatable
story
or
or
a
or
a
suggestion
or
something,
then
we
would
love
to
hear
from
you
and
everyone
can
learn
from
this.
So
we've
got
a
mic
that
we
can
pass
around
yeah.
We
have
a
mic
that
we
can
pass
around.
Surprise
we're
doing
this
early,
so
yeah.
H
So,
thank
you,
I
think
I
live
in
this
world,
I'm
Shankar,
this
I
work
for
Caterpillar
I,
have
responsibility
for
devsecops
and
Power
Platform
bunch
of
other
stuff.
I.
Think
one
thing
what
you
can
think
about
Kate
I
think
this
is
a
great
you
know.
Step
forward
is
when
we
hear
the
stories
it's
about
trust
and,
and
you
have
to
focus
on
this
platform,
how
to
build
that
trust.
You
know.
Maybe
there
is
you
know
in
bug
mount.
H
It
is
happening
a
little
bit
like
if
there
is
certain
person
who
says
yep,
there
is
a
problem
you
focus
on
it
faster
because
they
have
you
know
nine
out
of
ten
times
in
the
past.
Their
issues
have
been
really.
You
know
the
ones
which
you
really
need
to
hit,
because
when
you're
trying
to
deal
with
thousands
or
millions
of
vulnerabilities,
the
challenge
we
have
with
the
developer
Community,
which
one
I
need
to
focus.
H
First,
it's
not
about
whether
I
have
focus
on
it,
whether
you
know
it
is
important
or
not,
but
I
have
so
many
of
them.
Okay.
So
how
do
I
focus
so
I'm,
hoping
when
this
platform,
when
you
kind
of
you
know
build
it
is,
let's
just
say
I,
think
you
said
Paulo
right?
No!
No!
Yes!
So,
let's
just
say
Paolo
reports,
you
know
10
of
them
and
you
know
developer
Community
kind
of
latches
on
to
that
saying:
hey.
This
is
important,
so
kind
of
Paolo
stocks
kind
of
rises
in
there
and
they
go
next
time.
H
Power
reports,
the
11th
man,
people
are
going
to
start
paying
attention
because
this
so
I
I'm
not
trying
to
make
it
more
competitive
but
I'm
trying
to
Envision
to
say
this
will
help
in
prioritizing
stuff,
because
my
whole
life
not
whole
life.
Last
few
years,
it's
it's
about.
You
know
how
do
I
give
right
guidance
to
the
community
saying
this.
One
is
more
important
than
this
one
and
we
rely
on
multiple
sources,
as
you
can
imagine,
and
so
hopefully,
this
platform
would
be
one
of
those
sources
to
be
able
to
do
that.
So.
D
That's
great
yeah
I
love
that
idea
of
sort
of
like
you
know.
We
have
credits
in
our
system
like
how
many
credits
does
the
researcher
have
to
their
name?
I
might
I
might
toss
this
ball
over
to
Howa
Howa.
Do
you
have
any
other
like
thoughts
coming
to
mind
of
like
ways?
We
could
also
build
trust
between
the
security
researchers
and
the
maintainers
honestly.
B
I
think
from
the
research
that
you
know,
just
speaking
with
both
groups,
I
think
in
terms
of
building
that
trust
will
have
to
happen
outside
of
the
process
right.
So
one
of
the
things
that,
as
I
mentioned
at
the
top,
was
hey,
we
don't
interact
outside
of
this
process
and
maintainers
said
hey
when
I
receive
an
initial
report
right.
The
initial,
the
first
thing
I'm
feeling
is
Stress
and
Anxiety
right,
so
I
think
figuring
out
spaces
outside
of
the
disclosure
process,
which
can
be
a
stressful
situation,
for
both
parties
involved.
B
C
I
C
E
The
triage
list,
like
on
the
incoming
reports,
where
it
says,
like
the
person
just
like
somewhere
just
yeah
like
four
and
a
half
stars
but
like
like
somewhere
there,
some
kind
of
indicator-
that's
just
like
this
person,
has
reported
a
lot
and
they're
all
really
good,
like
put
them
at
the
top
of
the
list.
Yeah.
A
G
D
Yeah
yeah,
that's
actually
built
into
the
feature.
So
since
you're
still
involved
in
the
draft
security
advisory
as
a
reporter,
you
can
write
the
temporary
private
Fork.
If
you
want
to,
they
can
kick
you
maintainers,
you
can
kick
them
out
if
you
don't
want
them
to,
but
you
you
can
fix
it.
The
whole
thing
if
you
want
the
other
thing
you
can
do,
is
just
watch
and
see
what
changes
they
are
making
in
that
temporary
private
fork
and
so
you're
keeping
track
of
the
status
along
the
way
that
whole
time.
A
J
J
You
know-
and
you
say,
like
hey-
you
probably
should
get
a
CV
number
for
this
or
hey.
You
should
open
and
get
a
security
advisory
for
this
or
hey.
You
know
and
there's
a
lot
of
what,
like
you
know,
so
how
what?
What
do
you
think
the
best
way
to
educate
the
I
mean?
Besides
doing
this
work,
because,
like
you,
but
again,
they
don't
watch
these
talks.
J
How
can
GitHub
help
assist
education
in
in
in
helping
maintainers,
understand
the
disclosure
process
and
how
that
process
works
for
their
vulnerability,
especially
if
a
vulnerability
or
something
like
that
has
become
something
they
are
now
aware
of
like?
How
can
we
enable
them
to
understand
what
they
mean?
What
their
part
is
in
that
Madison.
F
I
was
gonna,
say,
I
think
evangelizing
it
where
they
are
where
maintainers
are,
where
developers
are
making
this
information
easily
accessible,
freely
accessible.
It's
it's
in
the
docs
we're
going
to
be
talking
about
this
forever
I'm
going
to
be
evangelizing.
This
forever.
I
love
this
feature
and
I
think
there's
a
lot
of
really
positive
incentive
for
maintainers
to
want
to
turn
this
on.
The
information
will
go
directly
to
them.
It
takes
out
any
other
potential
third
parties.
F
It
makes
it
easier
for
researchers
they'll
be
able
to
hopefully
respond
faster
it'll
lead
to
better
communication,
better
information,
ideally
a
more
polished
final
product,
with
great
vulnerability
information
that
can
could
result
in
alerting
their
users
more
easily,
especially
if
they're
using
the
GitHub
platform.
So
we
we're
I
am
personally
involved
in
a
number
of
best
practices
too
about
this
for
maintainers
for
reporters
I've
been
involved
in
like
so
so
many
coordinated
vulnerability
disclosures
best
practices.
F
My
background
was
working
on
the
sort
coordination
team,
international,
coordinating
vulnerabilities
on
an
international
scale,
so
I
am
personally
really
passionate
about
this.
So
I
think
sharing
this
information
where
maintainers
are
on
GitHub
at
maintainer
conferences.
At
developer
conferences
anywhere,
they
are
if
we
can
share
this
information
and
make
it
as
as
obvious
as
possible,
and
it
is
easy
for
them
to
make
use
of
it.
I
think
it'll
increase
the
likelihood
and.
A
This
is
the
way
that
it
used
to
be,
and
this
is
how
it's
working
now,
and
so
that's
why
the
people
who
are
participating
here
and
who've
learned
about
private
vulnerability
disclosure.
When
you
have
some
success,
we
would
love
to
share
that
success
with
you
and
help.
Others
learn
how
they
can
do
it
for
themselves
too.
F
And
similar
to
what
Kate
said
earlier
too,
like
we
want
to
hear
all
of
the
feedback,
success
is
definitely
but
any
any
troubles,
any
conflicts,
any
anything
that
can
be
better
because
by
no
means
is
this
done,
and
Reporting
is
just
a
small
part
of
the
disclosure
process,
which
is
as
much
as
we
would
love
to
automate
this
and
throw
as
much
Tech
in
it
as
possible.
This
really
is
a
human-based
process,
so
we
want
all
of
the
feedback.
C
E
Yeah
I
will
say
as
well,
but
like
even
just
having
the
feature
on
like
things
about
like
cves
and
disclosure,
just
by
forcing
everyone
who
has
it
turned
on
into
the
GitHub,
like
ghca
GHSA,
like
process
at
the
bottom
of
the
screen,
there's
a
giant
request,
CV
button
and
then
once
you've
clicked
that
there's
a
disclose
button
so
like
it'll,
guide,
maintainers,
who
may
not
be
too
familiar
with
it.
But
they
turn
this
on,
like
it's
literally
step
by
step
button
by
button
through
what
you'd
expect
cve
disclose
and
like
it's
pretty
straightforward.
K
Yes,
open
refractory,
we
are
working
with
open
ssf
on
an
ambitious
project
to
actually
scan
the
entire
all
the
repositories
in
the
past.
In
the
pipei
repository
all
the
libraries
in
there
all
350
000
of
them
and
then
reporting
those
vulnerabilities
at
scale
to
the
maintainers,
so
Jonathan
also
is
working
on
similar
stuff,
but
he's
working
on
specific
vulnerabilities
that
are
across
multiple
repositories,
we're
working
on
different
vulnerabilities
that
can
be
on
different
repositories
and
and
Reporting
them,
and
so
speaking
with
medicine.
K
Yesterday
about
when
would
like,
we
can
build
a
bot
to
actually
do
these
reportings
and
then
the
other
thing
is.
When
do
we
actually
ask
the
maintain
like
enforce
the
maintainers,
to
turn
this
thing
on
by
default,
so
both
of
them
are
important
like
enforcing
them,
so
that
it's
done
by
default
now
doing
that
with
a
bot.
Thank
you.
D
Yes,
so
we'd
love
a
world
where
this
is
turned
on
for
every
single
repository.
We
cannot
force
that
on
maintainers
there's
a
lot
of
maintainers
with
very
different
needs.
It's
a
big
place
technology
and
so
there's
a
lot
of
you
know.
There's
there's
teeny
tiny
projects.
Who
would
you
know
who
would
have
very
few
vulnerabilities
and
there's
huge
massive
projects
who
already
have
like
huge
massive
flows
for
how
they
manage
vulnerabilities.
D
I
A
D
L
Two
questions
actually
coming
from
industry,
not
from
the
the
the
testing
side
or
the
maintainer
side,
but
Paolo
you
mentioned
about
a
third
party
validation
service.
Could
the
GitHub
security
team
be
that
third
party
validation
service
when
we
talk
about
private
right
again,
coming
from
from
the
industry
side?
Is
there
any
feedback
into
the
GitHub
security
team
to
to
perhaps
investigate
use
that
as
a
new
threat,
feed.
F
Do
so
so
we
have
a
curation
team
here
at
GitHub
who
works
on
our
advisory
database,
so
when
a
maintainer
publishes
a
GitHub
security
advisory,
that
feed
does
come
to
my
team.
Actual
human
beings
review
this
information
and
the
same
with
the
cve
requests
that
we
received
through
the
GHSA
feature.
All
of
that
is
reviewed
by
a
team
of
security
analysts
here
at
GitHub,
when
it
is
within
scope
for
the
ecosystems
that
we
support,
because,
unfortunately
we
can't
support
anything
again.
This
is
a
very
human-based
process.
F
We
can
include
it
in
our
database
and
generate
depend
about
alerts
which
is
wonderful,
so
that,
in
my
opinion,
is
a
huge
incentive
for
maintainers
to
turn
on
this
feature
and
make
use
of
it.
It's
a
great
way,
given
a
number
of
factors
that
we
can
reach
users
for
this,
so
GitHub
plays
a
sort
of
role
currently
in
the
way
that
we're
doing
that
we've
discussed
how
we
can
help
this
moving
forward
too.
F
So
we
have,
we
have
a
number
of
ideas
in
places
that
we
can
probably
improve,
because
again,
this
is
a
public
beta,
but
I
think
there's
a
lot.
A
lot
of
room
where
we
can
help
and
do
a
lot
of
good.
So
my
my
background
is
from
a
neutral
third
party
that
did
exactly
this
so
I'm,
personally,
very
passionate
about
it
and
I
think
it's
a
place
that
we,
we
could
have
some
good,
but
we
we're
not
there
yet.
L
D
M
I've
seen
this
from
both
sides
and
the
reality
is
that
I
think
that
this
program
is
a
great
program
but
I've
been
creating
GitHub
issues
for
problems
that
I
find
in
people's
repositories
for
years
yonks
and
they
ignore
them
right
and
they
just
delete
them
and
I
hope
that
with
this
and
you're
right,
if
they
turn
it
on
that's
great,
but
that
doesn't
mean
they're
necessarily
going
to
do
the
right
thing.
So
I
live
in
Australia
now
and
I.
M
Don't
know
if
anybody's
heard
about
this
little
breach
that
we
had
in
Australia
the
Optus
preach.
But
I
can
tell
you
that
that
event
has
changed
us
culturally
in
Australia.
So
we
give
a
crap
now
about
apis
and
endpoints,
and
so
my
point
in
bringing
this
up
is
to
say
forcing
the
industry
forcing
developers
pushing
them
a
little
bit
outside
of
their
comfort
zone
can
be
very
productive
and
I
guess
I'll
leave
it
at
that.
I
Do
you
all
have
any
like
four
thoughts
on
moderation
of
reports?
I've
had
to
hire
essentially
triage
teams
to
manage
report
coming
in
because
essentially
we
don't
have
time
to
triage
them
ourselves
and
a
lot
of
them
don't
have
a
signal
and
so
I
imagine
at
the
beginning.
This
won't
be
a
problem
because
there's
no
money
involved,
but
as
this
grows,
do
you
have
like
moderation,
thoughts
or
anything
like
that.
D
I
sense,
a
theme
in
the
feedback,
y'all
I,
think
yeah
I
feel
bad
I'm
going
to
say
the
same
thing
again,
but
again
you
know
we're
launching
this
MVP
right
now,
it's
all
free,
so
there
probably
won't
be
you
know,
reports
that
require
too
much
triage
or
moderation.
It's
people
reporting
Jonathan's
laughing.
D
A
D
Great
question:
so
if
you
are
the
admin
of
a
repository
that
you
would
like
to
enable
private
vulnerability,
reporting
on
and
a
whole
lot
of,
people
in
this
crowd
really
want
you
to
do
that.
Please
go
to
these
settings
of
your
repository
click
code,
security
and
analysis
on
the
left
hand,
sidebar,
and
then
it's
like
the
first
option,
so
you
just
have
to
click
enable
and
it's
on
so
repo
settings
code,
security
and
Analysis
First
Option
click
enable
there's,
not
an
org
level.
Setting
great
feedback,
Jonathan
Jonathan
is
asking
for
an
org
level.