79% of the time, third-party libraries are never updated by developers after being included in a codebase – despite the fact that more than two-thirds of fixes are minor and do not interfere with the functionality of most software applications. complex, Veracode research reveals.
Open source libraries are constantly evolving, so what looks secure today may not be secure tomorrow, potentially creating a significant security risk for software vendors and users. The research analyzed 13 million crawls from over 86,000 repositories containing over 301,000 unique libraries, and also surveyed nearly 2,000 developers to understand how they use third-party software.
Research also reveals notable fluctuations in the popularity and vulnerability of libraries from year to year. For example, four of Ruby’s five most popular libraries in 2019 were no longer in the top 10 in 2020, while some of Go’s most vulnerable libraries in 2019 became less vulnerable in 2020 and vice versa.
Since almost all modern apps are built using open source third-party software, a single flaw or tweak in a library can spill over into all apps using that code, which means these constant changes have a direct impact. on software security.
Almost all repositories include libraries with at least one vulnerability. Chris Ing, Research Director at Veracode, explains: âThe vast majority of applications today use open source code. The security of a library can change quickly, so keeping an up-to-date inventory of your app’s content is crucial. We’ve found that once developers choose a library, they rarely update it. With suppliers facing increasing oversight over the security of their supply chain, there is simply no way to justify a ‘set it and forget it’ mentality. It is essential that developers keep these components up to date and react quickly to new vulnerabilities as they are discovered.
Building secure applications with open source code doesn’t have to be demanding
Despite the dynamic nature of the software landscape, developers often do not update open source libraries after including them in software applications. A lack of contextual understanding of the relationship between a vulnerable library and its application can be a barrier. For example, developers who report that they don’t have this information will take more than seven months to fix 50% of the flaws, but that drastically reduces to three weeks when they have the right information and guidance.
Plus, they can react quickly when alerted to a vulnerable library, fixing 17% of flaws in an hour and 25% in a week. So when they have accurate, timely information, developers can prioritize security appropriately and fix vulnerabilities quickly.
The flaws in the open source library can be fixed with an update
- 92% of flaws in open source libraries can be fixed with an update, and 69% of updates are only a minor or lower version change
- Even when an update to an open source library produces additional updates, almost two-thirds of them will only be a minor version change and not likely to break the functionality of even the most complex applications. .
- Only 52% of the developers surveyed have a formal process for selecting third-party libraries, while more than a quarter do not know, or even ignore, if there is a formal process and
- Security is only the third consideration when selecting a library, while functionality and licensing rank first and second, respectively.
Securing Software Supply Chain Gets White House Attention
Last month, the White House issued a cybersecurity executive order of which nearly 25% focused on securing the software supply chain. In the future, software vendors who sell to the federal government will be required to disclose the composition of their software and ensure that software applications have undergone automated testing.
Chris Wysopal, CTO at Veracode, said, âAs Executive Order continues to take shape, anyone developing software should ensure that they analyze their software early and often in the development lifecycle. The growing popularity of open source software, combined with increasingly demanding development cycles, translates into a higher propensity for software vulnerabilities. Scanning earlier in the process significantly reduces the risk profile, and most fixes are minor and therefore will not impact the functionality of even the most complex software.