►
From YouTube: Security is a feature - GitHub Universe 2020
Description
Presented by Keith Hoodlet, Senior Manager, Application Experience, Thermo Fisher Scientific
In today's world, we find no shortage of headlines about how $APPLICATION was found to have a critical remote code execution bug, or how $COMPANY had a data breach because they failed to patch their instance of $OPEN_SOURCE_PROJECT. As the rest of the world slowly adopts Agile ceremonies and DevOps patterns, we continue to find that security is sent to the backlog and forgotten. This talk challenges the status quo by discussing how companies can and should treat security like a feature—something to be constantly maintained and improved upon. We'll also cover the tools and techniques you can use to develop more secure software.
For more from GitHub Universe 2020, visit https://githubuniverse.com
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
I
am
responsible
for
the
teams
that
make
up
the
largest
enterprise
applications
that
we
have
here
at
thermo
fisher,
including
the
conference
office
and
service
technologies,
teams
which
do
an
excellent
job
themselves,
keeping
the
business
running,
especially
during
the
situation
that
we're
in
with
the
global
pandemic,
really
hats
off
to
them.
In
terms
of
all
of
the
great
work
that
they're
doing
to
keep
us
moving
forward
in
a
past
life
here
at
thermal
fissure
scientific,
I
was
the
senior
manager
of
global
devsecops.
A
So
formerly,
I
hosted
the
application
security
weekly
podcast,
starting
back
in
2018,
with
paul
acadorian
episodes
zero
zero
to
55,
because
we
start
from
counting
at
zero.
In
the
deaf
world,
I
was
a
rank.
65
bug
crowd,
bug,
bounty,
hunter
back
in
2018
and
an
mvp,
and
when
I'm
writing
some
code,
I
really
love
to
jump
into
visual
studio
code.
It's
a
great
platform
for
those
of
you
that
haven't
had
a
chance
to
jump
in
and
get
your
feet
wet.
A
Personally,
I
love
writing
in
python,
and
bash
javascript
is
something
I'm
still
trying
to
pick
up.
Golang
is
another
favorite
of
mine.
When
I
get
an
opportunity-
and
there
are
a
couple
projects
I
want
to
highlight-
I
did
start
the
infosec
mentors
project
or
restarted
it
really
and
made
it
open
source
and
then,
of
course,
I'm
working
on
another
project.
A
That's
private
currently
called
the
secure
functions
project,
but
will
eventually
be
released
open
source
once
it's
ready
for
the
world
to
embrace
think
of
it
more
like
an
object,
relational
mapper
for
security,
in
terms
of
the
way
that
you
can
put
security
into
your
code
and
some
of
those
sensitive
functions
that
you
that
you
build
on.
That
said
some
of
my
hobbies
I
love
to
read,
I
can
always
recommend
books
and
I'll
have
some
here
for
you
today.
A
Writing
is
something
that
I
enjoy
doing
on
occasion
and
then
gaming
breath
of
the
wild
legend
of
zelda
is
a
favorite
of
mine
right
now
and
of
course,
during
times
when
we're
not
in
covet,
I
love
to
travel,
can't
wait
to
get
back
to
japan
and
say
ohio
gozaimasu
to
all
my
friends
out
there
in
japan.
So
let's
jump
in
so.
First
of
all,
you
know
what
makes
something
a
feature
right.
A
That's
something
that
is
is
often
discussed
in
concerning
the
project,
management
or
product
management
team,
the
dev
teams,
they
always
say.
Well,
that's
not
really
a
feature
security's,
not
a
feature,
and
that's
because
of
course
features
are
things
that
customers
ask
you
for
right,
they're,
the
things
that
people
want
to
see
the
things
that
people
will
complain
about
if
they
don't
have
it
in
your
application,
and
so
therefore
they'll
tell
you
about
it,
then
of
course
there's
resources
in
terms
of
people,
time
or
money.
A
A
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
as
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
ecommerce,
but
alaska
dev.
Are
you
using
some
some
sort
of
financial
transaction
application
on
your
phone
and
the
answer
is
almost
universally?
Yes.
A
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.
A
A
Do
it
when
there's
a
bomb
about
to
go
off
in
terms
of
some
vulnerability
in
a
dependency
or
in
your
code
base,
that's
been
uncovered
or
if
those
bombs
have
already
exploded,
you're
going
to
spend
time
and
money
on
those
things
to
very
quickly
fix
them,
and
it
tends
to
be
very
disruptive
when
you
do
that.
Unfortunately,
when
that
happens,
you're
going
to
be
disrupting
all
of
the
other
features
that
your
customers
have
asked
you
for,
that
they're
outwardly
expressing
that
they
want.
A
A
So,
of
course,
what
happens
when
you
don't
take
security
seriously?
What
are
those
things
that
occur
in
the
world
as
a
result
of
that?
Well,
first
of
all,
vulnerabilities
continue
to
pile
up.
If
you
don't
fix
one
vulnerability,
you're,
probably
going
to
lead
to
a
chain
of
vulnerabilities,
multiple
vulnerabilities,
it's
it's
a
challenge.
A
good
example
of
that
is,
unfortunately,
capital
one.
A
Now,
from
the
fines
themselves,
it
was
estimated
to
cost
about
150
million
us
dollars
for
them
to
pay
for
all
of
the
different
fines
and
regulations
that
they
got
struck
with,
but
the
total
cost
of
the
company
in
terms
of
buying
all
those
security
tools,
hiring
new
staff
upgrading
all
of
their
applications
was
estimated
over
500
million
us
dollars.
That's
a
lot
of
money
that
they
could
have
been
investing
in
other
ways,
or
they
could
have
made
smaller
investments
in
security
and
been
a
lot
better
off
over
the
long
term.
A
As
a
result
of
it,
you
also
see
vulnerabilities
leading
to
bad
publicity.
Key
example
of
that
is
uber
back
in
the
day,
and
this
is
not
too
long
ago.
There
was
a
data
breach
of
over
a
hundred
thousand
us
dollars
that
was
paid
out
via
a
bug
bounty
program
that
they
ended
up,
losing
their
cso,
our
chief
security
officer
over
because,
of
course,
it
was
seen
as
a
cover-up
and
that
chief
security
officer
is
now
being
brought
up
on
criminal
charges
as
a
result
of
trying
to
cover
up
the
breach
event.
A
It
was
really
unfortunate
both
for
for
uber,
who
does
generally
a
pretty
good
job
of
security
and
well,
quite
frankly,
for
all
of
their
customers
that
were
caught
up
in
all
of
that
and
then.
Finally,
of
course,
there's
zoom.
Now
zoom
is
a
great
product
and
they're
one
of
those
companies
that
is
used
universally
to
try
and
get
us
through
the
situation
that
we're
in
today.
But
here's
the
challenge.
These
global
pandemic
situations
happen,
hopefully
once
in
a
lifetime.
A
Unfortunately,
for
them,
they
had
some
end-to-end
encryption
challenges
that
were
brought
forward
right,
as
this
all
kicked
off,
and
of
course,
then
they
had
some
security
vulnerabilities
that
were
piled.
On
top
now,
they've
rushed
to
hire
a
chief
security
officer
and
bring
in
security
as
new
feature
sets
in
their
application.
A
They
could
have
avoided
that
and
actually
captured
a
great
bigger
part
of
the
market
share
out
there
in
the
world
if
they
had
actually
considered
security,
a
feature
from
the
get-go
and
now
their
competitors
have
caught
up
and
in
some
cases
are
stealing
that
market
share,
that
they
could
have
grabbed,
and
it
doesn't
have
to
be
this
way.
Quite
frankly,
there
are
a
number
of
things
that
we
can
do
as
developers
and
as
security
professionals
to
make
our
applications
more
secure.
A
A
It
was
rampant
and
almost
universal
within
the
city
and
one
of
the
psychological
theories
around
this
was
because
of
broken
windows
and
graffiti
found
throughout
the
city,
especially
in
subway
cars
and
their
kind
of
public
transit
systems,
one
of
the
ways
they
fixed
that
they
actually
took
those
subway
cars
out
of
production,
they
repainted
them
and
then
sent
them
back
into
the
production.
As
that
paint
was
drying
so
that
they
could
show
that
the
city
really
cared
about
the
people
that
lived
there
and
the
public
transit
systems
that
they
were
investing
in.
A
When
we
think
about
the
tomatoes
and
the
tomato
sauce,
I
like
to
say,
check
your
recipe
and
check
your
ingredients
and
by
checking
your
recipe,
I
mean
static
analysis
going
ahead
and
taking
a
look
at
your
code
to
make
sure
that
you're
not
inserting
any
sort
of
vulnerable
functions
or
calling
things
in
a
way
that
you
really
shouldn't
be
such
as
calling
directly
to
your
sql
database
as
opposed
to
using
an
object,
relational
mapper
and
then
checking
your
ingredients.
Dependency
check
or
depend
dependency.
Checking.
A
It's
one
of
those
tool
sets
that
can
really
help.
You
understand
that
the
ingredients
that
you're
putting
into
your
applications
are
fresh,
that
they're
continuously
being
updated
and
that
they're
actually
going
ahead
and
solving
some
of
those
problems
that
you're
seeing
when
it
comes
to
the
vulnerabilities
at
the
end
of
the
day,
if
you
make
a
great
recipe
with
rotten
ingredients,
it's
going
to
turn
out
pretty
bad
for
your
health
and,
of
course,
for
anyone.
A
A
I
have
a
couple
recommendations
here
in
terms
of
some
tools
that
you
can
go
ahead
and
use
to
do
that,
but
making
sure
that
you're
actually
checking
the
inputs
that
you're
throwing
into
your
code
to
make
sure
that
your
application
is
reacting
in
safe
and
secure
ways
and
then
for
compiled
applications.
There's
fuzzing.
Basically
again,
it's
like
throwing
spaghetti
at
the
at
the
wall
to
see
if
it
sticks
or
throwing
a
bunch
of
inputs
at
your
code
to
see
what
your
application
does
when
you
throw
it,
something
that
it's
not
really
anticipating.
A
So
there
are
a
lot
of
ways
that
we
can
solve
this
problem
when
it
comes
to
treating
security
as
a
feature
as
we
develop,
and
then,
of
course,
there
are
benefits
to
treating
security
as
a
feature.
A
good
example
of
that
as
attack
complexity,
increases.
One
of
the
things
that
I
like
to
think
about
here
is:
why
are
phishing
attacks
still
so
prevalent,
because
people
fall
for
them?
A
It
ends
up
being
state
actors,
as
opposed
to
cheeky
kids
on
the
internet,
for
an
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.
A
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,
the
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
so
where
to
get
started
right.
How
can
we
actually
start
implementing
these
things?
A
And
I
always
like
to
say,
of
course
people
are
probably
the
most
important
thing
within
your
organization.
The
next
most
important
thing
is
that
process,
and
you
have
to
think
about
a
few
things.
First
of
all,
what
speed
of
development
do
you
need
to
actually
be
hitting?
Are
you
a
web
application
that
needs
to
have
sub
millisecond,
or
rather
excuse
me
sub
second
or
millisecond
deployments,
or
are
you
building
a
product
that
has
a?
A
I
don't
know
six
month
release
cycle
and
it
doesn't
need
to
be
patched
right
away
because
it's
not
connected
to
the
internet
or
it's
not
supposed
to
be
connected
to
the
internet?
That's
really
going
to
shape
how
you
think
about
solving
security
problems.
A
really
good
example
of
that
is
thinking
about
how
fast
you
might
fix
a
problem
if
it
was
impacting
your
revenue
generation
in
some
way,
such
as
being
able
to
have
people
go
through
a
checkout
process.
A
If
you
react
faster
than
security
for
that
thing,
because
it's
impacting
your
revenue,
you
probably
should
think
about
how
you
can
actually
make
security
react
faster
as
well
in
terms
of
implementing
them
as
part
of
that
process,
and
then,
of
course,
think
of
your
breadth
of
testing.
You
want
to
be
considerate
about
not
only.
How
much
are
you
actually
covering
your
code
with
unit
tests
and
integration
tests
that
follow
that
happy
path,
but
work
with
your
security
team?
A
To
think
about
how
you
can
follow
the
unhappy
path
through
the
things
that
your
application,
that
it's
not
expecting
or
that
it
would
should
handle
gracefully
or
would
otherwise
avoid
falling
over
because
of
the
unhappy
or
malicious
unit
test
that
you're
throwing
at
it?
And
then,
of
course,
think
about
that
mean
time
to
resolution
measure.
A
You
probably
are
going
to
encounter
an
issue
at
some
point
in
the
history
of
your
application
as
a
result
of
those
vulnerabilities
that
are
going
unaddressed
so
measure
it
and
then
bring
it
forward
to
your
leadership
to
make
sure
that
it
gets
addressed
on
a
regular
basis,
which
gets
to
the
last
point,
of
course,
which
is
allocating
time
for
technical
debt.
I
like
to
say
that
if
you
allocate
time
to
fix
those
things,
periodically
fix
the
broken
windows
paint
the
walls,
change
change
the
drapes.
A
It
allows
you
in
this
case
to
improve
your
code
over
time,
making
the
house
worth
living
in
and
the
neighborhood
a
better
place
for
your
customers
to
live
in.
So
if
you
allocate
about
20
time
for
technical
debt
over
time,
you're
going
to
end
up
being
able
to
release
faster,
to
have
better
testing
and
resolve
problems
quicker.
It
pays
itself
in
the
long
term
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.
A
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
secure,
and
then
secrets
management
making
sure
that
you're
actually
dealing
with
those
problems
of
committing
secrets
to
your
code
by
understanding
how
that
works
and
making
sure
that
people
understand
how
to
use
the
secrets
fault
that
you're
using.
Of
course,
cyber
arc
conjure,
also
has
another
solution
in
the
space,
and
I
strongly
recommend
you
check
it
out
and
then
for
further
learning.
A
I
strongly
recommend
these
three
books
to
just
about
anyone
that
I
talk
to
the
devops
handbook
is
something
that
every
individual
contributor,
whether
you're
a
developer
or
a
project
manager
or
someone.
That's
working
with
a
software
product
in
some
way
should
read
front
to
back,
because
it
will
cover
pretty
much
every
use
case
that
you
can
think
of
including
part
six,
which
is
about
security,
which
is
why
I
often
say
devsecops
is
the
buzzword
today,
but
it's
really
just
part
of
devops.
A
It's
always
been
part
of
the
devops
handbook,
and
it's
something
that
I
encourage
a
lot
of
people
to
go
read
for
those
people
that
are
either
in
the
manager's
path
or
in
terms
of
their
career
or
are
looking
to
get
into
management.
I
strongly
encourage
camille
fournier's
book
the
manager's
path,
largely
because
it
brings
that
human
element
to
the
problems
that
we
deal
with.
A
It
thinks
about,
of
course,
making
sure
that
you're
not
burning
yourself
out
or
your
team's
out,
and
it
talks
through
kind
of
every
level
from
a
lead
engineer,
all
the
way
through
cto
on
what
your
world
will
look
like
as
a
result
of
moving
down
that
path
in
your
career
and
then
finally,
for
those
leaders
that
are
watching.
I
strongly
strongly
encourage
reading
lean
enterprise.
A
It
is
one
of
those
books
that
will
bring
forward
in
the
first
half
of
the
book
a
lot
of
the
ideas
that
you
see
in
the
devops
handbook,
but
in
the
second
half
it's
pure
gold.
It
will
talk
through
a
lot
of
the
different
challenges
that
you're
going
to
experience
and
then,
of
course,
how
to
slowly
break
them
down
and
rethink
about
the
way
that
you're
going
to
address
them
and
then
move
forward
and
build
a
better
enterprise
as
a
result.