While the decrease is undoubtedly good news, most development teams still fail to adequately inventory their software dependencies — a point of concern because indirect dependencies, meaning libraries used by imported code — can account for the majority of vulnerabilities. More than 70% of vulnerabilities in Node.js, Ruby, and Java, for example, occur in indirect dependencies, not in the original imported open source library, according to the "State of Open Source Security 2020" report, published today by software security firm Snyk.
In one case, a Java application comprised 80 lines of code with seven dependencies, but when all of the code was imported, the code base expanded to 59 sub-dependencies and more than 700,000 lines of code, says Alyssa Miller, application security advocate at Snyk.
"You don't even necessarily know that all those dependencies are there, but they are undermining your security," she says.
As open source software components have become arguably the most important part of software development, managing the vulnerabilities posed by those components has become a major task for companies. Almost every software program uses open source software, with the average application using 445 open source components, according to a recent study by Synopsys.
Acknowledging this, the Internet Security Forum (ISF) released its "Deploying Open Source Software: Challenges and Rewards" report today, highlighting best practices for companies using open source software in development.
"Many organizations are adopting agile and DevOps methodologies, which is driving an increased uptake of OSS [open source software] and, in turn, the creation of new mixed-source applications," stated Paul Holland, principal research analyst at the ISF. "The growing prevalence of OSS needs to be balanced by a concerted effort to manage its use appropriately and effectively."
Different programming languages and their associate application frameworks have different considerations when it comes to securing the software. PHP applications tend to use a relatively low number of open source libraries — 34, on average — but have a higher number of vulnerabilities, according to data analyzed by application security firm Veracode.
"There is a lot of factors that can come into play here. NPM has a pretty significant drop in the number of vulnerabilities, but they also have a solid backlog of vulnerabilities that they are investigating, which is causing delayed fixes," Miller says.
Two classes of vulnerability demonstrate the unique nature of open source software and dependencies, where vulnerability types tend to result in a lot of reported issues or are widespread, but generally not both.
A significant number of open source software project suffered attacks in the form of malicious changes to the project, according to the report. A malicious change typically happens when a rogue developer — often an agent of a nation-state or cybercriminal gang — joins a project to introduce a vulnerability. Yet, while critical in severity, such malicious changes did not impact very many projects.
"They are difficult to find," Miller says. "I think that is the reason we see a low number of them. It is not a well-understood vulnerability at this point."
Finally, software container images — Docker being the most popular example — often pool together vulnerable software and should be investigated, Snyk said. The most recent version of the Node server, at the time of the report, had more than 642 known vulnerabilities in the software contained in the image, including 17 high vulnerabilities, the company said.
"Companies need to try to minimize the software footprint of these images," Miller says. "If you pull Node-Slim [the stripped down version of the Node server], then you lose 95% of the vulnerabilities. So if you don't need the full-blown image, choose the minimal version."
- Flaws Found in Some Open Source Projects Exploited More Often
- Unpatched Open Source Libraries Leave 71% of Apps Vulnerable
- Nine in 10 Applications Contain Outdated Software Components
- Misconfigured Containers Again Targeted by Cryptominer Malware
- How Cybersecurity Incident Response Programs Work (and Why Some Don't)