Say No To Dependency Hell
0 likes132 views
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
Say No To Dependency Hell
- 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
- 4. Nowadays software projects are highly interconnected 4 Own code Dependencies Own code Dependencies Software project
- 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
- 10. 10
- 14. When you have a dependency 14 1 211 21 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 11 21 1 Direct Direct and transitive notions do not represent which dependencies really can be controlled Transitive Own
- 25. Observation 2 25 1 2 11 21 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, isnt 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 Lets say No to the Dependency Hell Information about our research is here: http://bit.ly/vuln-research-trento