►
From YouTube: Open source security: advisories and workflows to keep open source secure - GitHub Satellite 2019
Description
Presented by Bryan Clark, Senior Manager, Product Management, and Justin Hutchings, Senior Product Manager, Security/OSS Intelligence
Security is the most critical challenge in open source today, and the GitHub Team is investing in helping developers and teams work through their pain points. In this session, you'll learn how GitHub's tools are helping security researchers, maintainers, developers, and enterprises keep code secure.
About GitHub Satellite 2019
A community connected by code
Explore our interconnected community—and how collaboration turns ideas into innovations.
Join us in November at San Francisco's Palace of Fine Arts for GitHub Universe - https://githubuniverse.com/
A
We're
gonna
talk
about
open
source
security
yeah.
Thank
you.
So
here's
that
we're
gonna
do
this
on
this
breakout
session.
We're
going
to
talk
about
two
things,
kind
of
in-depth,
so
one
is
gonna,
be
key
aspects
of
the
security
advisories.
The
thing
that
we
shipped
today
and
then
we're
gonna
walk
through
a
bit
of
a
demo.
So
we
want
you
to
see
some
of
the
like
real
details
of
what
security
advisories
it
does
and
we're
gonna
give
you
like
the
overview
of
how
you
see
it
in
action.
A
You
can
also
follow
along
at
home
if
you
want
we'll
give
you
some
instructions
on
that
later.
So,
first,
let's
start
with
some
kind
of
common
security
processes.
So
we
talked
to
a
number
of
different
open
source
industry
groups
about
how
they
handle
vulnerabilities
and
what
they
do,
and
we've
been
looking
at
this
process
kind
of
from
the
lens
of
the
reporter
on
one
aspect
here
which
is
up
over
there
and
then
the
maintainer
on
the
other
side,
so
you're,
seeing
like
two
personas
and
how
they
deal
with
this
security
vulnerability
process.
A
So,
first,
let's
imagine
we
have
a
researcher
who
found
a
vulnerability
and
they'd
like
to
report.
It
first
step
there
as
they
need
to
find
the
repository
they
need
to
find
the
source
code.
Hopefully
this
is
pretty
easy
from
there.
What
they
need
to
do
is
understand
how
we
report
the
security
vulnerability,
how-do-you-do
cloak
like
disclose
this
often
this
is
like
embedded
in
a
readme.
This
is
somewhere
in
the
docs.
Whatever
the
security
process,
is
it's
a
little
bit
hidden
at
first,
sometimes
because
this
isn't
a
common
event
for
open
source
repositories
to
deal
with.
B
If
you
did
the
keynote
this
morning,
you
might
have
heard
about
the
security
policy,
and
you
know
the
key
aspects
that
we've
done
here
are
provide
really
good
discoverability
on
the
security
policy.
We've
we've
added
it
to
our
new
repo
security
tab
and
what
we've
done
is
make
this
also
very
easy
for
organizations
to
set
once
for
all
of
their
repos.
B
B
We
also
wanted
to
make
sure
that
we
actually
interrupt
users
when
they're
about
to
file
an
issue,
because
one
of
the
biggest
problems
that
we've
seen
with
security
vulnerability
reports
is
when
people
go
and
file
a
public
issue
as
soon
as
you
do
that
you've
just
released
a
zero-day
onto
the
world,
congratulations,
and
so
now
what
happens
is
if
you
have
a
security
policy
in
your
repo
will
actually
prompt
you
during
the
issue,
template
selection,
to
say
if
you're
reporting,
a
security
vulnerability.
Please
read
the
policy
and
report
it
the
right
way:
okay,.
A
So
now,
in
our
process,
a
researcher
can
use
what
is
hopefully
a
private
channel
email
or
a
mailing
list,
whatever
the
project
has
disclosed
as
their
processes
for
connecting
with
the
maintainer
x'
from
there.
Usually,
the
researcher
once
connected
discusses
the
vulnerability
that
they
found.
They're
talking
about
version
ranges
they're
talking
about
severity,
and
then
the
maintainer
often
agrees
okay.
This
is
a
vulnerability.
We're
gonna
go
ahead
to
the
next
step.
A
So
now
we
kind
of
jump
over
to
the
maintainer
perspective.
At
this
point,
the
maintainer
job
here
is
to
kind
of
coordinate
with
anyone
else
in
the
project,
so
it
could
be
other
maintainer
x'.
It
could
be
if
they
have
like
a
larger
group,
has
security
advisors
or
like
a
security
team
that
can
help
often
the
maintainer
x'.
Do
this
coordination
in
an
issue
and
what
we
call
a
shadow
repository.
A
B
You
know
the
the
big
challenge
that
we
get
with
these
shadow
repos
is
obviously
other
than
the
pain
of
just
managing
a
separate
repo
see
you
can
go
hide
from
your
public
users
and
contributors.
You
try
and
do
things
like
that
are
clever,
so
someone
reported
an
issue
to
you.
Maybe
through
your
hacker
one
or
your
email
address,
and
you
say:
I'm
gonna
bring
that
person
in
so
they
can
help
me
validate
this
particular
vulnerability
and
all
the
patches
I've
made
for
it
great
sounds
good.
So
far
the
challenge
is
after
you
finish
that
issue.
B
Did
you
remember
to
delete
them,
or
did
you
just
let
somebody
that's
seeking
bounties
sit
on
your
shadow
repo
with
full
access
to
all
of
the
security
patches
that
you
mean
to
make
that
are
not
yet
publicly
disclosed.
It's
a
really
common
problem
and
we
want
to
make
sure
that
anything
you
do
in
this
space.
We
we
make
really
easy
to
revoke
and
control
next,
please
so
in
the
maintainer
security
advisories.
What
we've
done
is
we've
defaulted,
the
security
set
to
the
smallest
set
possible
by
default.
B
So
when
you
come
in
with
a
new
maintainer
security
advisory,
you
start
out
just
with
your
organisation
owners
and
your
repo
admins.
We
think
those
are
the
people
that
are
most
trusted
for
security
fixes,
and
if
you
have
people
you
need
to
bring
in
whether
it's
part
of
your
engineering
team
that
aren't
admins
or
if
it's
an
outside
collaborator,
one
of
your
best
users,
one
of
the
security
researchers,
you
can
bring
them
in
and
give
them
access
just
to
this
particular
advisory
and
all
of
the
collateral.
A
So
the
next
step
here
maintainer
is
create
pull
requests
to
start
generating
these
fixes
they're
working
within
a
shadow
repository,
they've,
coordinated,
understood
the
problem
and
now
they're
trying
to
make
different
branches
fixes
against
those
branches.
In
order
to
finally
publish
something
that
it
will
actually
address
the
vulnerability
and
if.
B
You've
had
to
deal
with
this
before
you
know,
just
how
painful
it
is
right,
you're
trying
to
target
like
five
release
branches.
You
know
your
cordoning,
possibly
several
vulnerabilities
at
the
same
time,
the
bigger
your
project,
the
more
like
this
is,
you
know
we
talked
to
the
folks
from
rails
and
they
were
telling
us
just
how
painful
this
is
for
them
as
they
try
and
target
multiple
versions
and
deal
with
all
of
the
combinations
of
permissions
and
permutations.
So
we
put
together
a
space
in
the
security
vulnerability
security
advisory.
B
Excuse
me
where
you
can
create
a
temporary
private
Fork.
What
this
gives.
You
is
one
repo
that
is
directly
associated
with
that
advisory
and
you
can
put
all
of
your
patches
there
and
merge
them
in
one.
Go,
let's
a
look
at
the
next
one,
so
you
can
see
after
you've
created
your
temporary
private
Fork.
This
looks
normal.
It
looks
like
a
normal
repo
and
it
is
it's
just
locked
down
to
that
same
user
list
that
we
talked
about
in
the
previous
slides
and
you
can
go
ahead
next,
please
thank
you.
A
Well,
so
what
we're
doing
is
trying
to
wrap
up
the
entire
security
advisory
system
into
one
section.
One
thing
like
one
place
where
you
can
kind
of
view:
here's
the
discussion
here
are
all
the
fixes
we've
been
working
on
here,
the
people
we
have
access
to
because
now
you're
at
the
stage
where
it's
time
to
publish
right
it's
time
to
reveal
the
work
that
you've
been
doing
in
private
and
make
it
public.
So
here,
you're
gonna
merge
changes
into
your
public
repository
you're
gonna,
publish
packages.
You
can
often
do
this
via
CI.
B
Yeah,
absolutely
you
know
one
of
the
things
that
we
think
is
so
important
out
of
security.
Advisories
is
the
ability
to
alert
downstream
dependencies,
and
so
you
know
we
put
together
a
brief
form.
Most
of
the
fields
on
this
are
completely
optional,
just
asking
for
some
basic
things
that
github
can
use
to
help
codify
this
to
target
the
right
people
with
security
alerts.
So
we
asked
for
affected
versions
and
patched
versions,
but
very
importantly,
we
also
really
care
about
what
package
you're
actually
fixing.
If
it's
a
package,
we
know
that
many
repositories
have
many
packages.
B
I
picked
on
rails
earlier
there
are
a
mega
mono
repo
that
has
like
10
or
12
packages
that
drop
out
of
it,
and
so
it's
important
that
you
tell
us
what
specifically
you're
fixing
and
then
you
know
give
your
users
as
much
information
as
they
can
to
assess
the
impact
of
exactly
what
the
vulnerability
was.
We
know
not
everyone's
gonna
patch
immediately,
so
you
want
to
provide
as
much
information
as
you
can.
So
people
can
make
the
determination
on.
B
What's
the
right,
you
know
risk
to
reward
on
taking
the
patch
now
versus
waiting
until
maybe
they
have
a
better
time
to
release.
Finally,
on
here,
I
want
to
mention.
We
also
would
love
for
you
to
cross-reference
with
your
CVEs,
so
if
you're
a
CNA
or
work
with
the
CNA,
if
you
drop
that
in,
we
will
go
ahead
and
link
all
those
things
together,
we
won't
double
alert
and
so
that'll
really
help
with
the
alerting
process
downstream.
So
your
users
don't
see
anything
too
noisy
yeah.
A
All
this
data
that
you're
filling
out
here
this
is
what
goes
into
security
alerts.
So
this
is
what
users
are
gonna
see
when
they
get
a
security
alert
on
the
package
that
you've
created
an
advisory
for
so
we're
really
taking
a
lot
of
that
like
ability
to
alert
your
downstream
users
and
kind
of
bringing
it
in-house.
So
that
maintain
errs
have
that
option,
and
this
is
where
you're
filling
out
this
information
to
say.
Here's.
The
full
impact
here
is
a
recommended
fix
in
order
to
reduce
the
kind
of
burden
on
downstream
users.
B
Right
so
I
normally
like
to
do
these
live.
We
don't
have
the
AV
for
that,
but
what
we're
gonna
do
is
I
have
baked
a
demo
beforehand
and
if
our
folks
in
AV
will
play
the
video
please
we
will
walk
through
exactly
all
this
I'll
narrate
live
there
we
go,
it
is
alright.
So
you
know,
as
we've
talked
about
Security's
really
one
of
the
biggest
problems
facing
software
today,
so
I
have
a
demo
repo
that
we
put
together
and
github.
This
is
nothing
special,
but
I
learned
about
a
security
vulnerability.
B
I
have
an
eval
in
my
HTML
or
my
index.html.
It's
a
terrible
move.
I
know,
but
at
least
I
can
now
fix
it
right.
So
I'm
gonna
go
to
the
security
tab
and
start
by
creating
a
new
draft
Advisory.
There
are
no
tricks
here.
This
is
one
cut,
so
you
know
if
I'm
being
slow
on
the
screen.
It's
just
because
I
talk
too
much
so
we're
gonna
type
in
some
of
the
basic
details
and
what
you'll
notice
about
this
is.
It
looks
like
an
issue
and
that's
deliberate.
B
We
really
want
to
make
sure
that,
when
we're
going
through
and
creating
these
advisories,
we
create
the
smallest
amount
of
friction
possible
to
get
you
started
and
working
with
the
other
collaborators.
On
your
repository,
we
want
to
make
sure
that
you
get
the
conversation
started
so
that
you
can
get
into
the
fix
as
fast
as
possible.
B
At
this
point,
we
have
a
draft
Advisory
now
I
showed
you
earlier
how
you
can
add
collaborators,
but
you
know
in
this
case
I
think
the
best
move
is
just
to
go
straight
to
the
patch
I
know
where
the
bug
is.
I
know
how
to
fix
it.
So
what
I'll
do
is
I'll
go
ahead
and
create
a
temporary
private
Fork
on
large
repos.
This
might
take
a
couple
minutes
that
you
know
we're
actually
creating
a
fork
if
it's
a
big
repo,
it
might
take
a
minute
this
one's
really
small.
B
Okay,
so
from
here
all
we're
gonna
do
is
we're
gonna
open
the
repo
and
you
could
click
on
that
link.
I
didn't
actually
know
that
until
a
couple
days
ago,
so
I
copied
and
pasted
and
I'm
just
gonna
go
into
the
repo
and
make
a
change
in
index
dot.
Html.
So
I
mentioned
there
was
an
eval
here.
You
can
see
right
there
in
the
search
text.
We
have
the
eval
statement.
That
was
clearly
a
terrible
mistake
that
should
have
been
removed
earlier,
so
we'll
just
go
ahead
and
knock
that
out
and
create
a
pull
request.
B
You
know,
none
of
this
should
look
weird.
This
is
all
your
normal
process,
even
though
you're
part
of
a
security
advisory
here,
everything
should
feel
really
natural
and,
like
you,
don't
have
to
bring
a
lot
of
extra
knowledge
or
tools.
One
thing
that's
really
important:
here
we
don't
run
any
CI
and
we
don't
run
any
tests
at
PR
time
and
the
reason
for
that
is
we
don't
want
a
risk
disclosure
of
the
vulnerability
before
you're
ready
to
publish.
B
So
once
you
have
all
of
your
patches
ready,
then
your
your
base,
repos
CI,
can
run
all
right.
So
we
have
the
the
pull
request
ready
and
you
can
see
that
it's
one
click
if
I
want
to
merge
this
and
get
it
ready
to
go
as
Brian
mentioned
earlier.
We
know
a
lot
of
repos
have
a
continuous
integration
suite
that
may
take
minutes
or
hours
or
days
to
run.
B
In
this
case,
there's
no
there's
no
package,
there's
no
library,
so
all
I
really
need
to
do
is
type
in
a
version.
Number
I
could
go
into
more
detail
about
some
of
the
things
around
the
impact,
but
for
the
sake
of
expediency,
I'm
just
going
to
go
ahead
and
publish,
and
what
happens
when
we
finish
this
publish
process.
B
When
we
hit
the
publish
button,
this
will
immediately
become
public
to
all
users
in
the
repo.
So,
if
you
go
to
the
security
tab,
you'll
be
able
to
see
any
of
the
published
advisories
available
there.
So,
regardless
of
whether
you
have
downstream
dependencies
or
not,
your
users
will
have
transparency
into
the
security
things
that
you've
made
the
choice
to
fix.
B
So
last
button
here
is
the
publish
button
and
we
will
press
that.
One
final
comment
that
I
want
to
make
on
this.
One
is
once
you've
published.
This
goes
into
a
review
queue
that
we
run
at
github
and
the
key
point
that
we're
trying
to
make
there
is.
We
want
to
make
sure
that
anytime,
you
use
one
of
these
advisories,
that
we
have
all
the
right
metadata
and
that
we
can
target
the
alerts
to
the
right
people.
B
If
we
don't
need
to
send
alerts,
we
certainly
won't,
but
we
want
to
make
sure
we
don't
have
duplication.
You
know
we
talked
about
all
the
white
source
data
that
we're
pulling
in.
We
do
not
want
to
have
multiple
alerts,
so
we
have
individual
engineers
that
evaluate
each
one
of
those
alerts
and
make
sure
that
we
don't
double
alert
with
that
five
minutes
in
and
we've
gone
through
the
entire
process
of
creating
a
draft
working
on
a
patch
merging
the
patch
and
publishing
it
back
to
github.
A
So
yeah
like
we
want
to
encourage
you
to
actually
try
this
out.
Like
security
is
a
process
you
can
create
your
own
test
repository.
You
can
then
generate
a
fake
package
JSON
file
if
you
want
and
then
go
to
your
Security
tab,
open
up
a
draft
security,
advisory
and
kind
of
run
through
this
whole
thing
yourself,
don't
publish
it
to
us,
because
we
don't
want
those
things
you
can.
A
You
can
try
but
like
run
through
the
whole
process
like
test
it
out,
because
when
this
actually
happens,
when
you
actually
get
a
vulnerability
reported,
you
want
to
have
like
seeing
the
whole
process
like
have
familiarity
with
it
before
that
kind
of
Black
Swan
event
happens
to
you
or
one
of
the
projects
you
maintain
absolutely
next
up.
We
have.
A
B
A
Our
plan
is
to
we're
gonna
come
down
front
and
kind
of
be
available.
Justin
and
I
will
also
be
I'm,
pointing
to
wherever
the
ask
github
group
is
it's
like
down
through
the
floor.
We'll
also
be
down
there
to
kind
of
field
questions.
If
you
have
questions
or
concerns,
you'd
like
to
bring
up
we'd
love
to
talk
through
those,
so
any
questions
out
there
in
the
audience.
Anyone
want
to
come
up.
B
C
C
B
C
B
I
just
want
to
finish
by
saying
thank
you,
everyone
in
the
community
for
caring
about
this.
You
know
one
of
the
things
that
we
really
hope
to
do
with
this
tool
is
help,
make
it
easier
for
all
of
you
to
disclose
and
fix
your
security
vulnerabilities
in
the
right
way.
Because,
ultimately,
you
know
software
runs
on
trust,
and
you
know
NAT
showed
this
morning
the
data
that
we
have
about
exactly.
B
You
know
how
many
contributors
you
have
how
many
open-source
dependencies
everyone
has
and
you
know
security
relies
on
all
of
us,
we're
all
security
engineers
and
we
all
have
to
take
responsibility
for
doing
disclosure
and
patching
in
the
right
way.
So
we
hope
these
tools
will
help
you
and
we
appreciate
everybody's
attention
to
this
problem
because
it's
it's
super
amazing,
to
see
this
kind
of
turnout.
Thank.
A
You
and
reach
out
to
us
either
if
you
want
to
work
on
this
advisories.
If
you
want
improvements
or
changes
connect
with
us,
however,
you
can,
if
you
have
a
vulnerability,
that's
being
reported
and
you're
actively
working
in
a
security
advisory.
Also
reach
out,
we
can
be.
You
can
use
the
collaborators
list.
To
add
us.
Add
people
from
our
team
into
there
to
help
you
out
like
this.
This
shouldn't
be
a
thing
that
you
do
alone,
just
like
NAT
said
in
the
keynote
right
this.
This
isn't
a
solitary
activity.