►
From YouTube: Dependency hell - Or, Developers' perception of software dependencies - GitHub Satellite 2020
Description
Presented by Ivan Pashchenko, Postdoctoral Research Fellow, University of Trento
Security vulnerabilities introduced by software dependencies can lead to severe incidents. Take for example, the Equifax breach, when the private data of more than 143 million people became publicly available due to a security vulnerability in an outdated software dependency. Despite the fact that GitHub Security Alerts and other tools allow software developers to check free open-source dependencies, developers still aren't paying enough attention to their security. In this talk, Ivan will discuss the perceptions of developers coming from 25 companies located in nine countries—and will present the insights on their practices, from the selection of software dependencies and updating of software dependencies to automating the dependency-management process and the mitigation of bugs and vulnerabilities in dependencies where a fixed version doesn't exist. Armed with this new knowledge, participants will discover the implications of the most popular dependency-management strategies, and from there will be able to improve the dependency management of their own software projects.
GitHub Satellite: A community connected by code
On May 6th, we threw a free virtual event featuring developers working together on the world’s software, announcements from the GitHub team, and inspiring performances by artists who code.
More information: https://githubsatellite.com
Schedule: https://githubsatellite.com/schedule/
A
However,
one
thanks
Martin
for
the
introduction
thanks
Danny
yeah.
This
is
even
from
its
away
I'm
doing
my
postdoc
in
software
security
at
the
University
of
Trento
and
today
I'm
talking
to
you
from
the
beautiful
Italian
Alps.
Even
though
these
days
we
are
required
to
stay
at
home
and
watch
our
plane,
I
invite
you
to
the
butyl
hike
to
the
short
walk
in
the
mountains
and,
in
the
meantime,
I
will
tell
you
the
story
about
developers
perception
of
software
dependencies.
A
Well,
imagine
we
are
on
our
way,
so
take
a
bags
jump
on
the
board
and
let's
hit
the
road
well
on
the
way
you
let
me
start
with
the
story
of
the
equifax
company.
If
you
facts
is
one
of
the
largest
multinational
consumer
credit
reporting
agencies,
it
collects
and
sells
credit
and
demographic
data
like
names,
credit
card
details,
driver
licenses,
social
security,
numbers,
etc.
It's
a
large
amount
of
sensitive
personal
data
of
more
than
800
million
people,
a
huge
pay
to
huggers,
isn't
it
in
2017.
Indeed,
Equifax
announced
a
cyber
security
breach.
A
Let's
have
a
look
at
its
timeline
on
March
6
2017.
They
was
a
vulnerability
affected.
I
purchased
rats,
library
disclosed.
The
vulnerability
was
severe
as
it
allowed
remote
common
execution,
along
with
the
vulnerability
at
the
same
day,
they
were
exploit
in
the
fixed
version
of
the
library
available.
However,
if
he
first
did
not
react
on
it
on
May
13th
72
days,
both
disclosure
hackers
discovered
the
Equifax
consumer
complaint.
Web
portal
used
vulnerable
patches,
trans
dependency
and
hackers
were
able
to
get
access
to
the
web
server.
A
So
for
the
next
77
days,
they
managed
to
get
to
customers
data
due
to
the
absence
of
proper
segmentation
in
the
network,
and
they
also
discovered
some
admin.
Passwords
on
the
effexor
are
stored
in
plain
text.
So
after
the
British
discovery
in
the
29th
of
July,
Equifax
kept
the
bridge
secret
for
40
days
until
the
7th
of
September.
When
he
finally
told
to
the
world
that
the
critical
personal
data
of
more
than
145
million
people
were
stolen
due
to
a
security
vulnerability
in
a
vulnerable
dependency,
quite
dramatic,
very
dramatic,
isn't
it
well.
A
In
the
meantime,
we
have
a
writer
starting
point,
so,
let's
start
walking
out
to
the
mountain
peaks,
but
so
coming
back
to
dependencies.
Let's
check
what's
changed
since
the
time
of
the
graphics
bridge.
So
from
the
academic
side,
there
is
a
lot
of
research
going
on.
You
see,
I,
just
typed
our
vulnerable
dependencies
and
Google
Scholar
returned
me
about
130
key
results.
130
keep
papers
from
industry.
They
appeared
a
bunch
of
tools
that
allow
us
to
check
dependencies.
A
top
of
our
projects.
A
Github
security
alert
service
allows
developers
who
maintain
the
projects
that
would
have
to
check
their
dependencies
and
Pam
has
a
built-in
independency,
checker
and
being
old.
It
eclipses
stadion.
By
up
and
language-specific
tools.
It
can
be
used
for
java
python,
sneaking
sources
clear.
Our
multi
language
dependency
analysis
tools.
Well,
that's
quite
a
lot
of
options,
but
what
about
developers
do
they
actually
follow
the
suggested
practices?
Do
they
use
the
dependency
management
tools?
A
To
answer
these
questions,
we
carried
out
a
study
with
2,500
press
developers
coming
from
10
different
countries:
Italy
Germany
Russia
Vietnam
United,
Kingdom
Spain,
the
Netherlands
Croatia
Slovenia
Lithuania.
These
developers
are
involved
in
development
of
desktop
mobile
web
and
embedded
applications.
They
work
in
large
or
small
medium
enterprises,
lead
user
group
and
actively
contribute
or
even
lead
a
large
free,
Libre
open-source
projects
they
develop
in
C,
C++,
Java,
JavaScript
and
Python.
A
So,
together
with
these
developers,
we
discussed
dependency
management
process
from
every
possible
angle,
and
today,
based
on
these
interviews,
I
will
share
with
you
our
observations
on
the
following
aspects:
selection
of
new
dependencies,
updating
of
existing
already
used
dependencies
after
mating
dependency,
management
on
usage
of
dependency
management
tools,
mitigation
of
Vong
of
mitigation
vulnerabilities
when
no
fix
available
and
well.
Let
me
start
with
the
first
aspect:
selection
of
new
dependencies,
the
most
interesting
observation
about
it.
That
selection
in
dependencies
is
not
an
easy
task.
A
Developers
have
to
check
various
sources
and
combine
different
kinds
of
information
to
understand
whether
they
want
to
include
a
particular
library
to
their
project
or
not.
This
task
requires
time
and
experience
in
large
enterprises
Alysse.
They
exist
specific
departments
and
specific
people
who
do
this
job
the
pre-select
dependencies
and
put
them
into
a
pool
of
people
pre-approved
libraries,
so
the
developers
of
such
companies
are
safe
to
use
any
library
from
the
pre-approved
list
in
their
projects.
A
If
a
developer
needs
some
particular
functionality,
she
can
ask
for
a
new
level
to
be
checked
and
after
clearing,
this
Tigra
would
be
included
in
the
list
of
pre-approved
libraries.
If
not
cleared,
eternity
will
be
suggested
for
small
companies
as
amis.
Such
approach
is
quite
expensive.
In
the
best
case
scenario,
a
team
of
people
who
performed
selection
transforms
into
software
architect
or
an
experienced
developer,
who
selects
libraries,
otherwise
developers
just
look
at
some
matters
of
a
library
in
general.
A
They
are
looking
for
popularity
and
the
goods
come
in
support
of
a
library
as
well
as
this
matrix
would
mean
for
them
fast
appearance
of
functionality
and
security
fixes
and
the
developers
will
not
remain
alone
with
you
with
their
problems.
If
something
happens,
they
can
ask
the
library
in
tears
and
receive
a
fast
response,
a
solution
for
their
issues.
You
know
this
description
reminds
me
a
formulation
of
a
dynamic
programming
problem.
Indeed,
we
have
a
lot
of
repeated
actions.
Developers
look
for
exactly
the
same
information
for
the
same
libraries.
A
The
Google
library
name
check
its
discussions
at
Stack
Overflow
check
codex.
The
positron
is
library
check
number
of
stars
forms
project
contributors.
Maybe
they
also
check
number
of
open
issues
if
the
project
is
stored
on
github
all
these
to
decide
whether
the
library
is
good
enough
to
be
included.
So
what
would
be
the
solution
to
optimize
this
process?
A
For
me,
the
solution
would
be
to
cache
the
repeat
at
work
or
like
we
call
it
in
dynamic
programming
memorization.
So
there
is
a
need
to
combine
this
kind
of
information
together
and
present
it
in
the
form
of
mathematics.
That
shows
the
library
is
well
supported,
mature
and
not
affected
by
security
vulnerabilities
in
the
form.
This
is
used
in
large
enterprises
when
they
have
a
pool
of
pre-approved
libraries,
but
this
feature
is
also
much
requested
by
travelers.
A
Okay,
so
what
about
already
selected
and
used
libraries
here?
There
are
two
major
issues:
awarness
and
lack
of
resources
to
control
the
penances
in
large
enterprises.
There
might
be
a
bit
more
resources
all
they
may.
They
might
have
a
policy,
something
like
things.
So
all
issues
before
go
into
production,
so
developers
have
to
fix
issues
in
software,
the
premises
if
there
are
any
in
small
companies
or
for
individual
developers,
the
resources
are
multi
mitad.
Hence
developers
prefer
to
postpone
updates
because
they
don't
want
to
break
the
project's
in
case.
A
The
intersection
about
security
here
that
many
developers
reported
a
security
fixes
for
good,
while
supported
popular
libraries
typically
do
not
introduce
any
breaking
changes.
Also,
this
fixes
they
were
kind
of
a
deer
fast,
so
vulnerabilities
motivate
for
updating.
If
they
are
severe,
widely
known
and
dicks
versions,
is
it
a
dot?
A
So
what's
the
implication
here,
our
separation
between
functionality
and
security
is
necessary.
Ideally,
a
developer
should
be
able
to
see
okay,
this
version
has
functionality
changes
and
this
version
only
security
changes.
This
way
she
could
plan
the
update.
If
she
sees
a
new
dependency
version
with
only
security
changes,
then
she
can
plan
to
adopt
it
fast
for
functionality
changes
she
can
decide
whether
she
need
such
functionality
and
plan
its
adoption.
A
A
Ok,
going
to
ultimatum,
as
I
mentioned,
developers,
lack
awareness
of
existence
of
issues
in
dependencies
and
like
resources
to
cope
with
these
issues
in
theory
of
tomato
dependency
management
tools
are
there
to
help
developers.
However,
the
major
observation
is
that
developers
do
not
trust
these
tools.
They
do
not
allow
us
to
perform
sensitive
tasks
like,
for
example,
update
of
software
dependency,
so
the
tools,
if
used,
only
facilitate
finding
vulnerabilities
that
effects
of
the
dependencies
for
their
projects.
A
However,
if
a
tool
produces
too
many
false
positives
or
low
priority
alerts
and
I
heard
several
developers
anomalies,
so
developers
just
decide
to
ignore
such
tools.
They
perceive
this
alert
as
spam
and
switch
the
social
channels
of
their
dependencies,
so
the
developers
say
well
if
there
is
a
new
version
or
a
significant
event
that
I
can
just
discover
from
the
social
channel.
A
So
with
the
implications
for
tool
developers,
dependency,
analysis
tools
should
first,
during
a
rate
only
irrelevant
alerts,
so
these
alerts
are
not
perceived
by
developers
as
spam.
Very
importantly,
second
dependence
analysis
tool
should
show
the
affected
components
of
the
dependent
project,
so
developers
could
immediately
decide
how
severe
is
the
impact,
for
example,
whether
core
component
is
affected
or
not.
A
Unfortunately,
not
all
security
fixes
appear
fast
and
there
could
be
cases
when
there
is
no
fixed
version
of
the
dependency
available.
So
how
do
the
Vella
percent
again
such
as
NARS?
First,
they
try
to
assess
if
vulnerability
impacts
them
their
projects,
their
customers,
if
not,
for
example,
of
a
project
only
used
for
internal
reasons,
developers
might
decide
not
to
do
anything
and
just
wait
for
the
fixed
version
or
community
or
ground
if
the
vulnerability
effects
their
projects
and
especially
their
customers
developers
check.
A
If
there
is
any
activity
going
around
the
vulnerability
developers
see
that
security
pics
is
expected
to
appear
fast,
they
might
decide
to
apply
a
temporary
solution
like
disable
affected
functionality
of
their
project
or
roll
back
to
previous
save
dependence
version.
Well,
if
the
fix
is
not
going
to
appear
fast
and
then
developers
might
decide
to
switch
to
another
library,
several
experts
developers
reported
that
they
do
not
wait
for
others
to
fix
the
issues,
so
they
go
directly
to
dependency
project,
okay,
fix
it
and
create
pool
requests
to
make
the
fix
available
for
the
community.
A
So
how
depends
analysis
tools
could
support
developers
in
such
a
situation?
First,
they
could
determine
part
of
the
analyzed
project
affected
by
the
vulnerability,
so
developers
could
quickly
disable
it.
Second
dependency
analysis
tools
can
facilitate
access
to
the
dependent
source
code,
so
skill
developers
could
go
and
fix
the
vulnerability
directly.
B
Thanks
very
much
Eve,
and
that
was
a
great
night
I
enjoyed
it
so
yeah
thanks
for
taking
us
through
that
it
was,
you
know.
Really
you
showed
you.
Research
shows
how
hard
it
is
to
keep
up
to
date
with
defenses
security
is
just
you
know
too
hard.
It's
really
really
tricky
to
do
as
a
developer,
but
it's
also
good
cuz.
Quite
a
lot
of
the
recommendations
seem
to
you
know,
sort
of
help.
B
The
girl
of
advanced
security
features
that
gray
and
Pavel
was
showing
us
easier
earlier,
definitely
seem
to
adhere
to
a
lot
of
your
research
recommendation,
so
yeah
I'm
fertile.
Oh,
this
is
quick,
but
no
dependencies
are
scary
anyway.
So
yeah
Dana.
What
about
you?
What
do
you?
What
do
you
think
the
session
and.
C
You
know
I
just
think
it's
fascinating
like
how
we
take
for
granted
all
of
the
the
nuances
we
have
when
we
write
code
you
know,
and
especially
when
you
have
mono
monolith
or
monolith
application,
there's
just
so
many
dependencies
you're
like
library,
after
library,
after
library,
and
then
we
go
into
these
new
architectures,
where
it's
a
shy,
slight
shift.
But
then
you
have
services
compounded
with
new
dependencies
that
have
new
libraries
and
packages,
and
so
it's
just
awesome
that
we're
focusing
on
there
and
trying
to
bring
down
that
fear,
because
it
is
scary,
you
don't.
A
C
Be
the
person
making
a
breaking
change?
You
don't
want
to
be
the
person.
That's
like.
Oh
no,
like
I've,
missed
this
in
my
dependency
tree,
and
so
it's
just
fascinating.
The
research
that's
happening
here,
but
I
want
to
kick
it
over
to
some
questions
that
we
have
coming
in.
So
as
we've
been
saying,
if
you
want
to
ask
something
right
now
or
take
them
live,
you
can
go
over
to
github
satellite
comm,
slash
discussions
and
me
and
Martin
will
be
queuing
them
up,
but
we
got
one
right
now
come
in
from
all
right.
C
A
C
A
Okay,
great
question:
yeah
I
mean
definitely
so
if
you,
if
you
are
using
these
hop,
foster
knee
and
maintaining
your
projects
well
hub,
provides
a
very
good
service
for
that.
What's,
besides
of
these,
so
just
for
your
tools,
there
are
several
tools
available
like,
for
example,
sneak
is
a
great
tool
and
it's
provide
some
good
functionality.
Then
I
think
it
also
provides
a
lot
of
functionality
for
free.
So
you
can
just
try
it.
A
B
Fantastic
yeah
so
got
another
question
here
from
oh
I
like
this
daily
you,
let
me
pronounce
the
hard
usernames
brilliant
well
done
so
from
nassif
nassif
him
tears.
Oa
om!
Think,
sorry
about
that.
For
butchering
your
your
handle
again,
how
do
developers
in
your
research
how
the
developers
usually
investigate
if
the
vulnerability
in
the
dependency
affects
their
project
or
not?
You
know,
assuming
that
such
investigation
will
influence
a
developer's
decision
on
updating
that,
if
you
know
the
vulnerability,
how
do
they
usually
research
that.
A
A
Well,
so,
if
I
understand
the
question
correctly,
so
basically
I
I
heard
the
two
stories.
So
this
depends
on
the
MIS
kind
of
the
type
of
they
they
let
say
the
develop
the
vulnerabilities
discovered.
So
if
there
is
a
fixed
version
for
this
vulnerability,
then
then
typically
and
the
libraries
are
kind
of
good
and
well
supported.
So
then,
typically,
there
is
some,
so
so
developers
kind
of
okay.
So
how
can
I
frame
it?
Well?
Okay,
so
sorry
for
for
this
introduction,
that's
yeah
so
well,
first,
what
yes
some
developers!
Basically
they
are.
A
They
did
sometimes
just
no,
that's,
okay,
they
using
these
dependencies
right.
So
but
typically
this.
This
is
kind
of
the
first
layer
layer
of
dependencies
like
what
is
the
directly
configure
from
their
projects
and
so
for
these
dependencies.
They
typically
just
the
keep
it
in
mind.
That's
addy
use
this
dependence
and
then
they
kind
of
read
somewhere
and
now
in
some
social
media
and
Twitter
or
in
somewhere
that
we
there
is
there's
a
problem
with
this
dependency
and
this
problem
is
like
if
it's
discussed
a
lot,
so
they
start
to
see.
A
Okay,
maybe
I
should
also
cannot
updated,
but
and
that's
the
most
common
practice
that
I
heard
that's
what
they
do,
but
actually
nowadays
the
the
the
situation
is
much
worse,
because
we
have
a
lot
of
like
transitive
dependencies
that
are
hidden
and
sometimes
as
a
developer.
You
don't
even
know
that
so
you're
kind
of
dependent
on
this
library,
and
so
even
if
vulnerability
like
a
cure
there,
then
the
only
way
for
you
to
know
about
it
is
just
to
use
the
dependency
manager
tool,
dependency,
analysis
tool.
A
A
A
C
I
totally
feel
you
it's
we
used
to
work
on
for
our
heart.
You
didn't
have
the
visibility
into
your
code
and
now
all
these
amazing
tool
sets
so
you
can.
You
can
monitor
in
real
time
can
understand
your
dependencies
before
you
ship.
You
can,
you
know,
get
automatic
remediation
of
vulnerabilities.
I'm
gonna
tell
you,
you
know
yeah,
we
are
I,
think
was
it
last
year,
its
satellite
or
the
universe?
We
released
dependent
bot
and
that
thing
has
saved
my
ass
so
many
times,
because
dependencies
are
hard.
A
A
C
Make
up
my
own
words
so
Jamie
Sloan,
that's
right:
I
took
the
easy
line
at
Jamie,
Swan
and
I
should
be
Swami,
Swami
or
Sloan.
You
know
what
I
love
you
much
love.
They
want
to
know.
Open-Source
software
gives
us
the
benefits
of
collaboration,
quick
delivery,
so
developing
ways
we
can
stay
secure.
Why
not
losing?
That
is
the
way
to
go.
They
agree.
So
what
about
crowdsourcing?
A
That's
a
great
idea
and
I
would
be
really
happy
if
this
is
actually.
This
would
be
actually
possible
to
to
do
it
and
but
I
think
in
in
a
way
open-source
allows
us
to
to
perform
these
cause.
I
mean
dependent.
Dependencies
are
typically
open-source,
and
so
anyone
can
just
go
and
fix
it.
The
problem
here
that
vulnerability
is
like
vulnerability
fixes
are,
might
be
bit
more
difficult
to
implement
and
they
require
some
expertise
to
create
a
fix.
A
At
least
that's
what
developers
told
me
so
because
if
you
do
not
fix
it
correctly,
then
everyone
is
just
thinks
that
okay,
it's
fixed,
so
it's
safe
and
they
can
use
it
and
yeah.
But
if
it's
not
done
it's
a
problem
so
so
yeah,
so
there
should
be
some
way
how
to
basically
control
the
quality
of
such
fixes.
B
A
A
Actually
I
also
participated
to
one
of
the
researchers
away.
We
we
tried
actually
to
look
if
we
can
write
some
tests
to
succeed,
some
of
the
vulnerabilities
and
well
in
our
research.
We
discover
that
it's
not
always
possible
to
just
fire
all
of
them
and
that
well,
this
is
called
reachability
analysis,
and
so
sometimes
you
can
just
find
that.
A
So
there
is
a
connection
like
statically,
but
then
you
can
also
try
to
run
some
unit
tests
and
this
would
be
the
dynamic
analysis
and
that
will
guys
if
it
can
trigger
the
vulnerability,
then
it's
for
sure
it's
for
sure
executable.
But
if
not,
then
what
I
mean?
If
there
is
still
this
connection
that
is
reported
by
a
static
analysis,
then
it
still
should
be
kind
of
fixed.
So
answering
the
question:
yes,
the
dynamic
analysis,
so
it's
the
unit
testing,
it's
it
can
help.
A
You
find
vulnerabilities,
it's
for
unit
testing
report,
you
something
then
it's
for
sure.
You
need
to
fix
it,
but
for
the
other
part,
so
here
I
would
say
that
we
need
to
combine
the
two
things.
So
you
need
to
combine
the
unit
tests
with
also
some
static
resolutions
like
with
Ribeira
talents
and
so
on,
got
it.
B
That's
fantastic
yeah
they'll
send
out
a
tweet
to
research
paper
read
a
while
ago,
so
at
Martin
Woodward
on
Twitter.
If
you
want
to
get
that,
but
it's
it.
Basically,
it
linked
not
test
coverage
to
the
biggest
source
of
issues
and
things
like
that
and
it
wasn't.
You
know:
static
code,
analysis
errors
or
some
of
these
such
things.
Actually,
the
metric
that
most
accurately
predicted
where
errors
were
going
to
occur
was
organizational
complexity.
So
how?
B
How
crazy
is
your
org
chart
and
it's
amazing
how
much
you
know
problems
would
come
about
in
software
development
they're
actually
because
of
the
the
people,
the
wetware,
rather
than
you
know,
getting
above
80%
on
your
test
coverage
or
whatever
anyway
right.
Well,
even
that
was
a
great
session.
So
thank
you
very
much
for
your
time.
We
really
appreciated
that
so
speech
later
he's
gonna
be
in
Q&A.
If
you
wanna
get
in
contact
so
see
you
later
on.
Thank
you.
Kiba
Thank,.