►
From YouTube: Applying the GitHub security development lifecycle to your project - GitHub Universe 2019
Description
Presented by Justin Hutchings, Senior Product Manager, GitHub
Software security is hard! In this talk, we will review the causes of major software security incidents, and how they could have been mitigated. Then, you will learn about the how adopting a security development lifecycle is the best way to protect your projects and learn specific security practices.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
So
I
hope
nobody's
burned
out
on
security.
I
know
we
just
hit
that
hard.
We
talked
a
lot
about
security,
so
today
what
I
want
to
do
is
tell
the
security
story
in
a
slightly
different
way.
I
want
to
talk
about
a
security,
development
lifecycle
and
today,
I
hope
to
convince
you
that
there's
no
set
of
tools
you
can
buy.
A
Even
great
organizations
often
have
to
be
reminded
that
security
is
the
existential
threat
for
every
one
of
our
products.
Doesn't
matter
how
good
your
features
are
it
doesn't
matter
how
clean
your
UI
is
if
no
one
trusts
you
and
so
I
thought
sort
of
long
and
hard
about
what
message
I
wanted
you
to
take
away
here
and
so
I
threw
the
the
word
soup
here
on
the
screen
to
try
and
figure
out
like
which
one
of
these
catchphrases
we
should
go
for.
You've,
probably
seen
these
in
the
marketing
material.
A
From
like
half
a
dozen
companies
out
on
the
show
floor,
right
shift
left
or
defense-in-depth
I,
I
sort
of
created,
one
that
that
was
new
here
there.
It
is
you
can't
wave
a
magic
wand
and
be
secure.
That's
just
not
something
you
can
do.
You
need
security
to
become
a
comprehensive
part
of
your
software
development
lifecycle.
A
And
so
today,
I'm
gonna
tell
you
about
three
different
things:
I'm
gonna
tell
you
about
some
past
security
incidents.
I'm
gonna,
try
and
demonstrate
to
you
that
it
didn't
matter
how
sophisticated
their
tooling
was.
I
want
to
demonstrate
to
you
that
security
incidents
can
happen
to
any
one
of
you
in
the
room.
We'll
talk
about
what
the
security
development
lifecycle
is
and
then
recommend
some
specific
practices
that
everyone
can
take
back
and
implement
in
your
organization
to
protect
you
from
the
common
kinds
of
security
issues
that
you
might
encounter.
A
So
I'm
going
to
talk
about
three
security
incidents
today,
I've
redacted
the
names
and
I've
done
so
because
any
of
these
incidents
could
have
happened
to
anyone
in
the
room.
There's
nothing
special
about
these
incidents
or
about
these
companies
that
any
one
of
us
would
have
been
vulnerable
or
immune
to,
and
so
let's
go
through.
Those
first
I
want
to
talk
briefly.
A
Maybe
there
it
goes
first
I'll
talk
about
an
issue
that
happened
with
a
financial
company,
and
you
know
this
is
a
really
interesting
one,
because
there
was
a
hostile
actor
and
they
went
fishing
for
credentials.
So
they're
sending
emails
into
the
organization
and
seeing
if
they
can
get
anyone
to
bite,
they
got
one
person
to
bite,
they
provided
their
password
and
their
username
and
they
installed
some
malware.
A
Now
this
problem
was
compounded
because
once
they
had
access
to
that
users
credentials,
that
user
had
a
VPN
that
got
onto
the
production
network
and
so
with
those
credentials
they
had
and
the
vulnerability
you
can
see.
They
went
searching
through
the
network
to
see
if
they
could
find
anyone
that
they
could
get
into.
They
found
one
server
that
didn't
require.
Two-Factor
authentication
and
with
that
they
were
able
to
get
access
to
the
production
database,
and
these
are
the
sorts
of
things
that
can
happen
to
anyone.
A
It
was
a
configuration
issue,
one
user
made
a
mistake
and
then
one
developer
made
a
configuration
issue,
and
so
the
origin
here
was
a
phishing
attack,
some
malware
on
a
PC
pedestrian
stuff,
the
escalation
we
had
a
VPN
with
production
access,
it
didn't
do
health
checks,
I
didn't
find
the
malware.
Two-Factor
authentication
was
missed
on
one
minor
server
and
then
you
know
they.
They
didn't
have
the
data
security
to
isolate
that
database
from
those
lower
security
services.
A
Ultimately,
what
ended
up
happening
is
more
than
70
million
accounts
were
breached
and
it
costs
the
company
10
billion
dollars
for
a
phishing
attack.
Let's
do
another
one,
it's
not
special!
Sorry
we'll
talk
about
mitigation.
So
in
this
one
there
are
a
number
of
things
we
could
have
done.
Obviously,
more
user
training
helps
prevent
phishing.
Not
everyone
is
an
engineer,
not
everyone
as
sort
of
the
security,
spidey
sense
and
so
having
that
phishing
training
is
really
important.
A
They
might
have
found
that
they
had
the
one
that
was
missing
to
a
PHA
and,
of
course,
monitoring
once
the
user
was
in
the
system.
You
know
there
were
all
these
errant
network
calls
trying
to
find
a
server
that
would
work
without
to
a
PHA
at
all.
These
login
attempts
that
failed,
because
I'm
gonna
assume
the
user
didn't
click.
The
approve
button
on
the
to
FA
prompt
those
should
have
triggered
on
so
many
of
things
and
they
didn't.
A
So,
look
at
another
company
call
this
one
credit
company-
this
is
gonna,
maybe
seem
a
little
familiar
for
you.
You've
got
a
huge
server
farm.
You've
got
tons
of
microservices
tons
of
instances
and
we're
all
using
open
source
in
our
supply
chain.
You
may
remember
back.
There
was
a
particular
open
source
vulnerability
that
allowed
pretty
easy
remote
code
execution
from
a
network
endpoint.
This
company
knew
they
had
a
great
monitoring
system
in
place
there,
their
security
team.
Let
everyone
know
there's
this
problem.
They
told
everybody
go
patch.
This
is
a
big
vulnerability.
A
They
sent
the
emails
to
everyone.
The
owner
of
one
of
the
servers
didn't
see
the
email
he
didn't
patch
the
server
and
no
one
followed
up,
and
so
an
outside
user
went
poking
around
to
see
if
they
could
find
any
networks
or
any
endpoints
in
the
network
that
had
that
vulnerability.
It
had
a
very
identifiable
network
pattern,
and
so
they
found
it
now.
They're
in
they've
got
a
foot
in
the
door
and
from
there
what
they,
what
they
found
was
that
the
monitoring
systems
were
offline.
A
So
they
had
a
remote
code,
execution
system
and
this
company
had
a
great
security
system
they
purchased,
but
all
the
SSL
certs
for
that
security
system
were
expired.
So
all
the
traffic
that
happened
in
the
datacenter
was
encrypted.
They
couldn't
tell
what
it
was
doing,
and
so
they
were
effectively
blind
in
the
organization.
A
This
one
gets
better,
though,
because
there's
another
common
mistake,
one
of
the
servers
had
plaintext
credentials
on
it
and
eventually
that
user
from
scanning
the
network
found
those
credentials,
brought
them
back
and
then
used
those
to
access
the
database
once
they
got
into
the
database,
they
managed
to
get.
You
know
to
scan
48
different
databases.
They
found
a
whole
bunch
of
valuable
data.
Ultimately
they
were
in
the
network
for
78
days
without
being
detected.
A
A
A
So
what
are
the
mitigations
here?
Well,
obviously,
better
monitoring.
You
know
jamie
talked
earlier
today
about
how
you
know
we're
offering
some
tools
for
for
open
source
Vil
dependency
management.
You
should
be
using
something
for
this.
You've
also
got
to
make
sure
that
you
have
a
process
in
place
to
deal
with
everyday
things
like
expiring
certificates.
You
know
maintaining
your
servers
doing
service
health,
obviously
threat
modeling.
A
Finally,
I
want
to
talk
about
one
and
this
one's
a
favorite
of
mine
because
it
actually
used
part
of
a
platform.
I
worked
on
story
time
here
is
I
used
to
work
on
print
drivers
of
all
things:
sexiest
technology
in
the
world.
Everybody
used
print
drivers
yeah.
So
one
of
the
things
that's
really
interesting
about
Windows
is
print
servers.
Are
a
software
distribution,
endpoint
IT
administrators
hate
this,
because
why
would
you
distribute
software
from
a
print
server,
but
it's
something
that
happens,
and
so
the
the
Stuxnet
worm
was
a
really
interesting
one.
A
A
They
wanted
to
get
to
a
collection
of
industrial
machines
made
by
Simmons,
and
those
machines
were
centrifuges
that
are
being
used
for
nuclear
enrichment
in
Iran,
and
so
they
knew
their
their
adversary
was
air-gapped,
and
so
they
had
engineered
a
system
to
automatically
replicate
on
a
network
and
propagate
by
any
USB
key.
So
let's
see
what
that
looks
like,
so
you
can
see
the
net
the
vulnerability
once
introduced,
propagates
on
the
network
and
then,
if
there
are
any
attached,
USB
devices,
it'll
jump
onto
that
and
infect
those
machines
as
well
and
in
fact
those
networks.
A
Once
it's
on
a
network
that
has
one
of
those
Simmons
centrifuges,
it
tells
it
to
spin
out
of
control,
and
eventually
they
explode
now
I'm,
giving
you
this
example.
Just
as
way
of
contrast.
The
first
two
vulnerability
are:
you
know,
incidents
we
talked
about
super
pedestrian.
This
one
wasn't,
you
know
we
ended
up
with.
A
We
ended
up
with
there.
It
is.
We
ended
up
with
four
unique
zero
days
on
Windows,
as
well
as
a
compromised
trusted.
Cert
that
allowed
the
software
to
propagate
without
any
install
prompts
it
expanded
itself
by
infecting
devices
via
the
network,
as
well
as
using
USB
devices
to
jump
an
air
gap,
it
infected
about
200,000
computers
and
destroyed
20
percent
of
the
Iranian
nuclear
program,
and
so
that
was
a
very
specific
attack
from
a
very
motivated
attacker
with
extreme
capabilities,
and
you
think
about
the
mitigation
here.
A
I
guess
they
could
have
stuffed
their
workstations
ports
with
epoxy.
This
isn't
what
you're,
defending
against
the
majority
of
attackers
that
want
to
do
financial
damage
that
want
to
get
information
that
they
can
sell
on
the
black
market
on
the
dark
web
as
it
were,
they're,
not
gonna,
jump.
Think
design
things
to
jump
and
the
amount
of
effort
that
you're
gonna
spend
to
build
an
aircraft
Network-
and
you
know,
build
out
this
culture
where
there's
such
a
stuffy
sense
of
security,
you're
going
to
kill
all
of
your
innovation.
A
That's
not
your
risk
factor,
the
other
things
are
the
low-hanging
fruit,
and
so
what
did
we
see
across?
All
of
these?
Obviously
there's
human
error.
Here.
Human
error
is
the
number
one
source
of
security
vulnerabilities.
We
also
see
the
limited
threat
modeling,
and
this
is
really
a
social
process
for
how
we
engineer
software
with
security
in
mind.
Of
course,
insecure
development
practices
and
ineffective
validation
made
it
worse.
A
If
we
had
the
right
pen
testers
for
using
great
static
analysis
tooling,
any
one
of
these
vulnerabilities
might
have
been
detected
and
then,
finally,
you
think
about
this
whole
assume
breach.
If
you
don't
have
monitoring,
you
can
assume
they're
in
your
network
all
day,
long,
you're,
never
gonna,
know,
and
so
I
hope.
A
A
We'll
also
talk
about
verification
techniques
that
you
can
use
and
then
finally,
monitoring
in
response,
because
security
incidents
will
every
one
of
us
in
this
room
will
be
part
of
an
incident
response
at
some
point
in
our
lives
and
so
having
the
process
to
respond
to.
It
makes
your
life
a
lot
easier
going
forward,
alright,
so
training.
This
is
the
boring
one
right.
Everyone
goes
like
training,
sure
sure
and-
and
you
know,
I
want
to
start
like.
Yes,
you
need
to
do
things
like
account.
Security
training.
You've
got
to
tell
people
you're
being
phished.
A
You
need
to
use
to
FA
you.
You
want
to
make
sure
that
you're
communicating
securely
on
security
issues,
but
you
know,
let's,
let's
go
to
even
a
more
basic
thing.
Does
your
team
know
what
your
security
policy
is?
Do
they
know
how
to
disclose
a
vulnerability
to
your
customers?
Do
they
know
you
know
whether
or
not
whether
or
not
a
service
is
maintained
or
supported?
Do
they
know
what
kind
of
data
they
can
put
on
servers?
Do
you
have
encryption
policies
that
they
should
be
respecting?
A
Do
you
have
threat
modeling
that
you've
trained
people
on
we'll
talk
more
about
that
in
a
bit?
Does
everyone
know
how
to
use
the
verification
tools?
You've
purchased?
Everyone
in
this
room
has
probably
spent
an
inordinate
amounts
of
money
on
software
that
will
protect
your
systems,
but
if
your
developers
don't
use
it
and
don't
know
how
it's
not
gonna,
get
you
a
lot,
I
mean
then.
Finally,
when
there
is
an
incident,
do
people
know
how
to
respond?
Do
they
know
who
to
go
to
I'm
at
github.
We
have
a
great
thing.
A
We
have
the
oh
alias
when
you
screw
up
and
having
something
like
that.
We
all
laughed
like
when
we're
at
the
the
orientation
and
they
say
yeah
email-
oh
we're
not
kidding,
but
that's
what
it's
called
you'll.
Never
forget
it
because
of
that,
and
you
make
it
something
where
no
one
every
github
er
knows
this,
that's
what
you
do,
and
so,
when
there's
a
phishing
attack
and
you
respond
to
it,
you
did
the
wrong
thing,
because
it
was
really
well
done.
A
That's
what
you
do
and
we
protect
each
other
if
I
haven't
convinced
you
on
why
humans
are
your
biggest
risk.
I
want
to
point
to
this.
This
great
tweet
here
from
from
Joe,
so
there's
an
app
on
the
Google
Play
Store
I.
Don't
know
why
they
published
it.
This
makes
no
sense
to
me
it's
an
app
that
automatically
accepts
duo
to
FA
pushes
because
some
people
go
look
security
team.
You
made
this
too
hard
for
me.
A
I
just
can't
be
bothered
to
get
my
phone
out
of
my
pocket,
so
this
accepts
it
more
than
a
thousand
people
have
installed
this
thing.
The
negative
reviews
are
all
from
security
people
that
go.
Oh,
my
don't
please!
This
is
a
terrible
idea.
I
know
it's
painful,
but
please
don't
do
this,
but
your
users
are
your
biggest
risk.
A
So,
let's
talk
about,
you
know
a
design,
phase
architecture
review.
How
many
of
you
have
an
architecture
review
board,
anyone
in
the
room,
phew,
okay,
how
many
of
you
do
threat
modeling
and
do
the
little
data
flow
diagrams?
And
what
have
you
very
few?
Okay,
so
you
know
I
had
a
I
had
a
developer.
I
worked
with
ages
ago
and
I
was
some
like
young
out
of
college
guy
going
through
our
our
security
practices
and
I'm
like
we
got
to
do
threat.
Modeling
he's
like
we're,
not
gonna.
Do
that?
No,
no!
A
We
have
to
do
threat
modeling,
it's!
It's
really
good.
I'll
show
you
so
I
built
this
big
data
flow
diagram
to
describe
these
legacy
systems
that
had
been
in
place
for
fifteen
years
and
we
found
real
vulnerabilities
at
the
end
of
it.
He
said
I'm
glad
you
made
me
do
that
they
said
I'm
glad
you
did
it,
because
this
is
what
we
have
to
do.
We
have
to
have
the
conversation
about
how
these
things
work.
A
A
Do
we
have
data
that
we're
running
or
parsing
right?
Do
you
do
process
images?
Well,
there's
a
there's,
an
AOP
risk
right
there,
because
if
someone
can
break
out
of
that
image,
parsing
code
and
overrun
a
buffer
well,
all
of
a
sudden,
you're
you're
now
vulnerable,
and
so
you
go
through
and
you
have
to
figure
out.
What
are
your
trust
boundaries?
Where
are
you
accepting
input?
Where
are
you
storing
things?
A
How
are
you
interacting
between
your
micro
services,
micro
service,
based
architecture,
by
the
way,
is
one
of
the
biggest
boons
and
risks
that
I've
ever
seen,
because
people
will
say
I
want
to
isolate
all
my
things,
but
then
I
give
them
full
token
access
to
everything,
and
so
now
you
have
50
different
end
points
that
you
can
talk
to
and
if
you
find
one
that's
over
permissioned
well,
you
lost,
and
so
threat.
Modeling
and
architecture
review
are
amazing
processes
and
I
hope
everyone
adopts
them
as
part
of
your
flow.
A
Once
you
get
into
development.
Obviously
you're
gonna
be
writing
your
code.
You're
gonna
be
doing
the
normal
things
you
do,
but,
as
you
know,
as
we've
heard
all
week
this
week,
open
source
is
an
increasingly
large
part
of
development
right.
Do
you
know
what
open
source
you're
using?
Do
you
have
an
inventory
and
did
the
developers
that
brought
it
in
tell
you
why
they
needed
it?
Because
one
of
the
biggest
challenges
you
have
is
you
bring
in
an
open
source
dependency?
Maybe
you
used
it
for
a
prototype?
You
never
got
rid
of
it.
A
You
you
aren't
using
that
that
code
path
anymore
for
for
production,
but
you
still
have
the
vulnerabilities
there,
because
you've
inherited
all
those
things.
One
of
the
things
we
do
at
github
that
I'm
really
excited
about.
We
we
do
a
security
review
and
so
for
every
feature
that
goes
live.
We
open
an
issue,
there's
an
issue
template
we
fill
it
out
and
they
ask
us
all
these
questions.
They're,
like
do
you
accept
user
data?
Do
you
use
these
particular
architectural
constructs?
Where
do
you
store
things?
A
Even
when
you're
doing
conference
different
development,
you
know
you've
got
a
deadline,
it's
better
to
miss
your
conference
than
it
is
to
ship
and
have
someone
up
on
you
the
next
week.
Right,
like
all
of
your
great
press,
goes
out
the
window,
the
minute
you
get
exploited
and
so
take
your
time
and
make
sure
that
security
has
the
right
to
say
no,
you
can't
ship
until
you
fix
these
things.
A
Verifying,
obviously,
this
this
ones
later,
you
know
you
think
about
the
shift
left
paradigm
right,
we're
we're
already
after
development
we've,
maybe
shipped
some
things.
You
know
how
many
of
you
use
pen
testing
or
employ
a
red
team.
Okay,
fair
number
good,
how
many
of
you
using
static
analysis,
more
good,
good,
I
like
that
and
then
fuzzing,
maybe
maybe
okay
couple.
So
you
know
the
the
key
lessons
that
I
think
are
here.
Regardless
of
how
good
your
practices
are,
it's
always
good
to
have
something
double-check.
You
cuz
things
slip
through
the
cracks.
A
It's
a
big,
complicated
world.
We
all
know
how
hard
software
is
to
write
and
these
things
help
I'm,
not
gonna.
You
know
belabor
the
point
on
static
analysis,
fuzzing,
let's
go
into
that
briefly.
So
fuzzing
is
an
amazing
thing
in
there
it's
a
lot
easier
than
it
used
to
be.
There
are
a
lot
of
open
source
tools
out
there
that
helped
we
used
to
have
to
take
a
well-known
set
of
files
and
bit
flip
and
do
all
these
random
things.
A
A
A
Obviously
you
know,
as
Jaime
told
you
just
last
hour:
we've
got
the
dependency
graph
dependency,
insights,
I,
hope
everyone
will
use
those
they're
free,
but
you
you
also
have
to
recognize
what
your
inventory
looks
like
if
you're
a
C++
house,
we
can't
do
much
for
you.
There
are
commercial
products
out
there
that
can
help
and
you
may
have
to
buy
one
or
you
know
if
you're
primarily
running
you
know
you're
primarily
running
systems
where
your
vendor
in
your
software.
Do
you
have
a
process
where
you
can
monitor
what
you're?
A
Actually
using
do
you
know
what's
vendor
din?
Do
you
know
what
the
versions
are?
Do
you
know
where
they
came
from
I?
Remember
when
I
worked
on
a
previous
team,
we
had
15
copies
of
one
open
source
library
checked
into
our
mono
repo.
There
were
different
versions.
They
had
been
forked
because
people
had
said
ooh
that
one's
really
good,
but
if
I
change
this
one
method,
signature
it's
better
and
then,
when
the
vulnerabilities
come
out,
you
go
now.
I
have
to
handwrite
everything.
A
I
have
to
go
back
and
look
at
all
these
things
and
I've
moved
on
to
the
next
thing,
and
so
you've
got
to
have
a
process
to
keep
these
things
going
to
monitor
the
risks
that
are
gonna,
be
facing
you
going
forward
and
then
response.
Of
course.
Does
everyone
have
an
incident
response
plan
when
you
find
a
vulnerability,
how
you
respond
to
it
from
an
engineering
perspective
from
a
an
investigation
perspective
in
terms
of
what
the
damage
actually
was,
how
you
disclose
those
things?
A
If
you
don't
now's
a
great
time,
there's
no
better
time
than
now.
One
of
the
things
that
github
added
earlier
this
year
is
a
capability.
Is
the
ability
to
describe
a
security
policy?
Jamie
showed
that
earlier
and
it's
one
of
those
things
you
know
you
think
about
the
verification-
and
you
know
hacker
powered
security,
telling
people
how
to
contact
you
when
they
find
something
he's
so
important.
A
I've
gone
to
so
many
open-source
projects
and
there's
literally
no
way
to
contact
them
for
security.
Things
I
have
had
to
post
issues
and
say
I
am
aware
of
a
security
thing.
Will
you
please
contact
me
at
this
email
address,
so
we
don't
disclose
everything
to
people
so
give
them
a
chance.
Go
to
hacker
1,
put
up
a
secure
email,
a
box
do
something
and
then,
when
you
actually
get
to
fixing
things,
make
sure
you
do
it
in
a
quiet
place.
A
You
know
it
wouldn't
be
appropriate
for
everyone
in
your
organization
to
know
you
have
a
an
unpatched
security
vulnerability
and
we
talked
about
the
human
risk.
People
talk,
have
a
policy
in
place
for
who
gets
to
hear
about
these
things.
Who's
involved
in
incident
response
who's
in
the
tent,
as
it
were
on
these
things
and
then
finally
publish
the
CVE.
This
is
one
of
the
best
ways
that
we
can
improve.
Transparency
and
security
across
our
ecosystem
is
to
tell
people
when
we've
patched
a
security
vulnerability
and
what
has
to
happen.
A
A
Recap,
security
incidents
can
happen
to
any
one
of
us.
Every
one
of
us
in
the
room
will
deal
with
a
security
incident
in
your
career
and
you
should
bake
security
into
every
phase
of
your
software
development
process
so
that
it's
cheaper
than
cleaning
up
at
the
end.
You
don't
have
that
reputational
impact.
We
talked
about
how
you
want
to
train
your
users,
because
your
users
are
often
your
greatest
risk.
You
want
to
implement
design
reviews
so
that
you
can
protect
from
issues
before
they've
even
been
authored.
You
won't
have
secure
development
practices.
A
What
I
want
to
do
sort
of
as
a
parting
note
here
and
and
we'll
be
around
later?
There's
a
capture
the
flag
exercise
over
in
the
the
connect
space,
but
I
want
to
give
you
a
couple
of
resources
that
I
I
really
personally,
like
a
couple
of
books
from
Microsoft
press
that
I'm,
a
big
fan
of
to
people
like
secure
writing,
secure
code
or
SATA.
Is
that
a
fun
book
for
people?
A
It's
good
good
bedtime
reading
I'm,
also
a
big
fan
of
the
threat
modeling
book,
if
you
haven't
done
threat
modeling
before
it,
is
such
a
good
practice
to
bring
to
your
organization
and
that
book
walks
through
categorizing
issues
how
to
diagnose
them.
What
a
repudiation
attack
even
is,
that's
always
a
fun
one
and
then
there's
one.
A
You
know
the
the
24
deadly
sins
of
software
security,
I'm,
a
big
fan
of
that
one.
A
security
person
from
Microsoft,
David
LeBlanc
wrote
that,
and
it's
great
it
talks
about
all
of
these
sort
of
classic
things
that
you're
gonna
see
your
cross-site
scripting
your
buffer
overruns,
your
you
know,
unvalidated
inputs,
all
those
sorts
of
things,
and
it
does
it
in
a
very
conversational
way,
a
very
practical
way.
A
They
bought
github,
but
I
I'm,
gonna,
steal
from
them
prodigiously
the
security
development
lifecycle
that
they
developed
is
really
where
world
class.
So
if
you
want
to
know
more
about
some
of
the
practices
that
are
in
here,
there's
a
lot
of
long-form
documentation,
you
can
read
there
to
try
and
figure
out
how
you
can
apply
all
of
these
concepts
to
your
organization.
A
The
last
thing
I'll
leave
you
with
is
your
greatest
asset
as
much
as
your
greatest
risk
are
your
people,
and
it's
not
just
the
people.
You
work
with.
It's
also
the
people
in
this
room,
so
it
encourage
you,
while
you're
here
at
github
universe,
to
make
connections
with
other
people
that
are
like-minded,
because
what
you
might
find
is
the
other
people
in
the
room
have
figured
something
out
you
haven't
and
so
I
want
to
challenge
you
all
to
go
and
talk
to
two
people.
You've
never
met
today
and
just
ask
them
hey:
what
are
you?
A
What
are
you
doing
for
software
security?
What's
working
for
you
and
bring
that
back
to
your
organization,
because
I
bet,
you're
gonna
learn
some
things
and
you
know:
we've
all
got
things
to
teach
each
other.
So
with
that
I'll.
Thank
you
all
and
have
you
enjoy
the
rest
of
your
universe?
Thank
you.
Everybody.