►
Description
Both Sonatype and Red Hat have spent many years studying enterprise development teams, open source projects, and how everything in the OSS ecosystem works together, Over time, we’ve found three truths for software engineering teams and the 20 million software developers that work for them: They seek faster innovation. They seek improved security. They utilize a massive volume of open-source libraries. These truths can sometimes feel at odds with each other. Developers do not often “own” the security of their own products. Instead, they are subject to security oversight and are relegated to using reactive tools that tell them about vulnerabilities and code issues after development. While the majority of developers have become more aware of security, it’s difficult to implement appropriate measures when current tools to manage open source dependencies are often built with security in mind more than development.
A
Whoops
always
loved
the
screen
share
thing
today
with
us.
We
have
matt
howard,
the
cmo
of
sona
type,
and
he
brought
with
him
the
co-founder
and
cto
brian
fox,
and
these
gentlemen
here
today
are
going
to
talk
about
all
things,
sonotype
and,
and
I
would
like
to
say
that
we
are
fortunate
enough
to
have
been
working
with
sonatype
for
several
years
now
and
for
them
for
the
point
of
helping
to
get
their
software
tested
and
certified
on
the
red
hat
portfolio
and
specifically
red
hat
openshift.
So,
gentlemen,
thank
you
for
joining
the
show
today.
B
Thank
you.
Thank
you,
michael
for
having
us
and
thank
you
red
hat
for
hosting
the
show.
It's
always
fun,
to
have
the
opportunity
to
talk
with
the
community
at
large
and
just
just
one
small
clarification
on
something.
You
said
we're
not
going
to
be
talking
about
all
things,
sauna
type
today
we're
certainly
going
to
try
and
avoid
that
as
much
as
possible.
C
Yeah,
that's
a
great
question.
I
haven't
thought
about
that
in
a
while,
so
I
got
involved
in
in
maven
2004
2005.
maven
2
was
still
in
alpha.
Maven
one
was
was
the
thing
at
the
time
I
got
involved
in
that
because
we
were.
I
was
at
a
small,
boutique
public
health
shop
and
we
were
modernizing
our
processes
moving
to
subversion.
You
know
the
big
popular
source
control
before
git
and
trying
to
find
something
better
than
ant
to
manage.
C
You
know
increasingly
complicated,
build
environments,
and-
and
you
know
I
I
was
doing
a
lot
of
development
management
at
the
time.
Not
so
much
coding,
and
so
the
people
working
for
me
were
were
piloting
out,
maven
and
bumping
into
edge
cases
and
I'd
go
home
and
start
hacking
on
it
at
night
and
fix
the
problems
and
come
in
the
next
day
and
then
have
my
employees
pick
up
and
and
use
the
plug-in
that
I
wrote
overnight
to
to
move
that
forward.
C
C
It
became
kind
of
fun
and
became
a
hobby.
You
know
and
and
fast
forward.
Several
years
later
you
know
there
there
was
an
opportunity
to
join
jason
and
a
couple
others
to
to
start
a
company,
because
maven
was
kind
of
becoming
the
big
hot
thing.
Everybody
wanted,
training
on
it
and
people
needed
help,
and
so
that
that
was
the
genesis
of
sonotype
was
going
out
and
doing
training
and
consulting
to
help
big
companies
adopt
maven.
You
know
that
was
2007
and.
B
B
It
intersected
with
sort
of
this
idea
that
software
development
could
be
sort
of
accelerated
in
some
form
or
fashion
by
enabling
developers
to
kind
of
borrow
components
or
library
or
code
from
third
parties,
broadly
speaking,
open
source
ecosystems
and
and
and
benefit,
and
so
what?
What?
At
that
time,
were
you
sort
of
imagining
or
what
was
your
thought
process
like
as
you
sort
of
think
about
where
software
has
kind
of
come
to
today
and
and
where
maven
sort
of
intersected
with
the
early
days
of
componentized
software
development.
C
Yeah
well,
what
was
interesting
about
maven
was
that
you
know
it.
It
kind
of
it
was
opinionated
and
in
it
forces
standards
on
projects
and-
and
you
know,
build
systems
before
that
it
was
like
impossible
to
come
along
and
build
somebody
else's
software.
You
had
like
all
kinds
of
switches
and
things
to
install
it
was
it
was
really
hard
and
that
actually
made
it
hard
to
both
adopt
and
contribute
to
open
source.
C
You
know,
prior
to
getting
involved
in
maven,
we
tried
to
patch
some
stuff
on
eclipse
the
ide
and
that
build
process
like
was
impossible.
Even
for
a
group
of
us
who
spent
all
day
doing
java,
we
could
could
barely
get
the
thing
to
build,
and
so
we
just
threw
our
hands
up
but
maven.
On
the
other
hand,
you
could
you
could
very
easily
reproduce
the
stuff,
and
then
it
made
it
super
easy
to
contribute
and-
and
that's
what
was
really
interesting
about
it,
and
so
because
maven
was
kind
of
forcing
the
adoption
of
binary
reusability.
C
So,
in
order
to
use
somebody
else's
open
source
code,
you
could
just
add
a
line
to
your
build
script
and
it
would
download
it
and
figure
out
all
the
dependencies
for
you
and
and,
and
you
were
off
to
the
races
it
made.
It
really
easy
to
just
pick
up
and
use
components
where,
prior
to
that,
you
might
be
cutting
and
pasting
code
that
you're
not
even
sure
how
to
get
it
to
compile.
C
So
it
kind
of
it
kind
of
kicked
the
doors
wide
open,
certainly
in
the
java
side
of
things
in
in
terms
of
being
able
to
make
people
make
it
easier
for
people
to
adopt
open
source.
Now
what
happened
is
when
we
were
then
going
into
large
companies
helping
them
kind
of
modernize
this
they
started
bumping
up
against
these
problems
where
they're
saying
like
okay,
this
is
great,
but
now
my
developers
are
using
all
of
these
things
and
we're
not
really
sure
how
we
feel
about
that
right.
C
So
suddenly,
suddenly
you
know
they
were
both
getting
the
benefits
but
potentially
subjecting
themselves
to
the
risks
of
of
unmitigated
open
source
and
and
that
kind
of
led
to
where
we
are
focused
today
with
trying
to
help
developers
make
better
choices
around
the
components
they
use.
But
at
that
time
you
know,
people
were
largely
worried
about
license
risk.
You
know
gpl
and
agpl
and
those
kinds
of
things,
and-
and
this
comes
off
the
back
of
a
lot
of
gpl
like
lawsuits
in
the
early
2000s.
C
B
Well,
it
certainly
seems
based
on
what
collectively
we
know
about
the
state
of
software
development
today,
but
that
developers
are
indeed
consuming
with
incredible
appetite:
massive
volumes
of
open
source
and
third-party
libraries,
and
then
the
question
becomes
well.
How
do
you
do
that
hygienically?
How
do
you
do
it
securely?
How
do
you
do
it
responsibly?
How
do
you
do
it
efficiently
and
in
a
way,
that's
fast
and
doesn't
slow
down
the
pace
of
your
your
innovation?
B
You
know
in
many
respects
that
same
purpose,
that
red
hat
serves
for
red
hat
enterprise.
Linux
is
being
served
in
some
form
or
fashion
by
companies
like
sonotype
to
application
level
libraries.
So
how
is
it
that
a
developer
today,
building
applications
has
a
sense
as
to
which
libraries
they
should
use
which
dependencies
they
should
update?
Or
not
I
mean
how
do
you
go
about
making
good
quality
decisions
as
a
developer
today,
in
a
world
where
you
have
infinite
libraries
from
which
to
choose.
C
Yeah,
I
think
that's
probably
the
area,
that's
matured,
the
least
honestly,
I
think,
there's
still
a
lot
of
go
to
google.
Ask
your
friends.
Look
in
forums,
there's
a
lot
of
happenstance
that
happens
in
component
choice.
It's
something
that
we're
trying
to
change.
But
given
that
that's
the
process,
it's
not
like
there's
a
tool
in
a
company.
It's
not
like
it's
natural
in
the
ide
or
any
of
these
things.
It
creates
it.
C
It's
a
challenge
because
there's
not
a
canvas
for
which
we
can
plug
into
and
paint
upon
right
to
help
guide
that
choice
that
that's
been
a
problem
since
forever.
There
have
been
many
projects
that
have
come
and
gone.
You
know
trying
to
provide
a
website
to
do
that.
You
know
some
of
them
more
successful
others
less,
but
that,
but
that
is
a
challenge
and
we're
we're
trying
to
plug
into
corporate
infrastructure.
C
But
there's
always
that
little
bit
of
a
religious
war
where
developers
don't
like
being
told
what
to
do
they
like
to
have
the
information,
but
if
it
feels
big
brother-ish
authority
authoritarian,
it
can
backfire.
So
it's
a
it's
like
you're,
walking
a
knife's
edge
on
on
trying
to
provide
useful
information
that
they
can
pull,
not
push.
B
You
know
you
want
maximum
freedom
with
respect
to
making
those
choices,
so,
whether
it's
google
or
some
forum
or
some
friend
that
tells
you
which
component
is
good
for
your
purpose.
You
might
sort
of
take
it
on
word
of
mouth
and
make
the
decision
that
way.
But
what
is
what
about
sort
of
managing
the
the
quality
of
that
component
from
that
point
forward
into
the
actual
development
life
cycle?
And
arguably,
what
about
managing
that
component?
B
C
Yeah,
well,
I
think
that's
one
of
the
areas
that
was
the
slowest
to
to
catch
up
to
this
new
world
that
may
have
been
introduced
right
prior
to
that.
You
saw
a
very
manual
workflow
process
around
approving
components
and
that
more
or
less
worked
because
it
was
hard
to
pull
in
new
components
and
when
you
did,
they
didn't
often
have
really
deep
transitive
dependency
trees
right,
but
in
a
modern
world
in
in
java
you
pull
in
one
component.
C
C
Managing
you
know,
using
whitelist
and
blacklist
was
simply
not
going
to
cut
it
and
and
and
and-
and
we
saw
companies
struggling
to
com
to
to
produce
a
complete
inventory-
they
they
might
only
be
focusing
on
their
direct
dependencies
and
ignoring
those
hundred
or
thousand
transitives
below
it
just
because
they
simply
couldn't
do
anything
about
it
right.
So
that
was.
B
The
problem
that
we
set
up
and
how
much
of
that
you
said
companies
were
struggling
to
get
to
manage
that
reality
with
white
light,
whitelist
and
blacklist.
I
mean
I
hope
that
the
struggle
was
developers
just
kind
of
expressing
frustration
with
respect
to.
Let's
just
call
it
overburdening
governance
right.
C
Like
yeah,
the
reality
was
they
if
they
had
a
process
like
that,
one
or
two
things
were
happening
100
of
the
time
either
it
was
not
effectively
deployed,
so
developers
were
doing
whatever
they
wanted
anyway,
and
we
see
this
time
and
time
again
where
we
talk
to
companies
and
like
oh,
our
list
of
open
source,
it's
really
small,
it's
800
things
right
and
then
we
come
in
and
we
do
a
scan.
They
might
have
800
things
in
one
of
their
applications.
C
They
get
80
000
components
that
they're
actually
using
that
800
list
was,
was
the
things
that
were
self-reported
right.
So
if
they
had
a
list
and
they
were
relying
on
developers
to
self-report,
they
were
kidding
themselves.
If
they
were
an
organization
that
they
actually
had
the
ability
to
lock
it
down
and
enforce
it
and
they're
rare
but
they're
out
there,
then
what
happened?
Was
they
counter
incented,
the
lack
of
innovation
developers
just
basically
throw
their
hands
up
and
go
well?
C
I
guess
we're
just
gonna
keep
using
struts
one
forever
right,
and
this
is
why
you
know
at
conferences.
I
would
always
ask
you
know:
15
years
after
the
stretch,
one
was
known
to
have
level
10
vulnerabilities
who
hears
using
struts.
That's
one
and
there's
always
people
that
raise
their
hand.
You
say
why
it's
like,
because
it's
on
my
approved
list
right
well,
it
was
approved
by
a
guy
a
decade
ago:
nobody's
looked
at
it
since
and
so
so
you're
either
pretending
that
you're
doing
a
good
job
at
it
or
you're
actually
enforcing
it.
B
It's
called
the
state
of
the
software
supply
chain,
research,
and
it's
if
you,
if
anybody's
interested,
we'll,
have
a
link
to
it
at
the
end
of
this
talk,
but
really
good,
solid
sort
of
original
research.
We
do
in
partnership
with
folks
like
gene
kim
and
stephen
mcgill,
and
and
look
deeply
into
sort
of
maven
central,
which
is
a
an
asset
that
we
contribute
to
the
to
the
java
community
and
have
from
inception
it's
on
a
type.
B
But
in
the
aggregate
view
of
the
software
supply
chain,
research
that
we
have
done,
we've
begun
to
see
this
concept
of
herd
migration.
I
know
you
have
a
couple
of
images.
You
know
listening
to
you
talk
about
this
idea
of.
Sometimes
a
developer
will
update
a
dependency
if
it's
easy
and
the
company
permits
it.
It's
the
right
thing
to
do.
They
are
able
to
do
it.
Great
fresh
software
is
better
than
stale
software,
so
always
update
your
dependency.
Sometimes
the
developer
doesn't
update
a
dependency.
Why
I'm
not
entirely
sure?
B
Maybe
it's
because
the
company
doesn't
permit
them
to
do
so,
but
but
when
you
think
about
the
all
of
the
variables
in
in
dependency
management
and
third-party
open
source
libraries,
you
you
can
imagine
you
get
a
visualization
of
what
this
concept
of
herd
migration
might
look
like
curious
to
get
your
thoughts
on
that.
It's
it's
been
a
fascinating
thing
for
me
to
kind
of
get
familiar
with
and
hoping
you
might
be
able
to
share
some
perspective
with
the
audience.
C
Yeah,
so
this
I'm
sharing
my
screen
now
this
is
oss
index.
This
is
a
site
that
we
have
that
provides
free
scanning
and
data.
As
you
saw,
I
searched
for
spring
web
and
you
know
I
can
see
some
of
these
have
vulnerabilities.
But
what
you're
talking
about
matt
is:
is
this
this
relatively
recent
innovation
that
we've
been
working
on
here?
We
call
this
kind
of
the
herd,
migration
graph
and,
and
what
we've
been
exploring.
C
Is
this
concept
of
you
know
that
some
modern
organizations
have
taken
to
evergreening
their
dependencies
and
automatically
updating
right,
and
so
you
can
get
alerts
from
github
when
a
new
version
is
out
there,
you
can
even
have
it
automatically
update
a
pull
request
and
and
whatever
to
keep
yourself
up
to
date
and
on
its
face.
That
sounds
like
a
great
idea.
It's
certainly
better
than
ignoring
updates
indefinitely
for
the
struts.
C
Pretty
much
everybody's
build
is
fetching
it
like
nearly
instantly
because
it's
always
trying
to
get
a
latest
version,
and
so
you
know
that
that
behavior
is
not
one
that
maven
has,
and
so
you
know,
I
I
think
we
see
less
less
of
those
types
of
things
happening
in
maven,
because
you
know
people
don't
update
by
default
as
fast.
But
if
you
introduce
these
new
evergreening
capabilities,
you
basically
bring
along
the
bad,
which
is
you
you're,
you're
grabbing
untested
code,
and
so
what
we're
trying
to
find
is
how
can
we?
C
How
can
we
predict
when
is
a
good
time
to
move
and
and
the
idea
of
the
herd
moving
along
to
safety
is
basically
what
this
is
visualizing.
So
you
see
each
of
these
lines
between
all
the
different
versions
here,
and
this
is
spring
web
that
I'm
showing
each
of
these
lines.
The
the
the
darkness
indicates
how
many
different
migrations
we've
observed.
The
red
ones
are
ones
that
were
migrated
at
the
time.
Somebody
did
an
update.
They
were
updating
to
an
already
known,
vulnerable
thing
right,
so
red
is
obviously
not
good.
C
C
I
don't
I
don't
have
it
on
this
website
yet,
but
we're
starting
to
look
at
things
that
kind
of
show
how
quickly
people
tend
to
update
and
and
there's
a
there's,
a
gap
like
you
don't
want
to
be
on
the
latest
version,
but
you
don't
want
to
fall
behind
the
herd.
There's
a
nice
sweet
spot
in
the
middle,
where
you
can
do
the
optimum
number
of
updates
so
that
you're
not
on
the
bleeding
edge
constantly
but
you're
not
also
lagging
behind
right.
C
Just
is
is
a
lot
of
entropy,
maybe
for
a
little
benefit
right.
If
you
don't
need
the
fix
that
came
in
the
latest
patch
and
it
wasn't
a
vulnerability,
then
updating
it
just
potentially
causes
more
change
and
more
opportunity
for
something
to
break
at
run
time.
You
know
this
is
a.
This
is
joe
to
time
the
population's
a
little
bit
smaller,
but
you
can
see
a
much
more
orderly
update
that
this
seems
to
be.
People
largely
are
moving
version
over
version
over
version.
C
You
know,
for
whatever
reason
2.9.8
like
nobody
went
to,
there
must
have
been
something
glaring
wrong
glaringly
wrong
with
that,
and
so
what
we're
trying
to
do
is
use
these
types
of
data
that
that
we
can
see
from
our
visibility
both
within
our
customer
set,
but
also
within
the
repositories
that
we
run
maven
central.
We
can
see
what
the
herd
is
doing.
You
may
not
always
understand
why,
like
does
it
matter,
why
nobody
went
to
2.9.8,
not
really.
Why
would
you
want
to
be
the
only
person
to
do
that
right.
C
See
a
new
version
that
came
out
and
not
enough
of
the
herd
has
moved
on
to
that
new
island.
Maybe
you
shouldn't
either
and-
and
you
know,
these
types
of
behaviors
and
algorithms
can
help
us
walk
that
gap
between
just
blindly
updating
to
every
version
and
then
leaving
it
to
random
occurrence.
When
a
developer
decides
to
update
a
dependency,
the
efficiency
gain
can
happen
in
the
middle
when
you're
making
the
least
number
of
smart
steps.
B
B
Let's
call
them
exemplary
with
respect
to
how
often
it
is
that
they
release
ie
push
new
features,
how
often
or
quickly
it
is
that
they
respond
to
new
vulnerabilities
with
a
patch.
How
you
know
many
developers
do
they
have
who
are
contributing
on
average.
You
know
how
vibrant
is
the
project
with
respect
to
resources?
Is
it
a
foundationally,
supported
project,
or
is
it
two
guys
in
a
garage
kind
of
thing
and
and
so
curious
to
get
your
thoughts
on
this?
C
You
know,
there's
a
lot
of
things
that
need
to
be
considered
and
the
problem
is
that
it's
hard
to
take
all
of
that
data
and
bring
it
together.
That's
kind
of
what
we've
been
trying
to
do
both
in
the
you
know.
The
community
sites
like
oss
index,
but
also
in
our
products,
is
to
make
it
possible
to
bring
that
data
together,
so
people
can
make
reasoned
choices
like
you
know,
this
is
a
different
view
of
spring.
This
is
spring
core
and
it's
it's
interesting.
C
If
you
zoom
in
on
this,
you
know
you
can
see
the
the
dot
zero
problem
in
action
here.
People
were
largely
ignoring
the
release
candidates
and
some
of
the
milestones
as
you
would
expect,
but
there
were
a
bunch
of
people
who
made
updates
from
four
to
some
early
versions
of
five
when
they
were
vulnerable
because-
and
presumably
these
other
versions
existed
at
that
time.
So
why
did
they
move
to
that?
One?
C
Probably
they
didn't
want
to
get
on
to
the
late
latest
and
greatest,
but
they
didn't
have
the
visibility
that
they
were
in
fact
introducing
a
new
vulnerability
and
the
likelihood
is
this
vulnerability,
probably
is
not
the
same
one
that
they
were
leaving.
So
it
was
a
net
new
vulnerability
right
and-
and
this
is
the
challenge,
if
you
don't-
have
the
complete
visibility,
information,
you're
kind
of
just
shooting
in
the
dark
but
like,
as
you
said,
there's
the
dynamics
are
different
on
a
project
by
project
basis.
B
Or
or
or
arguably
years
and-
and
I
know,
there's
examples
of
projects
where
you
basically
have
two
constituents
of
users,
those
that
are
on
version
call
it
two
or
three
shall
never
migrate
to
version
four
or
five
and
whoever's
on
four
or
five.
You
know,
and
you
have
these
disparate
sort
of
dynamics
between
developers
who
are
effectively
living
on
islands,
different
islands
relative
to
different
versions,
but
it's
the
same
project.
C
You
can't
just
look
at
you,
know
the
the
herd
of
spring
core,
but
you
have
to
understand
the
entire
transit
of
hull
and
and
when
you
start
introducing
tens,
hundreds
thousands
of
those
dependencies,
it's
impossible
for
a
human
to
like
sort
through
that
dependency
tree
and
all
of
the
possible
combinations.
And
that's
where
that's
where
the
automation
and
the
computers
can
really
help
right.
That.
A
C
B
Right
I
mean
that
this
idea
that
that
the
freshest
software
is
the
best
software
and
if
there's
a
new
version
of
dependency
use
it
because
it's
fair
is,
is
really
interesting.
You
can
sort
of
understand
on
the
surface
why
someone
might
look
at
it
and
sort
of
say
new
is
better,
but
but
we
understand-
and
I
think
certainly
as
we've
observed
as
as
arguably
sort
of
black
hats
or
nefarious
actors
in
general
has
have
observed
if
the
world
is
automatically
going
to
update
to
the
latest
version
of
a
dependency.
Why
not
pick
up?
B
Why
not
raise
your
hand,
pick
up
a
shovel
and
become
a
volunteer
and
contribute
to
a
project
and
and
inject
some
malware,
because
you
know
some
very
large
percentage
of
the
world's
developer
community's
got
tooling
that's
going
to
automatically
pick
it
up.
It's
like
the
perfect
way
to
distribute
potentially
sort
of
malicious
code
curious
to
get
your
thoughts
on
that,
and
is
this
something
you're
seeing
have
we?
I
know
we
do
a
lot
of
research
in
this
area,
but
you
know
it's
it's
it's
important
for
people
to
get
their
head
around
this.
C
Yeah
I
mean
we
that
this
new
trend
of
attacks
on
on
the
supply
chain
has
really
kind
of
taken
off
in
the
last
couple
of
years.
In
fact,
I
have
a
slide
here
that
I
can
show
you
know.
We
started
to
see
this
back
in
2017
when
there
was
a
new
set
of
attacks,
and
what
was
notable
to
me
at
that
point
was
that
the
attacks
were
focused
on
the
open
source
publishers
themselves
that
so
the
payload
was
extracting
in
some
of
the
early
cases,
npm
and
python
publishing
credentials
right,
which
is
new.
C
At
that
time.
Most
of
the
time
people
were
putting
things
in
the
application,
so
they
could
steal
the
data.
The
applications
had
access
to
not
the
developers,
and
so
that
was
back
in
17.
You
can
see
the
trend
up
until
19.
There
were
about
216,
but
then
just
last
year
it
exploded
right.
So
this
is
due
to
the
copycat.
C
Once
these
things
happen,
there
will
guarantee
to
be
more
and
more
and
more
as
as
the
bad
guys
also
innovate
right.
So
there
was
an
explosion
of
these
things,
and
so
what's
interesting
as
we
see
this
unfold
is
that
the
attacks
have
shifted
a
bit
from
focusing
on
the
open
source
publishers
to
get
to
get
access
to
their
credentials
and
and
the
reason
for
why
you
might
do.
That
is
it's
kind
of
evident
here
right.
C
C
And
the
the
ones
that
have
happened
most
recently
have
been
inserting
remote
access
back
doors
onto
the
development
machines.
Now,
if
you
couple
that,
with
with
infrastructure
as
code
and
people
that
are
publishing
things
cloud
native,
it
means
the
development
environment
has
access
to.
In
many
cases
the
secrets
that
control
the
actual
production
environment.
C
That's
why
the
development,
the
developers
are
the
target,
and
I
spend
a
lot
of
time
trying
to
educate
security
teams
on
this,
that
they're
so
focused
on
making
sure
that
the
software
that
gets
released
out
of
their
environment
is
safe
for
their
end
users.
Right,
that's
what
the
focus
is
on,
and
so
you
know
you,
you
see
that
manifest
in
security
scans
happening
before
release.
Well,
guess
what?
If
your
developers
were
the
target?
C
You've
missed
the
entire
war
right,
the
the
the
theft
has
occurred
on
the
factory
line.
It's
not
resulting
in
a
defective
car
coming
out
of
the
factory
right
and-
and
this
is
a
new
thing
that
so
many
environments
are
just
not
geared
up
to
think
about
and
to
do
anything
to
protect,
and
you
know
to
put
it
into
context
I
like
to
to
talk
about.
B
Well,
this
is
this
is
a
again
to
sort
of
put
this
very
important
point
into
context.
It's
useful
to
think
just
just
back
a
few
years
ago,
where,
from
an
open
source
security
risk
as
it
relates
to
third-party
libraries.
You
know
a
lot
of
the
attention
was:
how
quickly
could
organizations
respond
to
a
new
zero-day
disclosure
and
patch
something
in
production?
Famously
you
know,
the
struts
disclosure
from
apache
went
out
to
everyone
in
the
world.
Unfortunately,
at
equifax
they
they
presumably
based
on
what
I
know
was
disclosed
publicly
in
the
congressional
report.
B
I
believe
that
it
wasn't
because
they
didn't
necessarily
understand
or
have
visibility
into
the
transitive
nature
of
that
of
that
particular
vulnerable
version
of
struts
and
and
but
in
any
case,
it's
like
okay,
bad
guys.
Look
for
public
disclosures
from
apache
once
apache
tells
the
world
that
there's
a
vulnerability
and
tells
the
world
to
patch
it.
It's
a
race
between
the
good
guys,
patching
and
the
bad
guys
exploiting
that
race
is
kind
of
the
old
day
like
the
new
day
is
like.
C
Yeah
I
mean,
if
you're
looking
at,
if,
if
you're,
if
you're
a
bad
guy
and
you're
looking
at
you,
know
trying
to
be
maximally
efficient,
that's
exactly
what
you
would
do,
you're
gonna
pick.
You
know
it
before.
You
saw
the
consolidation
of
attacks
on
things
like
struts,
because
they
they
represented
this
common
mode
failure
same
thing
with
commons
collections.
C
You
could
assume
that
every
java
application
had
that
on
its
class
path,
because
it
was
almost
guaranteed
to
be
true,
and
so,
while
you
know
software
development,
these
days
benefits
from
the
ability
to
reuse
these
components
and
produce
value
faster.
It
also
puts
us
at
a
shared
risk
because
we're
all
using
the
same
component,
which
makes
that
a
sweet
spot
for
the
bad
guys.
You
shift
that
forward
a
little
bit
and-
and
now
you
see,
you
know
evergreening
and
people
that
don't
have
control
over
the
dependencies.
C
C
And
the
one
we
just
it
just
went
out
yesterday
was
db
json
or
something
like
that
right
and
it
had
the
exact
name.
The
file
names
were
the
same.
If
you
didn't
know
what
to
look
for,
it
would
look
like
a
totally
legit
package.
It
had
a
readme
and
and
everything
you
know,
and
it's
it's
exactly
like
the
the
phishing
attacks.
You
see
where
these
the
bad
guys
create
websites
that
look
exactly
like
your
bank
login.
They
go
through
the
app.
C
Octopus,
probably
most
people
don't
know
what
I'm
talking
about,
because
it
tended
to
be
a
small
impact,
but
back
in
was
it
may
june,
something
like
that.
There
was
a
new
version
of
malware
going
around.
That
was
novel
because
it
it
it
looked
and
felt
like
the
90s
with
the
xe
viruses
that
replicated
you
know
so
you'd
run
this
thing
and
it
would
infect
everything
on
your
floppy
disk
and
everything
on
your
hard
drive.
C
That's
exactly
what
this
octopus
virus
was
doing,
so
the
payload
was
ultimately
a
remote
access
toolkit
trying
to
drop
it
on
the
development
machines,
but
in
the
process
it
was
leveraging
the
intellij
ide
to
replicate
itself
into
every
single
jar
that
the
developer
had
access
to
right.
That
was
the
viral
nature
of
it.
So
all
of
these
malicious
attacks
that
we've
been
talking
about
for
the
past
couple
years,
we
hadn't
seen
them
virally
replicating
like
the
old
90s
and
octopus
did
now.
C
It
seemed
to
be
self-limiting,
for
whatever
reason,
nobody
really
knows
why
it
wasn't
bigger.
Maybe
not
enough
people
were
using
intellij,
but
we
have
to
expect
that
someone
out
there
right
now
is
looking
at
that
and
trying
to
figure
out
how
to
take
that
and
combine
it
with
some
of
these
other
attacks.
Well,.
B
B
Everybody
wins,
yay,
happy
happy,
there's
a
big
part
of
this
conversation
which
we
haven't
really
touched
on
yet,
which
is
less
about
security
and
vulnerabilities,
and
more
about
just
developer
productivity
like
look
building
software
and
maintaining
your
application
is,
and
innovating
and
and
thinking
about
creative
new
problems
or
new
ways.
Creative
ways
to
solve
problems
is
what
developers
love
to
do
and
do
best.
B
So
so
I'd
love
to
get
your
thoughts
on
this
idea
of
you
know
what,
but
within
that
that's
the
idea
of
look
developers,
love
to
innovate
developers
also
increasingly
are
being
asked
to
serve
as
soldiers
on
the
front
line
of
the
security
conversation
that
we're
having.
But
how
is
it
that
they
can
serve
as
soldiers
on
the
front
line
of
security
conversation
and
do
it
with
like
minimal
effort
and
maximum
effect
in
terms
of
productivity?
Things
like
breaking
changes
like.
Why
should
a
developer?
B
C
Right,
I
mean
they're
all
kind
of
intertwined,
it's
sort
of
an
extension
of
the
herd,
migration
that
we
were
talking
about
before,
but
you
know
the
herd
migration
kind
of
helps.
You
figure
out
where
people
are
going,
not
necessarily
why
and
it's
it's
not
always
possible
to
contextualize
it
for
your
application,
but
something
like
breaking
changes
right.
That's
the
thing
developers
are
always
afraid
of
like.
If
I
update
to
this
new
dependency,
how
much
work
is
it
going
to
take
to
even
get
the
thing
to
compile
right
and
then
later
you
know?
C
Is
it
going
to
introduce
runtime,
behavior
changes
that
are
going
to
break
and
do
I
have
good
enough
tests
that
I
think
that
that's
reasonable?
You
know
that's
an
age-old
problem
that
everybody
always
has,
and
it's
a
reason
why
you
know
developers
sometimes
push
back
when
security
says
hey.
You
know
you
need
to
update
this
dependency,
it's
the
fear
of
the
unknown.
So
introducing
you
know
breaking
api
changes
like
we're.
C
We're
doing
will
help
with
that
conversation
so
that,
if
you
can,
if
you
can
understand
that
the
apis
between
the
version
you're
on
and
the
version
you're
targeting
have
minimal
changes
and
even
better,
if
you're
able
to
to
couple
that
with
something
like
a
static
code.
Analysis
where
you
could
say
not
only
have
the
apis,
maybe
not
changed,
but
specifically
the
ones
you're
using
haven't
changed.
This
should
be
basically
a
drop
in
replacement
right.
It
changes
the
conversation.
B
You
touched
on
it
just
a
moment
ago.
You
mentioned
this
idea
of
what's
happening
in
run
time
in
production
and
and
as
the
world
sort
of
begins
to
sort
of
you
know,
shift
more
and
more
from
this
sort
of
you
know.
Infrastructure
is
on-prem
in
a
data
center
with
four
walls
and
a
firewall,
and
you
know
segmented
network
traffic
inside
of
it
blah
blah
to
this
new
world
reality
of
public
and
hybrid
clouds.
You
know
the
perimeter
begins
to
disappear.
B
People
are
all
of
a
sudden
and
adopting
in
this
everything,
speed
is
critical.
Devops
is
everywhere.
Let's
release
continuously
every
day
every
hour.
How
fast
can
we
release
kind
of
world
what's
happening
with
respect
to
this
conversation
that
we're
having
about
the
open
source,
libraries,
the
dependency
management
after
the
build,
once
the
build
is
done
and
we're
now
sort
of
into
this
container
conversation
and
we're
into
this?
You
know
deployment
conversation
with
respect
to
things
like
kubernetes
and
cloud
native.
C
B
Right
and
part
of
the
new
process
is,
I
mean
you
know,
I
mean
obviously
developers
with
with
with
thousands
of
open
source
libraries
at
their
fingertips,
infinite
choice.
You
know,
automation
tools
like
sonotype
and
help
them
make
better
decisions
with
respect
to
how
it
is
that
they
consume
those
open
source,
libraries
for
purposes
of
building
better
software.
B
Similarly,
when
it
comes
time
for
that
developer,
to
you
know,
provision
infrastructure
in
a
cloud
environment
and
use
something
like
terraform
to
do
it,
you
know
how
much
do
you
natively
trust
the
developer
to
to
be
their
own
operations
engineer
and
configure
their
own
infrastructure?
I
mean
it's
they're
still:
human
and
they're
not
and
they're.
B
Just
you
know
it's
just
a
very
interesting
conversation
in
a
world
where
the
developer,
on
one
hand,
has
an
infinite
supply
of
open
source
at
their
fingertips
and,
on
the
other
hand,
has
you
know
public
cloud
infrastructure
at
their
fingertips
and
can
provision
away
as
much
as
they
want.
So
the
heart's
content,
it
sort
of
begs
the
question
infrastructure
as
code
is
incredibly
powerful
and
efficient
from
a
process
perspective.
B
C
B
C
They're,
both
the
source
and
the
target,
potentially
in
this
new
world,
and-
and
you
know,
the
the
processes
need
to
shift,
but
so
often,
I
think,
is
the
case
in
in
software
development,
it's
all
about
patterns,
and
I
think
we
we
sometimes
fail
to
recognize
the
that
we
don't
have
to
reinvent
the
wheel.
We
just
have
to
apply
this
known
pattern
to
this.
Otherwise
new
behavior,
you
know
so
being
able
to
do
the
the
the
infrastructure
is
code
and
you
know
monitor
it
incrementally
provide
the
right
guidance
to
the
developers.
C
It's
kind
of
the
same
as
everything
we've
been
talking
about
in
terms
of
dependencies,
especially
when
many
of
those
tools
actually
have
dependencies
where
you
can
depend
upon
a
script
that
was
written
by
somebody
else,
whether
it's
in
your
company
or
not.
If
you
don't
understand
the
implications
of
that
in
a
chain
of
that,
it's
it's
no
different
right
and-
and
so
you
know,
I
think,
that's
kind
of
where
the
the
natural
evolution
of
this
always
goes.
B
Yeah,
a
hundred
percent-
well,
I
think
we're
we
have
just
a
few
minutes
left
and-
and
you
know
I
want
to
thank
you
for
your
time,
brian
and
and
michael
thank
you
and
and
to
everyone
at
red
hat
for
for
letting
us
sort
of
share
some
perspective.
Today
on
the
on
the
show,
you
know
by
last
sort
of
little
bit
of
context,
I'll
share
with
respect
to
sonotype
as
a
company
we're
we're
a
tools
company.
A
Thanks
matt,
that
was,
that
was
a
really
really
really
interesting
and
insightful
discussion
that
you
folks
had.
I
really
really
enjoyed
the
the.
Would
you
call
it
the
herd
slides
with
with
all
the
lines
that
was,
that
was
actually
fascinating.
I
personally
myself
don't
write
code,
but
I
feel,
like
I
feel
like
now.
I'm
going
to
go
pick
up
a
shovel
and
go
join
one
of
the
communities
and.
A
A
B
Yeah
100,
and
I
mean
just
to
be
very
clear-
I
mean
we
have.
We
have
mad
respect
for
everything
that
red
hat
does
and
represents
in
in
the
global
ecosystem
of
software
and
and
open
source.
In
particular,
I
mean,
as
I
mentioned
earlier,
I
mean
in
in
some
ways,
while
you
guys
did
what
you
did
so
brilliantly
for
red
hat
enterprise
linux
back
in
the
day
we
kind
of
borrowed
from
to
brian's
earlier
point.
So
much
of
software
is
about
patterns.
A
B
A
B
Right
right,
the
the
nexus
repository
is
available
there,
which
just
again
for
for
sake
of
clarity,
but
the
two
core
products
that
we
have.
The
nexus
repository
is
a
binary
repository
manager
for,
for
you
know,
storing
components,
libraries
build
artifacts
and
and
and
accelerating
the
pace
and
the
quality
of
builds.
And
then
we
have
a
separate
product
called
nexus
iq
server,
which
supports
different
policy,
automation
and
enforcement
points
along
the
development
life
cycle.
That's
nexus
lifecycle,
nexus
firewall.
A
B
Absolutely
yeah
100,
so
community
is,
is
everything
and-
and
we
certainly
believe
very
strongly
in
in
contributing
to
the
community,
wherever
we
can
and
have
done
so
for
a
long
time
across
a
number
of
different
important
sort
of
landscapes.
The
the
first
bullet
here
is
is
about
oss
index,
which
is
a
is
a
resource
that
we
provide
to
the
community
and
provides
anyone
for
free
visibility
into
vulnerabilities
associated
with
third
party
libraries
and
would
encourage
anyone
to
check
it
out
if
you're
interested,
there's
a
bunch
of
really
high
value
there.
B
That's
that's
pretty,
uniquely
positioned
in
terms
of
data
that
we
possess
from
things
like
maven,
central
and
the
like,
and
and
would
encourage
you
to
take
a
peek
at
that
and
then,
of
course,
if
anybody's
interested
in
actually
sampling
our
our
commercial
products,
you
can
do
so
with
a
free
vulnerability
scan
at
sonotype.com
appscan.
That's
what
we
call
a
nexus
vulnerability
scan
and
then
just
more
generally,
you
can
check
us
out
on
the
web.
We
would
be
happy
to
answer
any
questions
if
anybody
would
like
to
reach
out
afterwards.
A
Well,
thanks
for
that
and
yeah,
if
anyone
wants
to
get
connected
with
anyone
at
the
at
the
sonotype
team,
they
can
just
email
me
as
well.
I'm
just
wait:
redhat.com
w-a-I-t-e
redhat.com
and
that
wraps
up
another
episode
of
the
open
shift.
Commons
briefing
our
operator
hour
show
is
every
wednesday
at
same
bat
time
same
bat,
channel,
matt,
howard
cmo,
so
type
was
awesome.