►
From YouTube: Scaling the security researcher to eliminate OSS vulnerabilities once and for all - Universe 2022
Description
Hundreds of thousands of human hours are invested every year in finding common security vulnerabilities with relatively simple fixes. These vulnerabilities aren’t sexy, cool, or new, we’ve known about them for years, but they’re everywhere! The scale of GitHub and tools like CodeQL enable one to scan for vulnerabilities across hundreds of thousands of OSS projects, but the challenge is how to scale the triaging, reporting, and fixing. n this session, Jonathan Leitschuh will cover a highly scalable solution for fixing vulnerabilities—automated bulk pull request generation. Jonathan will discuss the practical applications of this technique on real-world OSS projects. He will also cover technologies like CodeQL & OpenRewrite (a style-preserving refactoring tool created at Netflix and now developed by Moderne).
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
Thank
you
hi
everybody
and
welcome
to
scaling
the
security
researcher
to
eliminate
open
source
security
vulnerabilities
once
and
for
all.
My
name
is
Jonathan
lightshu
I'm,
a
software
engineer,
and
software
security
researcher
I
am
a
get
up
star
and
GitHub
security,
Ambassador
and
I'm.
Also
the
first
ever
Dan
Kaminsky
fellow
at
human
security.
You
can
find
me
on
Twitter
at
J
lightsu
and
on
GitHub
under
the
same
handle
a
little
bit
of
a
disclaimer.
A
For
those
of
you
who
don't
know,
Dan
was
a
famous
security
researcher,
known
for
a
famous
vulnerability
in
DNS
back
in
2008,
he's
also
known
for
his
compassion
and
kindness
in
the
security
community,
and
unfortunately,
he
passed
away
last
year
and
the
Dan
Kaminsky
Fellowship
was
created
to
sponsor
a
fellow
to
work
on
a
project
that
helps
improve
the
security
of
the
internet.
And
so
that's
the
work
that
I've
been
doing
for
the
past
year
here.
A
So
spoilers
we're
gonna
jump
ahead.
You
know
to
the
punch
line
so
I
generated
over
100
150,
pull
requests
to
fix,
zip
slip
across
the
open
source
ecosystem,
primarily
in
the
Java
ecosystem.
The
story
starts
with
a
simple
vulnerability,
and
this
vulnerability
was
the
use
of
HTTP
to
resolve
dependencies
in
my
corporate
companies.
Gradle
build
and
I
was
curious.
A
How
I
had
gotten
this
code
into
my
build,
because
there
was
a
security
vulnerability
and
the
answer
to
that
question
was
that
I
had
actually
copied
and
pasted
this
snippet
of
code
from
an
open
source
project
that
I
was
relying
upon.
Why
is
the
use
of
https
important?
It's,
because,
if
you're
not
using
https
in
to
resolve
your
dependencies
and
you're
not
doing
additional
artifact
Integrity
checking,
it
can
result
in
your
artifact
getting
compromised
during
by
an
attacker
in
the
middle
vulnerable
or
by
an
attacker
in
the
mid
who's.
A
In
the
middle
of
your
connection-
and
this
can
lead
to
you-
know
the
artifact
that
you're
downloading
the
jar
file
or
being
compromised
and
have
an
additional
code
injected
into
it.
That
can
compromise
your
CI
CD
pipeline
or
your
developer
machine,
and
this
is
an
example
of
that
vulnerability.
Existing
in
Maven
Palm
files,
so
Maven
is
used
to
build
50
of
all
the
Java
ecosystem.
A
It
existed
in
organizations
like
spring
Apache,
Red,
Hat,
kotlin,
jet
brains,
Jenkins
Gradle,
The,
Groovy,
Alaska
search,
Eclipse,
Foundation,
it's
on
top
of
that
Oracle
was
vulnerable.
The
National
Security
Agency
LinkedIn
stripe
I
found
this
in
in
the
open
source
projects
of
all
these
different
organizations
and
when
I
reached
out
to
Maven
sonotype
Maven.
Sonar
type
is
the
equivalent
of
npm
to
the
JavaScript
ecosystem
and
Pi
a
pip
for
the
python
ecosystem.
A
When
I
reached
out
to
maven
type,
they
said
that
25
percent
of
their
traffic
was
still
using
HTTP
in
June
of
2019.
and
so
I
reached
out
to
the
major
artifact
servers
in
the
Java
ecosystem,
Maven
Central,
J
Center
spring
and
the
Gradle
plug-in
portal,
and
pushed
forward
an
initiative
to
decommission
the
use
of
HTTP
in
favor
of
https
only
for
the
entire
Java
ecosystem
and
these
org.
A
And
so
you
can
imagine
what
might
have
happened
on
January
15
2020
broken
software
lots
of
broken
software.
Unfortunately,
but
we
stopped
the
bleeding
and
we
fixed
this
glaring
security
vulnerability
impacting
the
Java
ecosystem.
But
what
about
the
other
repositories?
Unlike
pip
and
npm,
Java
uses
a
lot
of
different
repositories.
P
companies
can
run
their
own
artifact
servers,
so
this
fixed
it
for
the
top
most
commonly
used
artifact
servers.
But
what
about
the
rest
of
the
ecosystem
and
I
thought?
Why
don't
we
just
fix
the
code?
A
A
You
know
entire
the
entire
ecosystem
of
a
language
to
find
this
vulnerability
and
from
that
list
I
was
able
to
get
a
list
of
vulnerable
projects,
and
for
this
code,
query
GitHub
awarded
me
a
2
300
bug
Bounty
for
just
contributing
it
back
as
a
query
that
now
any
open
source
project-
or
you
know,
organization
using
GitHub,
Advanced
security-
is
now
consuming
and
will
be
able
to
alert
for
vulnerabilities
against
their
infrastructure
and
their
software,
and
then
I
wrote
a
pull
request
generator.
The
first
version
of
it
was.
A
It
was
a
python-based
pull
request
generator,
it
was
a
wrapper
over
github's,
Hub
CLI
and
it
had
one
nasty,
regular
expression
and
a
lot
of
bouncing
off
of
github's
rate
limiter,
and
this
is
the
code
there's
an
underlying
engine
behind
here.
But
this
is,
you
know
the
commit
message
and
the
regular
expression
required
to
make
the
fix
and
to
drill
into
the
regular
expression.
The
reason
that
I
used
a
regular
expression
is
because
any
X
XML
parsers
that
you
use
in
the
industry
when
they
pull
the
file
content
into
the
parser.
A
A
However,
the
problem
is,
if
you
use
regular
Expressions,
to
solve
your
problem,
then
you
have
two
problems:
the
problem
you
originally
had
and
the
regular
expression-
and
so
regardless
of
that
it
worked
I
generated
pull,
requests,
1596,
polar
Crest,
and
this
is
an
example
of
the
code,
the
diff
that
was
generated
in
total
I
generated
1596
pull
requests
to
fix
this
vulnerability
at
scale,
and
this
was
done
in
2020
as
of
today.
There's
about
a
40
merge
rate
of
those
pull
requests,
they're
originally
created.
A
This
is
my
contribution
graph
for
2020..
You
can
see
two
major
Peaks
where
I
actually
had
you
know
engaged
in
these
Polar
Express
generation
campaigns,
so
I
have
a
problem
as
a
security
researcher
and
the
problem
I
have
ADHD
and
that's
not
my
problem.
Adhd
is
not
my
problem
but
I
chase,
squirrels,
I
love,
finding
vulnerabilities
and
I
love,
reading
vulnerability,
disclosures
and
the
problem
that
I
have
is.
A
If
I
read
through
a
vulnerability
disclosure
I
will
me
usually
be
like
I
wonder
where
else
this
vulnerability
exists
and
the
tools
that
I
have
like
GitHub
code
search
and
code
ql.
Allow
me
to
find
vulnerabilities
at
scale
across
open
source
and
the
problem
that
I
have.
Is
that
I'm
finding
too
many
vulnerabilities
as
an
example?
This
is
a
result
from
lgtm.com
which
is
owned
by
GitHub
all
the
results
of
a
code,
ql
flagging
down
zip
slip,
which
is
a
pretty
critical
security,
vulnerability
and
we'll
dive
into
more
later.
A
But
there
are
pages
and
pages
and
pages
of
this
that
you
can
find
I
need
automation
to
to
fix
these
vulnerabilities
at
scale,
because
I
can't
individually
as
a
reporter
report
to
all
these
individual
projects
that
are
vulnerable.
There's.
Just
not
enough
of
my
time
and
enough
of
me
to
do
that,
and
this
is
where
open
rewrite
comes
in
the
underlying
basis
for
open
rewrite.
Is
that
open
rewrite
extracts?
A
While
your
compiler
is
running
your
Java
compiler
or
any
other
compiler,
it
extracts
the
abstract
syntax
tree
from
your
code
and
and
the
abstract
text
tree
is
the
thing
that
your
compiler
operates
on
to
generate
the
byte
code
or
whatever
you
need.
The
problem
with
the
abstract
syntax
tree
is
that
the
abstract
syntax
tree.
If
you
were
to
dump
the
abstract
syntax
tree
back
out
into
source
code,
you
would
have
no
white
space.
All
the
comments
would
be
lost.
A
All
the
additional
contacts
will
be
lost,
and
so
you
can't
make
transformations
of
source
code
based
just
upon
the
AST,
and
so
we
need
what
open
rewrite
offers
and
unlocks
is
a
format
preserving
abstract,
syntax
tree.
All
the
comments
are
preserved,
all
the
white
space,
all
the
tabs,
all
of
that
information
about
the
source
code
is
preserved,
but
in
an
abstract,
syntax
tree
that
you
can
manipulate
and
make
changes
to
and
then
dump
back
out
into
source
code
open
rewrite
while
it's
parsing,
your
source
code
also
extracts
information
from
your
source
code.
A
Like
does
this
project
use
tabs?
Does
this
project
use
spaces?
Do
they
put
braces
on
a
new
line
and
so
new
code
can
get
generated,
looking
like
the
surrounding
code,
which
is
really
important,
because
you
want
to
make
sure
that,
when
you're
generating
code,
it
looks
like
the
code
that
the
maintainers
created
so
that
you're
not
getting
complaints
of
this
doesn't
match
the
formatting
of
the
code
thanks
for
the
contribution,
but
we
can't
accept
it
and
on
top
of
the
preserving
the
style
open,
rewrite
is
also
a
fully
type
attributed
AST.
A
So
this
is
an
example
of
this
log
statement.
Is
that
log
for
J?
Is
that
slf
for
J?
Is
that
log
back?
You
might
need
to
know
that
to
make
a
transformation
to
fix
a
vulnerability
or
fix
something
in
your
code,
I
can't
imagine
there
ever
being
a
security
vulnerability
in
a
massive
logging
framework
used
by
the
entire
industry
log4j.
A
So
you
know
that's
why
this
stuff
is
important
and
open
rewrite.
The
AST
is
both
syntactically
and
semantically
aware.
You
can
see
that,
with
with
all
this
information,
with
all
the
type
information
and
all
the
spaces,
you
end
up
with
a
much
more
Rich
graph.
There's
actually
six
thousand
nodes
missing
from
this
graph
on
the
right,
because
if
we
were
to
add
them,
it
would
be
too
dense
for
you
to
actually
be
able
to
see
anything
meaningful.
A
Let's
assume
that
we
need
to
inject
this
little
bit
of
code
to
fix
the
vulnerability,
zip
slip
which
we're
going
to
talk
more
about
later
open
rewrite
comes
with
a
templating
engine
to
generate
an
AST
for
your
code
to
let
you
ins
insert
it
into
a
specific
location
in
your
source
code
to
make
Transformations,
and
it
also
comes
with
a
coordinate
system
that
lets
you
specifically
place
it
at
a
specific
coordinate
and,
and
that
lets
you
target
specifically
the
changes
that
you
need
to
make
to
fix
a
vulnerability
or
fix.
You
know
whatever.
A
You
need
in
your
source
code
and
so
that
lets
us
inject
this
fix
into
the
AST
in
a
way
that
matches
the
formatting
and
styling
of
the
surrounding
source
code
and
so
what's
possible.
Now
what
other
vulnerabilities
can
we
fix
with
the
unlock
that
open
rewrite
provides
as
part
of
my
research
I
looked
at
three
different
vulnerabilities,
temp
directory
hijacking,
partial
paths,
virtual
and
zip
slip.
Unfortunately,
given
the
time
that
I
have
I'm
only
going
to
have
the
time
to
cover
two,
so
we're
going
to
jump
right
into
partial
path,
reversal
and
zip
slip.
A
The
first
vulnerability
that
we're
going
to
talk
about
is
part
path.
Reversal,
partial
past
reversal.
Let's
assume
that
you
have
logic
that
you
want
to
sandbox
to
a
single
directory
or
a
user.
Let's
say
user
Sam
and
you
have
another
user
local
on
that
system,
and
you
have
user
Samantha
partial
past
reversal
allows
an
attacker
to
access
a
sibling
directory
with
the
same
prefix.
A
Normalizes
the
file
to
remove
past
reversal
like
dot
dot,
slash
sort
of
payloads
that
may
be
supplied
by
a
user,
and
but
the
problem
with
Git
canonical
path
is
that
when
you
are
working
with
a
new
file
and
you
supply
a
string
that
has
you
know
an
trailing
slash
when
you
call
get
canonical
path
on
it,
you
end
up
with
a
string
that
does
not
have
that
trailing
slash
on
it.
And
so,
when
you
do
a
starts
with
comparison
on
it,
you
can
be.
It
allows
for
bypass.
A
So
as
an
example,
let's
assume
that
you've
got
user
Sam
as
the
directory
that
you're
trying
to
sandbox
to
and
you'll
use
our
supplied
input.
That
comes
in
that's
a
path
to
personal
payload
when
this
gets
appended
together
and
gets
normalized
by
get
canonical
path.
You'll
see
that
this
starts
with
Clause
is
no
longer
valid,
and
this
I
o
exception
does
not
get
thrown,
even
though
this
is
breaking
out
of
this.
This
logic
that
this
guard
is
intended
to
protect
against.
A
So
the
fix
for
this
is
to
Simply
re-add
the
file
separator
on
the
end
of
the
path.
However,
that's
less
than
ideal,
because
you're
still
comparing
strings,
the
better
solution
is
to
use
the
Java
path
object
to
compare
strings.
This
starts
with
method,
for
that
does
the
correct
comparison
in
a
way
that's
guaranteed
to
be
safe.
So
how
do
we
find
this
vulnerability?
We
need
to
look
for
subjects
and
arguments
that
our
get
canonical
path
and
from
there.
A
We
also
want
to
look
for
cases
and
make
sure
that
that
past
separator
is
not
being
appended
because
something
critical
about
this
is
we
don't
want
to
fix
vulnerabilities
that
are
not
present,
because
if
you
do
that
you're
going
to
end
up
just
upsetting
maintainers
you're
going
to
waste
time,
you
just
you
know,
you
want
to
make
sure
that
you're
not
doing
that.
So
you
want
to
only
fix
vulnerabilities
that
are
really
truly
vulnerabilities.
It
can't
just
be
that
easy,
though
right
just
those
two
things.
Well
developers
write
code
in
a
lot
of
different
ways.
A
Let's
say
that
a
developer,
instead
of
putting
everything
is
one
line.
They
instead
extracted
one
of
those
components
into
a
variable,
or
they
extract
the
argument
into
a
variable
or
they
have
the
fix
specified
in
a
variable.
How
do
you
determine
whether
or
not
that's
vulnerable
or
not?
We
need
this
New
Concept,
and
this
concept
is
called
data
flow
analysis.
Now,
data
flow
analysis
allows
us
to
track
through
the
code
that
there
is
a
variable
flowing
to
this.
A
If
check
and
also
lets
us,
you
know
we
can
do
multiple
bits
of
data
flow
to
track
logic,
multiple
in
multiple
places
in
our
source
code,
but
it
also
lets
us
track
through
intermediate
variables,
so
it
can
be
really
powerful
to
allow
us
to
determine
a
vulnerability's
presence
or
not.
Dataflow
allows
us
to
uncover
hard
to
find
vulnerabilities
and
prevents
false
positives.
The
dataflow
API
is
very
similar
to
codeql's
dataflow
API.
So
if
you're
familiar
with
writing,
codeqql
I
wrote
the
API
to
let
you
translate
that
knowledge
very
easily
between
codeql
and
open
rewrite.
A
Also,
let
me
translate
my
knowledge
much
easier
and
so
putting
it
all
together.
This
is
an
example
of
the
fix
for
partial
paths
reversal.
You
can
see
the
change
made
to
to
fix
the
code
to
use
the
correct
starts
with
call.
So
the
second
vulnerability
that
I
want
to
discuss
with
you
all
is
a
vulnerability
called
zip
slip.
A
So
zip
slip
is
a
past
reversal,
vulnerability
that
exists
while
unpacking
zip
file
entries.
So,
let's
assume
that
you're
being
supplied
a
potentially
malicious
untrusted,
zip
file
and
you're
unpacking
that
into
a
directory
as
a
software,
you
know
in
your
code
ZIP
slip
it.
The
vulnerability
allows
a
malicious,
zip
file
to
unpack
its
contents
into
destination
directories
unintended
by
the
original
author
of
the
code,
so
you
may
specify
a
destination
directory,
but
because
the
zip
entry,
which
is
Zips
are
basically
entries
to
contents
of
file.
A
If
the
entry
is
a
path
to
Virtual
payload
when
it's
appended
to
the
destination
directory,
you
can
escape
that
directory
and
that
can
lead
to
remote
code
execution
and
overriding
other
sensitive
files
on
the
system
leading
to
compromise
of
the
system
at
large.
And
so
this
is
the
zip
vulnerability
in
Java
and
the
vulnerability
exists,
because
the
entry
is
being
trusted
to
be
used
to
create
a
file
object
and
then
that
file
is
being
written
out
to
when
the
file
output
stream
is
created.
A
The
shell
run
arbitrary
code,
zip
slip
is
complicated
for
most
fixing
perspective
and
the
reason
that
it's
complicated
is
because,
while
this
is
a
valid
fix
for
this
vulnerability,
where
you
have
this
guard
prior
to
the
unpacking
logic,
there's
also
another
valid
fix,
and
the
other
valid
fix
is
this,
where
you
put
the
logic
inside
of
an
if
check,
and
so
how
do
we
know
between
these
two?
If
there's
not
a
vulnerability,
if
there
is
a
vulnerability,
because
both
of
these
are
valid
fixes
for
this
again,
we
don't
want
to
fix
vulnerable.
A
We
don't
want
to
fix
non-vulnerable
code
because
we're
just
wasting
time
we're
going
to
offset
maintainers.
So
we
need
this
New
Concept
called
control
flow
analysis.
Control
flow
analysis
allows
us
to
differentiate
between
vulnerable
code
and
non-vulnerable
code
control,
flow
analysis
and
control.
Flow
control
flow
is
a
graph
representing
the
steps
of
a
program
and
how
it
flows,
and
there
are
these
Concepts
called
basic
blocks.
A
So
we
can
determine
for
this
bit
of
code
what
the
control
flow
graph
is
and
see
that
there
is
a
control
flow
node
that
guards
correctly
against
this
unpacked
logic
and
that
because
of
this
guard,
it's
not
vulnerable,
and
so,
when
we
put
all
this
together,
we
can
generate
a
a
fix
that
is
only
fixing
vulnerable
code
and
not
fixing
non-vulnerable
code.
Additionally,
those
this
fix
can
be
even
more
complicated
based
upon
the
surrounding
code
and
unpack
variables
and
move
them
around
because
of
the
power
that
open
rewrite,
provides
us.
A
And
so
let's
talk
about
pull
request
generation
if
you've
got
a
security
vulnerability,
everybody
gets
a
pull
request.
So
there's
a
problem
with
pull
request
generation
and
one
of
the
major
problems
of
pull
request
generation
is
how
fast
we
can
generate
pull
requests
in
order
to
generate
a
pull
request.
I
know
that
a
lot
of
you
are
GitHub
users
and
git
users.
A
That's
going
to
be
unique
so
that
you
don't
end
up
with
those
name
conflicts.
And
then
you
want
to
push
your
changes
and
then
create
a
pull
request
on
GitHub
and
three
of
these
things.
Forking
the
repository
rename
the
repository
and
creating
the
pull
request
on
GitHub,
our
GitHub
API
calls,
and
each
GitHub
API
recall
according
to
the
documentation,
requires
that
you
wait
at
least
one
second
per
per
operation
per
user,
and
on
top
of
that,
they
also
have
secondary
and
tertiary
rate
limits
that
are
limited
documentation.
A
One
of
them
is
not
documented
at
all,
which
basically
says
back
off
completely
and
just
wait
some
X
period
of
time.
That's
not
really
defined
so
keeping
those
things
in
mind.
The
answer
is
basically
just
slow
down
and
stop.
You
know
you
generate
pull
requests
at
a
much
slower,
Pace
than
you'd
really
think
you'd
you'd
want
to,
and
so,
if
there's
anybody
from
GitHub
watching
this
talk,
if
you
could
stop
rate
limiting
your
API
or
at
least
reduce
it
a
bit,
it
would
make
my
life
a
lot
easier
as
a
security
researcher.
A
So
we
made
it
this
far.
The
vulnerability
has
been
detected,
we've
detected
the
style,
so
we
can
generate
code.
Looking
like
the
surrounding
style,
the
code
has
been
fixed
and
a
diff
has
been
generated
and
the
rate
limit
has
been
bypassed.
How
do
we
actually
do
this
for
all
the
repositories
across
open
source?
So
at
this
point,
I
want
to
introduce
you
to
modern.
Modern
is
free
for
open
source
projects.
A
They
index
over
7
000,
open
source
projects,
and
it
lets
you
run
open,
rewrite
Transformations
at
scale
and
it
lets
you
generate
and
update
pull
requests.
All
the
pull
requests
you're
generating
modern
is
the
parent
company,
maintain
painting
open
rewrite
and
there
are
over
800
recipes
that
have
been
developed
to
fix.
You
know:
vulnerabilities,
perform
framework
migrations
like
migrating
from
June
4
to
Jane
at
five
spring,
for
our
older
versions
of
spring
to
newer
versions
of
spring
and
then
also
for
security
research.
A
It
lets
me
automate
the
generation
of
pull
requests
to
fix
these
vulnerabilities
at
scale
across
open
source.
So
when
I've
identified
the
vulnerable
projects,
I
can
run
the
recipe
against
all
these
projects
and
generate
a
diff
and
from
that
diff
I
can
select
all
those
projects
and
say
I
want
to
generate
a
pull
request
for
these
things,
and
so
I
can
say
that
I
want
to
specify
the
commit
message.
The
commit
title,
the
pull
request
title
the
branch
that
I
want
to
generate
the
pull
request
against
the
organization
that
I
want.
A
The
pull
request
to
come
from
I
can
supply
my
gpg
key
and
the
private
key
and
then
generate
pull
requests
from
my
account
as
if
they're
coming
from
me,
and
they
are
coming
from
me
because
I
wrote
the
recipe
that
actually
generates
the
the
fix.
But
there
are
more
than
just
7
000
open
source
repositories
in
the
world.
How
do
we
find
the
vulnerability
that
we
wanted?
A
So,
finally,
let's
go
generate
some
open
source,
pull
requests
and
I
did
that's.
What
I
did
I
generated,
pull
requests
I've
generated?
Quite
a
few
pull
requests
in
my
career
just
covering
the
three
projects
that
I've
been
engaged
in
for
this
work
for
under
the
Dan
Kaminsky
Fellowship
I
generated
64,
pull
requests
to
fix
temporary
directory
hijacking
50
for
partial
path,
traversal
and
150
for
zip
slip,
I've
actually
generated
over
600
new
pull
requests
in
2020.
A
A
So
you
need
to
be
conscious
of
that,
and
you
need
to
communicate
that
in
a
way
that
respects
the
maintainer
and
the
project
that
that
the
for
the
code,
you're
fixing
and
so
I
include
details
like
the
impact
of
the
vulnerability,
how
how
the
vulnerability
can
be
exploited
and
why
the
fix
is
written.
The
way
it
is
there's
a
saying
out
there.
A
Lesson
two
be
a
good
commit
is
in
gpg,
sign
your
commits.
This
is
what
gpg
sign
commits,
look
like
they're
verified,
otherwise
you
might
get
impersonated
like
Linus.
Horvald
has
been
a
couple
of
times.
Unfortunately,
then
ccom
ccom
is
a
commit
format
if
you're
interested
in
a
commit
format
specifically
for
security
fixes.
This
might
be
something
that's
good
to
look
into.
I.
Don't
have
the
time
to
go
into
it
now,
but
it's
something
to
look
into
four
Lesson
Four.
A
A
Unfortunately,
this
is
what
you
get
when
something
goes
wrong
on
GitHub,
and
this
was
my
GitHub
profile
for
most
2020..
So
there
are
risks.
You
might
break
your
GitHub
account.
They
might
have
fixed
this,
but
I
still
recommend
using
your
personal
GitHub
account
for
this
work,
because
it
helps
the
maintainer
recognize
that
it's
coming
from
a
real
person
and
not
a
bot
or
an
organization
that
human
element
is
important
in
this
work.
A
Lesson
number
five
coordinate
with
GitHub
before
you
attempt
this
sort
of
work
reach
out
to
GitHub,
let
their
security
lab
know.
This
will
keep
you
from
getting
banned
or
at
least
keep
them
aware
of
what
you're
doing
they
want
to
talk
to
you
about
the
work
you're
doing
so
I.
Did
that
and
I
highly
recommend
that
you
do
that
too?
If
you
want
to
engage
in
this
work
and
then
lesson,
six
can
consider
the
implications
of
this
work
when
I
engaged
the
first
time
in
this
campaign
of
fixing
this
vulnerability.
I
got
this
issue.
A
Is
this
responsible
disclosure
and
I?
Don't
use
the
term
responsible
disclosure
I
use
the
more
nuanced
term,
coordinated
disclosure,
but
regardless
of
the
term,
the
answer
is
no.
This
is
full
disclosure
of
a
security
vulnerability
in
open
source
without
a
fix
you're,
oh
dang,
a
maintainer,
and
so
there
is
something
to
consider
about
this
work
and
the
risks
associated
with
that,
because
you
are
publicly
exposing
a
maintainer
and
the
project
to
risk
by
identifying
and
fixing
this
vulnerability.
A
So,
in
conclusion,
as
security
researchers
I
believe
we
have
an
obligation
to
society.
We
know
these
vulnerabilities
are
out
there.
There's
the
statistic
that
GitHub
provided
back
in
2020
for
every
500
developers.
You'll
only
have
one
security
researcher.
We
as
security
researchers,
are
heavily
outnumbered
and
there
are
more
vulnerabilities
than
we
can
possibly
dig
out,
but
here's
the
thing
as
security
researchers
we've
seen
these
same
vulnerabilities
again
and
again
and
again
in
pen
test
reports
in
bug
reports.
A
A
You
can
deploy
your
security
fixes
or
other
fixes
that
aren't
even
security
related
at
all
at
scale
then
join
the
GitHub
security
lab
and
open
right,
slack
channels,
and
if
you
want
to
get
involved
in
open
source
security,
research
or
open
source
security
in
general,
consider
joining
and
participating
in
the
open
source
security
Foundation.
There
are
meetings
happening
on
a
weekly
basis
and
there's
an
open
calendar.
You're
welcome
to
join
any
of
the
meetings.