These days, there is a massive focus on securing software supply chains in the wake of some recent high-profile breaches. Still, a report published this week finds that developers never update a third-party library nearly 80% of the time after it’s been included in their codebase.
Based on 13 million scans of 86,000 repositories containing more than 301,000 unique libraries run by Veracode, a provider of application security testing tools, the report identifies the languages being employed most where libraries have never been updated are Ruby (67%), JavaScript (66%), Java (65%), Microsoft.Net (61%) and Go (54%).
Veracode, at the same time, also surveyed 2,000 developers to determine how third-party libraries are managed. Only 52% said there is a formal process for selecting third-party libraries, while more than a quarter are either unsure or unaware if there is a formal process in place.
Despite the regular discovery of new vulnerabilities, the primary reason third-party libraries are not updated is many developers are simply not informed. Developers who report they lack vulnerability reports will take more than seven months to fix 50 percent of flaws as a part of a regular update cycle. That time is reduced to three weeks when they have the correct information and guidance.
The goal, of course, remains to discover as many vulnerabilities as possible before an application is deployed in a production environment. As part of that effort, developers have embraced DevSecOps workflows that provide them with the tools they need to scan for vulnerabilities. The challenge is many vulnerabilities impact libraries are not discovered until after an application has been deployed. In many cases, however, it’s clear there is a failure to communicate between security teams that monitor databases that track vulnerabilities and the development team. “There’s a need to change the culture,” says Eng.
In other cases, there simply isn’t anyone to track the vulnerability database at all because internal IT teams simply lack the time or expertise required.
The tragedy is most of the vulnerabilities discovered only require a relatively simple fix, says Chris Eng, Chief Research Officer at Veracode. A full 92% of open source library flaws can be fixed with an update, with 69% requiring only a minor version change or smaller. The probability an update will break an application is therefore relatively small, noted Eng.
Things can get difficult when multiple updates have to be made all at once should a developer discover they are suddenly several release cycles behind, so Eng says it’s important for development teams to stay as current as possible.
Pressure on developers to address these and other application security issues is clearly mounting. A recent executive order issued by President Biden requires any organization doing business with the government to secure its software supply chain. Security teams, as a result, are being mandated to examine just how software employed within their organization is being created and maintained.
Developers deservedly or not are going to be seeing a lot more fingers pointing their way in the weeks and months ahead as software supply chain issues are worked out. The choice now is to wait for the organization to figure out what security checks need to be put in place or simply go ahead and create a process for regularly updating libraries deployed in a production environment before a more demanding one from on high is inevitably imposed.
