This document discusses the problem of dependency hell in software development and proposes approaches to better manage software dependencies and their vulnerabilities. It notes that modern software projects have many interconnected dependencies and outlines challenges with current methods of manually tracking dependency updates and vulnerabilities. It then presents some current dependency analysis tools like GitHub alerts, Snyk, and SourceClear. The document observes that current direct/transitive dependency classifications do not accurately reflect what dependencies are within a developer's control. It proposes methods like filtering non-deployed dependencies, grouping dependencies by project, and identifying "halted" dependencies no longer receiving updates to provide a clearer picture of exposure and priorities for remediation. The approach aims to reduce false alerts and help developers focus on fixing vulnerabilities

1. Say No to the Dependency Hell:
Proper Management of Software
Dependencies
IVAN PASHCHENKO
Trento - 2019

2. whoami
2
Ivan Pashchenko
• PhD candidate in Information Security at
the University of Trento
• Former Intern at SAP Security Research
• Former Leading Security Engineer at
Bashneft, Russia
• Snowboarder, hiker, volleyball player

3. 3
Software project
Own code

4. Nowadays software projects
are highly interconnected
4
• Own code
• Dependencies
Own code
Dependencies
Software project

5. Dependencies?
5

6. You are writing code…
This is a typical functionality, I do not want to invent a wheel – I will use
already developed functionality.
6

7. And you use just one
dependency…
7

8. 8
Welcome to the Dependency Hell

9. Open source software
9

10. 10

11. 11
Source: https://www.infoworld.com/article/2608895/open-source-
software/open-source-software-does-government-finally-grok-open-source.html

12. 12
Source: https://www.infoworld.com/article/2608895/open-source-
software/open-source-software-does-government-finally-grok-open-source.html

13. The Equifax breach
13

14. When you have a dependency
14
𝑚1
𝑚2𝑦1𝑥1
𝑦2𝑢1
𝑧1
direct
transitive
Dependency tree

15. Current dependency analysis
15
0. Follow the updates in your software dependencies manually
- Subscribe to mailing lists of your dependencies
- Telegram channels
- Analyze changelogs of the new releases
- Receive a lot of spam…

16. Current dependency analysis tools
16
1. Github vulnerability alerts:
Example: https://github.com/iluwatar/java-design-patterns/network/dependencies

17. Current dependency analysis tools
17
1. Github vulnerability alerts:
Listing the packages that a repository depends on:
https://help.github.com/articles/listing-the-packages-that-a-repository-depends-on/
Viewing and updating vulnerable dependencies in your repository:
https://help.github.com/articles/viewing-and-updating-vulnerable-dependencies-in-your-
repository/
About security alerts for vulnerable dependencies:
https://help.github.com/articles/about-security-alerts-for-vulnerable-dependencies/

18. Current dependency analysis tools
18
2. Snyk.io:
Home page:
https://snyk.io/
Introduction video:
https://youtu.be/4ng5usM6fd8

19. Current dependency analysis tools
19
2. Snyk.io – Vulnerability DB:

20. Current dependency analysis tools
20
2. Snyk.io – Vulnerability DB:

21. Current dependency analysis tools
21
3. SourceClear - https://www.sourceclear.com/
Advantages:
- one of the biggest vulnerability databases
Disadvantage:
- fully commercial
4. Vulas - https://github.com/SAP/vulnerability-assessment-tool
Advantages:
- open-source
- precise code base matching algorithm
Disadvantage:
- they do not publish the vulnerability database
- they support only Java (Maven&Gradle) and partially Python

22. You will have such a report
22
What would you do?
Ignore? Panic?

23. Observation 1
23
Some dependencies are non deployed, hence such vulnerabilities
cannot be exploited
𝑚1:compile
𝑚2: 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑦1: 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑥1: 𝑡𝑒𝑠𝑡
𝑦2: 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑢1: 𝑡𝑒𝑠𝑡
𝑧1: 𝑐𝑜𝑚𝑝𝑖𝑙𝑒

