►
Description
Find out what’s new in GitHub’s security products as we continue to build security into the developer workflow. We’ll make a major announcement in our supply chain security area, demonstrate the power of CodeQL for finding new vulnerabilities, and show how GitHub is helping security teams work with developers.
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
On
software,
so
the
security
of
that
software
is
critical.
Vulnerabilities
can
shut
down
International
infrastructure
and
disrupt
the
services
that
we
rely
on
over
the
last
three
years.
Software
security
has
made
the
headlines
more
times
than
any
of
us
would
like
as
the
home
for
software
development
GitHub
has
a
responsibility
to
help
I'm
gray,
the
vpa
product
at
GitHub
for
risk
for
the
security
features
that
we
build
to
help.
You
write
more
secure
code
for
the
last
four
years.
My
team
and
I
have
been
embedding
security
into
the
developer.
A
Workflow
we've
shipped
features
like
secret
scanning,
dependable
and
code
scanning
today,
I'm
here
with
some
of
the
team
to
tell
you
about
the
progress
we've
made.
The
lessons
we've
learned
and
what's
coming
next
I
want
to
start
with
three
critical
insights
that
underpin
everything
that
GitHub
is
doing
in
security
and
the
first
of
those
is
that
developers
are
at
the
heart
of
application.
Security
developers
write
the
fixes
for
vulnerabilities.
We
write
the
code
that
introduces
vulnerabilities
as
well
and
we're
the
ones
that
can
prevent
vulnerabilities
from
being
introduced
in
the
first
place.
A
The
second
Insight
is
that
software
security
can
be
something
that
we
collaborate
on.
We
all
want
the
software
that
we
write
to
be
secure,
but
we
also
want
the
open
source
code
that
we
rely
on
to
be
secure,
and
we
want
the
commercial
services
that
we
use
to
be
secure
to
there's
a
long
history
of
companies,
even
competitors,
working
together
on
software
security
and
just
like
we
all
benefit
from
open
source
and
the
collaboration
that
creates
it.
We
can
all
benefit
from
collaborating
on
software
security.
A
A
A
Some
of
those
changes
were
much
smaller,
like
making
it
possible
to
comment
in
a
pull
request
on
the
code
scanning
alerts
that
appear
there
and
those
small
improvements
add
up
they're
what
it
takes
to
build
security
tooling.
That
developers
want
to
use
every
day
and
of
course,
today
we've
got
some
announcements
that
we
made
earlier
in
the
keynote
you
heard:
Brittany
announce
private
vulnerability,
reporting
the
ga
of
coql
support
for
Ruby
and
an
expanded
security
Overview
at
the
organization,
Enterprise
level.
A
More
on
that
in
a
moment,
but
first
I
want
to
talk
to
you
about
something
we
launched
in
April
of
this
year
and
that's
secret
scanning
as
a
push
protection.
I
want
to
talk
to
you
about
secret
scanning,
because
it
is
a
great
example
of
the
difference
we
can
make
when
we
embed
Security
in
the
developer
workflow.
It's
also,
perhaps
surprisingly,
a
really
great
example
of
the
difference
it
makes
when
we
work
together
as
a
community.
A
A
So
what
do
we
do?
Well,
we
automatically
revoke
them
and
we
notify
the
owner
of
that
token,
and
it's
not
just
GitHub
tokens
that
we
do
that
for
we
work
with
60
Partners
to
help
keep
their
customers
safe
if
their
API
keys
are
leaked
in
GitHub.
Public
repos
here
are
just
a
few
of
the
new
partners.
From
this
year
we
onboarded
14
new
partners
over
the
last
12
months.
A
A
A
A
best
developer
experience:
it
would
be
better
if
we
prevented
that
leak
from
happening
in
the
first
place
and
that's
exactly
what
we
do
with
secret
scanning
as
a
push
protection
which
launched
in
April
for
GitHub
Advanced
security
customers
with
push
protection,
we
can
scan
pushes
before
accepting
them
and
if
they
contain
Secrets,
then
we
reject
them
last
month
that
helped
Advanced
security.
Customers
prevent
over
1
400
credential
leaks,
and
it
did
so
whilst
keeping
a
really
great
developer
experience.
A
A
A
If
you
want
to
learn
more
about
secret
scanning,
then
Mariam
sulacian
has
a
fantastic
talk
on
this
as
part
of
the
virtual
schedule.
I
highly
recommend
you
watch
it
when
you
get
home
from
universe,
but
I
hope
you
can
already
see
that
secret
scanning
is
built
for
developers
and
how
it
takes
a
community
approach.
B
You
know
open
source
is
such
a
ubiquitous
part
of
technology.
Today
it
can
be
easy
to
take
for
granted.
But
if
you
look
back
maybe
20
years
ago,
developers
like
you
were
writing
your
own
code
for
things
like
HTTP
databases
or
XML
parsing.
We
didn't
have
fancy
yaml
back
then
you
know
today.
These
are
things
we
all
rely
on
open
source
to
do
and
it
allows
each
of
you
to
build
your
experiences
faster
than
ever
on
a
huge
supply
chain
of
Open
Source
software.
B
It's
a
community
effort
and
I
want
to
look
back
on
some
of
the
ways
that
we've
partnered
with
members
of
the
community
to
make
dependabot
work
better
for
you.
This
year,
first
I'd
like
to
talk
about
language
support
over
the
past
year,
we've
added
support
for
three
new
languages
in
dependabot,
in
partnership
with
the
community,
starting
with
dart.
We
partnered
with
the
folks
in
Google
to
actually
deliver
Dart
support
when
they
contributed
that
directly
to
dependabot's
open
core
to
add
support
for
the
language.
B
These
Community
Partnerships
allow
us
to
meet
you
where
you
are
so
that
you
can
stay
on
top
of
the
latest
vulnerabilities
in
whatever
tooling
you
decide
to
use
now,
you
may
be
less
familiar
with
our
advisory
database.
That's
the
database
of
all
the
vulnerabilities
that
power
depend
upon
our
team
of
curators
reviews,
all
the
vulnerabilities
from
the
national
vulnerability
database,
of
course,
but
we
also
review
and
issue
cves
on
behalf
of
maintainers.
B
Thanks
to
your
efforts,
GitHub
is
the
largest
independent
cve
issuer
today,
and
a
really
unique
part
of
our
advisory
database
is
that
it's
truly
open
source.
You
can
check
it
out
at
github.com,
advisories
and
all
of
the
advisories
we
have
are
available
under
a
Creative
Commons
license
it's
free
for
everyone.
B
So
dependabots
come
a
long
way
this
year,
in
no
small
part
due
to
contributions
from
The
Wider,
open
source
community,
but
maintainers
told
us
there's
more,
we
can
do
to
help
them
with
a
really
painful
part
of
development
and
I'd
like
to
invite
Kate
Catlin,
to
tell
you
more
about
this
problem
and
what
we're
choosing
to
do
about
it.
Thanks.
C
We
need
to
talk
about
vulnerability,
reporting
in
open
source
by
giving
you
the
10
000
foot
view
of
how
it
works
today
for
those
of
you
who
have
not
been
through
this
process.
So
first
there's
a
security
researcher
and
they
find
something
and
they've
got
to
tell
the
owner
of
the
project
that
has
the
problem.
C
So
sometimes
that
repository
has
a
link
or
an
email
address,
and
then
it's
not
too
bad,
but
I
often
hear
from
researchers
that
they
spend
hours
trying
to
find
just
somebody
to
disclose
to
an
email
and
that's
just
to
kick
off
an
exchange
that
can
go
on
for
months
and
leave
everyone
exhausted.
So
we're
not
going
to
go
through
all
these
problems
right
now,
but
to
sum
it
up,
I've
got
a
quote
for
you
from
an
actual
security
researcher
in
our
ux
studies,
which
is
I.
C
Think
most
people
just
don't
disclose,
since
it's
so
much
work
and
that's
a
shame,
because
what
the
OSS
Community
needs
is
a
high
trust
and
collaborative
relationship
between
OSS
maintainers
and
security
researchers.
So
we
can
all
be
safer
and
we
think
GitHub
has
a
pretty
important
role
to
play
in
that
and
that's
why
I
am
so
excited
to
demo
for
you
today,
our
newest
feature
that
we
believe
resolves
a
lot
of
the
challenges
in
this
process,
which
is
called
private
vulnerability,
reporting.
C
Okay,
so
so
this
whole
process
starts
with
the
security
researcher.
So
let's
pretend
that
this
is
an
ultra
popular
repository
and
not
a
test
repo
that
I
just
spun
up
and
you
found
a
problem
in
it.
So
what
you're
going
to
do
is
navigate
to
the
security
tab
and
then
the
advisories
menu
and
there's
this
nice
inviting
green
report
a
vulnerability
button.
C
So,
quick
aside,
those
of
you
who
have
created
a
draft
security
advisory
before
this
is
the
same
form.
Don't
worry!
That's
intentional!
What
we
wanted
to
do
was
bring
the
security
researcher
into
your
existing
process
and
help
them
help
you.
So
it's
all
in
the
same
place,
so
I'm
going
to
fill
out
just
the
title
and
description.
C
Great
and
that's
actually,
all
I
have
to
do
to
submit
this
form.
We
do,
however,
know
that
a
lot
of
security,
researchers,
love
the
details
and
they've
done
a
lot
of
research
on
the
details
already,
so
we
left
you
the
rest
of
the
fields
here.
If
you
want
to
fill
out
all
the
metadata,
you
are
empowered
to
do
so.
So
we'll
click
submit
report
and
you
are
automatically
credited
already
for
that
report.
C
You
can
also
jump
into
this
temporary
private
fork
and
start
resolving
the
whole
darn
issue
for
the
maintainer.
If
you
know
how,
but
the
most
important
part
of
this
feature
right
now
is
that
it's
private.
So
as
of
right
now,
the
only
people
who
can
see
this
report
are
me
the
person
who
submitted
the
report
and
the
owners
of
the
repository,
so
they
can
see
the
report.
So
how
does
this
go
from
this
super
private
channel
of
communication
to
a
public?
You
know
sending
depend
about
alerts,
kind
of
advisory.
C
C
If
this
bug
is
actually
a
feature,
you'll
scroll
down
and
just
hit
close,
otherwise
you're
going
to
hit,
accept
and
open
as
draft,
and
then
it's
just
like
a
draft
security
advisory.
If
you
use
those
today
with
the
difference
that
the
reporter
is
still
involved
as
a
collaborator,
so
if
you've
got
follow-up
questions,
you
can
jump
into
the
comments
and
ask
them
there.
You
can
also
again
jump
into
that
temporary
private
fork
and
start
collaborating
with
the
maintainer
to
fix
the
problem
and
in
a
perfect
world.
C
The
security
researcher
has
filled
out
all
those
fields
for
you.
So
you
wake
up
in
the
morning
you're
drinking
your
morning,
coffee-
and
this
is
already
done,
but
even
in
that
most
perfect
Worlds.
The
reporter
cannot
merge
that
temporary
private
fork
for
you.
Nor
can
they
publish
this
advisory
for
you.
That
is
on
purpose
again.
We
we
want
to
make
sure
that
you,
as
the
admin
of
this
repository,
still
have
full
control
over
what
is
published
to
it.
C
So,
let's
compare
we've
got
the
situation
today
and
this
situation
after
private
vulnerability
reporting.
We
have
eliminated
the
challenge
of
finding
contact
info
because
it's
now
it's
just
a
form.
We
have
eliminated
the
challenge
of
the
reporter,
not
knowing,
if
anyone
received
this
or
is
doing
anything
with
it,
because
they
can
see
the
status
the
whole
way
through.
We
have
eliminated
the
challenge
of
maintainers
trying
to
triage
reports
from
wherever
they're
getting
them
all
across
the
Internet,
by
putting
it
in
one
central
location
which
is
the
same
place,
you
resolve
it.
C
We've
eliminated
the
challenge
of
maintainers
errantly,
not
actually
fixing
the
problem,
because
the
reporter
is
still
involved
and
contest
the
solution
that
they've
come
up
with
and
last
but
not
least,
we've
eliminated
the
challenge
for
you,
security
researchers
of
getting
credit,
because
it's
now
automatic
as
part
of
our
launch,
we're
so
excited
about
this
everyone's
excited
about
this.
All
these
organizations
were
excited
about
this,
so
they
signed
up
to
have
this
turned
on
before
it
was
even
launched.
C
So
that
means,
if
you
find
a
vulnerability
in
any
of
these
orgs
today,
you
can
submit
it
through
this
incredibly
easy
process.
Henceforth
and
last
but
not
least,
if
you
want
this
feature
on
your
repository,
navigate
to
repo
settings
and
then
you'll
hit
code,
security
and
Analysis
and
it's
the
first
listing
on
the
top,
so
all
you
have
to
do
is
Click
enable
once
again
we're
super
excited
about
the
difference.
Private
vulnerability
reporting
is
going
to
make,
but
we
also
want
to
prevent
vulnerabilities
from
happening
in
the
first
place.
C
D
Thanks
Kate,
that
was
great
Brave
doing
a
live
demo
at
Universe.
I
admire
that.
So
just
to
recap,
very
briefly,
as
we've
just
heard
from
Gray
and
from
Justin
and
from
Kate
at
GitHub,
we
believe
in
putting
great
security,
tooling
app
developers
fingertips
with
secret
scanning.
We
protect
developers
from
accidentally
disclosing
important
credentials
in
supply
chain
security.
We
help
them
bring
the
power
of
Open
Source
to
Bear
safely
and
confidently.
D
We
are
Paving
the
path
for
security
researchers
to
collaborate
more
closely
with
open
source
maintainers,
and
we
provide
a
free
and
open
database
of
security
advisories
that
helps
everyone.
So
where
does
code
scanning
fit
into
all
of
this?
Well,
if
you
haven't
come
across
it
before
think
of
it
as
something
that
helps
developers
write
more
secure
code
by
preventing
vulnerabilities
from
ever
hitting
the
main
branch
of
your
repository,
think
of
it
as
an
automated
security
reviewer
that
warns
you.
If
a
code
change
introduces
a
potential
vulnerability
right
there
in
the
pull
request.
D
Flow
code
scanning
itself
is
a
platform
helping
dozens
of
partner
and
open
source
analysis
engines
integrate
tightly
in
the
developer.
Workflow.
However,
we're
especially
proud
of
our
in-house
analysis
engine
code
ql,
which
is
used
by
the
vast
majority
of
code
scanning
users,
so
to
put
that
into
perspective
I
thought
I'd
share
a
few
Stats
today,
cold
KL
supports
nine
of
the
most
popular
programming
languages
on
GitHub,
and
thus
it
applies
to
the
majority
of
all
pull
requests.
D
During
a
working
week,
we
typically
run
over
150
000
analyzes
each
day
across
more
than
a
hundred
thousand
repositories,
both
public
and
private,
and
we
flag
potential
vulnerabilities
in
over
400
pull
requests
per
day.
Many
of
them
are
addressed
before
the
pull
request.
It's
ever
merged.
Of
course,
that's
the
best
way
of
addressing
a
potential
security
bug.
D
Just
looking
back
over
the
past
year
since
GitHub
Universe
we've
added
lots
of
new
analyzes
out
of
the
box.
We
now
have
25
percent
more
queries
and
protect
you
from
many
more
vulnerability
classes.
Code
KL
covers
every
single
one
of
the
Sans
top
25
list
of
most
dangerous
weaknesses.
We
cover
96
of
the
threats
identified
in
the
web
application.
Software
Consortium
with
dependabot
code
scanning,
covers
all
applicable
OS
top
10
entries.
But
what
does
all
that
mean?
D
It
means
our
users
are
protected
from
more
types
of
problem
as
they
go
about
their
daily
work,
and
the
number
is
of
course
still
growing
now.
What
does
it
look
like
to
bring
static
application
security
testing
into
the
developer
workflow?
Well,
as
I
said,
it's
a
bit
like
having
an
extra
security
expert
on
a
team
who
chimes
in
on
code
reviews
when
they
spot
something
behind
me.
You
can
see
this
in
action.
D
This
is
an
example
of
code
scanning
on
the
brave
browser
posting
a
comment
identifying
a
vulnerability
right
there,
where
the
problem
occurs,
it
can
be
discussed
just
like
any
other
pull
request
feedback.
Should
you
address
it
now
or
later?
What's
the
best
way
of
mitigating
it
best
of
all,
once
you
implement
a
fix,
it
will
be
resolved
for
you
allowing
you
to
merge
with
confidence
at
last
year's
GitHub
Universe.
D
We
launched
code
KL
support
for
analyzing,
Ruby
and
public
beta,
and
over
the
past
12
months
we
have
almost
doubled
the
available
analysis,
rules
for
Ruby
and
Incorporated
feedback
from
dozens
of
beta
users
who
have
fixed
more
than
4
000
alerts
in
their
Ruby
code.
Now
we're
ready
to
call
it
ga
and
as
we
look
ahead
what's
next
for
code
ql
well,
we
expect
to
bring
its
capabilities
to
the
most
popular
mobile
app
ecosystems,
with
kotlin
and
Swift
support,
shipping
and
beta
in
the
coming
months.
D
If
you're
interested
there's
a
talk
by
our
very
own
Tony
taralba
on
some
early
success
stories
here,
finding
real
vulnerabilities
in
popular
Android
apps
with
that
I'd
like
to
pass
it
over
to
our
very
own
gentle
cup,
Jen,
wasn't
able
to
be
with
us
in
person.
So
we
got
her
to
record
what
she
wanted
to
share
with
you.
E
Thanks
Pavel
hi
I'm,
Jen
I'm,
the
product
director
for
secret
scanning
and
security
overview
I
wish
I
could
have
joined
you
live,
but
I
am
38
weeks
pregnant
today
and
I
thought
it
would
be
best
to
pre-record
this,
but
hey
at
least
I
got
to
finish.
My
part
early
today,
I'll
be
talking
about
one
of
the
biggest
challenges
with
application,
security
and
organizations,
and
that
is
managing
code
security
at
scale
at
GitHub.
We
believe
that
developers
are
at
the
heart
of
application.
E
Security
and
we've
been
focused
on
embedding
security
into
the
developer
workflow
with
features
like
secret
scanning,
dependabot
and
code
scanning,
but
in
most
organizations
developers
don't
work
on
securing
software
alone.
They
collaborate
with
security
teams,
security
teams
think
holistically,
and
they
need
tools
to
help
them
work
across
many
different
repositories.
E
Today,
I'll
be
talking
about
how
you
can
manage
GitHub
security
features
at
scale
and
I'll
highlight
security
overview.
In
particular,
there
are
two
big
challenges
that
you
face
when
working
across
many
different
repositories.
The
first
is
driving
adoption.
This
could
be
a
one-time
activity
where
you
turn
on
security
features
everywhere,
or
it
could
be
a
gradual
rollout
across
teams.
E
The
second
big
issue
is
driving
remediation,
as
security
features
are
turned
on
you're
likely
to
find
a
lot
of
pre-existing
issues
that
need
to
be
resolved.
With
this
information,
you
can
work
with
developer
teams
on
burning
down
your
security,
Tech
debt
and
fixing
any
new
findings
in
a
timely
manner.
E
Let's
talk
about
driving
adoption
first
to
help
security
teams
who
are
working
across
lots
of
repositories.
We've
introduced
the
ability
to
enable
security
features
at
the
organization
level.
Today
you
can
enable
dependabot
and
secret
scanning
for
all
repositories
in
your
organization
in
one
click,
and
you
can
ensure
that
they
are
enabled
for
new
repositories
as
well.
E
We're
also
working
to
support
this
capability
across
all
organizations
in
your
GitHub
Enterprise
today
you
can
enable
secret
scanning
and
push
protection
for
your
entire
Enterprise,
and
our
vision
is
to
do
the
same
across
all
of
our
security
features.
Now
that
you've
seen
some
controls
to
drive
adoption,
let's
talk
about
how
you
get
visibility
into
how
it's
going
to
do
that.
Let's
take
a
look
at
two
new
pages
in
the
security
of
review.
E
Now
the
security
overview
is
a
page
at
the
organization
level
that
helps
you
to
understand,
what's
happening
with
GitHub
security
tools
across
all
of
your
repositories.
We
recently
made
it
available
to
all
GitHub
Enterprise
users,
and
it
shows
just
the
data
that
you
have
access
to
within
security
overview.
The
new
coverage
page
is
laser,
focused
on
helping
you
to
understand
and
track
adoption
of
GitHub
security
tools.
The
three
tiles
across
the
top
show
the
percentage
of
repositories
that
have
each
feature
enabled
and
soon
you'll
be
able
to
see
those
percentages
over
time
as
well.
E
For
example,
the
code
scanning
title
shows
how
many
repositories
have
enabled
alerts
and
pull
requests,
an
important
capability
that
surfaces
newly
added
vulnerabilities
right
in
the
pull
request,
so
the
developer
can
resolve
them
before
the
code
is
merged.
Finally,
the
repository
table
at
the
bottom
shows
you
the
current
status
of
each
security,
feature
for
a
given
repository
and
it
supports
filtering
and
sorting.
So
you
can
focus
on
the
repositories
that
you
care
about
most
next.
Let's
talk
about
driving
remediation
of
alerts.
E
Like
the
coverage
page,
there
are
three
tiles
across
the
top
that
focus
on
GitHub
security
features
depend
about
code
scanning
and
secret
scanning.
For
each
you
can
see
how
many
alerts
are
open
across
your
organization.
We
plan
to
highlight
key
metrics
for
each
feature.
For
example,
we're
experimenting
with
mean
time
to
resolve
dependent
bot
alerts.
E
The
risk
page
also
lists
repositories
on
the
bottom
of
the
page
and
indicates
how
many
alerts
are
open
for
each
security
feature.
Like
the
coverage
page,
the
risk
page
supports
sophisticated
filter
queries
to
help
you
target
the
subset
of
repositories,
you're
most
concerned
with,
for
instance,
you
can
check
how
individual
teams
are
faring
with
resolving
their
alerts.
This
will
help
you
to
drive
remediation
with
the
teams
and
repositories
that
you're
targeting
now.
E
E
Here
you
can
filter
and
sort
alerts
by
specific
criteria,
and
each
view
also
gives
you
the
ability
to
click
into
specific
alerts
for
more
details,
say,
for
instance,
that
you
learn
about
a
new
high
risk
dependency
vulnerability.
If
you
use
the
dependabot
page
to
search
by
that
dependency's
name,
you
can
see
how
many
related
alerts
have
been
created
across
your
organization.
A
A
So,
let's
recap:
Pavel
and
I
both
talked
about
preventing
vulnerabilities
with
code
scanning
and
secret
scanning
respectively.
In
both
cases,
GitHub
is
building
security
tools
for
developers
to
embed
security
deep
into
the
developer.
Workflow
T
quid
scanning
as
a
push
protection,
is
like
an
are,
you
sure,
prompt
when
you're
pushing
a
secret
and
code
scanning
is
like
having
a
security
expert
on
your
team
who
diligently
reviews
every
pull
request.
A
Both
are
built
around
the
idea
that
developers
are
at
the
heart
of
everything
in
application
security
we
heard
from
Justin
and
Kate
about
private
vulnerability,
reporting
which
we're
launching
today
in
public
beta
private,
vulnerable
with
private
vulnerability.
Reporting
is
really
all
about
the
impact
when
we
empower
the
community,
it's
built
for
maintainers,
to
make
it
easier
for
them
to
have
a
fantastic
security
disclosure
process,
but
since
we
all
rely
on
open
source
and
the
work
of
those
maintainers,
the
impact
of
that
ship
is
magnified
will
all
benefit
from
the
reduction
in
zero
days.
A
The
private
vulnerability
reporting
will
cause,
and
finally,
Jen
talked
about
what
GitHub
is
doing
to
make.
Our
security
features
work
at
scale
with
the
expansion
of
our
organization
and
Enterprise
level
security
views
as
we
build
Security
in
for
developer
workflow.
We
also
need
to
empower
security
teams,
github's
organization
and
Enterprise
security
overviews,
give
security
teams
the
insight
and
oversight
they
need
to
maximize
their
impact.
A
Github
is
doing
so
much
in
this
space.
There
are
90-something
change
log
posts
that
we
didn't
get
a
chance
to
talk
about
and
across
all
of
those
improvements.
I
hope
you
can
see
that
GitHub
is
also
focused
focused
on
the
areas
that
make
the
biggest
difference
we're
committed
to
embedding
security
into
the
developer,
workflow
to
empowering
the
community
and
to
supercharging
the
impact
of
security
teams.