The document discusses the challenges of dependency management in software development, highlighting that many developers hesitate to update dependencies due to fears of breaking changes and inadequate automated tools. It emphasizes the importance of selecting secure libraries based on community support and outlines the need for better tools that effectively distinguish between security and functionality changes. Overall, it stresses the necessity of improving dependency management practices to enhance software security.

1. Learning from Developers:
How to Make Dependency
Management Secure
IVAN PASHCHENKO
Postdoctoral Research Fellow @ University of Trento (IT)

2. whoami
2
Ivan Pashchenko
• Software Security Researcher @ University of Trento (IT)
• PhD in ICT from UNITN (IT)
• Former Intern @ SAP Security Research (FR)
• Former Leading Security Engineer @ Bashneft (RU)
• Snowboarder, hiker, volleyball player
2© 2020 IVAN PASHCHENKO. CC BY

3. 3
Own code
Dependencies
Software project
© 2020 IVAN PASHCHENKO. CC BY

4. Vulnerable Dependencies - Cause of Disaster
4
Disaster Rank OWASP Top 10
# of Breaches
Root Cause
% of Breaches
Root Cause
1
Components with known
vulns
12 24%
2 Security misconfiguration 10 18%
3 SQL-injection 4 8%
4 Weak Authentication 3 6%
4 Sensitive Data Exposure 3 6%
5 Function level Access control 2 4%
…
Source: https://snyk.io/blog/owasp-top-10-breaches/
© 2020 IVAN PASHCHENKO. CC BY

5. Developers still keep dependencies outdated.. Why?
5
3. R.G. Kula, D.M. German, A. O. TakashiIshio, and K.Inoue. 2017. Do developers update their library dependencies? Emp. Soft. Eng. Journ., 2017
Derr et al. [1]:
«Many dependencies are vulnerable, but
could be easily updated»
Kula et al. [3]:
«Many Java libraries do not react on
security updates»
Huang et al. [2]:
«Easy update would have broken around
50% of dependent projects»
Pashchenko et al. [4]:
«20% of vulnerabilities are in test/dev
scopes, hence, not exploitable»
1. E. Derr, S. Bugiel, S. Fahl, Y. Acar, and M. Backes. 2017. Keep me updated: An empirical study of third-party library updatability on Android. In Proc. of CCS’17.
2. J. Huang, N. Borges, S. Bugiel, and M. Backes. 2019. Up-To-Crash: Evaluating Third-Party Library Updatability on Android. In Proc. of EuroS&P’19.
4. I. Pashchenko, H. Plate, S.E. Ponta, A. Sabetta, and F. Massacci. 2018. Vulnerable Open Source Dependencies: Counting Those That Matter. In Proc. of ESEM’18.
© 2020 IVAN PASHCHENKO. CC BY

6. Developers may not be entirely irrational
in not always updating dependencies
6© 2020 IVAN PASHCHENKO. CC BY

7. 25 Developers
9 Countries
FLOSS, LE, SME, UG
C/C++, Java,
JavaScript, Python
7© 2020 IVAN PASHCHENKO. CC BY

8. Practices on the following aspects
Ø Selection of new dependencies
Ø Updating of existing dependencies
Ø Automating dependency management
Ø Mitigation of vulnerabilities when no fix available
8© 2020 IVAN PASHCHENKO. CC BY

9. Interview analysis
9
Inter ie ee
identi cation
Inter ie collection
Transcription &
Sharing
Open Coding
Selecti e coding Code gro ps
Sat ration check
Additional
con rmation
Code co-occ rences
MemberCheck
S mmar /F ll paper
Yes
No
Yes
Done
Obser ations and
Implications
© 2020 IVAN PASHCHENKO. CC BY

10. Implication
Library selection:
Ø developers pay attention to security only if it is required and enforced by the
policy of their company.
Ø rely on popularity and community support of libraries (e.g., number of stars,
forks, project contributors).
Observations (part I)
Updating software dependencies:
Ø avoid updating dependencies for any reason (afraid of breaking changes).
Ø security motivate for updating only if vulnerabilities are severe, widely known, and
adoption of the fixed dependency version does not require significant efforts.
10© 2020 IVAN PASHCHENKO. CC BY

11. Observations (part II)
Implication
Automation of dependency management:
Ø sensitive tasks (e.g., updates) performed manually
Ø current dependency analysis tools (if used) only facilitate the identification of
vulnerabilities in the project dependencies
Ø dependency tools produce many false-positive and low-priority alerts
Unfixed vulnerabilities:
Ø assess whether this vulnerability impacts their projects;
Ø wait for the fix or a community workaround;
Ø adapt own project: disable affected functionality or rollback to a safe version;
Ø maintain own fork of a dependency project (possibly fixing and making a pull
request to the dependency project).
11© 2020 IVAN PASHCHENKO. CC BY

12. There’s a need for high level metrics:
• library is well-supported
• mature
• not affected by vulnerabilities
• has compatible license (the library and its dependencies)
Developers -> an automatic approach capable of distinguishing functionality and security changes.
Lib users -> an automatic classifier capable of identifying if a specific library version includes changes related to
functionality or security.
Dep analysis tools are expected to:
• generate only relevant alerts
• show the affected components of the dependent projects
• suggest a fixed version and if its adoption introduces breaking changes
Tools could facilitate:
• accessing the dependency source code, so the developers could directly check it and possibly fix the issue
• finding an alternative library with similar functionalities and estimating the cost of switching to this library
12© 2020 IVAN PASHCHENKO. CC BY

13. 13
Securing software dependencies is important Sometimes tools report low priority alerts
There are still many things to be improvedAlthough there are a lot of things done
© 2020 IVAN PASHCHENKO. CC BY

14. The work has been partly funded by the EU under the H2020 Programs
H2020-EU.2.1.1-CyberSec4Europe (Grant No. 830929)
14
ivan.pashchenko@unitn.it
@IvPashenko
http://disi.unitn.it/~pashchenko
Contact me:
Dev perceptions preprint:
© 2020 IVAN PASHCHENKO. CC BY