The Open Source Vulnerability Database shut down this week posed yet another security challenge for developers who routinely inject massive amounts of free off-the-shelf code into new software.
As the name suggests, OSVD was a resource where non-commercial developers could look – free - for patches to known vulnerabilities.
Without it, other vulnerability repositories remain, but its closure points up one of the problems with how open source code is used, particularly in enterprise development: often once it’s incorporated into apps, it might never be updated to fix vulnerabilities that are discovered later.
And that is a big problem. “Everyone uses open source,” says Mark Curphey, CEO SourceClear, a startup focused on securing open-source software, particularly for corporate developers. “Ninety percent of code could be stuff they didn’t create.”
The percentage might actually be closer to 75%, but that’s still significant, says Mike Pittinger, vice president of strategy for Black Duck, whose automated platforms help customers ensure open source code remains free of vulnerabilities.
Other companies offer similar services, including WhiteSource, which handles the commercial use of information compiled in the OSVD. It discovers open source components in its customers’ apps and alerts when vulnerable code is added to ongoing software projects or when new vulnerabilities pop up that affect customers’ existing software.
Urgency to rapidly develop software leads to popular use of open source code. It’s available, often free and vetted by involved communities. But that urgency can lead to sparse records about what versions of what open source software is used, says Pittinger, leaving corporate security pros guessing when they’re trying to figure out how vulnerable their in-house apps are.
Unless developers log what open source code they use in an automated fashion, compiling that information later will be basically a best guess. “It’s only as accurate as is the memory of the development team,” he says.
Attackers are well aware of this use of open source code. They monitor GitHub, for example, to see who contributes what code and whose code had problems. Then they follow the people who follow them to find out what they’re working on, hoping they will use some of the vulnerable code they’ve found on GitHub, Curphey says.
The outcry was so loud that the registry, npm, went against the coder’s wishes and republished one 11-line piece of code whose absence was causing the most trouble.
Sign up for Computerworld eNewsletters.