24. Observation 2
24
𝑚1
𝑚2
𝑦1𝑥1
𝑦2𝑢1
𝑧1
𝑀
𝑌
𝑋
𝑈
𝑍
Direct
‘Direct’ and ‘transitive’ notions do not represent which
dependencies really can be controlled
Transitive
Own

25. Observation 2
25
𝑚1
𝑚2
𝑦1𝑥1
𝑦2𝑢1
𝑧1
𝑀
𝑌
𝑋
𝑈
𝑍
‘Direct’ and ‘transitive’ notions do not represent which
dependencies really can be controlled
Own
In direct control
Out of direct control

26. Observation 3
26
𝑚1
𝑥1
𝑢1
𝑣1 𝑣2
𝑣1
𝑣1 𝑣2 𝑣3
𝑡0 𝑡1
There would be no version of x1:
1) to fix vulnerability in x1
2) adopt fixed version of u1
Fixing such a dependency would require a software company either to contribute to the
halted library (make a new release) or maintain an own copy of the library
Some libraries may become halted

27. Counting dependencies
27
Build dependency tree
Maven goals: dependency:tree and dependency:resolve
Filter non-deployed dependencies
Exclude test and provided scopes
Group dependencies by projects
Group all GAVs with the same groupId within one path and substitute
them in the path with the GAV, closest to the vulnerable GAV
Identify halted dependencies
•𝐿𝑎𝑠𝑡 𝑟𝑒𝑙𝑒𝑎𝑠𝑒 𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙 = 𝛼 σ𝑖=0
𝑛
{ 1 − 𝛼 𝑖
∗ 𝑅𝑒𝑙𝑒𝑎𝑠𝑒 𝑡𝑖𝑚𝑒 𝑛−𝑖}
•𝐸𝑥𝑝𝑒𝑐𝑡𝑒𝑑 𝑟𝑒𝑙𝑒𝑎𝑠𝑒 𝑑𝑎𝑡𝑒 = 𝐿𝑎𝑠𝑡 𝑟𝑒𝑙𝑒𝑎𝑠𝑒 + 𝐿𝑎𝑠𝑡 𝑟𝑒𝑙𝑒𝑎𝑠𝑒 𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙
•𝐸𝑥𝑝𝑒𝑐𝑡𝑒𝑑 𝑟𝑒𝑙𝑒𝑎𝑠𝑒 𝑑𝑎𝑡𝑒 < 𝑇𝐼𝑀𝐸 ⇒ 𝐿𝑖𝑏𝑟𝑎𝑟𝑦 𝑖𝑠 ℎ𝑎𝑙𝑡𝑒𝑑
Map with known vulnerable GA
S. E. Ponta, H. Plate, and A. Sabetta. Beyond metadata: Code-centric
and usage based analysis of known vulnerabilities in open-source
software. In Proc. of ICSME-18, 2018

28. Effects
Filtering non-deployed
Dependency grouping
“Is halted” analysis
28
20% less false alerts to check
Developers may have fixed 82%
of vulns in their dependencies
(45% increase)
14% of dependencies are halted,
hence would not be fixed

29. Following our approach you will have
the following report
29
A bit more clear what to do, isn’t it?

30. An example of our report
30

31. 31
We are looking for your experience
More details about our research are here:
http://bit.ly/vuln-research-trento
"Dependencies as you see it" (what the problems are, why people could, should, or won't
update etc.). This can be a brief Skype/Hangout/etc interview at your convenience.

32. We bring order to the
dependency hell
32

33. 33
For any questions or suggestions do not hesitate to contact me:
E-mail: ivan.pashchenko@unitn.it
Skype: ivanpashchenko
Web-site: http://disi.unitn.it/~pashchenko
Let’s say No to the Dependency Hell
Information about our research is here:
http://bit.ly/vuln-research-trento