►
Description
Key announcements:
We're welcoming Semmle to the GitHub family
Blog: https://github.blog/2019-09-18-github-welcomes-semmle/
GitHub is now a CVE-number authority
Blog: https://github.blog/2019-09-18-securing-software-together/#github-is-now-a-cve-numbering-authority
Dependency graph support is now available for PHP / Composer
Blog: https://github.blog/2019-09-18-dependency-graph-supports-php-repos-with-composer-dependencies/
A
Good
morning,
everyone
welcome
to
github
we're
so
excited
to
have
you
here
today.
You've
got
some
really
exciting
announcements
that
we're
coming
today
and
we've
got
a
bunch
of
developers.
Who've
joined
us
here
at
getup
headquarters
in
person,
so
first
I
want
to
welcome
all
of
you.
Thank
you
for
coming
to
our
humble
office
here
and
what
is
today
a
little
bit
of
a
drizzly
San
Francisco,
but
we
also
have
hundreds
or
I
think
thousands
at
this
point
of
developers
who
are
watching
on
the
livestream
around
the
world.
A
That's
in
beta
now
the
reception's
been
amazing,
we're
getting
a
ton
of
usage.
It's
actually
incredible
how
many
servers
and
VMs
we
have
to
spit
up
to
like
accommodate
everybody's
load
works
on
Linux,
Mac
and
Windows,
and
so
it's
been
also
gonna
be
released
to
the
public
generally
available
on
November
13th.
But
if
you
go
right
now
to
the
beta
page
and
sign
up,
you'll
get
admitted
instantly.
So,
if
you
haven't
tried
it
out,
go
give
it
a
shot.
A
We
also
announced
a
couple
of
months
ago
to
get
a
packaged
registry
where
we
basically
built
a
package
registry
to
every
single
repo
on
github,
so
whether
it's
a
private
repo
with
a
private
registry
or
a
public
repo
with
the
public
registry.
We
support
six
different
package
form,
that's
NPM,
nougat,
maven,
rubygems
and
docker
and
we'll
be
adding
more
in
the
future.
That'll
also
be
generally
available,
November
13th,
so
just
in
like
sixty
days
and
then
finally
we're
doing
something
pretty
revolutionary
and
pretty
amazing
I'm
personally
very
excited
about
kind
of
a
big
experiment.
A
We're
running
with
github
sponsors,
which
we
launched
in
May
of
this
year
and
getup
sponsors,
is
a
facility
in
github
that
allows
you
to
actually
financially
support
the
developers
whose
work
you
love
and
depend
on.
So
if
there
are
folks
you
know
who
are
working
on
your
dependencies
that
you
want
to
make
sure
they've,
you
know
they're
independent
developers,
they
get
the
support
they
need.
You
can
sponsor
them.
There
we've
had
thousands
of
developers
sign
up
for
this.
We
have
a
bunch
of
folks
now
who
use
it
to
make
rent
every
month.
A
Over
the
last
25
years,
open
source
has
evolved
from
being
kind
of
a
niche,
almost
pseudo
academic
activity.
You
know
we're
developers
at
universities
or
large
institutions,
would
write
some
code
and
share
it
with
each
other,
similar
to
publishing
a
paper
and
build
on
each
other's
work
to
being
really
at
the
foundation
of
all
software
right.
In
fact,
99%
of
all
software
projects
today
use
open
source.
It's
it's
actually
hard
to
find
a
software
project
that
doesn't
use
open
source.
A
We've
also
seen
this
huge
trend
towards
these
packaged
registries
in
dependency
management
systems
and
as
a
result
of
those,
the
transaction
costs
of
using
building
blocks,
have
gone
way
down,
and
the
consequence
of
that
is
that
our
dependency
graphs
have
exploded
right.
It
is
now
super
common
for
us
to
see.
You
know
node
applications
as
an
example
not
to
pick
on
anyone,
but
you
know
that
we'll
have
thousands
of
explicit
and
peer
modules
that
they
are
pulling
in
and
in
their
transitive
dependency
tree
huge
numbers
of
components,
so
there's
been
enormous
benefits
to
this
right.
A
I
mean
developers
can
actually
focus
on
the
code
that
makes
their
application
unique.
Instead
of
writing
everything
from
scratch,
and
so
you
know
you
get
to
operate
at
a
higher
level,
you're
more
efficient.
You
get
more
done
in
a
way.
You
know,
developers
today
can
write
less
code,
we're
more
like
integrators.
You
know,
grab
a
little
code
from
you,
know,
ruby
gems
and
maybe
some
Stack,
Overflow
snippets
and
and
then
we'll
write
some
also,
but
we
don't
have
to
do
that
as
much.
That's
very
interesting
new
world.
A
Now
this
new
world
has
benefits,
but
it's
also
come
with
new
challenges
right
and
one
of
the
most
important
new
challenges
is
around
security,
because
it's
great
that
you
get
to
build
on
the
work
of
thousands
of
strangers
on
the
internet
when
you
write
new
code,
but
it
also
means
effectively
that
those
thousands
of
strangers
have
like
commits
access
to
your
production
code
in
a
way,
in
fact,
most
of
the
code
you're
putting
in
production.
You
probably
didn't
write
it's
sort
of
external
to
your
team
and
so
you've
got
the
technical
term
for
this.
A
Is
you
have
R
and
O's
in
your
supply
chain?
Basically,
and
that
means
if
any
one
of
your
dependencies
has
a
vulnerability.
You
have
a
vulnerability
right
and
the
fact
is,
this
might
not
even
be
a
dependency.
You
knew
you
had,
it
might
be
a
dependency
of
one
of
your
dependencies.
So
so
this
is,
the
changing
world
and
kind
of
open
source
has
succeeded
and
has
had
such
a
positive
impact,
because
it's
so
low
friction
right.
We
don't
have
to
ask
permission.
Sign
a
vendor
agreement,
form
partnerships
to
collaborate
on
software.
A
We've
got
to
make
some
changes,
and
specifically,
we
have
to
change
and
improve
our
processes
and
our
tools
and
our
norms,
our
community
norms
and
social
norms,
sort
of
upgrade
the
operating
system
of
open
source
to
adapt
to
the
new
threat
landscape,
so
that
we
can
continue
to
build
trust
and
security
directly
into
the
way
open-source
works.
So
that
is
what
we're
setting
out
to
do,
and
it's
not
a
thing
that
github
can
do
alone
right,
and
this
is
a
whole
ecosystem
and
a
whole
community
effort.
A
We
have
to
get
security,
researchers,
maintainer,
x',
the
developers
who
consume
open
source
code
and
then,
in
the
case
of
companies
that
are
large
enough
to
have
security
teams
all
of
those
parties
to
work
together
in
a
coordinated
way,
and
one
of
the
reasons
that
this
challenge
hasn't
been
addressed
in
the
past
is
that
the
workflows
and
the
tools
and
the
processes
you
need
to
build
span.
All
these
personas
and
historically,
people
have
looked
at
this
problem
through
the
lens
of
one
persona.
What
can
I
develop
or
do
what
can
I
maintain
or
do?
A
What
can
a
security
team
do
and
most
products
have
tried
to
address
a
single
persona?
That's
not
what
we're
gonna
do.
A
github
we're
doing
is
we're
taking
this
holistic
view
and
what
we're
calling
the
open
source
security
workflow
to
identify.
What
needs
to
happen.
So
let
me
walk
you
through
that.
So
the
first
step,
the
first
persona,
is
the
security
researcher.
Who
is
the
who's?
A
The
individual
sometimes
called
hackers
that,
like
benign
hackers
right,
you
know
if
you're
familiar
with
hacker
one
and
they're
like
geniuses
right,
they
look
at
code
and
they
find
the
things
the
developer
never
intended
that
are
possible
in
that
code,
whether
it's
a
buffer,
overrun
or
remote
code
execution
vulnerability.
You
know
they
do
that
through
tremendous
experience,
insight
and
pattern
matching
they
identify
an
issue
and
then
they
have
to
disclose
it
to
the
vendor
in
the
case
of
a
proprietary
application
or
to
the
open-source
maintainer.
A
Those
are
great
things,
but
there's
two
problems
right
now
that
those
folks
face
first
discovering
and
identifying
these
vulnerabilities
is
kind
of
an
elite
activity
that
only
a
small
number
of
people
can
do,
and
it's
a
very
manual
process
that
doesn't
operate
at
scale
right.
So
there's
wonderful
teams
out
there
like
project
zero
at
Google
that
do
a
great
job
of
identifying
these
things.
But
you
know
it's
a
very
manual
activity
of
scales
with
the
number
of
geniuses
you
can
employ
right.
A
The
second
issue
is
that,
in
the
case
of
open
source
projects,
the
best-run
projects
that
are
corporate
found,
you
know
sponsored
or
have
foundations
for
the
one
percent
of
open
source
projects.
They
may
have
good
ways
for
you
to
disclose
vulnerabilities
to
them,
but
99%
of
open
source
projects.
Don't
you
know
you
go
to
the
github
repo?
Maybe
you
can
file
a
public
issue.
Suddenly,
the
vulnerability
you've
disclosed
is
public
to
the
whole
world.
It's
a
zero
day.
A
That's
not
a
great
situation,
or
maybe
you
clone
the
repo
and
find
their
email
address
and
get
log,
and
then
you
mail
them
that's
kind
of
the
state
of
the
art
right
now.
So
that's
the
first
problem.
Okay,
once
I
maintainer
learns
about
a
vulnerability,
they
should
verify
it
and
fix
it,
ship,
a
new
release
to
their
users
and
then
alert
all
their
downstream
users.
It's
time
to
upgrade
right
well,
I.
A
Think
some
of
the
challenges
here
that
maintainer
face
is
that
open
source
communities
are
in
public,
and
so,
if
the
developer,
if
the
maintainer
is
trying
to
fix
this
issue,
the
the
tools
they
have
to
collaborate
with
their
team
are
also
public.
So
again
you
have
the
zero
day
problem
where
you
can
actually
just
watch
maintainer
struggle
with
active
security
bugs
in
public
and
there's
actually
kind
of
a
whole
industry
of
people
who
scrape
github.com
to
find
these
discussions
and
build
databases
out
of
it.
A
So
that's
not
a
great
situation
and
then,
finally,
for
me
and
Tanner's,
you
know
for
them
most
of
the
time
if
you're,
like
the
median
open-source
maintainer
a
security
issue
like
this
is
a
Black
Swan
event:
you're
not
used
to
it.
You
don't
know
exactly
what
to
do.
No
one
trained
you
for
this:
how
did
you
become
a
maintainer?
Well,
you
just
built
a
thing
that
you
wanted
and
somebody
else
liked
it
and
they
started
using
it
and
someone
contributed
and
now
you're
a
maintainer.
A
And
now
you
have
to
know
how
to
handle
vulnerabilities
and
these
kind
of
crazy
events.
And
so
how
do
you
notify
all
your
users
and
responsibly,
you
know,
alert
them
to
the
fact
that
they
need
to
upgrade
that
process
isn't
on
Rails
and
then
finally,
as
a
developer,
who's
consuming
open-source?
You
know
if
you
are
shipping
code,
that
you
didn't
write
strangers
on
the
internet,
wrote
the
contains
vulnerabilities
and
and
that
those
vulnerabilities
have
been
identified
and
fixed.
A
Well,
you
need
to
update
right,
like
you
need
to
actually
update
your
dependencies,
so
you
stop
shipping
vulnerabilities
and
then
you
should
take
steps
yourself
to
prevent
you
or
your
team
from
incorporating
more
vulnerabilities
into
your
code
either.
You
know
dependencies
with
known
vulnerabilities
or,
like
maybe
repeating
the
same
code
patterns
that
led
to
that
vulnerability
in
the
first
place
like
that
buffer,
overrun
or
whatever
it
was
a
challenge
is
here,
is
that
in
general,
open-source
developers
don't
fix
vulnerable
dependencies
quickly.
A
In
fact,
the
stat
that
we
have
from
looking
at
this
on
github,
just
rather
alarming,
is
that
after
a
developer
has
been
notified
to
be
critical
vulnerability
in
one
of
their
dependencies.
30
days
later,
only
30
percent
of
developers
have
upgraded
their
dependencies
on
average.
So
upgrade
rates
are
super
low
and
then
the
vulnerabilities
can
recur.
You
could
make
the
same
mistake
in
your
code
that
your
dependency
made
and
you'd
never
be
the
wiser
or
another.
One
of
your
dependencies
could
do
the
same
thing.
A
So
this
is
the
set
of
challenges
that
are
affecting
when
you
look
holistically
across
this
workflow
in
the
personas
there's
sort
of
challenges
in
every
step.
Now
the
good
news
is
at
github.
Over
the
last
six
months,
we've
been
investing
heavily
in
every
part
of
this
workflow
and
we're
going
to
show
you
some
of
the
progress
we've
made
and
we're
gonna
make
some
new
announcements
today.
That
I
think
they'll
be
pretty
excited
about.
So
to
take
you
through
that,
please
welcome
my
colleague,
gray
Baker
right.
B
I'm
going
to
talk
you
through
the
work
that
github
has
been
doing
to
secure
that
open
source
workflow
I'm,
going
to
start
from
the
very
beginning
where,
as
a
security
researcher,
you
found
the
vulnerability
to
the
point
where
you
pass,
that
on
to
the
maintainer
and
the
work
they
do
and
finally
to
the
end
user,
upgrading
to
a
fixed
version
and
defusing
that
vulnerability
in
their
codebase.
So,
let's
start
at
the
very
beginning,
imagine
I'm
a
security
researcher
and
I
think
I've
found
a
vulnerability
in
webpack.
B
B
I
quickly
find
web
packs
security
policy
that
security
policy
tells
me
how
to
disclose
that
vulnerability
in
private,
but
if
I
wasn't
a
security
researcher,
maybe
I
wouldn't
have
known
to
come
straight
here.
Github
has
a
special
handling
of
security
policies.
If
you
have
a
security
tool
empty
file
at
the
top
level
or
in
a
doc
github
folder
on
your
repo,
then,
when
I
go
to
create
an
issue
on
your
repo
you'll,
see
I'm
immediately
directed
to
that
policy.
B
If
my
issues
got
anything
to
do
with
security,
so
by
having
that
policy,
the
web
pack
team
are
helping
avoid
uncoordinated
accidental
public
disclosure
and
helping
protect
the
millions
of
users
of
web
pack.
If
you're,
an
open-source
maintainer
I
really
recommend
having
a
security
policy
in
your
repo.
B
B
This
part
on
the
web
pack
repo
because
I'm
not
a
maintainer
of
web
pack,
so
I'm
going
to
demo
it
on
a
repository,
but
I
do
have
maintaining
privileges
on
there's
a
security
tab
on
every
repo
on
github
and
if
you
click
into
it,
you'll
find
details
of
any
alerts
which
I'll
talk
about
later,
but
also
the
opportunity
to
create
advisories
about
that
repo.
Here's
one
that
one
of
my
colleagues
has
created,
and
it's
in
draft
form
that
advisory
is
a
private
space
for
me
to
work
with
my
fellow
maintainer
and
anybody
else.
B
I
invite
him,
as
we
figure
out
how
to
fix
a
security
vulnerability.
We
can
write
comments
to
each
other
and
those
comments
are
private
and
we
can
also
collaborate
on
code
together
in
a
private
fork.
Then,
when
we're
ready,
we
can
merge
the
contents
of
that
private
fork
into
our
upstream
repo,
and
it's
only
then
that
the
work
that
we've
done
will
be
visible
to
the
wider
community.
B
Finally,
when
we
have
that
fix,
we
want
to
publish
it
and
tell
the
world
about
it.
Security
advisories
have
a
way
to
do
that
as
well.
When
we're
ready,
we
can
fill
in
details
of
the
vulnerability,
so
you're
gonna
get
rich
metadata,
that's
gonna
get
published
to
the
community,
so
they
can
better
respond
to
this
and
we
can
click
to
publish
the
advisory.
B
It's
the
perfect
way
to
have
a
coordinated
disclosure,
and
today
we've
got
an
announcement
about
how
we're
improving
this
process,
because
you
might
have
seen
when
I
was
entering
details
that
I
had
the
option
to
enter
a
CVA,
which
is
a
unique
identifier
for
vulnerability.
I'm
excited
to
announce
that
github
is
becoming
a
CBE
numbering
authority,
which
means
that
you'll
be
able
to
apply
for
a
CVA
from
within
github
rather
than
having
to
go
to
a
flow
externally.
B
It's
really
cool.
It's
really
cool
and
I
want
to
thank
the
team
at
mitre
for
being
so
easy
to
work.
With
on
this
process,
they've
made
the
process
of
becoming
a
CNA
for
github
a
real
pleasure,
so
thanks
mitre.
So
now,
once
that
alert
has
been
published,
the
final
step
is
for
end-user
developers
to
upgrade
to
a
fixed
version.
This
is
where
github
security
alert
emails
and
I.
Automated
security
fix,
pull
requests
come
in
and
I
want
to
demo
them
now
and
I've
got
another
announcement,
which
is
previously.
B
B
The
dependency
I'm
introducing
is
common
mark,
which
is
a
markdown
rendering
library,
and
it
turns
out
that
in
Northpoint
18.2
there
was
a
high
severity
vulnerability.
That's
now
been
fixed
and
the
maintainer
of
common
mark
created
a
github
security
advisory.
For
that.
So,
let's
see
what
happens
when
I
push
a
vulnerable
dependency
to
get
up.
B
You
can
see
that
that
push
has
just
been
received
and
in
a
couple
of
seconds,
github
has
identified
that
I
now
have
a
vulnerable
dependency
in
my
repo
I.
Can
click
through
to
see
details
of
that
vulnerability
and
in
background
github
is
creating
an
automated
security
fix,
pull
request?
Now,
that's
gonna,
take
a
minute,
or
so
so
I'm
gonna
talk
to
you
a
little
bit
more
about
how
github
does
this.
B
So
on
the
one
hand,
we
have
all
the
advisory
information
that's
been
published
by
the
common
mark
team,
as
I
said,
that
happened
to
be
a
github
security
advisory,
but
github
also
listens
to
the
nvd.
Looking
for
any
vulnerabilities
that
have
a
CBE
that
weren't
published
in
that
way,
then
we
combine
that
with
github
dependency
graph,
which
is
our
scan
of
every
repositories
dependencies
so
that
we
can
find
vulnerable
dependencies
for
you.
B
Github
is
generated
a
pull
request
that
updates
the
minimal
amount
in
order
to
fix
this
security
vulnerability.
It's
just
taking
me
up
a
patch
version.
I
can
see
that
my
tests
are
passing
I
can
view
the
change,
log
and
release
notes
which
both
have
details
of
the
fix
and
I
can
merge
with
confidence,
and
when
I
do
so,
my
Aza
trees
gonna
be
fixed.
B
B
B
The
second
thing
that's
available
now
is,
if
you
are
a
github
enterprise,
customer
you'll
be
able
to
see
details
of
run
abilities
in
your
dependency
insight
screen.
So
if
I
go
to
my
organization
and
I
click
on
insights
and
their
dependencies,
I
can
see
details
of
all
of
the
dependencies
I'm
using
within
my
organization
and
I
can
click
into
the
ones
that
have
a
security
vulnerability
here
will
show
just
the
critical
security
vulnerabilities
that
are
open
and
clicking
into
details
of
any
of
these
will
tell
me
which
repositories
I
have
that
are
affected.
B
So,
as
a
security
team,
you
can
easily
prioritize
which
repos
you're
fixing
first
so
you've
seen
the
flow
from
end
to
end
to
defuse
a
vulnerability
in
an
open
source
dependency.
I've
got
one
more
thing:
I
want
to
show
you
before
I
hand
back
to
net,
which
is
around
token
scanning,
so
the
work
that
github
done
in
open
source
dependency
security
is
great,
but
then
other
kinds
of
security
vulnerabilities
as
well
and
one
that
we
already
help
with
is
credential
scanning.
B
It's
the
easiest
thing
in
the
world
to
accidentally
check
in
a
credential,
and
if
you
do
that
on
an
open
source
repository,
that's
a
problem
that
you've,
just
given
the
keys
potentially
to
your
AWS
account
to
the
whole
of
the
internet.
This
is
how
you
wake
up
with
a
$50,000
AWS
bill
and
somebody
mining
Bitcoin
on
your
dime.
B
So
every
push
to
an
open
source
repo
is
scammed
by
github
to
identify
tokens
like
that,
and
it
will
automatically
communicate
with
the
provider
that
we
found
a
token
that's
now
in
the
public
domain
and
they'll
act
accordingly.
In
some
cases
that
means
invalidating
the
token.
In
some
cases,
that
means
just
alerting
you
and
we
have
a
long
list
of
providers.
That's
growing
all
the
time
that
we
work
with
in
this
way
to
try
and
help
keep
your
credentials
safe,
as
well
as
your
dependencies
thanks
very
much
I'll
hand
back
for
now.
A
All
right,
thank
you,
Greg,
so,
as
you
can
see,
we're
taking
this
end-to-end
perspective
on
security.
That
runs
all
the
way
from
the
researcher
who
finds
the
vulnerability
through
the
maintainer
down
to
the
developer
and
even
includes
insights
for
the
security
team
of
your
company
to
understand
vulnerabilities,
not
just
in
one
repo
or
one
project,
but
to
get
that
holistic
view
over
your
entire
company.
A
We've
made
a
lot
of
progress
and
when
grace
just
shown,
you
improves
a
lot
of
the
problems
that
we
talked
about
a
few
minutes
ago,
but
there's
still
two
areas
where
more
work
is
needed,
where
there's
still
major
challenges
in
the
security
industry
that
we
think
it
get
up.
We
have
a
rule
to
help
out
with
the
first
is
that
problem
of
manual
vulnerability
discovery.
A
You
know
we're
in
this
very
lucky
position
to
work
with
the
entire
ecosystem
of
vendors
and
developers
who
are
working
to
address
these
problems
and
we've
gotten
to
know
a
bunch
of
the
companies
in
the
space,
and
one
company
in
particular
has
an
absolutely
groundbreaking
technology
that
has
had
a
huge
impact
on
the
ability
of
security
researchers
to
scale
their
work
and
then
developers
generally
to
apply
their
knowledge
to
their
codebase
at
scale.
And
so
today,
I
am
very
excited
to
announce.
The
github
is
acquiring
Cemil.
A
This
is
a
big
deal.
We
really
could
not
be
more
excited
about
the
team
and
the
technology
that
are
joining
github
in
to
get
a
family
with
sam'l
sam'l
has
the
world's
most
powerful
semantic
code
analysis
engine
they
can
take
code
and
turn
it
into
a
graph
that
we
can
query
and
learn
from
and
we're
bringing
together
the
world's
most
powerful
semantic
code
analysis
engine
with
the
world's
largest
developer
community,
and
the
potential
of
that
is
absolutely
enormous.
So,
to
tell
you
more,
please
welcome
Cemil,
CEO
and
co-founder
gogit
amor,
okay,.
C
Cells
technology
is
based
on
the
idea
of
code
as
data.
It
takes
the
code
in
a
repository
and
it
turns
it
into
a
graph
that
you
can
search
and
analyze
with
simple,
concise
queries,
the
queries,
a
simple
and
concise,
but
they
actually
do
deep
semantic
code
analysis
and
in
particular,
if
you
know
about
a
vulnerability
that
was
caused
by
a
coding
mistake,
you
can
go
and
look
in
your
own
repository
in
other
people's
repositories
for
all
the
variants
of
their
mistake
and
so
make
sure
that
a
whole
class
of
vulnerabilities
is
eradicated
once
and
forever.
C
You
can
also
use
the
technology
to
make
sure
about
such
vulnerabilities.
Such
mistakes
never
entered
production
in
the
first
place.
Many
security
researcher
writes
a
query:
diagnosis,
vulnerability,
right
security,
find
instances
of
the
mistake.
You
can
run
those
queries
as
part
of
your
regular
testing
process
in
particularly
you
can
run
them
as
part
of
your
code
review
to
make
sure
that
the
problem
once
identify
never
comes
back.
C
If
BOTS
identified
never
comes
back
again,
the
query
language
that
makes
all
of
this
possible
is
both
declarative
and
object-oriented,
and
that
means
that
it
becomes
extremely
easy
much
easier
than
before
to
create
these
deep
semantic
analogies
and
it
did.
Our
customers
frequently
tell
us
that,
with
sam'l
they're
able
to
identify
vulnerabilities
that
escaped
all
other
means
of
detection,
they
also
tell
us
that
tasks
that
usually
take
weeks
or
even
months
can
now
be
accomplished
in
hours.
C
B
Thanks
again,
I
am
so
excited
about
this
technology
and
what
we
can
do
with
it.
It
is
just
amazing
and
I'm
gonna
try
and
communicate
some
of
that
by
showing
you
an
example
of
this,
but
the
possibilities
are
kind
of
limitless.
So
I
want
to
talk
to
you
about
vulnerability
that
I
have
accident
accidentally
introduced
in
my
code.
It
is
a
java
d,
serialization
bug,
and
these
happen
all
the
time
and
they're
really
haunted
attacked
but
Cemil
just
absolutely
nails
them.
B
B
Let's
see
how
Cemil
handles
it,
so
fortunately,
I
put
this
in
a
pool
quest
and
it's
got
sam'l
running
on
it
and
someone
has
found
an
alert
which
is
the
serialization
of
user.
Controlled
data
and
I
can
view
details
of
that.
So
I
want
to
see
like
Hal
cemil's
found
this,
because
it's
split
across
two
files,
there's
nothing
that
you
could
do
in
terms
of
linting.
That
would
find
if
that
analysis
has
to
be
way
more
sophisticated.
B
What
sam'l
is
done
is
its
followed,
the
code
all
the
way
through
it's
found
the
place
where
I'm
accepting
user
input
and
then
it's
looked
to
see
where
that's
going
and
it's
passed
through
a
function
and
eventually
is
being
deserialize
and
that's
where
the
problem
lies
so
I
can
see.
You
know
immediately
that
this
is
genuinely
a
problem
and
then
we'll
then
links
out
to
Doc's
about
what
I
can
do
about
it
and
and
everything
else,
and
if
you
think,
Oh
gray,
you
know
that's
just
toy
code.
It's
of
a
simple
example.
B
Then
look
at
this
one
where
the
parts
of
I'm
flowing
through
our
12
steps.
This
is
a
vulnerability
that
was
announced
last
week
in
Apache
Oh
F
biz,
which
is
a
framework
different
powers,
a
suite
of
Apache
applications.
It
was
issued
a
CVE,
it
has
now
been
patched
and
it
was
found
by
by
Cemil,
because
it's
very
very
tricky
to
spot
these
as
an
end
of
an
individual
engineer,
this
software
allows
you
to
do
it
automatically
I'm
so
excited
about
what
we
can
do
with
this
app
get
up,
find
your
hand
back
to
that.
A
Thank
you,
okay.
Thank
you.
Greg,
congratulations
to
the
Seminole
team
on
what
you've
built
we're
so
excited
to
work
with
you.
We're
really
excited
to
integrate
Seminole
directly
into
github
and
make
these
powerful
capabilities
available
to
open
source
developers
everywhere
and
to
all
get-ups
customers,
and
so
this
is
something
that
we're
looking
forward
to
doing
over
the
net
over
the
coming
months.
That
I
think
will
have
a
huge
impact.
A
So
we
made
a
few
announcements
today:
we've
taken
you
through
kind
of
our
strategy,
there's
a
lot
more
work
for
us
to
do,
but
you
can
see
where
we're
going
and
how
seriously
we're
taking
this.
You
know.
Today
we
announced
PHP
support
and
our
dependency
graft
and
therefore
for
security
alerts.
We've
told
you
that
github
is
now
a
CNAs
CVE
numbering
authority,
which
means
you
don't
have
to
go
to
the
DMV.
To
tell
people
about
your
security
problems.
A
You
can
just
do
it
on
github
super
helpful
for
maintainer,
x'
and,
of
course,
the
acquisition
of
Cemil,
which
we
think
is
going
to
bring
together
this
incredibly
powerful
technology
with
developers
and
security
researchers
around
the
world.
So
this
is
the
beginning.
I
think
the
key
message
that
I
want
everyone
to
take
away
is
git
hubs,
commitment
to
really
following
through
on
our
responsibilities
in
the
opportunity
we
have
to
secure
software
development
from
end
to
end,
but
this
is
also
a
joint
activity.
A
This
is
something
that
we're
all
going
to
have
to
explore
and
go
on
this
journey
together.
Maintainer
x'
around
the
world
are
gonna
have
to
adopt
these
capabilities
and
security.
Researchers
are
gonna,
have
to
scale
their
work
and
we're
all
gonna
have
to
take
this
more
seriously
over
time.
So
we're
excited
about
that
journey.
If
you
want
to
learn
more
about
what
github
is
doing,
we
have
a
page
that
has
a
nice
summary
of
of
our
work.
You
go
to
github.com
slash
features
/.
A
You
will
have
a
number
of
new
security,
related
announcements
coming
up
in
the
future
and
then,
of
course,
in
less
than
two
months
and
I
think
56
days,
not
that
I'm
counting.
We
have
our
major
developer
conference
of
the
year,
which
is
github
universe.
It's
here
in
San,
Francisco,
November,
13th
and
14th.
We
bring
together
hundreds
of
the
world's
top
maintainer
zhh
largest
companies
that
are
using
open
source
and
using
github.
You
know,
developers
and
students
from
around
the
world.
A
Thousands
of
folks
it's
a
great
event
and
we'll
have
some
really
big
product
announcements
there
as
well,
so
hope
to
see
you
there
all
right
so
to
everyone
who
joined
us
here
in
the
room
and
for
those
of
you
who
joined
us
online.
Thank
you
for
spending
part
of
your
Wednesday
with
us.
We
appreciate
it
we're
looking
forward
to
your
feedback.