►
From YouTube: How GitHub builds GitHub - Universe 2022
Description
GitHub is the home for all developers. This is no different inside GitHub's own walls where our own passionate group of engineers use our own developer platform to build, scale, and deliver secure software that the world’s next 100M developers will love. Join us as we explore how GitHub builds GitHub using the full range of capabilities from Copilot to Projects to power innovation across GitHub’s engineering team!
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
So
just
a
level
set
I
think
we've
all
got
a
lot
of
the
same
challenges
and
we
probably
have
some
of
the
same
challenges
that
each
of
you
were
dealing
with
on
a
day-to-day
basis,
whether
you're,
innovating
and
building
new
things
you're
going
to
have
bugs
feature,
requests,
support
escalations,
you
name
it
and
we've
all
got
to
keep
track
of
all
of
that
stuff.
And
we
have
to
do
that
at
scale
and
we
do
it
on
GitHub.
Now.
A
Everyone
also
wants
to
see
their
ideas
in
the
hands
of
their
customers
as
soon
as
possible,
and
our
devs,
like
you,
care,
a
lot
about
how
fast
changes
actually
show
up
in
production
and
because
of
that,
we
literally
ship
hundreds
of
times
a
day,
and
we
also
know
that
mainstream
security
threats
are
more
prevalent
than
ever,
whether
you're
worried
about
sophisticated
criminal
syndicates
or
you're
just
trying
to
keep
those
dependencies
up
to
date.
We're
thinking
about
that
stuff
too.
A
A
A
A
A
That's
just
a
ton
of
branches,
pull
requests,
commits
issues
and
more
and
finally
thinking
about
running
a
system
like
GitHub
at
scale
is
top
of
mind
for
us
and
we
think
a
lot
about
availability
and
how
to
make
sure
that
using
GitHub
is
just
a
great
experience
for
everybody,
who's,
relying
on
our
code
and
each
day
to
give
you
an
idea
of
that
scale.
Github
processes,
more
than
4.3
billion,
API
requests.
A
So
today,
I'm
going
to
walk
you
through
a
little
bit
of
how
we
use
our
own
products
to
make
sure
that
being
a
developer
at
GitHub
is
awesome
in
each
of
those
categories
and
you'll
be
able
to
leave
here
with
some
tips
that
I
hope
will
help
you
ship
faster,
have
happier
developers
and
ultimately
operate
and
build
from
here
on
GitHub
like
we
do
so
going
to
the
first
of
those
three
areas.
Let's
start
talking
about
productivity
for
us,
the
two
biggest
game,
changers
of
the
last
few
years
have
been
adopting
code,
spaces
and
co-pilot.
A
These
are
two
amazing
proof
points
of
why
we
are
absolutely
convinced
that
development
is
moving
to
the
cloud
and
we
know
it
because
we're
already
there
and
we're
living
it
every
day.
First,
with
code
spaces,
a
little
bit
of
context,
you
know
truthfully.
Local
development
hasn't
actually
changed
that
much
in
the
last
10
years.
A
If
you're
new
in
your
job,
you
get
a
laptop,
you
follow
a
Litany
of
instructions,
you're
installing
plugins,
getting
your
dot
files
building
dependencies
and
you
know
if
if
everything
goes
right
and
the
planets
and
the
stars
are
lined
up
in
a
particular
fashion,
you'll
get
a
working
build
environment
on
the
first
try,
and
maybe
your
documentation
is
really
good
and
it
helps
you
with
that.
But
what
about
later
on
when
a
change?
A
Clobbers
your
local,
build
environment,
some
of
those
cases-
and
this
was
the
case
at
GitHub-
for
a
long
time
that
meant
you
had
to
start
all
over.
You
had
hours
of
productivity
lost
or
maybe
you're
just
going
to
rage,
rm-rf
those
local
clones
in
frustration,
so
we're
talking
hours,
sometimes
before
your
first
commit,
maybe
more
hours.
If
you
have
to
rebuild
from
scratch,
that's
just
more
time
wasted
to
rebuild
that
local
setup.
This
sound
familiar
to
anybody
out
there
I
see
a
lot
of
nodding
heads
in
the
audience
here,
So
speaking
from
our
own
experience.
A
A
It's
a
huge
difference
and
I
can
also
throw
it
away
and
start
over
in
seconds
if
I
need
to
local
development.
Also
has
other
challenges
too,
and
the
one
that
comes
to
mind
for
me
is
thinking
about
traditional
endpoint
security
challenges.
Who,
amongst
us,
has
not
felt
the
pain
of
hearing
the
fans
spin
up
on
your
laptop
and
everything
grinds
to
a
halt,
as
your
build
process
competes
with
the
endpoint
security
agent
for
those
precious
scarce
cores
on
your
machine.
A
We
also
know
there's
other
local
soft
spots
as
well
with
local
development
and,
if
you're
an
adversary
thinking
about
targeting
the
software
supply
chain,
they
might
compromise
your
local
machine,
inject
backdoors.
Other
malicious
code
into
your
local
branch,
hoping
you'll
unwittingly,
commit
that
back
up
to
Maine
eventually
deployed
that
to
production.
These
are
real
challenges
and
real
reasons
why
we
moved
to
code
spaces
it
it's
faster
than
any
commodity,
Hardware
that
we
can
buy
for
our
developers.
A
We
don't
have
to
worry
about
local
environment
constraints
like
CPU
architecture
or
memory,
and
we're
abstracting
away
a
ton
of
local
attack
surface
for
our
developers.
Now,
if
you're
like
me
and
you
live
in
the
midwest,
sometimes
heating,
your
home
office
with
a
local
build,
can
be
a
nice
thing
to
do.
But
that
is
the
thing
in
the
past.
Moving
forward
with
moving
development
to
the
cloud.
A
The
second
tool,
that's
had
a
big
change
in
our
day-to-day
developer.
Experience
has
been
GitHub
co-pilot.
Now
we've
been
using
this
internally
for
a
little
over
a
year
and
it
still
feels
like
magic
to
me
every
day
and
my
running
joke
is
it
isn't
just
good
at
writing
code?
It's
also
pretty
good
at
writing.
Okrs
and
conference
talks
too.
Now
magic
sounds
cool
but
like
how
good
is
it
actually?
Well?
Don't
take
my
word
for
it.
A
On
our
internal
experience,
we
did
recently
publish
a
study
that
looked
at
co-pilot
performance
across
two
groups
of
developers,
one
who
used
copilot,
one
who
didn't
hopefully
not
surprising,
to
learn
that
copilot
was
able
to
complete
the
same
users
with
copilot
were
able
to
complete
the
same
task.
55
percent
faster
than
the
group
that
didn't
have
Copilot
now
getting
the
job
done
faster,
is
great
and
how
many
engineering
managers
out
there
perked
up
at
hearing
about
productivity
gains,
some
of
you,
but
it's
not
just
faster
developers,
are
telling
us.
A
It
is
a
better
experience
across
a
number
of
other
dimensions.
In
fact,
three
quarters
of
developers
that
we
spoke
to
said
copilot
help
them
stay
in
the
flow
and
spend
more
time
focusing
on
the
fun
parts
of
their
jobs.
Think
about
that,
for
a
second
developers
are
telling
us
they're
more
satisfied
with
their
jobs
when
they
use
Copilot.
B
Thanks
Mike,
we
are
using
these
products
every
day
to
improve
productivity
across
our
teams.
Codespaces
automates,
repetitive
manual
steps,
checkout
downloading
tools
and
dependencies.
Even
initial
build
and
running
tests
and
copilot
helps
you
stay
in
the
flow,
avoiding
common,
syntax
errors
and
boilerplate
typing.
Together.
They
help
our
developers
focus
on
what
matters
building
awesome
features
for
our
users,
so
let's
Dive
Right
In,
so
my
team
Works
mainly
in
the
Ruby
monolith
that
serves
github.com
like
we're
talking
about
github.com,
GitHub
gab,
so
many
githubs
for
every
task.
B
We
start
a
code
space
with
a
single
click
right
from
the
code
drop
down
like
this
as
Mike
shared
code
spaces
are
instant
on
customizable
container-based,
developer
environments
in
the
cloud,
so
spitting
up
in
the
background
is
a
powerful
machine
that
will
run
github.com
and
its
dependent
Services.
My
default
editor
is
set
to
vs
code
desktop
so
for
my
daily
work,
I
launch
directly
into
my
preferred
tools
and
the
experience
is
customized
with
my
themes,
extensions
and
Dot
files.
Let's
make
this
like
a
little
bigger.
B
Actually,
I
just
go
like
this.
There
we
go
okay
in
configurus
code
makes
this
all
possible
by
defining
your
Project's
developer
environment
right
next
to
your
code.
So
everyone
gets
the
same
experience
every
time
and
with
pre-builds
you
can
offload
common
setup
like
running,
build
and
tests.
It's
like
continuous
integration,
but
for
your
developer
environment
and
it
makes
startup
blazing
fast.
B
So
here,
I'll
just
make
this
a
little
bit
bigger.
So
everybody
can
see
all
right.
So
we're
going
to
finish
up
installing
my
DOT
files
and
then
we'll
get
a
welcome
message
and
then
we'll
be
all
set
and
ready
to
go.
So
what
I'm
going
to
do
is
I'm
going
to
go
ahead
and
start
the
server,
but
we
won't
just
run
the
website
just
yet
so
script
server
there
we
go
and
we'll
cancel
that
out.
B
Okay,
so
while
the
script
or
while
the
server
gets
running,
I'm
just
going
to
go
ahead
and
hide
this
and
we're
going
to
actually
peek
at
the
configuration
that
makes
this
possible.
The
dev
container
Json
file
so
right
here
in
the
top
left
from
our
folder,
we'll
select
Dev
container
Dev
container
Json,
and
this
is
kind
of
a
lot
so
I'm
not
going
to
go
over
every
line
in
this
file.
But
this
is
a
pre-configured
tool.
Stack
that
helps
you
get
your
environment
set
up
and
ready
to
go.
B
We
specify
the
base
image
minimum
host
requirements.
We
load
default
extensions
I'm,
going
to
come
down
here
a
little
bit
more.
We
forward
a
ton
of
ports,
there's
like
a
lot
going
on
in
this
project
and
we
also
pre-authenticate
access
to
other
repositories.
So
now
anyone
on
the
team
can
contribute
to
making
sure
that
every
developer
gets
a
great
default
experience.
B
We
all
know
the
struggle
of
works
on
my
machine
and
now
with
code
spaces,
it
works
on
every
machine
every
time.
Now
some
configuration
makes
sense
for
everyone,
but
developers
also
have
their
own
preferences.
I
prefer
the
GitHub
Lite
theme,
which
is
located
loaded
automatically
and
with
setting
sync
I,
get
the
material
icon,
vs
code
extension,
so
I
can
always
see
my
file
type
at
a
glance
and
my
DOT
files
load.
B
T-Max
split
window
and
I'll
just
go
ahead
and
start
top
in
one,
so
that
I
can
just
have
my
critical
processes
wherever
I
want.
But
I
have
access
to
the
terminal
right
here.
So
we
all
have
our
preferences
so
code
spaces
works
with
us
speaking
of
preferences,
like
many
of
you,
I'm
rarely
coding
in
a
single
language
and
so
I
switch
editors,
often
and
code
spaces
works
with
the
tools.
I
love
vs
code
desktop
like
I'm
using
here,
but
from
our
code
spaces
dashboard
right
here
in
the
top
nav
we
have
access
to
code.
B
Spaces
will
come
down
here,
and
this
is
actually
the
code
space
that
we
were
just
working
on
together.
All
right
click
here
on
the
dots
open
in
and
you
can
see
that
I
have
access
to
code
spaces
in
the
browser
to
vs
code.
Desktop
and
now
in
private
preview,
we
have
jetbrains
and
Jupiter
lab.
So
if
someone
on
my
team
prefers
Ruby
mine,
all
they
need
to
do
is
launch
open
in
and
with
the
terminal
access
through
the
GitHub
CLI.
B
B
B
Mona
Lisa
there
we
go
now
I
work
on
the
code,
spaces
team,
but
I
had
an
interesting
idea
that
I
wanted
to
add
an
emoji
to
your
team's
account
on
the
main
dashboard,
because
I
just
want
to
help
people
see
that
they're
how
they're
growing
their
communities
you
know
add
a
bit
of
Whimsy.
So
right
here
on
the
bottom
left
corner
is
your
team's
count
now
I
could
just
file
an
issue
with
my
idea,
but
I
think
showing
a
prototype
is
way
more
powerful.
B
So
I
can
simply
write
a
comment
around
what
I
want
to
achieve.
So
here's
are
your
teams
and
see
there.
I
go
all
right,
so
I
am
going
to
assign
an
emoji
based
on
teams.count
and
integer
within
a
range
of
zero
to
100.
and
I.
Think
for
0
to
20.
Let's
just
assign
something
like
this.
Like
cute
plant,
awesome,
hey,
thank
you
copilot,
all
right,
I'm,
just
that's
exactly
what
I
wanted
all
right!
All
right,
Emoji
equals.
B
B
B
Well,
the
only
thing
is
that
code
spaces
are
private
by
default,
so,
but
all
I
have
to
do
is
come
over
here
to
this
visibility,
right
click
and
I
can
make
this
public
so
that
I
can
just
share
it
with
a
team
right
away
or
I
could
just
make
it
private
to
my
organization,
which
I
know
my
chief
security
officer
really
appreciates.
So
I
can
safely
share
this
URL
with
anyone
on
my
team
and
get
real-time
feedback
and
since
code
spaces
automatically
installs.
All
of
my
favorite
tools.
A
All
right,
thanks
April,
that
was
great
I-
think
it's
fair
to
say
that
going
all
in
on
cloud
has
been
awesome
for
developers
inside
GitHub.
It
is
more
fun.
It's
faster
you're,
more
engaged,
it's
you're
working
on
the
more
interesting
and
more
challenging
work,
because
you
can
spend
less
time
on
the
boilerplate
and
more
time
on
the
creative
part
of
your
job.
A
How
can
you
find
what
you
need
when
you
need
it,
because
it
has
huge
implications
for
how
teams
think,
in
terms
of
in
terms
of
how
they
collaborate
together
as
groups
and
at
GitHub,
we're
remote
first
and
we
have
highly
distributed
teams.
So
we
we
have
to
be
super
intentional
about
how
we
keep
teams
up
to
date
across
our
work
and
make
it
easy
to
find
what
we
need
to
get
the
job
done
and
that's
where
we
think
things
like
issues
and
projects
really
come
into
play.
A
It
helps
teams
without
any
additional
reporting
overhead
linking
the
pieces
together
between
what
they're
doing
in
the
places
that
they're
doing
it
into
an
easy
to
use
view
of
the
map.
It
is
easy
to
use
macro
view
of
the
project
now.
To
give
an
example.
Actually,
GitHub
security
team
was
one
of
the
first
adopters
of
the
new
GitHub
projects
inside
the
company,
using
issues
to
track
and
deliver
on
their
okrs
and
major
projects.
That
team
consists
of
developers,
analysts,
security,
researchers
and
a
whole
bunch
of
other
teams,
and
really
for
us.
A
It
was
about
having
an
easy
way
to
think
about
the
Tactical
initiatives
and
how
they
fit
together
into
the
bigger
picture
connecting
people
to
the
work
from
the
work
that
they're
doing
to
the
mission
that
we
have
as
a
company.
That
actually
makes
it
easier
for
us
to
not
only
track
work
and
drill
down
into
an
individual
or
single
task,
but
you've.
A
A
I
mean
I
know
it
I
I
hear
some
juggling,
which
I
think
means
some
of
you
know
it
too.
Yeah
I
think
we've
all
been
there.
This
is
super
frustrating
to
be
spending
time,
hunting
for
things
and
knowing
they're
there,
but
not
being
able
to
find
them.
Not
only
is
this
frustrating,
but
it
actually
has
the
extra
implication
of
your
getting
out
of
the
ideal
Flow
State,
and
it
has
even
more
Global
implications
because
you're
trying
to
find
something
instead
of
thinking
about
how
does
the
work
I'm
doing
fit
into
that
bigger
picture?
A
The
GitHub
monolith
that
April
showed
a
few
minutes
ago
is
about
15
years
old
and
in
many
cases
hubbers
need
to
find
code
that
was
written
long
before
they
joined
the
company.
That
can
be
really
time
consuming
if
you're
not
sure
where
that
is
to
have
to
navigate
and
try
to
locate
that
we've
been
using
the
new
code
search
and
code
view
internally.
For
some
time
now-
and
let
me
tell
you
it
is
super
satisfying
to
be
able
to
find
what
you
need
quickly
and
just
keep
going
with
your
work.
A
You
know
that
feeling
of
achievement
that
you
get
when
you're
working
on
a
puzzle,
and
you
find
that
last
piece
that's
been
missing
in
the
house
and
you've
been
searching
for
high
and
low
for
days.
It
is
super
satisfying.
This
happens
to
me
all
the
time.
I
have
eight
kids
in
my
house,
so
we're
constantly
losing
puzzle
pieces.
C
All
right
thanks,
Mike
and
hello
universe,
as
you
know,
we're
working
to
be
the
home
for
all
developers,
and
that
also
means
being
the
home
for
all
development
processes,
from
solo
devs
to
open
source
projects
to
Enterprise
software
teams
and
the
teams
at
GitHub
are
no
different
projects
and
issues
are
the
heart
of
planning
and
tracking
on
GitHub.
We
use
these
tools
so
that
we
can
easily
track
work
across
the
company,
but
how
do
teams
like
mine
at
GitHub
break
down
our
work
into
manageable
tasks?
C
C
C
Well,
that
is
until
today,
our
new
and
improved
task
lists,
which
we've
been
using
behind
the
scenes
for
a
few
months
now
are
a
powerful
new
addition
to
both
GitHub
projects
and
issues,
and
once
it
loads
you'll
see
that
the
new
tasks,
this
UI
shows
metadata
like
labels
and
assignees
along
the
right
side,
and
the
new
omnibar
makes
it
incredibly
easy
to
add
new
issues
to
the
task
list.
Take,
for
example,
adding
issue
number
31
integrate
with
back
end
and
under
the
hood,
it's
all
just
markdown.
C
This
means
we
can
quickly
decompose
work
either
from
the
UI
using
the
omnibar
or
in
edit
mode.
As
you
see
me
doing
here
with
the
task
investigate
latency
issues
when
I
save
the
markdown,
it's
reflected
in
the
UI
and
then
I
can
easily
convert
that
task
into
a
new
issue.
In
my
repo
we've
also
built
in
a
new
breadcrumb
navigation
in
projects
which
helps
us
easily
explore
interconnected
issues,
so
we
can
easily
navigate
all
the
way
down
and
then
back
up
and
issue
hierarchy,
no
matter
how
many
levels
it
contains.
C
That
means,
if
you're
an
SVP
of
engineering
like
Mike,
you
can
click
all
the
way
down
to
the
actual
Feature
work
without
ever
leaving
your
project
we've
also
tightly
integrated
tasks
us
with
projects,
so
our
team
can
use
new
tasks-specific,
Fields,
powerful
filters
and
new
project
views
to
better
understand
how
their
work
fits
together.
Let's
enable
the
new
tracks
field
in
our
project.
C
C
We
can
also
see
the
inverse
of
this
relationship
which
children
belong
to
which
parent
by
enabling
the
tracked
by
field,
and
now
that
we've
enabled
it.
You
can
see
that
in
our
tasks
column,
each
item
shows
which
parent,
it's
tracked
by
our
teams,
also
use
powerful
filters
to
create
new
views
based
on
issue
hierarchy.
For
example,
we
could
create
a
bug
bash
view,
so
we
can
focus
on
all
the
the
bugs
submitted
in
our
Alpha
using
the
first
batch
in
our
list.
General
bug
fixes
from
alpha
feedback.
C
First
we'll
create
a
new
view
and
name
it,
something
like
bug,
bash
and
maybe
include
like
a
cute,
Caterpillar
emoji
and
then
we'll
filter
only
for
issues
tracked
by
our
Alpha
bug
batch
by
typing
tracked
by
and
then
referencing
our
issue
number,
which
in
this
case
is
30..
Now
we
can
easily
see
which
bugs
need
to
be
addressed
for
beta.
C
Let's
take
this
bug,
for
example,
it
looks
like
it's
related
to
a
react
component
called
a
go
seems
like
there's
a
bug
in
the
implementation
and
we're
not
rendering
a
tool
tip.
But
let's
say
I'm
not
familiar
with
this
code
base.
How
do
I
even
get
started?
Well,
we'll
do
a
quick
search
and
to
show
the
power
of
the
new
GitHub
code
search.
We're
going
to
search
across
the
entire
GitHub
code
base,
an
organization
which
has
over
5000
repos
and
2
million
files.
C
C
This
is
only
possible
because
we've
built
the
new
code
search
engine
completely
from
scratch,
with
a
focus
on
performance
and
searching
codes
specifically,
so
you
can
find
only
the
most
relevant
results
now
on
the
screen.
You
can
see
that
there
are
a
few
examples
of
how
this
component
is
being
used.
Let's
dig
in
using
the
new
code,
View
we've
totally
redesigned
the
code
view
to
tightly
integrate,
search,
browsing
and
code
navigation.
C
We
can
see
an
example
of
how
the
ago
component
is
used
simply
by
clicking
on
it
in
the
new
symbols
pane.
We
see
the
definition
as
well
as
references
to
this
component
across
the
repository
and
organization,
and
we
can
jump
right
to
where
this
component
is
defined
by
clicking
on
its
definition
and
here's.
The
implementation
it
looks
like
the
fix
will
be
easy,
we'll
just
need
to
add
a
tooltip
around
lines
51
to
56..
C
Let's
put
a
link
to
what
we
found
back
in
the
issue.
To
give
engineering
a
head
start,
reading
and
understanding
code
is
for
is
an
essential
task
for
every
developer,
especially
when
working
in
large
and
unfamiliar
code
bases
and
like
Mike
mentioned
earlier.
This
new
set
of
capabilities
allows
our
teams
to
work
within
the
monolith
faster
and
more
efficiently,
with
code
search
you'll
be
able
to
find
the
information
you
need
across
your
entire
code
base
almost
instantly
and
if
you're
as
excited
by
these
new
features,
as
we
are
I've
got
some
great
news.
C
A
A
A
It's
actually
what
the
security
team
enables
to
happen
out
at
the
edges
each
day
and
we're
trying
to
make
it
easier
for
people
to
safely
and
securely
get
things
done,
while
preventing
the
downside
risks
from
happening,
and
these
concepts
are
not
actually
opposing
to
one
another.
When
you
take
a
thoughtful
approach
to
the
experience
that
your
developers
have
every
day-
and
this
is
actually
why
I
think
we
are
in
the
midst
of
a
culture
shift
inside
security.
A
Frankly,
the
industry
has
not
necessarily
learned
from
all
of
its
mistakes.
We
struggle
with
many
of
the
same
issues
that
have
plagued
the
security
industry
for
more
than
a
decade
exposed
credentials
just
to
give
you
an
example
are
still
the
root
cause
of
more
than
20
of
breaches.
Today,
fishing
is
still
by
far
the
cheapest
easiest
way
for
an
adversary
to
get
into
an
organization
and
wreak
havoc
and
we're
still
pleading
with
organizations
to
implement
some
of
the
basics.
A
Like
multi-factor
authentication,
that's
one
of
the
most
effective
techniques
to
keep
Bad
actors
at
Bay,
but
I
am
here
to
tell
you
that
I
do
think.
There's
good
news
ahead
in
security
and
the
closer
we
can
bring
security
and
development
teams
together
the
better
the
outcomes
and
security
experiences
that
we
can
actually
create
together
and
one
of
the
things
that
I
love
most
about
security.
Is
that
when
you
do
it
right,
you
execute
it
properly,
you're,
actually
empowering
teams
to
go
faster
and
innovate
without
slowing
them
down.
A
Think
about
it,
like
the
seat
belt
in
your
car
seat
belts
are
not
there
to
slow
you
down,
they're
there
to
keep
you
safe,
while
you're
going
fast
and
building
security
into
the
developers,
workflow,
not
interrupting
them
from
it.
With
helpful
guard
rails
like
this,
helps
actually
make
people
makes
it
helps
people
make
smarter
and
safer
decisions
faster.
A
So
at
GitHub
we
build
security
into
everything
that
we
do
across
the
developer
lifecycle,
and
this
is
from
how
we
protect
our
own
hubbers,
the
github.com
platform
and
the
millions
of
Open
Source
maintainers
and
customers
who
use
GitHub
every
single
day.
Now,
I'll
tell
you
about
one
of
my
favorite
security
controls
that
we
use
internally
to
protect
our
hubbers
and
our
own
systems.
Maybe
you've
seen
one
of
these
I'll.
A
We
really
do
think
that
software
supply
chain
security
starts
with
the
developer
and
if
your
developer
accounts
aren't
protected,
just
know
that
this
is
where
adversaries
will
start
if
they
can
take
over
the
account
of
a
popular
of
the
contributor
to
a
popular
open
source
project.
This
can
actually
have
disastrous
consequences,
not
just
to
that
project,
but
to
all
the
downstream
consumers
of
that
project.
A
That's
why,
as
we
recently
did
with
maintainers
of
critical
packages
on
the
npm
registry,
we're
actually
going
to
require
that
every
developer,
who
contributes
to
software
on
github.com
from
anywhere,
will
need
to
use
some
form
of
two-factor
authentication
by
the
end
of
next
year.
Now,
two-factor
authentication,
adoption
among
our
daily
active
users
today
is
just
under
20,
which
is
pretty
good
relative
to
other
platforms.
A
D
Thanks
Maj
Hello
Universe,
as
Mike
mentioned,
we
bake
security
into
everything
we
do
from
our
research
to
our
resources
and
our
security
products
in
GitHub
Advanced
security.
We
use
secret
scanning
depth
on
the
boat
and
code
scanning,
with
code
QR
I'm,
going
to
focus
on
codeql
our
semantic
code
analysis
engine
that
automates
security
checks
and
I
will
walk
you
through
a
few
ways.
We
use
it
to
secure
GitHub
and
the
broader
open
source
community.
D
The
main
idea
behind
codeql
is
that
it's
driven
by
a
set
of
Open
Source
queries
that
model
many
different
types
of
vulnerability
patterns
across
a
wide
range
of
programming
languages.
This
way
it
acts
as
a
security
Force
multiplier
by
capturing
one
given
pattern.
As
a
code
current
query,
we
can
detect
all
instances
of
that
type
of
vulnerability
across
all
of
our
current
and
future
projects.
D
D
it
turns
out.
Head
requests
would
bypass
the
protection
still
be
processed
without
going
through
our
oauth
endpoint
telling
me
that
I'm
logged
in
not
good
the
GitHub
security
team
shared
this
pattern
with
the
code
ql
product
team,
alongside
Improvement
ideas
for
the
queries,
and
they
came
up
with
this
query-
to
detect
this
anti-pattern
on
github.com.
D
We
then
deployed
this
query
on
all
of
GitHub.
Github
and
code
scanning
with
codeql
is
very
easy
to
set
up
on
your
repo
as
a
new
GitHub
actions
workflow
using
the
GitHub
codeql
action,
and
we
were
able
to
detect
and
fix
all
instances
of
this
oauth
bypass
across
github's
code
and
also
to
protect
against
future
instances.
D
This
kind
of
vulnerability,
Discovery
feedback
loop,
where
vulnerability
patterns
shared
by
security
teams
at
GitHub
or
at
our
customers,
end
up
as
codeql
queries
that
are
then
available
for
everyone.
It
truly
acts
like
a
global
Force
multiplier
for
security,
knowledge
in
the
developer
and
security
communities.
D
Now
I
want
to
talk
about
something
that
is
the
coolest
part
of
my
job.
The
security
Labs
mission
is
to
build
and
inspire
a
community
of
hackers,
it's
amazing
to
work
with
this
community
and
it
has
been
from
day
one
of
the
job
when
my
colleague
Kevin
expected
the
vulnerability
in
Apple's
xnu
to
remotely
shut
down
my
phone
well.
By
doing
that,
he
inadvertently
shut
down
all
the
Apple
devices
on
the
floor
and
my
job
is
to
distill
all
of
this
incredible
collective
security
knowledge
into
this
feedback.
Loop
amplify.
D
D
D
D
So
one
the
security
lab
was
auditing,
github's
open
source
dependencies.
We
decided
to
run
this
query
on
data
hub
data.
Hub
is
a
popular
open
source
data,
catalog
solution
built
by
LinkedIn
and
with
other
1900
Forks
on
GitHub
and
more
than
5
million
pools
from
Docker
herb
and
boom.
This
new
codeql
query
found
an
authentication
bypass.
D
D
D
A
All
right
all
right,
thanks
Javier
also,
you
know
not
to
let
your
phone
get
too
close
to
Xavier's
team.
After
hearing
about
his
experience,
securing
the
world's
open
source
code
really
is
a
team
effort
and
it's
incredible
to
see
all
the
ways
that
the
community
jumps
into.
If
you
can
take
anything
away
from
this
I
hope
it
said,
security
shouldn't
be
about
gatekeeping
your
teams
from
shipping.
It
should
be
about
the
process
and
the
support
that
enables
them
to
ship
quickly
and
with
confidence.
A
Now,
as
you
can
see,
GitHub,
we
have
a
lot
of
the
same
challenges
that
any
other
development
team
out
there
has
doesn't
matter
if
you're
processing,
4.3
billion
API
requests
a
day
like
we
are,
or
if
you're,
just
starting
on
that.
Next
idea,
that's
going
to
be
launched
into
the
world.
Our
goal
today
was
to
give
you
a
window
into
a
few
of
the
ways
that
we
use
GitHub
to
build
our
own
platform
securely
and
improve
our
own
developer.
A
Experiences
not
only
be
more
productive,
collaborative
and
secure,
but
really
to
be
more
creative
to
be
happier
and
to
build
the
best
work
of
Our,
Lives
and
I
can't
wait
to
see
how
you
put
some
of
this
to
work,
to
show
us
what
you're
building
on
GitHub.
Now,
let's
build
from
here
together.
Thank
you.
E
All
started
as
a
collaborative
coding
project.
The
goal
was
to
build
a
place
for
every
developer
and
create
a
home
for
every
great
idea
and
15
years
later,
we've
seen
things.
No
one
expected
I
mean
there's
a
helicopter
on
Mars,
there's
a
vault,
storing
the
world's
open
source
code
beneath
an
Arctic
Mountain.
There's
a
network
of
satellites
taking
pictures
of
a
black
hole
and
your
sources
of
e-commerce.
E
Gaming,
streaming
search,
social
media
and
AI
were
all
built
right
here
and
that's
not
even
counting
the
thousands
of
groundbreaking
startups
using
GitHub
to
move
from
idea
to
concept
to
IPO
and
countless
lives
have
changed
every
step
of
the
way.
Github
has
looked
for
ways
to
support
developers
all
over
the
world
by
helping
them
get
paid
for
their
contributions
or
giving
them
native
AI
tools
and
automation,
or
by
moving
software
development
to
the
cloud
or
providing
the
most
secure
environment
available.
E
The
world's
biggest
companies
and
its
leading
startups
rely
on
GitHub
to
build
great
things
and
the
world
we
help
build
is
already
changing
faster
than
its
specs
recommend.
The
only
certain
way
to
improve
anything
is
to
offer
everyone
a
better
place
to
connect
and
collaborate.
The
deaf
Community,
wherever
they
live
and
wherever
they
work
are
the
ones
who
will
lead
the
way,
because
we're
not
just
in
this
together
we're
better
together.
So
let's
go
make
something
great
and
let's
build
from
here.