►
From YouTube: How do Mature DevOps Teams Manage Software Security?
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
A
Hey
everybody
thanks
for
tuning
in
today
to
Clay
Smith's
monthly
webinar.
Today's
topic
is
on
how
do
mature
devops
teams
manage
security
so
before
we
get
started,
let's
go
through
a
few
housekeepingers.
We
have
prizes
to
give
out.
So
we
have
two
free
lunches
and
two
free
prize
packs
to
give
away
at
the
end
of
the
webinar,
so
be
sure
to
watch
till
the
end,
to
win
a
chat
to
be
at
a
chance
to
win
we're
also
streaming
on
Twitter
on
LinkedIn
on
YouTube,
as
well
as
our
webinar
platform.
B
A
So
today
we
have
Nigel
Kirsten
and
Jack
Chester
Nadia
Kirsten
is
the
field
CTO
at
puppet
by
perforce
and
he's
the
author
of
Puppets
much
love
report
on
state
of
the
devops,
and
we
also
have
Jacques
Chester
he's
this:
a
senior
staff
software
developer
at
Shopify,
he's
an
author
of
a
book
k-native
and
action
on
Building
Services
applications
and
he's
the
chair
of
open
SF
software
repository
working
group
and
heavily
involved
in
Ruby's
open
source
community.
A
So
thanks
for
coming
today,
hey
and
Nigel,
so
you
have
released
10
I!
Think
that's
the
full
10
reports
every
that's
a
lot
on
the
state
of
the
devops.
So
how
was
that
it's.
B
It
was
her
idea
in
the
first
place
and
she
was
she
really
drove
it
for
a
number
of
years.
I
was
co-author
and
then,
when
Dr
Nicole
forsgren
came
on
for
for
four
years,
I
think
it
was
there.
B
She
really
bought
a
level
of
statistical
rigor
and
research
to
the
whole
project,
but
there's
been
so
many
people,
Gene
Kim,
James,
Turnbull,
Jazz,
humble
Michael,
stunke
we've
had
so
many
great
authors
over
the
years,
but
last
year
for
us
was
a
really
big
one
because
it
was
10
years
and
suddenly
made
me
realize
how
long
I'd
been
missing
around
this
industry.
I
had
to
look
up
the
term
for
this
the
other
day
of
semantic
Association.
B
B
Yeah
I'm
I'm
guiding
it
at
the
moment.
We've
got
a
fantastic
researcher,
Ronan
cleanan
who's,
taken
on
sort
of
the
bulk
of
the
work
and
is
working
with
some
research
firms
for
us
we're
trying
to
do
something
a
bit
different
this
year,
because
I
think-
and
we
can
chat
about
this.
This
topic
goes
forever,
but
basically
I.
Think
devops
is
now
such
a
big
big
field.
It's
very
difficult
in
a
single
report
to
sort
of
come
up
with
interesting,
useful
findings.
B
You
have
the
folks
at
the
beginning
of
their
Journey,
the
folks
who
are
very
much
post
devops.
The
folks
who've
moved
on
who've
tried
it
who
it
doesn't
work
who
it
does
work
and
trying
to
do
all
of
that
in
a
single
report.
I
think
you
just
end
up
producing
a
book.
Every
year
we're
just
focused
on
platform.
Engineering,
yeah
I
can't
write
a
book
every
single
year.
It
gets
through
it
yeah
yeah,
absolutely.
A
Software
repositories
and
I'm
just
wondering
how
you
got
into
that
and
how?
What
was
your
journey
to.
C
Yeah
I've
been
I've,
been
co-chairing
or
Deputy.
Chairing
I,
don't
know
how
you
want
to
describe
it
with
Dustin
Ingram
from
Pipi
from
the
python
software
Foundation.
How
did
I
get
into
it?
I
used
to
work
for
a
company
called
pivotal,
which
you
know,
I
really
enjoyed
my
time
there,
and
one
of
the
things
I
worked
on
at
pivotal
was
what
was
called
pivotal
Network.
C
C
No,
this
is
really
a
thing
that
happened
like
the
the
software
like
the
USB.
Stick
would
be
walked
under
arm
guard
like
it
was.
It
was
not
kind
of
a
place.
Okay
and
I
I
suddenly
thought
there
are
people
in
the
world
who
would
be
very
interested
in
getting
inside
those
cages
through
our
software,
and
that
was
one
of
those
oh
expletive
moments
and
that
that
led
to
my
interest,
that
was
that
was
sort
of
like
the
the
lightning
bolt
that
led
me
down
the
path
to
where
I
am
today.
A
Oh
cool,
so
our
topic
today
is
how
do
mature
devops
teams
manage
software
security
and
so
I
thought.
My
first
question:
I'll
post
to
Nigel
and
like
like
I
know,
we
were
saying:
devops
means
nothing
anymore.
What
does
devops
mean?
Is
it
just
Automation
and
cloudy
stuff?
It's
just
tools
right,
yeah,.
B
Yeah
I
mean
this
is
I,
think
it's
a
tough
one
and
you
talk
to
folks
like
Patrick
Dubois,
who
has
very
much
coined
the
term
and
there
was
a
deliberate.
It
was
very
deliberate
that
they
wasn't
a
clear
definition.
Here
is
exactly
the
reductive
definition
we
have
of
what
we're
trying
to
do
here,
because
in
many
ways,
if
we
tried
that,
if
you
look
back
at
the
early
days,
it
was
basically
a
bunch
of
sysadmins
going.
How
do
we
actually
be
agile?
How
do
we
actually
take
agile
in
spirit
and
apply
it
to
operations?
B
Oh
look.
We
have
all
of
these
cultural
problems.
All
of
these
accountability.
You
know,
ownership
doesn't
match
Authority.
All
of
these
things
and
I
think
we
had
had
such
a
vibrant,
interesting,
exciting
space
emerge
because
it
wasn't
really
tightly
defined
and
you
turn
up
to
devops
days
and
you
could
get
a
talk
about
just
about
anything.
But
then
we
hit
the
Enterprise
and
I
think
the
lack
of
a
definition
meant
that
honestly,
like
shyster
vendors,
stepped
in
and
started
going,
we
do.
B
Devops
here
is
devops
in
a
box
or
Consultants
coming
along
in
a
similar
way
to
Agile
and
safe
and
various.
You
know,
sort
of
permutations
like
that,
but
I
don't
think
are
particularly
true
to
the
original
spirit.
So,
as
far
as
what
it
actually
means
to
me,
I
take
a
pretty
big
tent
approach:
it's
a
loose
collection
of
practices,
Technical
and
cultural,
to
get
over
organizational
boundaries
inside
organizations
so
that
we
can
ship
software
with
less
stress
and
better
like,
and
that
sounds
really
vague
and
could
apply
to
just
about
anything.
A
Yeah,
it
was
like
I've
worked
on
those
teams
where
it's
like
every
six
months.
I
think
that's
a
normal
kind
of
thing.
You
would
release
something
and
it
would
be
very
stressful
and
something
would
go
wrong
and
then
you'd
have
to
roll
back,
and
it
was.
It
was
a
high
stress
moment
in
a
a
big
long
journey.
So
I
think
that
moving
away
from
that
is
is
a
good
thing.
I'm.
A
And
so
how
does
that?
How
do
you
see
security,
it's
security
becoming
bring
being
brought
into
it
more,
it
wasn't
like
at
the
start.
We
tried
to
merge
development
and
operations,
and
now
we're
well
like
not
just
now,
but
now
we're
like
oh
security,
we're
kind
of
still
a
bit
siled,
let's
bring
them
back
into
this
tent,
and
is
that
how
you
see
a
charcoal.
C
Yes
and
unfortunately,
in
just
because
of
the
sort
of
the
economics
of
the
situation,
it's
going
to
be
siled
for
a
while
in
a
lot
of
ways,
there's
just
not
that
many
cyber
security
folks
to
go
around
so
a
lot
of
organizations
either
deliberately
without
thinking
about
it
or
out
of
regret
wind
up
with
a
Central
Security
team.
That
acts
as
a
gatekeeper,
which
we
know
from
our
devops
days
is,
is
an
anti-pattern.
C
The
other
thing,
I
see
as
an
anti-patent,
is
again
very
much
like
the
experience
that
devops
went
through
the
evolution
is
the
idea
that
there's
a
box
of
software
you
can
install,
and
today
you
have
security
and
that's
not
true
at
all,
and
it's
it's
a
Pity
that
we
have
to
go
through
this
Evolution,
but
I'm
I'm
hopeful
that
we'll
come
out
the
other
side
with
something
better.
C
Yeah,
it
is
important
to
think
carefully
about
your
tooling
Dan
lorentz
who's.
The
CEO
of
a
company
called
chain
guard
says
a
lot
and
I
agree
with
him.
I
had
a
similar
sort
of
motto:
Once
Upon,
a
Time
which
is
that
build
is
production.
The
the
systems
where
you
are
building
the
software
are
as
sensitive
and
you
know,
risk
dense
as
production
itself,
because,
as
I
said,
you
know
like
if
somebody
gets
into
the
bucket
of
bits.
You
are
in
a
world
of
hurt
and
a
lot
of
the
time.
C
People
historically
have
underrated
that
risk,
and
so
the
bucket
of
bits
has
been
the
fastest
path
into
production,
to
attack
the
build
system
itself
or
the
the
artifact
system
itself
as
well.
C
C
But
I
think
there's
there's
sort
of
like
two
great
tributaries
of
risk
or
two
great
tributaries
of
security
risk
that
you
can
think
about
flowing
into
the
river
as
it
were,
and
one
of
them
is
that
build
system
Upstream
dependency.
You
know,
risks
that
come
from
the
outside
of
the
organization
and
then
risks
that
come
from
the
inside
and
the
really
big
one
is
making
sort
of.
C
You
know:
unintentional
errors
in
your
software
that
lead
to
a
vulnerability
that
one
I
think
doesn't
get
as
much
time
as
it
needs
to,
because
it's
hard
again
to
install
something
or
it's
hard
to
have
a
you
know,
a
checklist
that
says.
I
have
now
secured
myself
against
security
errors.
A
Yeah,
actually,
one
of
the
times
where
you
probably
as
a
developer,
have
the
most
power
over
security
is
when
you're
bringing
in
these
dependencies
like
what
like.
What
is
it
that
you
should
consider
when
you're
like
considering
bringing
a
brand
new
dependency
like
water,
that
you
could
like?
What
does
the
checklist?
Should
you
have
a
checklist
or
are
you
can
use,
or
should
you
be
able
to
test
anything
on
your
developer.
C
Well,
yes,
or
no,
so
that
that's
an
emerging
field
right
now
is:
is
people
producing
these
checklists
there's
even
a
startup
called
soccer.dev
who
have
sort
of
automated
the
checklist
for
npm
at
least
yes,
I
would
broadly
say
like
take
the
things
you're
already
doing
so
is
this
project
Lively,
you
know,
is
it
active?
Are
people
still
contributing?
C
Do
they
respond
quickly
to
problems?
You
also
want
to
look
at
security
practices
like
do.
They
have
MFA
enabled
on
the
repository
accounts
that
they
use,
but
also
you
want
to
make
sure
little
things
like.
Are
you
accidentally
installing
a
different
dependency
from
the
one?
You
thought?
Are
you
making
a
typo
so
double
check
that
you're
getting
the
package?
B
Because
I
think
one
of
the
things
that's
underpinning
all
of
this
is
how
hard
it
is,
because
you
know
software
development
as
a
team
sport,
the
teams
keep
getting
bigger
and
bigger
and
bigger
with
different
roles,
and
it's
often
really
hard
as
an
individual
practitioner,
to
actually
make
a
good
decision,
whether
you're,
locally
or
globally.
Optimizing
and
I
think
that's
what
a
lot
of
this
stuff
comes
down
to.
It's,
like
your,
your
job,
that
you're
being
measured
on
is
to
ship
some
software
or
Implement.
B
Some
pictures
resolve
some
bugs
or
whatever,
and
if
everyone
just
goes
for
the
shortest
possible
path
to
get
there,
you
end
up
in
a
situation
where
the
environment
they're
operating
in
becomes
more
fragile,
more
aerophone,
more
insecure
and
yet
we're
just
not
very
good
as
human
beings
working
in
large
groups.
How
do
you
surface
the
right
kinds
of
things
to
make
a
decision
between
local
and
Global
optimization.
C
Yeah,
they
don't
have
a
solution
here.
No,
if,
if
you
have
a
solution,
then
I
urge
you
to
put
your
name
in
for
a
Nobel
prize
in
economics,
exactly
because
that
would
be
a
pretty
big
breakthrough.
A
For
a
life
cycle
source
code,
the
cicd
system,
the
artifacts
repository
the
dependencies,
the
external
dependencies
on
public
repos
and
then
all
the
tooling
you
use
as
well
you're
like
you're
scripting,
your
environmental
variables,
like
it's
just
there's
just
a
lot.
There.
C
Is
there
is,
and
that's
that's
one
of
the
hard
things
about
being
a
software
developer?
Is
that
there's
so
much
to
know
about
so
many
topics
that
it's
hard
to
be
an
expert
in
everything
I
again
I
wish
I
wish
I
had
the
solution
where
I
could,
just
you
know,
do
a
sort
of
an
Isaac
Asimov
thing
and
you
play
a
tape,
and
that
puts
a
memory
in
your
head.
C
Exactly
you
put
in
the
reel
to
reel
and
some
blinking
lights
and
there
you
go
but
I
think
there's,
there's
still
a
lot
of
value
in
creating
a
minimal
level
of
awareness
of
the
possible
issues.
You
don't
have
to
necessarily
know
the
solutions.
You
just
have
to
know
a
that.
There
might
be
a
problem
here
and
B
where
you
can
get
help.
A
Yeah,
absolutely
and
I
know
both
of
you
are
are
have
talked
about
how
cultural
change
and
how
people
are
actually
and
focusing
on
people
is,
but
is
a
great
way
to
get
better
security.
A
B
So
I
think
there's
a
there's,
a
bunch
of
things
to
I
think
unpack
there.
One
is
that
you
know
devops,
and
you
know
a
lot
of
the
most
significant
Tech
movements
we've
had
of
how
we
build
software.
These
are
Grassroots
movements.
These
won't
buy
people
at
the
top
of
the
hierarchical
pyramid
inside
organizations.
These
are
people
who
are
down
at
the
bottom,
and
so
it's
easy
to
sort
of
go.
B
We
have
a
cultural
problem
and
one
of
the
things
we
found
out
from
last
year's
day
devil
support
when
we
did
a
bunch
of
qualitative
and
quantitative
research.
Was
that
all
organizations
with
lots
of
what
we
would
call
cultural
problems
talk
about
culture
all
the
time,
but
organizations
that
don't
have
many
of
those
sorts
of
problems
they
stopped
using
the
word
culture,
because
it's
not
it's
not
actionable,
and
it's
actually
encourages
a
weird
kind
of
form
of
helplessness.
B
Inside
organizations
like
if
you're,
an
individual
developer
and
you're
like
well,
our
culture
doesn't
allow
for
people
to
just
make
those
sort
of
decisions.
Everyone
goes.
You
know
it's
like
an
earthquake.
What
are
you
going
to
do
about
it?
You
know
you
just
sort
of
wait
for
it
to
move
on,
but
organizations
have
actually
implemented
these
sort
of
changes
and
had
fewer
cultural
problems
somewhat.
Paradoxically,
don't
talk
about
culture,
they
talk
about
specific
things.
We
have
a
problem
with
ownership.
B
A
B
One
of
the
things
with
the
team
topologies
authors,
Manuel
and
Matt,
who,
if
you
haven't,
read
team
topologies,
it's
one
of
the
best
organizational
design
books
ever
around
Tech
and
they
they
definition
they
came
down
to
was
stop
talking
about
culture.
Talk
about
what
you
need
to
do
to
be
able
to
ship
software
quickly
with
low
cognitive
load
and
stress
on
individuals.
If
you
actually
look
at
those
things
and
identify
them,
then
they
start
becoming
things.
People
feel
like
they
can
do
something
about.
So
that
was
a
really
long-winded
way
of
saying
I.
B
A
B
People
people
can
tell
if
they're
making
a
difference,
as
you
say,
when
they're
working
currently
one
of
the
things
I
found
really
frustrating
when
I
worked
at
Google
was
there?
Was
this
ineffable
phrase?
Googliness
of
people
go
well,
that's
not
very
googly
and
you're
like
I,
don't
actually
know
exactly
what
you
mean
and
I'm
pretty
sure
you're
just
using
this
as
a
weapon
to.
B
B
A
So
I
think
that
metrics
are
important
to
improve
software
security.
C
Yeah,
sorry,
to
cut
you
off,
no,
no,
but
to
answer
the
question
as
I
see
it.
Metrics
are
essential
they're,
not
enough
and,
as
we
all
know,
if
you
govern
purely
by
the
metrics
two
things
happen,
one
anything
that's
not
in
the
Matrix
you
will
ignore
and
two
if
what
you're
doing
is
like
a
control
Loop,
where
you
have
a
little
controller,
you
think
of
yourself
as
a
little
controller.
You've
got
your
sensors,
which
are
the
metrics
coming
in
and
then
you've
got
the
actuator,
which
is
you
doing
stuff
to
the
system.
C
It
turns
out
that
if
you
want
to
improve
the
the
difference
between
the
Target
and
what's
actually
happening
now,
the
easiest
thing
to
do
is
to
fiddle
with
the
sensor
right.
It
is
much
easier
to
to
gain
the
metrics
than
to
actually
improve
the
system.
So
you
need
to
be
aware
of
that,
and
the
reason
that
that's
important
is
that
if
you
tie
punishment
and
reward
to
metrics,
they
will
be
immediately
gamed
with
an
inch
of
their
life.
B
That's
a
really
good
example
of
this,
but
they
try
to
incentivize
all
of
the
tellers
to
getting
everyone
to
open
up
bank
accounts
and
instead,
what
they
end
up
finding
out
was
that
all
of
these
Terrors
tellers
on
mass
we're
doing
the
sort
of
natural
optimization
there,
which
is
just
going
okay.
Let's
open
up
lots
and
lots
of
accounts
for
people
whether
it
was
a
good
idea
or
not
yeah.
A
Oh
yeah
I,
remember
when
I
was
in
I
was
in
curries.
It's
like
electronic
store
and
I
was
a
cashier
and
I
had
to
really
get
my
metrics
up
on
selling
insurance,
I
think
on
products,
but
I
didn't
see
what
the
product
was
and
I
was
like.
This
is
my
this
customer
is
getting
my
two
cents.
Would
you
like
Insurance
on
your
product
and
she
just
looked
at
me
and
goes
like
no,
he
said
vacuum
cleaner
bag.
Yes,.
C
I
would
say:
use
use,
metrics
to
sense
the
environment
but,
as
I
said,
Beware
tying
punishment
reward
like
if
it
didn't
work
for
the
Soviet
Union,
who
had
unlimited
authority
to
try
to
make
it
work
an
unlimited
supply
of
men
and
women
with
guns
and
dogs
to
try
and
make
a
metrics
governing
system
work.
Then
it's
not
going
to
work
for
you
right.
So.
A
B
Yeah
I
think
there's
a
good
example,
so
to
kind
of
cut
you
off
here,
it's
like
because
I
get
asked
this
a
lot
about
the
big
four
metrics
that
came
out
of
the
work
we
did
with
the
Dora
folks
and
that
they
ran
with
you
know
the
mean
time
to
recovery,
change,
failure,
rate,
etc,
etc,
deployment
frequency
and
it
is
horrifying.
What
people
out
there
in
the
world
have
done
with
these
metrics
they're
a
sane
collection
of
four
metrics
that
pull
in
different
directions.
B
The
thing
I
often
talk
to
folks
when
they're
trying
to
do
devsecops
inside
organizations
at
the
start
of
this
journey
is
like
how
quickly
can
you
push
a
change
to
production
and
know
that
it's
actually
gone
out?
Because
if
you
can't
do
that
quickly,
if
you
can't
respond
to
something
push
out
a
fix
to
it
or
a
change
of
any
kind
and
know
whether
it
worked
or
not
like
that
is
just
the
101
instead
of
substrate,
and
you
can
spend
all
this
time,
optimizing
all
sorts
of
other
policies
and
processes.
B
A
Yeah
I'm
sure
people
have
finite
thought
recently,
with
log
for
shell,
oh
and
on
log
for
Shell
is
like.
Do
you
see
critical
vulnerabilities
and
updating
your
software
all
the
dependencies
as
in
a
having
a
process
for
that
being
really
important
or
what
you
yeah
yeah?
So
actually,
but
on
that
we
have
a
poll.
A
So
the
question
is:
do
you
pin
your
bills
or
do
you
update
to
the
latest?
So
this
is
sort
of
this
question
comes
up
with
it's
mostly
around
vulnerabilities.
Well,
not
there's
loads
of
good
reasons
to
update,
but
with
respect
to
security
when
you,
if
you
update
to
latest
you'll,
get
all
the
fixes,
but
if
you
pin
your
bills,
you're
not
going
to
be
tricked
into
updating
to
a
bad
version.
A
So,
and
so
we
see
here,
there's
there's
most
it's
kind
of
half
and
half,
but
most
people
prefer
to
update
to
the
latest.
So
24
I
said
by
49,
update
to
the
latest,
20
40
say:
pin
my
bills
and
the
rest.
Are
it's
not
important
to
me
so
I
think
and
I
I?
Don't
really
feel
like
this
question
is
solved
yeah,
so
I
in
Clay
Smith.
We
always
say
we
recommend
to
pin
your
bills
but
like
if
there's
a
critical
vulnerability,
it'd
be
great
if
you're
updated
as
quickly
as
possible.
A
B
A
To
give
you
a
a
prompt,
an
alert,
a
PR
to
with
an
update
to
the
latest
and
that
will
kind
of
Quicken
that
cycle.
So
what
do
you
guys
think
on
that
topic?.
B
This
one's
a
bit
of
a
honest,
this
I'll,
let
Jack
answer
this
more
in
more
detail,
but
I'd
say
at
a
high
level.
The
way
I
feel
that
is
some
of
it
depends
on
scale
if,
if
you're,
like
two
developers,
who
own
the
whole
system
that
you're
in,
like
you
know
in
a
very
small
startup,
the
answer
is
very
different
too.
B
If
you're,
a
multinational
bank
with
regulations-
and
you
know,
hundreds
and
hundreds
of
teams,
interacting
with
each
other
I-
do
think
you
know
the
big
problem
with
auto
updating
to
latest
all
the
time
is:
when
are
you
creating
that
artifact?
That
are
you
testing
like?
Are
you
creating
something
that's
going
to
be
tested
in
the
test
environment?
A
C
Depends
well,
on
the
one
hand
and,
on
the
other
hand,
I
I'm
broadly
in
the
camp,
that
you
should
pin
your
dependencies
in
source
code
and
update
them
automatically
I,
don't
like
mystery
dependencies
showing
up
in
production
without
warning
and
without
a
record
that
makes
me
deeply
uncomfortable
personally,
but
I
recognize
that
it's
a
hassle
we
are
sort
of
like
in
I,
don't
know
like
not
quite
the
pre-history
but
we're
definitely
at
least
no
further
than
the
Bronze
Age
in
term
of
dealing
with
this
stuff.
C
We
have
technology,
but
it
goes
blunt
easily
and
causes
a
lot
of
a
lot
of
hassle
and
we
just
need
to
learn
to
grow
the
muscle
to
do
it
and
that's
just
going
to
take
a
lot
of
time
and
be
sporadic
and
uneven.
But
I
do
agree
with
Nigel's
point
that
there's
sort
of
minimum
standards
of
hygiene
you
need
to
reach.
First,
you
need
to
have
good
testing
in
CI
in
place.
You
need
to
have
smooth
the
road
to
production
from
source
code
changes.
Those
are
the
same
capabilities.
C
You
will
need
to
automate
upgrades
I
would
put
nesters
here
about
like
the
trade-off
and
risks
between
waiting
to
upgrade
versus
upgrading
too
soon
and
sonotype
have
released
their
eighth
state
of
the
supply
chain
report
a
few
days
ago.
It's
worth
reading,
they
do
fantastic,
fantastic
research.
Their
position
is
that
you
should
hang
back
a
little.
C
You
know
one
on
two
versions
behind
the
pace,
or
maybe
some
amount
of
time
I
think
would
be
a
better
way
to
do
it
on
the
theory
that,
if
you're
right
at
the
bleeding
edge,
you
will
you
will
get
cut
from
time
to
time
and
that
it's
not
worth
the
risk
I'm
kind
of
on
the
fence
about
that.
I
think
that
the
incidence
of
a
vulnerability
existing
is
far
higher
than
the
incidence
of
a
supply
chain
attack
being
successful
balance
of
risks.
What.
B
About
General
bugs
too,
because
this
is
the
one
that
always
gets
me
like:
there's
nothing
I
find
more
frustrating
than
if
you're
developing
something
using
a
bunch
of
libraries
or
Frameworks,
and
you
keep
beating
your
head
against
the
wall
going.
Why
is
this
not
working?
It
should
be
working,
and
then
you
upgrade
a
dependency
and
you're
like
it
was
actually
above
all
wrong.
Yeah
I
think
there's
something
to
be
said
to
for
staying.
The
latest
generally
leads
to
a
better
experience.
C
It's
also
because
upgrading
is
is
not
just
like
a
linear
function
of
the
number
of
things
you
have
to
upgrade
it's
exponential
right,
because
there
are
interactions
between
the
dependencies.
So
the
longer
you
lead
it.
You
know,
like
the
the
larger
that
sort
of
Cartesian
join
of
Doom
gets,
so
you
wanna,
you
wanna,
keep
close
to
the
edge.
C
If
you
can
at
Shopify,
for
example,
we
have
the
monolith,
which
is
the
main
application
that
probably
largest
rails
app
in
the
world,
and
we
keep
that
on
Rails
Edge
once
a
week
once
a
week
we
upgrade
to
what
is
literally
in
the
main
repo
of
rails,
like
we're
not
waiting
to
point
releases
or
anything
like
that,
we're
keeping
up
with
it,
because
we
know
that
the
upgrade
pane
is
just
too
large.
C
If
we
hang
back
for
a
year
like
it
would
just
just
be
catastrophic
and
I
can
I
can
sort
of
look
back
at
the
earlier
history
of
the
company
through
through
documents
and
and
and
get
get
commits
and
I
can
see
that
pain
and
I
can
see
why
we
did
it.
B
So
I
think
one
of
the
interesting
things
well,
while
experience
working
out
her
audio
is
a
lot
of
this
conversation
around
security
issues
and
software
Supply
chains.
It
often
feels
kind
of
one-sided
in
terms
of
companies
that
are
getting
an
awful
lot
of
software
sort
of
for
free
from
volunteer
maintainers.
Who
have
been
you
know
every
time.
One
of
these
vulnerability
comes
out.
It's
like
everyone,
has
the
pitchforks
out.
B
For
the
meantime,
people
like
yeah
I'm,
you
know
I
was
doing
this
out
of
the
goodness
of
my
heart
and
I
was
maintaining
that
stupid
backwards
compatible
feature
because
you
all
protested
against
it.
I
think
something
has
to
change
about
the
producer
consumer
relationship
with
open
source
like
there's
a
general
assumption
that
it's
software
of
a
certain
quality.
Everyone
should
try
and
write
good
software,
but
something
feels
out
of
kilter
in
society
about
the
promises
and
commitments
that
people
expect.
There's.
C
A
there's,
a
really
fascinating
paper
that
just
is,
is
currently
in
preprint
on
SSR
and
the
social
science
research
Network.
It's
a
preprint
server
called
tragedy
of
the
digital
Commons,
which
which
is
like
written
for
a
Law
Journal,
but
goes
into
kind
of
like
the
economics
of
it.
You
know
like
the
law
in
economics,
kind
of
situation,
and
she
makes
exactly
the
same
point,
which
is
that
large
software
companies
in
particular
are
free
writing
off
the
community
in
a
big
way.
C
A
A
C
A
Received-
and
it
was
just
like-
oh
for
the
love
of
God,
like
he
he's
like
doing
this-
for
free
and
you're
like
telling
him
giving
him
a
legal
letter
to
update
and
like
from
a
company,
that's
using
his
code
for
free,
it's
it
definitely
doesn't
sit
well,
doesn't
seem
morally
right
or
something.
C
I
mean
I'm
I'm
kind
of
in
an
interesting
position
here,
because
I'm
I've
been
one
of
the
champions
for
introducing
MFA
requirements
for
for
software
repositories.
You
know
whether
the
authors
need
to
have
NFA
enabled
because
their
packages
are
so
widely
used
and
in
the
sense,
that's
imposing
a
cost.
You
know
it's
imposing
imposing
additional
effort
on
the
package.
C
Maintainers,
who
didn't
didn't
ask
for
it
right
and
and
I
do
feel
bad
about
that,
but
I
I
then
have
to
sort
of
take
the
utilitarian
stance
that
the
end
consumers
are
far
more
numerous
and
for
them
the
consequences
are
far
more
serious.
If,
if
there's
a
compromise,
it's
it's
a
tricky,
it's
a
tricky
thing,
but
I
think
the
difference
there
is
that,
like
the
end,
consumers
can
just
involve
other.
A
C
A
Have
turned
on
2fa,
maybe
some
of
them
don't
know
about
us
or
some
of
them
don't
want
to
do
it
and
I'll
just
wait
till
they
have
to
and.
C
C
A
Yeah
and
what
about
like
I've
seen
I
saw
a
list
of
things
that
maybe
open
source
maintainers
can
do
to
be
more
secure,
but
it
was
like
a
lot
of
stuff
for
someone
to
do.
It
was
like
add
scorecards
to
their
repo.
A
There
was
like
there
was
just
a
ton
of
stuff
to
oh.
Do
a
course
like
I.
Just
can't
imagine
if
you're
doing
this
in
your
spare
time
that,
like
a
lot
of
people,
are
gonna,
do
it.
B
Especially
when
people
often
got
into
this
because
it
was
fun,
you
know,
like
hey,
I
solved
a
problem
in
a
fun
interesting
way
and
I
want
to
share
that
with
the
world
and
I.
Think
I,
don't
know
if
our
software
licenses
are
the
ways
or
some
kind
of
opt-in
system,
but
I
feel
like
there's
got
to
be
a
way
to
distinguish
between
hey
everyone.
B
Here's
something
fun
and
cool
have
at
it,
and
I
am
deliberately
building
something
that
I
would
like
to
be
part
of
a
bigger
structure
and
a
bigger
ecosystem
and
I
think
that's
sort
of
the
constant
trade-off
you
don't
want
to.
You
don't
want
to
stifle
people
just
sharing
code
that
is
used
to
be
fun,
but
there's
going
to
be
some
Declaration
of
intent
somewhere.
C
And
so,
if
you
you
don't
like
those
terms,
you
are
within
your
rights
to
take
their
software,
which
is
open
source
into
running
yourself
within
your
rights
to
just
distribute
Source
from
a
website
that
you
own,
like
there's
Alternatives
like
they're,
not
as
convenient
right.
They
aren't.
But
you
know,
that's
that's
the
trade-off.
B
Yeah
I
think
that's
yeah,
and
it's
similar
to
all
of
this
reminds
me
of
I
was
a
Debian
maintainer
back
in
the
day
when
you
know
you
were
sort
of
in
one
of
two
big
Linux
camps
and
I
was
quite
shocked
when
I
sort
of
moved
to
that
point
level
of
suddenly
having
all
of
these
security
processes
enforced
on
me,
but
it
was
the
right
thing
to
do,
because
that
was
the
Distribution
Center.
You
know,
volunteers,.
B
Yeah
I
mean
I,
think
you
know
as
as
much
as
you
know,
I
hate
to
you
know,
particularly
towards
the
end
up
to
claim
the
death
of
the
operating
system
distribution.
A
lot
of
these
problems,
I
think
have
been
solved
in
smaller
communities
before
we're
just
now.
Dealing
with
them
happening
faster
in
a
bit
bigger
scale,
and
you
know
in
in
Tech
I
feel
like
we
love
nothing
more
than
to
ignore
the
discoveries
of
the
past.
A
Yeah
and
so
what
does
that
say?
So
what
do
you
think
there
are
the
biggest
challenges
in
software
security
or
is
it
like?
We've
been
talking
about
how
there's
just
so
many
challenges,
and
it's
just
all
of
them
together,
but
if
you're
gonna
give
yourself
a
top
one
or
two,
what
would
be
your
favorites.
C
C
There's
there's
this
vast
amount
of
latent
risk
out
there
and
we've
just
got
to
sort
of
chip
away
at
at
everything
that
gives
right
we're
pushing
in
every
direction
at
once
and
anything
that
gives
we
push
harder
because
we're
getting
some
progress
out
of
it.
We're
retiring
some
risk
from
it
building.
C
Building
it
up
and-
and
you
know,
reducing
the
net
risk
for
everybody,
which
is,
which
is
the
sort
of
the
goal.
You
know
that
there's
that
problem,
that
open
source
is
basically
are
comments
right,
like
it's,
it's
a
kind
of
a
resource
that
you
can't
exclude
people
from
using,
but
where,
if
lots
of
people
use
it,
then
that
puts
pressure
in
the
maintainers.
C
It's
rival
risks,
as
economists
call
it,
and
that's
Commons
and
they're
difficult
to
govern
they're
difficult
to
manage,
because
you
know
everybody's,
an
individual
they've
got
different
incentives
to
to
be
selfish
and
the
difficulty
is
finding
those
well-positioned
parties
to
be
involved
so
to
their
credit,
I
know
we
bashed
up
big
companies
but
to
the
credit,
a
lot
of
them
are
coming
to
the
table
or
trying
through
the
open
source
security
Foundation,
which
I
participate
in
open
ssf.
C
So
you've
got
your
Googles
and
your
Microsoft's
and
your
Amazons
and
and
a
whole
bunch
of
companies
participating
contributing
money
contributing
folks
time
trying
to
sort
of
attack
this
on
all
France
yeah.
A
C
A
Like
I
is
that
the
10
point
Mobility
plan
is
is
part
of
the
open
ssf
way
to
secure
open
source,
and
do
you
feel
like
open
source
is
one
of
the
most
important
things
to
secure
when
we're
talking
about
software
in
general,.
C
Is
the
sky
blue
only
on
sunny
days
yeah,
it's
it's
everywhere!
Now
it's
in
pacemakers,
it's
in
nuclear
power
plants
like
there
there
isn't
there
isn't
a
single,
critical
or
high.
You
know
High
consequence
piece
of
infrastructure,
whether
social
or
technical
that
doesn't
rely
on
it.
C
We
we
have
to
like
it's
it's
the
soft
underbelly
of
of
the
whole
of
the
social
economic
system.
At
the
moment,.
A
C
Strictly
yes,
this!
This
is
a
good
example
of
that
argument
from
tragedy
of
the
digital
Commons
article,
that
the
cost
should
be
pushed
onto
the
large
companies
that
currently
free
ride
and
have
the
resources
to
not
free
ride,
and
the
US
government
is
in
a
great
position,
because
it's
the
single
largest
page
tourist
software
in
the
world
to
push
push
those
standards
down
and
to
make
them
common
and
once
they
become
common,
then
other
consumers
from
those
companies
will
say.
C
Well,
you
already
have
that
capability
I
demanded
also,
and
that
creates
a
sort
of
a
flywheel
effect,
but
in
terms
of
Regulation
of
Open
Source
software
itself,
outside
of
those
big
companies
like
your
regular
maintainer
at
home
on
a
weekend
dear
God.
No,
that
that
would
that
would
kill
the
Golden
Goose,
but
not
before
the
goose.
You
know
defecated
all
over
the
bed.
B
Well,
I
think
what
is
a
rather
hairy
thread
to
mix
metaphor
or
something
we
don't
value
maintenance
enough
in
society
and
I
think
this
is
sort
of
part
of
the
problem
that
you
know,
and
this
is
why
I
think
right
to
repair
movements
and
all
of
these
things
are
so
important
that
you
know
you
work
in
Lots.
We
have
a
culture
in
software
development
that
I
think
reflects
Society
in
general.
B
At
the
moment,
which
is,
it
is
considered
better
to
launch
new
things
than
to
iterate
on
existing
things,
and
the
job
of
maintainers
everywhere
is
to
iterate
on
the
existing
things
and
I
think
the
healthiest
software
engineering
environments
I've
ever
worked
in
have
been
the
ones
where
they
really
senior
folks
are
sort
of
proclaimed.
You
know
people
lauded
to
look
at
systems,
make
small
incremental
changes
to
them
over
time,
keep
them
going
in
the
right
direction
and
that
that's
recognized
as
valuable
and
I
think
this.
B
B
Around
us
valuing
the
act
of
Maintenance
more
so
that
big
companies
did
want
to
participate
in
it
so
that
they,
you
know,
reached
out
to
maintain
projects
with
respect.
You
know
I
think
Google
does
a
reasonably
good
job
of
this
like
we,
we've
had
Google
for
each
other
security
vulnerability.
It's
something
you
you
ship!
You
know
we've
seen
some
of
our
users
have
it.
You
know
they
basically
wield
a
big
stick
and
go.
B
If
you
don't
do
something
about
this
in
30
days
or
60
days
or
whatever,
we'll
just
we'll
shout
it
from
the
rooftops
and
they
can
because
they
Googled
it
I
think
there
are
ways
to
do
that:
sort
of
sort
of
encourage
people
to
do
the
right
thing.
But
fundamentally,
we've
got
to
Value
the
act
and
process
of
Maintenance
more
everywhere.
A
And
she
I
wonder
if,
like
government
Fontaine
could
help
I
know,
like
obviously
the
10
point.
Mobility
plan
should
improve
security
and
that's
using
money.
I
know
maybe
to
I.
There
was
talk
about
resetting,
putting
funding
towards
resetting
to
fa
shark
and
public
repositories.
A
But
do
you
see
it?
Do
you
think
that
maintainers
could
get
paid
for
improving
security
of
prod?
Obviously
selective
products
like
that
are
used
in
critical
systems
like
do
you
think
that
would
that's
a
solution
or
is
that
just
it's
just
it's
not
it's
not
gonna.
It's
not
maintainable.
In
the
long
run.
C
I'm
concerned
that
it
goes
back
to
that
problem
of
metrics
that
that
it
will
be,
you
know,
the
incentive
is
just
to
do
what
what
the
funder
says
and
that
will
attract
people.
You
know
like
the
the
story
of
the
the
British
trying
to
get
rid
of
cobras
in
India
and
they
pay
people
to
bring
in
Cobra
heads
and
people
just
started
breeding
cobras
or
something
similar
where
there's
gun.
Buybacks
and
people
are
just
3B,
3D,
printing
guns
on
mass
and
bringing
in
boxes
of
3D
printed
guns
and
making
money
that
way.
C
I'm
concerned
about
that
I
think
where
government
has
a
role
in
terms
of
funding
at
least
would
be
on
what
you
might
think
of
as
sustainment
activities,
so
things
like
subsidizing
or
fully
funding
training
right,
making
it
freely
available
to
as
many
people
as
possible,
encouraging
colleges
and
universities
to
pick
it
up
as
part
of
their
curricula.
C
Things
like
you
know,
shared
resources
for
software
repositories,
shared
resources
for
open
source
projects
that
need
you
know
a
Security
review.
A
lot
of
things
that
the
open,
ssf
is
already
doing
can
definitely
be
scaled
up
with
Government
funding.
B
C
I
I
I'm
I'm,
a
bit
of
a
you
know
like
I.
Consider
myself,
a
Centrist
I
used
to
be
a
Libertarian
but
I'm
about
to
sound
like
a
raving
Looney
Lefty,
because
I
I
think
there's
far
too
many
things
in
corporate
malfeasance
in
which
the
punishment
is
a
fine,
whereas
it
should
be
criminal
time
for
the
executives
who
authorized
or
who
failed
to
authorize.
C
You
know
some
activity
yeah,
because
that's
the
only
thing
that
actually
gets
their
attention.
If
you
get
fined
it
doesn't
fall
on
the
people
who
made
the
decision,
it
falls
on
the
shareholders
exactly
right.
B
A
Right,
yes,
yeah
I,
actually
I
was
listening
to
the
the
security
weekly
podcasts
and
at
the
end
of
it
they
talked
about
insurance
as
a
way
to
to
drive
companies
to
to
do
more
to
be
better
at
security,
and
it
can
be
a
more
effective
way
than
compliance.
So
that
like
when
you,
when
you
have
a
data
breach
and
you
realize
you're
not
insured,
and
you
have
to
pay
a
lot
of
money
to
maybe
for
on
on
people
so
suing
you
or
even
to
get
back
to
where
you
were.
C
Why
not?
Why
not
vote?
You
know
we.
We
have
punishments
for
people
who
you
know
like
if
you
don't
do
fire
safety
in
your
factory
right.
Not
only
do
you
mess
up
your
insurance
and
not
only
can
you
face
fines,
but
the
people
who
are
responsible
are
criminally
malfeasant.
They
can
go
to
jail
for
neglecting
fire
safety.
C
You
know
the
consequences
of
of
data
breaches
dire.
The
consequences
of
lackadaisical
security
are
only
going
to
grow
worse
as
time
goes
on
and
as
as
all
matter,
somehow
becomes
programmable.
Basically,
then,
this
stuff,
really
matters
and
I,
think
this
argument
that,
like
oh,
but
the
corporate
veil
is
sacrosanct.
It's
just
like
the
corporate
veil
is
there
to
deal
with.
C
You
know,
questions
of
who
owes
debt
to
whom
like
who
can
be?
Who
who,
who
is
liable
for
how
much
it
didn't
give
you
like
a
magical,
get
out
of
jail
car?
That
was
never
the
idea.
So,
as
I
said,
I
sound,
like
you're
raving
Mooney
on
this
point,
because
I'm
so
frustrated
by
companies
that
walk
away
with
a
fine
and
the
executives
are
still
there
right.
They
don't
get
sacked.
They
just
go
like
oh
well,
that's
the
cost
of
doing
business
and
that
to
me
is
psychotic
yeah.
B
B
A
Who
gets
a
free
lunch
he's
sharing
on
on
the
streaming
platform,
we
have
Arthur
courage,
he's
a
free
lunch,
jinsu
prize
pack
Arjun
just
he
prize
pack,
I'm
I'm,
so
sorry,
I'm
butchering
these
poor
people's
names
Caitlyn.
So
oh
God,
Katelyn
I'm!
So
sorry
you
get
a
prize
pack,
Hunter
Kuhn
price,
Park
and
Hillary's
gonna
be
reaching
out
to
everybody
over
email.
With
with
your
details
to
send
it
on
your
send
it
on
to
you,
but
I
hope
everybody
enjoyed
our
talk
today,
I
loved
it
I'm.
A
So
sorry
about
my
my
speaker
issues.
It.