►
Description
Featuring Window Snyder, CSO, Square, Rhys Arkins, Director of Product, Whitesource, and Jason Mealins, VP, Platform Engineering, Tanium. Moderated by Natalie Bradley, Field Architect, GitHub.
Your business needs to innovate at the same pace of your customers’ fast-changing needs but without sacrificing necessary security and compliance processes. Balancing the tension between speed and risk is key to be successful—and there are lots of team management strategies and tools that can help. Hear from leaders who’ve learned how to strike a balance that works for their organizations and how you can borrow from what they’ve discovered.
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
A
Our
customers,
like
many
enterprise
customers,
are
focusing
on
implementing
DevOps
practices,
scaling,
agile
method,
illah
methodologies
and
shifting
their
culture
to
be
more
collaborative
and
transparent
and
I.
Think
it's
obvious.
Why
they're
looking
to
do
this
right,
because
all
of
those
practices
and
changes
really
enhance
how
a
business
is
able
to
build
at
speed,
deliver
efficiencies
and
quality
products,
but
with
speed
they
often
kind
of
find
more
security
risks.
Shall
we
say
in
your
development
process?
A
Sorry,
so
organizations
are
kind
of
trading
off.
Do
we
continue
to
build
at
speed
or
do
we
build
more
secure
products?
So,
with
me,
today,
I
have
a
panel
of
experts
on
all
things:
security
and
software
development
to
kind
of
talk
through
this
problem
of
how
we
balance
both
agility
and
security.
So
I'm
going
to
turn
it
over
to
you
guys
to
introduce
yourselves
who
you
are
kind
of
what
you
do
where
you
came
from
and
your
background
and
a
little
bit
about
what
software
development
practices
look
like
in
your
organization.
B
So
my
name
is
Risa
Hawkins
and
I
work
at
a
company
called
white
soft
I'm
product
director
responsible
for
developer
solutions.
We
are
actually
both
a
github
customer.
We
use
github
very
heavily
to
develop
all
of
our
software,
but
we're
also
a
security
partner
for
github,
where
we
build
open
source
security
solutions
that
integrate
with
github
and
github
Enterprise.
So
we
come
from
both
angles
there
and
within
white
sauce.
You
know
we
have
a
mix
of
both
open
source
as
well.
B
C
About
you,
I'm
window,
Schneider
I'm,
the
chief
security
officer
at
square
and
prior
to
square
I,
have
been
in
security
leadership
roles
at
companies
like
Intel
Apple,
Microsoft,
Mozilla
and
fastly
I
started
off
as
a
software
engineer
and
developed
a
number
of
methodologies,
including
threat
modeling,
to
support
application
security,
analysis
and
mitigation.
At
a
time
when
we
didn't
have
much
of
an
application
application
security
space,
so
I've
gotten
to
see
a
lot
of
different
kinds
of
security,
engineering
environments
and
work
on
security
in
those
environments.
And
that's
what
we're
talking
about
today.
C
D
Jason
Mewes
I
work,
a
titanium
or
an
endpoint
security
platform,
I've
been
doing
platform
development
for
about
16
years.
When
you
deliver
solutions
on
over
a
dozen
platform
and
architectures,
and
so
we
we
aim
to
help
our
customers,
customers
to
secure
their
environments
and
report
on
everything
that
they
see
within
them.
We
do
a
mostly
air
gaps,
development
practice
using
github
enterprise
and
so.
A
Before
we
get
too
indepe
with
all
of
these
questions,
you
just
want
to
level
set
a
little
bit,
because
there's
probably
some
terms
that
we're
gonna
use
quite
a
bit
and
I
want
to
make
sure
that
we're
all
using
the
same
definition
for
these
so
Rhys.
Can
you
tell
us
a
little
bit
about
what
shift
to
the
left
means
the
developer
mentality
or
noise?
What
those
kind
of
terms
mean
to
all
of
us
sure.
B
Yeah,
so
shift
left
is
a
term
that
you
hear
a
lot
in
the
in
the
industry.
So
it's
a
really
good
one
to
to
define
what
we
mean
by
it
in
general.
The
concept
of
shift
left
originates
from
this
idea,
or
it's
not
even
idea
to
concept
that
when
the
earlier
you
catch
problems
in
the
software
development
lifecycle,
the
cheaper
it
will
be
to
fix
them.
B
That's
that
that's
the
very
like
theoretical
approach
to
it.
Practically
what
this
means
in
a
security
point
of
view,
is
giving
developers
the
tools
they
require
to
perform
the
responsibilities
that
we
now
put
on
them
to
secure
software
from
from
the
beginning.
So
you
know
if
we
are
saying
that
you
know
security
is
a
shared
responsibility
and
developers
take
over
the
role
of
or
assume
much
of,
the
role
of
security.
We
need
more
than
just
words
there.
B
So
developers
need
visibility,
they
need
access
to
policies,
and
things
like
that,
so
an
example
of
like
say
shift
left
done
wrong.
Just
a
mild
example,
which
was
brought
up
yesterday
at
the
birds
of
a
feather,
was
where
a
developer
brought
essentially
a
finished
product
for
review.
Only
for
everybody
to
discover
it
was
built
on
top
of
a
third-party
dependency
that
was
not
appropriate
for
the
way
it
was
going
to
be
released,
so
it
had
to
go
all
the
way
back
and
to
be
largely
rewritten.
B
This
is
not
necessarily
developers
fault
if
there
wasn't
a
process
in
place
where
the
second
that
they
attempted
to
use
a
dependency
that
did
not
match.
You
know,
policies
that
they
weren't
alerted
to
that.
So
if
we
think
of
how
they
could
have
gone
more
left,
first
of
all,
ideally
it
wouldn't
get
to
like
a
human
review.
Ideally
that
would
have
been
caught
in
like
automated
testing,
like
so
at
the
minimum,
the
minute
that
it
was
pushed
to
github
and
run
on
CIC,
be.
B
If
you
have
corporate
policies
for
dependencies,
then
it
should
have
been
caught
they're
ideal.
It
could
have
been
caught
even
earlier,
and
this
is
where
tools
such
as
IDE
plugins,
come
in
so
like
a
developer,
could
literally
go
to
install
a
dependency
and
get
a
real-time
alert
that
this
dependency
violates
a
security
or
a
licensing.
You
know
things
like
that,
so
yes,
so
essentially
shift
left
in
practice
means
that
if
you,
if
you
ask
developers
to
assume
the
roles
of
security,
you've
got
to
give
them
the
tools
and
the
visibility
that
they
need
to.
A
So
now
that
we've
kind
of
got
that
cleared
up
what?
Where
do
we
begin
with
all
of
this
right?
There's
tons
of
security
tools
out
there
there's
best
practices,
there's
experts,
there's
different
roles
and
functional
areas?
Do
we
need
to
change
our
models?
Do
we
need
to
change
who
we
are,
what
we
do
we're
window?
Would
you
say
we
begin
in
all
of
this?
Well.
C
We
definitely
begin
with
security
requirements,
because
if
you
don't
define
what
you
need
to
protect
against
and
then
you're
operating
a
little
bit
blind
and
defining
the
requirements
is
appropriate,
even
if
you're
coming
into
an
environment
where
there's
an
established
product,
it's
been
out,
there
you've
got
legacy
of
ten
years
of
code
or
more
sometimes
a
lot
more.
If
you
don't
know
what
the
requirements
are,
then
it's
hard
to
evaluate
which
risks
you
can
tolerate,
which
risks
need
and
mitigated
it's
hard
to
evaluate
whether
or
not
this
risk
is
sufficient.
C
We
do
have
to
do
some
security
work
here,
because
we
can
recognize
that
this
is
the
way
the
the
landscape
looks
that
we
would
like
people
who
are
in
our
space,
who
are
deploying
similar,
apps
or
operations,
do
see
attacker.
So
we
have
to
incorporate
that
into
our
thinking.
Then
they're.
The
investment
of
demonstration
is
not
nearly
as
valuable
as
evaluating
the
resiliency
of
the
system
and
starting
from
the
perspective
of
what
are
we
trying
to
protect
in
the
system?
C
What
are
we,
what
mechanisms
are
in
place
to
make
the
system
more
resilient,
and
are
they
sufficient
to
the
threats
that
we
see?
Both
in
our
environment
and
in
similar
environments
and
potentially
in
environments
that
are
more
sophisticated
but
may
have
attackers
moving
from
from
certain
kinds
of
targets
to
targets
that
look,
maybe
more
like
your
environment,
your
app
your
deployment,
a.
D
You
know
you
know
what
recent
window
said
is
very
applicable.
I
mean
you
really
want
to
security,
to
be
all
parts
of
the
practice.
If
you
want
to
make
it
everyone's
job,
you
need
not
only
to
you
armed
people
with
the
tools
to
do
good
design
reviews.
You
need
to
have
a
good
security
team.
You
need
to
invest
in
outside
plan
testing
resources.
It's
there's
no
single
point
of
success
when
it
comes
to
security,
it's
at
every
point
of
the
development
cycle.
It's
at
every
moment
of
progress.
D
Think
it's
you
really
want
to.
You
know,
invest
in
both
internal
resources.
You
know
you
have
these
bots,
that
you
buy
that
analyze
your
source
code.
You
just
attic
analysis.
You
thread
sanitizer,
but
when
you're
looking
at
your
software
from
the
inside
over
and
over
again,
you
tend
to
get
stuck
in
patterns.
So
by
looking
to
outside
firms
to
validate
your
assumptions
or
uncover
new
assumptions,
you
just
you're
constantly
keeping
your
security
practice
fresh.
I,
if
you
stick
on
one
thing,
you'll
get
stuck.
A
B
Yeah,
so
this
is
coming
from
the
experience
of
you
know,
seeing
multiple
customers-
and
you
know,
sometimes
things
seem
to
work
really
well,
sometimes
not
so
much.
One
of
the
things
with
bringing
security
tools
into
the
workflow
is
that
you
can
have
this
high
amount
of
what
we
call
noise.
If
you're,
not
careful,
you
know
so
you
know
tell
me
a
great
security
scanning
tool
and
I'll
find
you
a
hundred
people
on
Twitter,
boasting
that
they
send
all
of
its
emails
to
trash.
B
You
know
like
if
you
don't
have
a
handle
the
noise
right,
that's
kind
of
the
result
that
you
will
get,
and
this
is
especially
true
if
you
have
like
a
large
number
of
repositories
or
you
are
also
shifting
left
very
fast.
You
know
if
you're
going
from
having
minimal
automated
approaches
to
having
you
know
really
sophisticated
tools
so
in
terms
of
what
we
see
companies
doing
right.
That
is
that
they
manage
the
signal-to-noise
ratio.
B
Now
you
know
so
first
part
is
that,
like
as
an
example,
not
all
projects
are
created
equal,
so
you
may
have
like
a
vulnerability,
a
Security
Alert.
But
if
that's
like
an
internal
like
timesheet
tool
or
something
like
that
or
if
that
is
a
back-end
that
has
very
strongly
typed
inputs,
then
a
large
majority
of
the
vulnerabilities
you
might
get
raised
for
that
are
essentially
not
applicable.
B
So
the
first
thing
that
companies
doing
a
good
job
of
is
that
they
have
at
least
two
tiers
between
like
exterior
facing
projects
and
internal
ones,
because
you
know,
if
you've
got
a
team
with
limit
amount
of
time
and
limited
patience.
If
you
start
like
alerting
them
that
you
know
that
the
the
buildings
on
fire
the
buildings
on
fire
and
then
they
look
and
say:
okay,
no,
that's
just
not
that's
just
not
going
to
happen.
You
know
so
the
best
ones.
B
B
You
know
subjective,
and
that
is
that
a
large
degree
of
the
security
threats
are
still
not
applicable,
even
if
they
are
user
facing,
because
they
require
the
user
to
have
the
ability
to
very
specifically
craft
inputs.
So,
like
a
very
good
for
second
step,
I
should
say
in
this
like
filtering
process
or
triage.
Is
that
you
try
to
identify
immediately
that
the
description
for
this
like
vulnerability
or
this
security
threat?
Is
it
actually
possible
for
the
user
to
craft
that
type
of
thing
or
as
it
is
impossible
in
our
system?
B
Now,
even
if
it's
impossible,
that
doesn't
mean
you,
don't
wanna
get
rid
of
it,
but
it
means
you
don't
want
to
be
telling
people
stop
all
the
work
you're
doing
and
so
on.
So
basically
the
ability
to
have
like
a
multi-stage
triage
process,
semi,
automated
and
semi
manual,
where
you
only
alert
people
to
fires
when
you've
gone
through
a
minimal
amount
of
triaging.
This
is
very
important
because
otherwise
you'll
just
not
get
you'll
struggle
to
get
acceptance
of
tools,
because
you're
just
constantly
alerting
people
to
things
that
they
think
are
wasting
the
time.
That's.
A
Awesome,
that's
great
I'm,
a
pattern
to
get
people
justed
too.
So,
let's
check
out
the
like
breakthrough
moment.
So,
obviously,
you've
all
come
up
in
your
careers
and
you've
worked
with
different
organizations
and
they're
all
in
different
phases.
But
if
you
have
a
beginning-
and
you
start
to
see
your
development
teams
in
your
organization's
start
to
do
things
smarter
and
better,
when
did
you
notice
that
breakthrough
moment
of
like
okay,
we're
actually
getting
it
where
we're
moving
there?
And
how
did
you
keep
that
momentum
alive?
C
In
2002,
I
had
just
run,
Microsoft
and
I
had
come
from
a
company
called
at
stake,
which
was
a
very
early
security,
consulting
company,
Fair
Play,
on
security
consulting
and
at
Microsoft.
There
was
a
lot
of
pain
around
malware
and
Bill.
Gates
had
just
released
the
memo
about
how
we're
gonna,
you
know,
turn
the
ship
and
take
security
seriously
etc,
but
I
found
I
was
beating
my
head
against
a
wall
in
terms
of
trying
to
get
security
work
in
place.
C
Now
to
be
fair,
we
didn't
have
books
on
security
on
application
security
work
back
there
there
was.
There
was
barely
an
industry
around
application
or
product
security.
So
it's
not
surprising
that
there
was
a
you
know
a
little
resistance
to
this,
because
it's
a
security
work
that
you
want
to
do,
especially
in
an
engineering
environment,
is
always
in
conflict
with
things
like
performance
or
schedule,
or
some
delightful
feature
that
you
want
to
ship
to
your
customers.
But
it's
gonna
undermine
the
entire
security
architecture
of
everything
you've
built.
C
So
it
was
very
hard
to
make
progress
until
slammer
and
blaster
over
the
same
couple
of
months
really
inflamed
the
entire
ecosystem.
People
are
feeling
a
lot
of
pain,
customers
were
feeling
pain,
and
that
meant
Microsoft
is
feeling
pain
and
all
of
a
sudden,
they
were
very
open
to
a
lot
of
the
work
that
I
was
trying
to
drive
there.
C
We
did
this
kind
of
work
and
that's
why
we
do
this
kind
of
work.
So
we
don't
feel
this
kind
of
pain,
that's
fantastic!
If
you
can
to
see
that
there
are
public
disclosures
of
incidents
that
could
have
happened
to
this
environment,
your
environment,
your
application,
but
won't
because
they
happen.
Somebody
else,
and
so
we
can
see
that
this
is
a
problem
that
we
need
to
mitigate.
C
Make
sure
that
we
are
resilient
against
that
we
can
great
justified
in
making
an
investment
in
that's
useful
as
well,
but
there
are
lots
of
organizations
that
are
able
to
do
that
kind
of
work
proactively
that
are
able
to
justify
that
kind
of
investment,
and
it's
it's
generally
our
responsibility
as
security
folks
to
try
and
find
the
right
balance
between
the
the
business
needs
and
the
security
risk
and
help
expose
that
to
the
the
folks
who
need
to
make
decisions
for
that
product.
Product
manager.
C
You're
going
to
be
able
to
mitigate
that
pain
for
this
company,
and
then
the
unfortunate
end
of
this
is
that,
after
you've
built
something,
that's
pretty
strong,
pretty
resilient.
Almost
certainly
you'll
get
no
credit
for
having
done
this,
because
you
only
see
security
when
it
fails.
So
you
just
get
to
know
that,
like
hey,
I,
think
I
addressed
the
things
that
I
care
most
about
that
are
most
important
for
this
business.
This
system
and
that's
gonna,
have
to
probably
be
enough
for
us.
So.
A
C
If
you
don't
see
any
security
issues,
it
might
be
because
you're
resilient
to
it
you're
not
you're,
not
vulnerable
to
the
to
the
attackers
that
are
out
there
or
it
might
be,
because
you're
not
very
good
at
looking
for
them,
and
your
audit
mechanisms
are
insufficient.
So
yeah
you
just
you
only
know
how
to
look
for
the
things
you
know
how
to
look
for.
D
I
think
it's
it's
the
the
things
that
everyone
know.
You
know
having
good
build
pipelines,
infrastructures
code,
you
know
if
people
are
spending
a
lot
of
their
time,
trying
to
recreate
their
build
environments,
recreate
their
dependencies
you're
going
to
keep
making
different
mistakes
over
and
over
again.
So
it's
simply
just
stopping
spending
the
time
to
make
sure
packages
are
repeatable.
Make
sure
builds,
are
repeatable,
make
sure
that
people
can
easily
test
new
new
pieces
of
software
new
pieces
of
code
and,
most
importantly,
regression
testing
right
if
you
have
as
a
bomb
vulnerability.
D
Why
isn't
that
a
test?
Why
isn't
that
running?
Every
time
you
build
because
it's
the
78th
time
when
someone
makes
a
change
way
over
here,
that
something
breaks,
it's
the
initial
investment
in
time
and
infrastructure
and
build
pipelines
is,
is
invaluable
like
too
many
too
many
times
we
take
shortcuts
and
we
don't
spend
the
time
to
build
our
infrastructure
properly
and
we
always
it
always
pays
dividends.
So.
A
I'm
gonna
piggyback
off
that
thought,
because
we
talked
about
what
makes
organizations
successful,
so
you
kind
of
let
a
little
bit
into
what
makes
them
unsuccessful
Reese.
Do
you
have
anything
to
add
because
you
kind
of
talked
us
through
what
you've
seen
that
was
successful?
Can
you
talk
us
through
what
maybe
you
have
seen
that
is
not
successful
or
not
working
yeah.
B
Yeah,
so
I
almost
did
that
earlier
on
the
on
the
flip
side.
So
you
know
we
talked
about
signal-to-noise
ratio,
so
a
classic
way
to
be
unsuccessful
is
to
spend
time
chasing
after
alerts
and
vulnerabilities
that
are
not
actually
like
applicable.
You
know,
and
we
kind
of
a
perfect
world
where
we
just
automatically
know
for
sure,
but
certainly
a
classic
anti-pattern
is
you
know,
chasing
after
every
single
alert
that
is
raised,
so
that
then
takes
it
to
the
like
the
next
challenge:
right,
nice.
Okay!
So
how
do
we
within
the
organization?
B
How
do
we
kind
of
prioritize
or
how
do
we
decide
what
to
do
right?
And
but
this
can
actually
lead
to
the
next
problem,
which
is
where,
if
you
take
an
overly
simplistic
approach
to
measuring
success,
you
know-
and
it's
very
tempting
to
use-
you
know
numbers
for
that
as
we
all
can
count
and
measure,
that's
a
classic
mistake.
So,
to
give
an
example,
you
might
bring
in
security
scanning
and
you
get
a
number,
you
get
a
count
and
you
can
say:
okay,
so
maybe
we're
going
to
be
modest,
we're
going
to
say
every
month.
B
We
want
to
bring
that
total
down
something
like
that.
Well,
you
might
say
we
want
to
reduce
it
by
ten
percent
twenty
percent-
something
like
that.
So
this
is
kind
of
like
a
top-line
approach
to
it.
Now
there
are
a
couple
of
sayings
quite
similar
that
I
like
one.
That
is
that
you
are
what
you
measure
and
the
other
is
show
me.
The
incentives
and
I'll
show
you
the
results.
B
B
This
is
probably
the
most
easy
mistake
to
stumble
into,
because
it
seems
like
a
good
idea.
You
know.
Measuring
is
a
good
idea,
but
you
just
have
to
remember
that
there
does
need
to
be
a
level
of
like
subjectivity
and
I.
Think
that
having
staff
understand
that,
like
security
is
security,
and
ultimately
you
know,
we
don't
want
to
be
exploited
that
we
don't
want
exploitable
problems
rather
than
we
only
focus
on
the
numbers.
A
Okay,
so
how
do
we
throw
this
one
to
you
window?
What
what
kind
of
culture
do
we
need
to
establish
in
an
organization,
or
do
we
even
need
a
culture
to
be
established
so
that
we
follow
these
successful
patterns,
but
we're
not
just
constantly
looking
for
the
easy
out
like
measuring
our
successes
and
looking
at
statistics,
would
you
say
the
kind
of
a
company
culture
goal
could
be
if
that's
such
a
thing,
so.
C
I
think
the
the
first
place
to
start
is
with
leadership,
because
that's
a
smaller
number
of
folks
to
change,
give
folks
the
space
to
do
the
work
that
they
know
they
need
to
do.
Developers
very
often
know
where
the
security
problems
are
in
their
software,
but
may
or
may
not
get
the
time
required
to
address
them
and
might
be
incentivized
by
getting
features
out,
but
not
for
addressing
more
of
the
the
work
of
maintenance,
the
work
of
refinement,
the
work
of
resilience
and
security
is,
and
that
isn't
that
set
of
things.
C
So
there
is
very
often
you
know
large
scale,
applications
that
have
hundreds
of
developers
working
on
them,
but
there's
also
an
understanding
that,
like
oh,
if
it.
If
this
thing
happened,
it
would
all
go
sideways.
It's
not
very
resilient
in
this
one
critical
function
or
we've
got
dead
code
lighting
around
because
the
work
of
going
around
and.
C
C
Processing
in
order
to
support
that
that
that
work,
we
don't
make
a
lot
of
space
for
that
kind
of
work
and
finding
that
balance
for
the
business
is
really
important.
That's
one
one
thing
we
can
do
from
a
culture
perspective
is
get
give
folks
the
space
they
need
to
do
the
work
in
the
first
place
and
evaluate
their
success
beyond
which
features
they
manage
to
ship
but
find
ways
to
reward
folks
who
are
making
our
our
software
more
resilient
and
more
robust,
more
scalable,
more
maintainable.
C
That
kind
of
work
additionally
in
over
reliance
on
tools
to
evaluate
whether
or
not
we're
doing
good
work
in
security
is
is
problematic.
My
my
phone's
been
ringing
off
the
hook,
because
someone
gave
my
personal
number
to
a
conference
at
some
point
and
then
it
got
sold
to
a
bunch
of
vendors
and
now
they're
like
calling
me
constantly-
and
it's
it's
very
frustrating
for
me
for
lots
of
reasons,
but
number
one
is
that
I
don't
start
with
a
solution
and
try
and
figure
out
how
it
can
benefit.
C
C
Is
there
something
that
we're
doing
here
through
education
that
we
could,
unless
I,
do
in
a
more
widespread
way,
a
a
focus
on
an
over-reliance
on
tools
and
on
vendor
solutions
is
is
problematic
because
they
very
often
especially
if
they
are
looking
for
a
signal
to
evaluate
whether
or
not
there's
a
problem
present
is
it's
problematic
cuz.
They
only
know
how
to
look
for
the
things
but
know
how
to
look
for
so,
let's
say
one
of
these
tools
does
something
like.
Let's
say
it's
a
static
analysis
tool
for
your
code
base.
C
So
that's
a
way
to
mitigate
a
lot
of
different
kinds
of
vulnerabilities
at
once,
and
it
doesn't
doesn't,
let's
say,
require
the
the
code
analysis
tool
to
try
and
identify
whether
or
not
this
specific
code
construct
is
going
to
result
in
the
vulnerability.
For
the
most
part,
those
tools
are
not
nearly
as
effective
as,
let's
say,
the
the
the
eyeballs
of
a
very
of
a
developer
who's
familiar
with
with
the
the
way
the
application
functions
and
also
has
some
security
training
security
expertise
has
has
spent
some
time
learning
how
to
find
vulnerabilities.
C
The
but
if
you
have
one
release
in
your
system-
and
you
definitely
do
trying
to
find
them
all-
is
problematic
because
again,
you
only
know
how
to
find
the
things
you
know
how
to
find
so,
instead
of
finding
them
all
implementing
high-level
practices
like
isolation
of
compartmentalization
such
that
there
is
a
vulnerability
in
this
component.
I
don't
know
where
it
is
I'm,
probably
gonna,
be
a
little
shake
them
all
out
with
either
tools
I
have
or
the
skill
set
that
I've
got
present
on
my
team.
C
So
how
can
I
mitigate
those
specific
vulnerabilities
in
this
component
well
through
isolation
and
compartmentalization
I
can
make
it
more
difficult
to
for
a
vulnerability
exploited
in
one
of
these
components
to
impact
other
components
in
the
system.
I
can
go
through
my
codebase
and
say
well.
Here
is
a
bunch
of
code
that
maybe
doesn't
serve
a
business
function
anymore.
Maybe
it's
not
widely
used
by
our
customers.
C
Maybe
it
was
built
because
we're
gonna
go
in
a
certain
direction
and
then
we
decided
to
go
in
a
different
direction
and
creating
a
practice
of
eliminating
code
that
is
I,
won't
say
dead,
because
if
it's
reachable,
then
it's
potentially
problematic
from
a
security
perspective,
but
maybe
not
serving
a
business
need
anymore
and
pulling
back
on
that,
so
that
it
doesn't
serve
our
abilities
and
that
code
base
don't
impact
your
customers.
These
are
the
the
the
only
real
way
that
you're
able
to
have
a
significant
degree
of
confidence
that
you
understand.
C
The
vulnerability
or
resilience
of
your
of
your
system
is
through
these
practices
that
we've
always
known
how
to
do,
and
they
are
the
same
in
every
environment
and
like
scale
up
and
down
the
tech
stack.
Whether
we're
talking
about
you
know
your
application.
Your
applications
server
your
operating
system,
your
firmware,
your
micro
code,
compartmentalization
isolation,
reduce
reduction
of
attack,
surface,
reducing
complexity
to
simplicity
as
much
as
possible.
C
C
So
the
attack
surface
available
to
this
component
is
reduced
by
a
significant
degree
in
terms
of
the
the
input
that's
available
to
it
from
the
system
had
to
go
through
a
very
narrow,
well-defined
communications
channel,
and
so
whatever
vulnerabilities
are
present
here
are
going
to
be
even
more
difficult
to
exploit
than
they
would
otherwise
be.
These
are
gonna.
Give
you
a
lot
more
confidence
than
some
vendors
tool.
C
That's
going
to
scan
your
codebase
looking
for
vulnerabilities
that
it
that
code
constructs
not
even
a
sorry
vulnerabilities
constructs
that
might
be
vulnerabilities
or
the
the
equivalent
for
the
deployment
and
of
things
might
be.
You
know
the
vulnerabilities
that
are
identified
publicly
in
technologies
that
you
deploy
in
your
in
your
you
know,
data
center
in
the
cloud
that
are
part
of
your
your
system.
Your
ability
to
patch
quickly
is
critical,
but
there's
always
going
to
be
a
window
of
opportunity
for
an
attacker,
especially
somebody's
going
around
looking
opportunistically
for
who's
deployed
this
technology.
C
Is
it
and
is
it
reachable
from
the
Internet?
What
can
I
throw
at
it
am
I?
Am
I
Mike?
Can
I
be
successful
here
and
the
the
the
window
of
time
it
takes
to
go
from
a
vulnerability
being
identified
at
to
crafting
a
purpose-built
exploit
to
go
after
it.
It
really
depends
on
the
team,
that's
doing
it,
but
it's
it's
it's
faster.
Then
you
probably
are
able
to
patch
so
you're,
better
able
to
protect
your
environment.
C
If
you
are
able
to
minimize
the
attack
surface,
if
you're
able
to
highly
compartmentalize
if
you're
able
to
create
sandbox
Azure
levels
of
of
separation
that
that
that
reduced
the
the
attack
surface
within
your
different
components
of
the
system,
those
are
the
constructs
that
you
can
have
more
confidence
in
than
your
ability
to
identify.
Whether
or
not
this
behavior
is
suspicious.
This
code
construct
might
be
a
vulnerability
or
patch
quickly
quicker
than
the
attacker
who's
opportunistically
waiting
to
get
into
your
environment.
There's
a
lot
of
work
to
do.
A
A
I've
got
two
questions
left
so
Jason,
I'm
gonna.
Have
you
answer
this
one
pretty
quickly
and
it's
it's
kind
of
a
eight
I
guess
a
continuation
almost
of
culture,
but
is
there
something
that
you
see
companies
spending
way
too
much
time
on?
Is
it
they're
over
analyzing
tools
are
over
architecting
the
perfect
solution
and
they're
just
not
getting
and
their
pipeline
of
their
dreams
created.
Or
what
have
you
noticed?
There
I
mean.
D
I
think
window
put
up
and
put
it
pretty
well.
I
think
companies
focus
on
security
as
a
secondary
concern.
It's
something
to
be
solved.
You
really
need
to
build
a
culture
of
security
in
your
development
practices.
Security
needs
to
be
part
of
what
you're
doing,
not
something
that
is
like
to
be
fixed
and
things
need
to
be
developed
and
thought
about
securely
if
you're
always
trying
to
solve
it
with
a
vendor
tool,
you're
trying
to
solve
it
with
some
sort
of
thing
that
gives
you
a
green
light,
a
red
light.
D
A
As
much
culture
as
it
is
everything
else
so,
due
to
the
time
the
amount
of
time
that
we've
got
left
I
do
want
to
leave
the
audience
with
maybe
a
bit
of
advice,
a
recommendation
whether
they
are
just
beginning
this
journey,
whether
they've
been
continuing
to
do
it
for
years
and
just
can't
get
over
that
hump
of
success.
What
what
piece
of
advice
would
you
give
everybody
in
the
audience?
One
last
thing
to
leave
them
with
and
Rhys.
A
B
So
one
piece
of
advice:
we
talked
a
little
bit
about
the
limitations
or
overlying
some
tools,
but
a
white
sauce.
We
are
a
tool
vendor,
so
I'm
gonna,
I'm,
gonna,
double
down
what
I
have
a
favorite
quote
from
the
matrix,
and
that
is
never
send
a
human
to
do
a
machines.
Job
now
what's
important
is
to
understand
which
jobs
are
machine,
jobs
and
not
to
accidentally
miss
classify.
But
there
are
a
lot
of
things
that
can
be
done
automated
and
should
be
done.
Automated
sofa
can
be
a
ship.
B
So
if
you
have
a
policy
not
to
have
outdated
dependencies,
then
fail
fail.
The
feature
request
that
includes
a
new
dependency
that
is
unmaintained
automate
the
updating
of
dependencies.
You
know,
if
you
have
very
specific
information
about
how
to
fix
a
vulnerability,
then
give
that
patch
to
the
developer,
to
apply
not
just
kind
of
a
description
saying
upgrade.
So
these
are
what
I
call
like
machine
jobs
and
I.
B
D
A
A
Okay,
that's
that's
about
it
got
like
one
minute
left.
So
if
anybody
have
any
last
thoughts,
parting
words
shout
out
now
very
quiet,
but
okay.
Thank
you,
everybody
for
your
time
today.
I
hope
you
have
some
piece
of
information
or
something
to
go
with
when
you
go
back
to
your
office
to
start
through
your
journey
of
balancing
agility
and
security,
these
guys
are
going
to
be
here
floating
around.
So
if
you
want
to
have
a
little
bit
more
of
a
deeper
dive,
they'll
be
here
to
have
that
conversation.
So
thank
you
all.