Veracode on Wednesday reported that 32% of applications are found to have flaws at the first scan and by the time they have been in production for five years, nearly 70% contain at least one security flaw.
With heightened focus on a software bill of materials over the past year, Veracode’s research team also examined 30,000 open-source repositories publicly hosted on GitHub, finding that 10% of repositories hadn’t had a commit — a change to the source code — for almost six years.
Chris Eng, chief research officer with Veracode, pointed out that the findings regarding repos that haven’t had a commit in six years doesn’t necessarily imply that those libraries add more risk. Eng said Veracode’s research is meant to attune people to ensure vigilance in monitoring and scanning third-party code in their application development.
“The most important steps that government agencies and businesses can take to reduce risk posed by open-source libraries are to use software composition analysis (SCA) tools to find libraries that have flaws that expose potential vulnerabilities,” said Eng. "Many understand and already do this. Of equal importance is when understanding the open-source libraries that they use, teams need to ensure they update to the latest versions of libraries. We have been startled to learn how many organizations use old versions of Log4j, for example, even predating versions that were compromised before the disclosure of the zero-day vulnerability in that library.”
Mike McGuire, senior security solutions manager at Synopsys Software Integrity Group, said his team’s research and analysis corroborate this problem, finding that 88% of applications contain open source components that have had no development activity in the last two years. McGuire said the fundamental issue isn’t that there are open source projects that have been abandoned or aren’t actively maintained, that’s a natural outcome in any ecosystem.
“The real problem lies in the fact that so many organizations are building their software on top of these abandoned open-source components,” said McGuire. “In many cases, it’s an awareness issue. Some organizations are unaware that their dependencies have fallen out of support, while others are completely unaware of which projects they even depend on. In other cases, organizations may determine that the cost of switching to a different component outweighs the benefits. Regardless, components that have lost development support represent significant avenues for security threats — some targeted, and some inadvertent."
Mike Parkin, senior technical engineer at Vulcan Cyber, said Veracode’s advice for creating a secure development process is sound. But calling open-source "fragile" doesn't follow, said Parkin.
“Finding that 10% of the GitHub repos they examined hadn't been updated in six years doesn't reflect on open-source as a whole,” said Parkin. “Considering how many projects are abandoned, or been forked, or superseded by new libraries — that number is really not surprising. Commercial libraries are also dropped, orphaned, or superseded. That doesn't indicate fragility, but natural evolution.”
Kristen Bell, director, application security at GuidePoint Security, said the 10% number illustrates the downside to enabling developers to freely use open-source code within their applications. Currently, Bell said security teams are chasing vulnerabilities within their repositories looking for whatever has been introduced into the environment by developers.
“Instead, organizations should adopt a process for open-source components to be vetted prior to being approved for use,” said Bell. “In essence, this is not that different from the third-party vendor management process many security teams already have in place as part of their technology procurement process.”
Sounil Yu, chief information security officer at JupiterOne, said Veracode’s research pointed to a need in the open source software community for a form of cell apoptosis, the process in which cells die.
“Outdated and vulnerable code should gradually be purged from the ecosystem,” said Yu. “That’s hard to do if we are not intentional in proactively removing it through software apoptosis. At the very least, we should label it as potentially toxic or dangerous, so that if someone chooses to reuse it, they know what they are getting themselves into."
