Software bugs are inevitable, but some issues are more about not vetting third-party libraries than actual coding mistakes. Many of the security vulnerabilities found in commercial software are the result of using at-risk versions of open source libraries and frameworks, and the problem isn’t getting any better.

Modern software development relies on cobbling together custom code with multiple open source components, but organizations underestimate exactly how many libraries and frameworks they actually use, Black Duck Software said in its latest Open Source Security and Risk Analysis.

Of the 1,000-plus commercial applications audited by the company in 2016, 96 percent contained at least one open source component. A little more than one-third of the application’s codebase is made up of open source code, with an average application using 147 unique components, according to the analysis.

“Components” is intentionally a broad term in this analysis, and it includes frameworks like Bootstrap and JUnit, scripting languages like PHP, libraries like jQuery and Apache Commons, and infrastructure technologies like the Linux kernel and Apache Tomcat. Including all these different elements makes sense because attackers don’t care if the issue is in the infrastructure or a library: A way in is a way in.

, which found that 97 percent of Java applications tested by the application security company contained at least one component with a known software vulnerability. At the time, Veracode highlighted the number of applications using buggy versions of Apache Commons Collections.

Know what you have

Development teams should maintain a full and accurate inventory of the open source components they use regularly so that they know which application is using which version. With that information on hand, when they receive information from public sources such as the National Vulnerability Database about publicly disclosed vulnerabilities, they know right away which applications are at risk.

Companies should also adopt an open source policy so that it’s clear how components are selected. As more and more of software development gets automated, a formal policy will help make sure the components are used correctly and the inventory is regularly maintained. There are ways to integrate open source component checks to build tools so that the tests run whenever new code is committed.