The closure of the Open Source Vulnerability Database this week has posed another security challenge for developers who routinely inject massive amounts of off-the-shelf free code into new software.
As the name suggests, OSVD was a resource where non-commercial developers could seek out – for free – fixes for known vulnerabilities.
+More on Network World: 10 cloud SLA best practices+
Without it, other vulnerability repositories remain, but its closure highlights one of the problems with using open source code, especially in enterprise development: often, once integrated into applications, it may not never be updated to fix vulnerabilities discovered later.
And that’s a big problem. “Everyone is using open source,” says Mark Curphey, CEO SourceClear, a startup focused on securing open source software, especially for enterprise developers. “Ninety percent of the code could be stuff they didn’t create.”
The percentage could actually be closer to 75%, but it’s still significant, says Mike Pittenger, vice president of strategy at Black Duck, whose automated platforms help clients ensure that open source code remains free of vulnerabilities.
Other companies offer similar services, including WhiteSource, which manages the commercial use of information compiled in the OSVD. It discovers open source components in its customers’ applications and alerts when vulnerable code is added to ongoing software projects or when new vulnerabilities appear and affect customers’ existing software.
The urgency to develop software quickly leads to the popular use of open source code. It is available, often free and trusted by the communities involved. But that urgency can lead to sparse records about the versions of open-source software being used, Pittenger says, leaving enterprise security professionals guessing when trying to determine the vulnerability of their internal applications.
Unless developers log the open source code they use in an automated fashion, compiling this information later will essentially be a best guess. “It’s only as accurate as 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 is contributing what code and what code has had issues. Then they follow people who follow them to find out what they’re working on, hoping they’ll use some of the vulnerable code they found on GitHub, Curphey says.
The outcry was so loud that the register, npmwent against the coder’s wishes and reposted an 11-line piece of code whose absence was causing the most trouble.
Problem solved, at least in this case. But the underlying problem – the common practice of reusing open source code in new software – remains.
It’s not just open source
The problem extends to commercial software as well, and vendors need to be held to a high standard, he says. They should disclose what is open source in their software, track it, and release patches when new vulnerabilities are discovered, he says.
Tracking the software supply chain in complex applications is important. Just last month researchers found over 1,400 vulnerabilities in a networked medical supply cabinet with third-party software built into its stack, including Microsoft Windows XP, Symantec pcAnywhere, and SAP Crystal Reports 8.5.
Keeping track is so important that later this month the Food and Drug Administration will begin work on the final draft regulations for medical devices and how to deal with software vulnerabilities that arise after medical devices are shipped.
Code security issues can extend to popular network devices, even security equipment. Famously, Juniper announced in December that its NetScreen equipment had been hacked and unauthorized code had been injected into the operating system. How is still a mystery – at least to the public. Unknown parties apparently installed the backdoor intentionally, leaving it to be exploited at will, but exploitable vulnerabilities can be the result of poor coding, inadequate quality assurance, or honest error.
Investigating what happened should have involved looking at what Curphey calls code genetics – where the code came from and who wrote it. Both need to be examined to determine how it happened and if genetics reveal an additional threat. “It could have been a dishonest developer. If so, what else did this developer mess with?” he says.
This is one of the basics of software security, but patching is often ignored or postponed until a more convenient time. This leaves a window of opportunity for attackers, who are well aware of this trend from network administrators, says John Pironti, president of IP Architects.
Take Microsoft’s Patch Tuesday, which fixes discovered weaknesses month by month. Because many organizations don’t patch right away, it results in a Patch Tuesday contest, he says. The game is, “How fast can I reverse engineer Microsoft patches?” he says. Attackers try to figure out what flaws the patches fix, create ways to exploit them, and then look for vulnerable systems to attack before they’re patched.
In the case of Juniper NetScreen, it’s likely that many customers using the equipment haven’t installed the patches yet and won’t for a long time, he says. “It will be used for years.”
There are steps you can take to reduce the risk:
- Understand what open source or third party is in the software you buy.
- Ask suppliers to document how they monitor the ongoing integrity of the components they use and how they correct defects. How mature is their software development lifecycle program that monitors code from birth to grave?
- If a commercial third-party library is used, is there an SLA with that vendor to ensure faulty components are corrected?
- Do commercial software developers use static and dynamic analysis and threat modeling to verify the viability of their software?
- Prioritize which applications are most closely monitored and maintained based on the applications’ importance to the business and the value of the resources they affect.
Companies should set up and maintain persistent programs to upgrade and patch their software as patches become available. “Security is fleeting,” says Pittenger. “Today’s scan is good, but that may change.”
And when purchasing apps, companies should ask developers about their supply chain security, how they screen the code they use, and what their plan is to fix their products once they are in the hands of their customers. “We need to raise the expectations we have of software vendors,” says Pironti.
Copyright © 2016 IDG Communications, Inc.