►
From YouTube: GitHub ¡Presente! Lo Mejor de GitHub Universe
Description
GitHub se complace en invitarte a que te unas a nosotros en el siguiente evento de GitHub ¡Presente! en Español.
Acompaña a Alexandra Bourne, gerente de proyectos técnicos, a Jaime Sanchez, Ingeniero de Soporte de GitHub Enterprise y a Miguel Ángel Durán , GitHub Star, para "Lo Mejor de GitHub Universe"
GitHub Universe es la conferencia anual de 3 días de GitHub. Este año lo celebramos virtualmente, y el evento "Lo Mejor de GitHub Universe" te mostrará lo más sobresaliente de más de una docena de nuestras 40 sesiones increíbles. Estos incluyen:
- Dark Mode
- GitHub Discussions
- Las últimas características lanzadas en GitHub Enterprise Server
- CodeSpaces
- Actions
- CodeQL
- Prácticas de seguridad
- Cómo usar GitHub para reducir la deuda técnica
- Consejos de desarrollo de varios de nuestros socios
Finalizaremos con un evento de zoom en el que podrás conectar con los empleados de GitHub para hacer preguntas y hacer sugerencias sobre nuestros productos. Por favor acompáñanos el Martes, 12 de enero a las 13:00 Ciudad de México, 14:00 Colombia, 20:00 Madrid
A
A
A
B
C
D
E
Good
morning
welcome
to
github
universe.
Today
we
are
going
to
walk
you
through
how
we
use
github
at
github
and
along
the
way,
show
you
some
of
the
really
cool
new
features
we've
been
building,
let's
check
it
out.
I
start
my
morning
with
the
github
mobile
app.
I
check
out
my
notifications
and
I
catch
up
with
my
favorite
communities.
E
E
F
With
github
mobile,
not
only
do
I
get
push
notifications
for
things
like
comments,
but
I
can
keep
working
on
any
of
my
repositories,
no
matter
where
I
am,
let's
jump
to
nao's
pull
request
and
take
a
look
with
ui
changes
like
this.
Sometimes
it's
hard
to
know
if
everything's
working
just
by
looking
at
the
diff.
E
Tens
of
millions
of
developers
use
github,
but
so
do
hundreds
of
thousands
of
companies,
including
some
of
the
biggest
in
the
world.
For
those
users,
we've
been
hard
at
work,
adding
all
the
new
features
you
saw
today
to
github
enterprise
server,
so
you
get
all
the
power
of
the
best
teams
in
the
world
running
on
your
company's
network.
That
includes
github
actions,
packages,
code
scanning
and
support
for
the
native
github
mobile
apps.
All
of
this
is
available
in
a
major
new
release.
We
call
github
enterprise
server
3.0.
G
G
I
J
J
K
Hi
everyone,
I'm
bailey,
I'm
here
with
matthew
and
we're
both
product
managers
on
github
code
spaces.
Earlier
there
we
announced
github
code
spaces
at
satellite
and
the
excitement
from
the
community
was
overwhelming,
to
say
the
least.
It
was
amazing
just
how
excited
the
community
was
to
be
able
to
have
a
cloud
dev
environment,
so
you
can
go
from
a
repo
on
github.com
to
a
running
code
space
within
seconds
without
any
setup
or
configuration
getup
codespaces
are
instant
cloud
developer
environments.
Codespaces
provide
you
with
a
machine.
K
Why
should
anyone
care
there's
a
lot
of
hardware
out
there
you're
watching
this
on
a
machine
that
you
can
potentially
write
code
on?
So
what
is
so
special
about
code
spaces?
The
goal
for
most
of
us
is
to
write
great
code
that
ships
value
to
our
customers,
the
open
source
community
ourselves.
Whoever
that
audience
is
the
goal
is
not
to
spend
your
time
doing:
local
dev,
environment
management,
although
it
can
consume
a
lot
of
your
time,
and
it
may
not
be
your
job.
K
Your
company
might
have
a
person
or
a
team
where
this
is
such
a
problem,
that
it's
become
their
job
and
hopefully
you're
not
managing
python
2.7
anymore,
that's
been
end
of
life,
but
it's
just
an
example
to
say:
let's
write
great
code
and
be
able
to
write
it
fast.
Writing
great
code
should
be
about
doing
just
that,
and
not
the
periphery
of
machine
management
that
surrounds
it.
L
The
way
we
get
to
code
spaces
is
right
from
this
page.
We
can
go
to
the
code
button
and
right
inside
this
drop
down.
We
can
open
this
project
inside
of
a
codespace,
so
let's
go
ahead
and
do
that
and
talk
about
what's
happening
and
what
that
offers
us
for
this
project.
So
I've
created
this
code
space.
I
was
using
it
pretty
recently
and
I'm
going
to
jump
in
and
just
resume
an
existing
code
space.
L
So
you'll
see
we
connect
here
and
we
land
in
what
fields
and
really
is
vs
code
and
it's
vs
code
in
the
browser
and
for
me
personally,
this
feels
a
lot
like
home
and
the
reason
is
because
I
use
the
github
dark
theme
and
this
is
using
the
github
dark
theme.
But
if
I
had
another
theme
I
could
have
that
set
up
and
synced
across
my
code
spaces
as
well.
L
You
can
see,
I
have
my
custom
bash
prompt
here
and
my
dot
piles
are
synced
over
automatically.
So
I
really
have
everything
that
makes
this
feel
like
I'm
developing
locally
you'll
even
see.
There
are
some
extensions
that
aren't
standard
here
that
don't
come
automatically
out
of
the
box,
so
I'm
also
able
to
bring
in
the
extensions
that
I'm
used
to
that.
I
like
to
work
with
and
use
them
all
inside
of
the
browser
for
this
code
space.
I
have
an
editor.
I
have
an
editor
in
the
cloud.
L
L
L
So
what's
going
to
happen
here
is
we're
going
to
connect
to
a
forwarded
port
from
this
codespace
and
it's
going
to
load
our
app
so
you'll
see.
I
have
this
app
called
haikus
for
mona
and
we
have
some
of
those
octa-cats
that
martin
was
just
talking
about,
and
I
have
little
haikus
that
we've
written
about
some
of
these
octa-cats,
and
this
is
really
cool.
I'm
running
a
node
app.
It
has
a
postgres
database
backing
it.
L
It's
not
super
complex,
but
I'm
able
to
get
the
full
app
running
with
a
container
for
my
web
service
and
with
a
container
for
my
database.
I
can
interact
with
it.
I
can
do
everything
I
would
do
to
build
this
app
locally
and
that
port
is
just
forwarded
on
securely
to
me,
but
we
also
again
have
vs
code
here,
so
we
can
do
more
than
just
run
our
app.
We
can
debug
our
app.
L
So
let's
go
ahead
and
run
this
app
with
our
debugger
attached.
So
you'll
see
we
have
the
app
our
port.
3000
is
forwarded
again
and
what
we're
going
to
do
here
is:
let's
just
set
a
breakpoint,
so
I'm
going
to
create
a
little
bit
more
space
here
and,
as
I
said,
this
is
a
pretty
basic
node
express
app
and
we
have
some
endpoints
that
are
defined
here,
and
we
have
this
end
point
for
for
the
heart
experience,
so
I
can
go
ahead
and
heart,
something
and
like
it
and
the
counter
goes
up.
L
We
hit
our
breakpoint,
so
we
can
jump
over
here.
We
can
actually
look
at
the
stack.
We
can
look
at
the
request
that
came
in
here.
We
can
step
through
this
function.
This
is
super
powerful.
I'm
able
to
you
know,
run
a
full
debugger
of
my
app
in
the
browser,
but
I
also
like
to
spend
a
lot
of
my
time
using
vs
code
locally,
and
I
want
to
go
from
vs
code
and
connect
to
my
code
space,
and
I
can
do
just
that.
L
So
what's
going
to
happen
here
is
this
is
going
to
take
a
second
it's
going
to
set
up
our
connection
and
then
we're
going
to
have
our
entire
code
space
in
just
the
state
that
it
was
right
because
we're
connected
to
that
remote
machine.
So
you
can
see
my
changes
are
here
and
I
can
go
ahead
and
if
we
want
to
make
our
commits
from
here
updates
for
live
demo
and
go
ahead
and
make
our
changes,
everything
looks
good
and
let's
go
ahead
and
push
them.
L
So
I'm
going
to
go
ahead
and
push,
and
now
our
changes
are
back
on
our
repo.
So
if
I
go
back
to
the
web,
we
can
see
this
full
end
to
end.
I'm
going
to
use
the
command
line
with
this
nifty
little
trick
to
go
back
to
the
repo
and
you'll
see
updates
for
live
demo.
Here's
our
commit
you'll
see
that
it
kicked
off
github
actions.
So
it's
now
running
my
tests
and
we
did
all
of
this
from
the
code
space.
C
D
C
C
J
Any
developer,
armed
with
a
browser
and
an
internet
connection
can
ship
code
with
code
spaces
and
that's
what
I
love
about
working
on
it
personalizing
your
experience
happens
through
two
main
areas
or
configurations
really.
You've
got
your
dot
files
and
you've
got
settings,
and
one
of
the
questions
I
hear
a
lot
is:
okay,
allison.
Why
would
I
use
one
versus
the
other?
J
Maybe
you
just
notice
that
your
code
space
is
mostly
right
and
you're,
not
quite
sure
why
we're
gonna
break
it
down
here.
So
if
you're
using
dot
files,
we
automatically
pull
any
public
repo,
that's
on
your
account
name,
dot
files
into
your
code
space
and
we
apply
them
at
creation
time.
So
if
you
perhaps
use
dot
files
to
set
up
your
local
machine-
or
you
checked
out
some
references
in
the
past
and
forked-
a
dot
files
repo
from
a
coworker
we're
automatically
pulling
that
in.
J
J
J
J
You
know
the
laundry
list
of
languages
in
order
to
support
getting
as
many
of
you
as
possible
started,
and
you
can
see
that
list
here.
But
if
you
need
a
bit
of
extra
configuration,
perhaps
you
have
a
very
specific
version
of
python.
You
need
you're
going
to
leverage
the
dev
container
json
for
configuration
now.
J
This
is
a
quick
sample
of
what
the
dev
container
file
might
look
like.
This
is
purely
a
configuration
file
that
lets
us
know
how
to
build
the
container
for
your
needs.
This
is
great
if
you're
a
lead
or
a
maintainer
of
a
repo,
and
you
don't
want
users
to
have
to
do
anything
more
than
click.
The
opening
code
space
button
now
important
things
to
note
here
are
that
the
dev
container
is
actually
checked
into
the
repository,
and
so
it
is
scoped
to
the
repo,
not
the
user.
B
C
C
B
M
Github
actions
has
grown
massively
right
now
we
run
about
75
million
jobs
at
the
slide,
says
73,
but
I
looked
this
morning.
It's
about
75
million
different
jobs
a
month
across
a
wide
variety
of
workloads.
Ci
is
probably
the
most
common
thing
that
people
absolutely
automate,
but
the
amazing
growth
has
really
come.
I
think,
due
to
the
community
and
if
we
look
across
sort
of
all
of
the
different
ci's
that
happen
on
github.
M
We
definitely
believe
actions
is
by
far
the
the
number
one
we
we
seem
to
do
the
most,
at
least
from
what
we
can
see.
We
actually
see
closer
to
10
000
different
actions
used
across
different
organizations,
and
we
think
that's
pretty
incredible,
because
that
means
people
are
are
both
using
the
community,
but
also
taking
advantage
of
of
using
actions
within
their
own
organizations.
M
M
If
you
looked
at
our
public
roadmap,
we
have
something
called
manual
approvals,
so
this
is
configured
on
your
repo
settings
outside
of
the
workflow
and
when
you
try
to
deploy
to
a
given
environment,
if
a
set
of
reviewers
is
required,
the
system
will
pause
that
job
before
it
ever
goes
to
a
runner
and
send
out
a
series
of
notifications
and
require
a
person
in
this
list
or
or
somebody
in
a
team
to
come
and
say
it's
okay.
For
that
job.
M
To
continue
to
deploy
to
that
environment,
we
heard
from
a
lot
of
people
that
you
know
they
want
to
be
able
to
track
what
is
currently
in
a
particular
environment
whether
that
environment
is
production
or
if
that
environment
is
a
staging
or
whatever
starting
to
build.
This
new
activity
log
here
is
is
part
of
our
goal
to
to
really
move
in
that
direction,
and
this
is
kind
of
where
this
kind
of
four-ish
new
capabilities
comes
in,
because
this
deployments
view
actually
exists
in
github.
M
We
wanted
to
give
you
a
much
better
way
to
visually
track,
how
your
workflows
are
progressing.
You
know,
as
you
have
these
more
complex
workflows,
particularly
ones
that
do
sort
of
pipeline
style
deployments
to
different
environments
or
maybe
have
rich
matrices
or
other
concepts
having
the
ability
to
see
where
those
go
and
sort
of
track
their
progress.
M
At
this
very
visual
level,
we
think,
improves
just
the
overall
usability
of
actions,
the
usability
of
more
complex
workflows
and
the
ability
to
debug
potential
issues,
and
we've
also
started
to
do
some
other
work
to
integrate
in
other
places.
I
think
you
saw
in
the
keynote
nat
had
a
really
neat
little
vignette
at
the
end
where
he
launched
dark
mode,
and
you
saw
sort
of
a
sneak
preview
of
some
work,
we're
doing
with
the
mobile
app.
M
We've
also
done
a
lot
of
work
with
the
team
who
works
on
the
slack
integration
to
integrate
those
there
and
you'll
start
to
see
these
roll
out
again,
and
we
we
think
that,
as
we
use
all
of
these
endpoints
for
github,
we
can
really
help
drive
that
culture
of
of
rapid
deployment
and
unblocking
your
team
from
where
you
are
exactly
how
you
need
to.
We
think
that
put
all
those
things
together
really
do
add
up
to
the
ability
to
do
very,
very
rich,
continuous
delivery
workflows
with
github
actions.
M
C
N
I'm
really
excited
about
talking
about
building
your
community
with
github
discussions
which,
as
of
tuesday,
is
available
for
all
repos
and
public
beta,
and
so
thousands
of
you
have
turned
it
on
since
then.
I
want
to
quickly
talk
about
the
open
source
ecosystem
and
why
github
discussions
exist
in
the
first
place.
N
N
We
want
to
keep
q
a
and
conversations
separate
from
github
issues,
but
we
also
don't
want
those
to
be
completely
detached
either.
Their
relationship
is
important,
so
you
can
think
of
github
discussions
as
the
living
room
of
your
open
source
community.
If
you
haven't
enabled
discussions,
yet
I'm
going
to
show
you
how
now
so
to
start
you're
going
to
want
to
go
to
your
repos
settings
page
and
then
you
can
go
on
that
default.
N
Now.
If
you
have
issues
that
should
be
discussions,
you
can
cover
those
individually
convert
them
in
or
in
bulk.
So
if
you
wanted
to
do
it
in
bulk,
you
can
go
here
to
the
label
section
here.
We
selected
the
question
label,
obviously
probably
the
best
one,
for
that
is
a
q,
a
category
and
there
you
go.
N
All
you
have
to
do
is
click
that
button
and
you're
going
to
convert
those
from
your
issues
over
to
your
discussions,
and
you
can
see
that
over
on
your
discussions,
page
every
repository
comes
with
a
default
set
of
four
categories:
general
ideas,
q,
a
and
show
and
tell
but
these
can
be
modified.
I
think
the
most
important
thing
about
categories
is
that
you
get
to
set
the
tone
here
to
help
the
community
know
what
to
expect
and
where
to
go.
Let's
get
directly
into
the
mechanics
of
marking
an
answer.
N
So
anyone
with
triage
plus
access
or
the
author
can
do
this,
and
this
is
kind
of
what
it
looks
like
when
you
find
an
answer
to
a
question.
You
can
click
on
the
check
box
and
a
great
box
will
appear
and
you
can
see
who
marked
the
answer
and
it'll
be
recorded,
so
you
can
even
see
who
marked
it
right
underneath
now
we
have
all
the
tools
that
we
need
to
manage
existing
discussions.
Let's
talk
really
briefly
about
some
enhancements.
N
We
have
to
improve
the
community's
interactions
and
first
things:
first,
you
can
see
right
here,
there's
a
leaderboard
on
the
right
hand,
side
and
it
shows
people
with
the
most
answered
discussions.
Finally,
I
wanted
to
briefly
talk
to
you
about
what
you
can
do
with
triager
write,
maintainer
and
admin
permissions
and
as
far
as
discussions
go,
people
with
write
maintain
admin.
Access
can
basically
do
the
same
thing
with
two
exceptions.
N
So
people
with
maintain
and
admin
access
can
enable
discussions
altogether
from
the
settings
page
and
also
they're
the
only
ones
who
can
create
and
edit
categories,
but
otherwise
they
have
the
same
permissions.
And
that's
basically
it
that's
what
you
have
so
we
talked
about
getting
started
categories.
New
discussions,
marking
answers
how
you
can
use
the
information,
the
site
to
provide
recognition
and
how
to
moderate
and
keep
the
community
healthy.
So
here's
an
example
here
where
snowpack
has
used
the
a
pin
discussion
as
their
change
log,
and
so
it's
kind
of
pinned
at
the
top.
O
Is
github
is
where
the
world
builds
software
over
50
million
developers,
trust
github
to
collaborate,
test,
build
and
deploy
code,
including
over
70
percent
of
the
fortune
50..
In
fact,
in
the
last
year,
over
60
million
new
repo's
were
added,
and
over
1.9
billion
contributions
were
made.
Those
are
some
seriously
big
numbers.
The
stability
and
resilience
of
our
global
platform
is
critical
to
providing
developers
with
a
platform
they
can
count
on.
Github
enterprise
is
built
on
the
same
principles
as
github.com
and
as
a
result
benefits
from
the
years.
O
We've
spent
optimizing
the
platform
to
be
trusted
reliable
and
resilient
from
day.
One
we've
focused
on
building
great
products
and
experiences
for
the
developers
who
spend
their
days
or
their
nights
on
github
from
pull
requests
to
code
spaces
actions
to
code
ql
and
everything
in
between
our
vision
is
to
build
the
home
for
all
developers,
whether
they're
working
on
a
fun
side,
project
or
building
mission,
critical
software
for
fortune
500.
O
C
P
We're
going
to
talk
about
this
state
of
security
today,
so
my
favorite
analogy
for
this
is
imagine
that
you
just
built
your
most
amazing
favorite
mansion
and
you
have
just
installed
all
the
most
expensive
furniture
and
all
the
most
expensive
appliances,
and
you
just
forgot
to
install
doors.
So
this
is
sort
of
how
we
treat
security
today
we
just
kind
of
say:
okay,
we
have
time
for
this.
We're
just
gonna
first
deliver
on
all
of
the
features
and
then
we're
gonna,
basically
add
some
locks
on
the
doors
and
some
doors
to
our
mansion
right.
P
Because
features
is
what's
important.
If
we
look
at
the
chart
of
how
we
deliver
code,
then
we
actually
see
that
the
more
lines
of
code
we
write
the
more
security
threats
we
actually
introduce,
and
so
we
don't
learn
from
our
mistakes.
We
just
basically
continue
committing
bugs
and
moving
on
and
just
like
committing
secrets,
committing
security
vulnerabilities
into
our
main
code
base,
and
despite
that,
as
developers,
we
often
treat
it
this
way.
So
we
just
basically
say:
okay,
it
works
in
dev.
So
it's
security
problem
now
right,
so
I
have
developed
my
code.
P
Basically,
we
have
about
45
million
estimated
developers
and
only
70
000
estimated
security
researchers
in
the
world.
So
today
I'm
going
to
basically
talk
about
how
github
can
help
you
fix
your
security
issues
for
you.
So
we
have
a
large
number
of
features
in
github,
advanced
security
that
can
help
you
integrate
security
into
your
developer
experience.
So
it's
not
extraneous
to
what
you
do,
but
rather
it's
shifted
all
the
way
left
and
integrated
into
your
development
life
cycle.
P
But
today
I'm
going
to
talk
specifically
about
the
code
part,
so
we
can
see
that
almost
50
of
all
the
breaches
in
the
world
actually
include
stolen
credentials
and
yet
we're
pretty
bad
about
not
committing
these
credentials
or
these
secrets
into
source
control
as
report
stories
and
this
where
secret
scanning
actually
comes
in,
so
we
have
different
sort
of
different
oriented
features
for
public
and
private
repo.
So
I'm
going
to
start
with
public
repos
for
public
reapers.
P
We
actually
have
secret
scanning
for
a
number
of
years
already
and
we
are
doing
it
at
massive
scale.
We're
scanning
about
150
million
pushes
a
week.
So
basically
every
push
into
a
public
repo
basically
gets
scanned
by
github
to
identify
secrets
and
many
people
don't
know
that
it's
happening,
because
just
because
it's
transparent
to
you,
if
you
as
a
user
check
in
your
code
and
that
code
actually
contains
the
secret,
so
we
actually
run
different,
regular
expressions
from
known
secret
scouting
partners
to
identify
if
somebody
you
committed,
actually
matches
one
of
these
secrets.
P
So,
basically,
we
then
send
the
matches
to
a
partner,
verify
endpoint,
and
then
the
partner
can
verify
if
it's
a
real
secret
or
if
it's
not
and
then,
depending
on
what
the
partner
wants
to
do
with
this.
Sometimes
they
revoke
the
secret,
and
sometimes
they
also
email,
the
user
right.
So
basically,
we
have
this
process
in
which
I
completely
transparent
to
the
user.
In
some
cases,
your
secret
actually
got
gets
revoked
by
the
partner,
and
so
your
secret
is
no
longer
in
the
repository.
P
C
Q
So
github
code
scanning
earlier
this
year,
we
announced
it
and
code
scanning
does
exactly
what
it
says
on
the
tin.
It
scans
your
code
for
security,
vulnerabilities
and
any
alerts
we
find
in
pull
requests
are
automatically
flagged
up
to
you
so
that
you
can
fix
them
before
you
merge
the
code
changes
into
your
main
branch
that
particular
code
patterns
could
be,
for
example,
a
server-side
template
injection
vulnerability
when
you
run
codeql,
whether
that's
in
code
scanning
or
on
your
own
local
machine.
Q
The
first
thing
it
will
do
is
it
extracts
all
of
the
source
code
that
you
have
into
a
special
relational
database
in
a
way
it's
similar
to
a
mysql
or
a
postgres
database.
It's
a
very
special
one,
though
special
purpose-built,
read-only
one.
We
call
it
a
ql
database
and
just
like
with
my
sql
and
with
postgres,
you
can
run
queries
against
that
database
and
in
fact,
a
code.
Q
Ql
query
looks
a
bit
like
a
sql
query,
but
it's
a
lot
more
powerful
I'll
show
you
one
in
in
the
live
demo
that
I've
got
now
a
code.
Qr
query
is
a
way
to
sort
of
interrogate
and
explore
your
source
code.
A
very
simple
query
might,
for
example,
look
for
a
variable
called
password
that
you
then
write
to
a
plain
text:
log
file,
more
advanced
security
analysis,
more
advanced
queries
do
very
intricate
flow
analysis.
Q
They
track
where
user
control
data
enters
your
application.
They
track
it
through
your
application
through
function,
calls
and
data
structures
to
a
location
where
it
might
be
used
in
an
unsafe
way,
and
the
ssdi
analysis
does
exactly
that.
It
tracks
untrusted
user
data
that
eventually
ends
up
in
a
template.
Q
Now,
in
a
way,
every
query
captures
the
security
knowledge
of
a
security
researcher,
and
by
codifying
that
knowledge,
that
we
can
apply
it
at
a
massive
scale.
So,
for
example,
we
run
qrl
against
hundreds
of
thousands
of
repositories,
and
every
single
query
result
that
we
get
is
a
is
an
alert
in
code
scanning.
B
D
R
R
So
why
isn't
security
considered
a
feature,
and
this
is
kind
of
an
interesting
topic,
because
one
of
the
things
that
I'll
often
ask
dev
teams
after
they've
done
some
security
review
of
their
applications
is
they'll
say:
do
you
have
a
banking
app
on
your
phone
now
that
doesn't
always
translate
depending
on
where
you
are
in
the
world,
some
cash-heavy
cultures?
Don't
really
use
banking
applications
might
do
e-commerce,
but
alaska
dev.
Are
you
using
some
some
sort
of
financial
transaction
application
on
your
phone
and
the
answer
is
almost
universally?
Yes.
R
I
like
to
say
this
is
kind
of
like
the
faucet
that
you
go
to
or
the
sink
that
you
may
go
to
and
when
you
turn
that
left
knob,
you
expect
the
water
to
be
hot.
That's
universally
true,
you
didn't
have
to
ask
anyone
for
it
and
you
didn't
have
to
tell
the
plumber
to
install
it
that
way.
It's
just
the
way
that
that
operates,
and
so
in
a
lot
of
ways.
R
R
It
ends
up
being
state
actors,
as
opposed
to
cheeky
kids
on
the
internet,
for
example,
and
so
that
way
your
application
will
be
a
little
bit
more
robust
and,
quite
frankly,
you're
out
running
a
majority
of
the
bears.
Of
course,
it
also
differentiates
your
project
or
your
product
if
you
think
about
apple,
for
example,
they're
almost
universally
known
for
a
lot
of
the
security
and
privacy
implementations
that
they've
put
in
place.
We
can
also
look
at
examples
within
the
software
development
landscape,
such
as
react
versus
angularjs
back
in
the
day
angularjs.
R
And,
of
course,
once
you
go
ahead
and
invest
in
security
as
a
feature,
it
allows
you
to
save
time
and
money.
It's
that
return
on
investment
that
compounding
interest
that
allows
you
to
actually
go
ahead
and
focus
on
other
investments
and
experimentation
so
that
you
can
grab
more
market
share
and,
of
course,
differentiate
your
product
and
then
pay
down
those
other
technical
debts
that
you
might
be
encountering
and
then,
of
course,
in
terms
of
some
tools
that
you
can
use.
I
like
to
say
with
static
analysis.
Github's
advanced
securities
toolset
is
phenomenal.
R
If
you're
on
the
github
platform,
which
I
would
think
that
you
probably
are,
if
you're
watching
this
and
then,
of
course,
osp's
dependency
check
tool.
If
you
need
another
thing
to
go
ahead
and
look
into
the
environment
and
make
sure
that
things
are
working
appropriately
and
the
libraries
you're
using
are
fresh
and.
C
B
I
I
So
today,
in
this
session,
we'll
cover
a
couple
of
different
topics.
First,
what
your
supply
chain
is,
including
everything
you
need
to
know
about
the
dependencies
you
pull
into
your
software,
such
as
information
on
their
vulnerabilities,
in
order
to
determine
your
risk
profile,
then
we'll
dive
into
what
github
can
do
to
help
you
address
vulnerabilities
in
these
dependencies
and
alert
you
when
new
vulnerabilities
arise,
using
dependency
graph
and
depend-a-bot
and
for
the
main
attraction
today
I'll
hand
it
over
to
william
to
delve
into
a
new
feature
that
we
just
demoed
in
the
keynote
this
morning.
I
That
will
help
you
shift
left
starting
today.
Dependency
review
we'll
cover
what
dependency
review
is,
how
it
works
and
how
it
can
help
you
shift
left
if
you're
unfamiliar
with
the
term
software
supply
chain.
It's
used
to
refer
to
everything
that
goes
into
your
software
and
where
it
comes
from,
and
what
is
that
it's
dependencies,
your
software
supply
chain
depends
on
well
your
dependencies
as
well
as
properties
of
your
dependencies
and
what
is
a
dependency.
A
dependency
is
another
binary
that
your
software
needs
in
order
to
run.
I
This
can
include
both
binaries
required
when
building
the
application,
often
called
dev
dependencies
as
well
as
binaries
that
are
actually
used
at
runtime.
A
dependency
enters
your
environment
when
a
developer
specifies
it
as
part
of
application
in
a
manifest
file
where
dependencies
are
declared
or
a
log
file
where
particular
versions
of
dependencies
are
specified.
I
The
thing
is
dependencies
can
be
risky,
they're,
not
code,
that
you
wrote,
you
don't
really
know
what's
in
them
kind
of
like
you,
don't
really
know.
What's
in
that
2
a.m,
shawarma
from
the
place
around
the
corner.
It
seems
fine,
but
you
never
know
so.
One
particular
piece
of
information
developers
should
pay
attention
to
is
vulnerability
information
if
your
dependency
has
known
vulnerabilities.
Well,
maybe
you
should
update
it
to
a
patched
version.
However,
not
all
vulnerabilities
are
properly
disclosed
or
patched,
and
there
are
other
potential
risks
to
using
a
given
dependency.
I
Other
security
risks
that
make
it
more
susceptible
to
being
attacked
or
harder
to
detect
an
attack,
legal
and
compliance
risks
for
using
a
dependency
in
a
way.
That's
not
in
line
with
the
specified
license,
maintenance
risks
if
a
dependency
is
no
longer
supported
and
you
don't
have
a
viable
alternative
and
other
risks
as
well,
so
to
make
the
dependencies
that
you
pull
in
less
scary.
We
want
transparency
as
to
what's
in
them,
so
that
you
can
be
confident
in
what
you're
consuming
if
you're
using
github.
I
I
We
have
first,
you
need
to
know
your
environment,
so
you
need
to
understand
what
dependencies
you
use
and
manage
your
dependencies.
That
is
know
about
vulnerabilities
in
those
dependencies
and
packages.
So
you
can
address
some
really
quick
to
discover
it
and
react
to
it
on
github
to
know
your
environment
use
dependency.
Graph
dependency
graph
identifies
all
upstream
dependencies
and
public
downstream
dependence
of
a
repository
or
package
and
items
are
automatically
added
to
the
dependency
graph.
I
When
you
add
a
new
dependency
and
to
manage
your
dependencies,
dependable
alerts
notify
you
of
repositories
affected
by
a
newly
discovered
vulnerability
to
do
this,
github
compares
the
information
in
the
dependency
graph
to
the
information
in
github's
advisory
database.
A
dependable
alert
can
either
be
sent
when
you
added
a
new
dependency
or
when
a
new
vulnerabilities
discovered
in
an
existing
dependency
that
you
have
dependable
security
updates
will
send
you
a
pull
request
to
update
a
dependency
to
the
minimum
version
that
resolves
a
known
vulnerability.
I
This
is
done
automatically
based
on
known
vulnerabilities
and
known
patched
versions
by
suggesting
a
change
to
update
packages
in
a
log
file,
and,
lastly,
dependable
version
updates.
Keep
your
dependencies
up
to
date,
even
when
there
isn't
a
new
vulnerability
by
checking
for
new
versions
on
a
configured
schedule.
S
Maya
spoke
earlier
about
defendable
alerts,
and
this
helps
you
react
to
vulnerabilities
that
already
exist
in
your
dependency
manifests
or
when
new
vulnerabilities
are
discovered
in
existing
dependencies
that
you
have,
it
will
also
catch
changes
that
are
pushed
directly
to
the
repository
dependency
review,
helps
you
shift
left
catching
vulnerable
dependencies
before
they're
introduced,
as
well
as
giving
you
more
context
about
those
dependencies.
They're
complementary
and
you
should
use
both.
B
A
We
just
released
the
state
of
october's
report
last
week.
It
was
a
birthday
present
to
myself
and
everyone
else.
We
took
a
slightly
different
approach
this
year,
so
in
addition
to
sharing
with
the
world
how
github
has
grown
and
changed,
we
also
did
some
deep
dives.
We
had
quite
a
year.
We
have
now
grown
to
over
56
million
total
developers
on
github.
A
A
Many
people
are
both
working
longer
hours
and
getting
more
done,
we
saw
contributions
to
open
source
jump
initially
40
compared
to
last
year
and
then,
when
they
settle
out,
they
settle
out
at
about
25
increase
compared
to
the
previous
year.
We
found
that
once
an
open
source
repo
starts
using
actions
on
their
pull
requests.
A
We
see
an
18
faster
time
to
merge
that
pull
request
and
an
increase
of
30
percent.
More
pull
requests,
merged,
github
released
and
announced
discussions
earlier
this
year,
so
we
took
a
look
at
the
next.js
repository
and
how
they
were
using
discussions,
and
it
was
great
to
see
and
kind
of
excited
to
see
how
this
grew
over
time,
and
what
we
found
is
that
it
really
helped
keep
this
community
more
resilient
and
more
sustainable.
A
What
some
of
our
other
analysis
found
is
that
some
of
the
best
ways
to
invite
and
encourage
and
foster
newcomers
to
stick
with
the
community
are
with
issues
the
challenge
with
issues
that
can
burn
out
maintainers.
So
the
exciting
thing
is
that
we
also
found
that
one
of
the
best
ways
to
encourage
newcomers
is
with
discussions.
A
Discussions
is
a
way
to
engage
talk
about.
What's
happening,
learn
new
norms.
Now
some
of
you
may
be
thinking
well,
what
does
this
have
to
do
with
me,
nicole,
this
enterprise
track?
This
is
great
because,
as
we
think
about
scaling
our
solutions
and
scaling
throughout
our
enterprises
think
about
things
like
centers
of
excellence
or
communities
of
practice.
This
helps
make
sure
that
our
expertise
isn't
siloed.
This
helps
us
spread
that
excellence.
A
It's
a
lot
like
inner
source
right.
We
have
so
many
things.
We
have
expertise.
We
have
process,
there's
so
many
things
that
we
can
share.
We
found
that
any
piece
of
code
or
any
repo,
has
a
59
chance
of
getting
a
security
alert
in
the
next
year
of
those
active
repositories
with
supported
package
ecosystems.
A
Most
vulnerabilities
are
mistakes;
only
17
of
them
are
explicitly
malicious
things
like
backdoor
attacks,
and
they
result
in
only
0.2
percent
of
alerts
in
the
in
the
very
commonly
and
most
used
repos
and
most
use
files.
Eighty-Three
percent
of
of
these
vulnerabilities
are
the
result
of
mistakes.
So
it's
important
to
remember
anyone.
Anyone
can
make
a
mistake
and
anyone
can
insert
a
mistake
into
your
code
base
so
by
leveraging
the
power
of
community.
A
That
means
that
anyone
in
this
community
can
help
find
these
vulnerabilities
and
fix
them
for
you
another
benefit
of
automation,
repositories
that
automatically
generated
a
pull
request
using
dependabot
to
fix
patch
their
software
1.4
times
faster.
So
many
times
people
ask
me:
what
does
shift
left
look
like
if
I
want
to
be
doing
devsecops?
What
does
that
look
like
this
is
what
that
looks
like
we
can
scale
what
it
is
that
we
find
we
can
build
that
into
our
development.
Workflow.
B
C
T
T
One
was
around
both
the
outer
loop,
how
you
deploy
software,
but
also
our
observability,
both
observability
during
a
deploy
and
then
just
generally
speaking,
another
big
set
of
work
streams
was
around
the
inner
loop
and
testing.
That
is
when
someone
is
coding,
they're,
making
a
build
locally,
they're
running
tests,
all
of
those
kinds
of
things
and
then
the
final
loop
was
final
work
stream
was
specifically
around
reliability.
T
What
parts
of
the
system
do
we
need
to
make
better
and
stronger
so
that
you
know
the
site
is
always
up
always
serving
our
customers
in
all
cases,
and
so
we
organized
across
those
we
had
objective
leads,
who
kind
of
looked
at
each
one
of
these
three
and
then
underneath
them.
We
created
virtual
teams
of
work
stream,
leads
to
tackle
very
specific
problems.
Ultimately,.
H
We
selected
these
as
some
of
the
work
streams
that
the
projects
that
we
were
going
to
work
on.
First,
we
wanted
to
look
at
how
we
could
speed
up
our
artifact
builds
and
we
need
some
more
progressive,
rollout
stages
and
automation
around
them,
and
we
noticed
that
there
were
recurring
themes
of
deployment
problems
that
we
could
eliminate.
That
could
take
care
of
that
need
for
manual
intervention,
so
we
aimed
to
increase
that
deployment
success
rate.
H
H
H
Last,
let's
see
the
time
to
resolve
incidents
when
they
do
happen
is
vastly
improved,
and
I
want
to
mention
a
thing
that
I
was
super
excited
to
see
happen
here.
We
set
up
a
mirror
of
our
github
repository
so
that
we
can
build
and
deploy
github
still
when
github
isn't
available
the
thing
that
we
do
it
when
it
is
and
another
one
I'm
super
excited
about,
is
that
we're
enabling
merge
queues
for
more
of
our
repositories.
H
We've
separated
out
how
we
bundle
up
our
home
requests
and
that's
separate
out
of
the
deployment
process
now
for
that
repository
so
yeah.
So
all
of
this,
along
with
some
simpler
confidence,
dashboards
again
that
progressive
rollout
automation
and
really,
I
believe,
just
involving
so
many
more
people
to
work
on
this
experience
and
the
outer
loop
and
the
observability
it
led
to
this
great
improvement
in
our
development
happiness
measurement
that
we
take
each
quarter.
H
160
percent
y'all-
like
that's,
that's
big,
and
I
don't
want
to
like
to
call
out
another
key
observation
related
to
this,
and
that
is
the
increased
unity
across
the
engineering
organizations
right.
So
many
teams
had
opportunities
to
work
together
on
things
that
we
wouldn't
ever
get
a
chance
to
collaborate
on
normally
and
the
results
of
that
have
been
so
positive.
But
really
how
do
we
keep
this
up?
That's
what's
really
important,
so
we
have
now
what
I
like
to
call
anti-slip
measures
in
place
formally
here.
H
We
call
it
our
fundamentals
program,
but
for
every
improvement
that
we
make,
we
set
new
benchmarks.
We
raise
that
bar.
We
monitor
them
and
tweet
to
understand.
Does
something
need
to
be
nudged
a
bit
right.
We
have
that
additional
visibility
to
make
it
a
lot
easier
to
have
these
conversations
with
product
managers
and
engineering
leaders,
and
it
makes
planning
able
to
factor
this
in
better
and
at
least
be
more
aware
of
what
we're
going
to
set
aside.
G
We
leveraged
our
products
issues,
actions
workflow
integrations.
We
focused
on
the
key
metrics
to
identify
bottlenecks
and
found
a
maintainable
and
a
reusable
solution.
We
ultimately
built
an
internal
tool
that
supports
our
developers
and,
at
the
same
time,
acts
as
a
guardrail
for
product
qualities
and
as
for
numbers,
we
reduce
our
ci
time
to
13
minutes,
making
our
ci
workflow
three
times
faster.
Then,
as
an
added
bonus,
we
reduced
our
compute
cost
down
by
a
fourth.
G
This
was
improvement
done
just
in
one
of
the
work
streams
in
the
larger
and
in
the
larger
initiative.
There
was
a
lot
more
improvement
as
liz
talked
about,
but
we
focus
on
the
fundamentals
of
development
tracking
down
important
metrics,
deploy
frequency
change,
fail
to
rate
time
to
restore
a
service
and,
of
course,
what
I
fix
lead
time
to
change
above
and
beyond
numbers.
G
Github
engineering
work
together
to
identify
prioritize
plan
swarm
on
the
most
important
impactful
issues
that
matter
to
us.
We
brought
together
teams
from
different
part
of
the
organization
to
work
on
the
fundamentals
and
what
warms
my
heart,
the
most,
is
how
we
were
able
to
focus
on
our
engineering
platform.
Cracking
down
technical
debt,
making
engineering
input
improvements
so
that
we
could
continue
to
build
the
best
in
class
developer
products.
For
you.