There are at least six types of open-source library vulnerabilities that we should all be concerned about. Before describing them it is worth reiterating that simply linking to a vulnerable library in your project doesn’t mean your application will have a vulnerability. You will only have a vulnerability if you are using the vulnerable methods of the vulnerable library in a vulnerable manner. This is important. To know this for sure you need to look at the call-graph of your application and see if there is a call-chain to the vulnerable method in the dependency graph.

Listing vulnerable libraries is easy but actually determining a vulnerability is hard.

For every vulnerable library being used we see a very small percentage (single digits) of those projects actually using the vulnerable methods and have a strong hunch that across all developers this is likely to actually be a tiny percentage (i.e. 0.1 %). Another way to read that is by just showing vulnerable libraries there is 'maybe' a 99.9% false positive rate. I will follow up on that hunch with real stats soon.

The six types of open-source library vulnerabilities are:

  1. Disclosed - a vulnerability where information is available in public places such as change-logs, commit-logs, issue-trackers, mailing-lists and vulnerability databases (including CVE’s in the NVD). (1)(2)
  2. Inherited - a new vulnerability that is the result of a library inheriting a library with a disclosed vulnerability via its dependency & call graph (both conditions needed).(3)
  3. Embedded - a new vulnerability that is the result of inheriting a library with a disclosed vulnerability from embedded code (usually as a result of cut-and-paste).(4)
  4. Similar - a new vulnerability that is the same or similar to a previously disclosed vulnerability but that is now found in a different library.
  5. Reintroduced - the same disclosed vulnerability that has been fixed in a previous release of the library but that has been reintroduced in a later version of the same library.(5)
  6. Zero Days - new issues that have not yet been the subject of public disclosure but known about by someone and likely being used by the bad guys in the wild.

We estimate that the total gene pool of open-source library vulnerabilities is likely made up of something like Type 1: 5-10 % (and CVE's are < 5% of this 5-10%), Type 2: 20-30%, Type 3: 20-30%, Type 4: 2-3% and Type 5: 50%.

References

  1. CVE's make up a small percentage of the disclosed vulnerabilities
  2. Tracking disclosed issues requires you to be good at scavenging on the Internet (or have a team working on using Natural Language Processing to track these things at scale)
  3. This means the full dependency graph i.e. the direct and transitive dependencies like Apache Commons Collections
  4. Like these issues we disclosed in Handlebars
  5. Like this issue we disclosed in Spring Social

Mark Curphey, Vice President, Strategy Mark Curphey is the Vice President of Strategy at CA Veracode. Mark is the founder and CEO of SourceClear, a software composition analysis solution designed for DevSecOps, which was acquired by CA Technologies in 2018. In 2001, he founded the Open Web Application Security Project (OWASP), a non-profit organization known for its Top 10 list of Most Critical Web Application Security Risks. Mark moved to the U.S. in 2000 to join Internet Security Systems (acquired by IBM), and later held roles including director of information security at Charles Schwab, vice president of professional services at Foundstone (acquired by McAfee), and principal group program manager, developer division, at Microsoft. Born in the UK, Mark received his B.Eng, Mechanical Engineering from the University of Brighton, and his Masters in Information Security from Royal Holloway, University of London. In his spare time, he enjoys traveling, and cycling.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.

 

 

 

contact menu