We’ve talked on this blog before about the conundrum posed by the widespread use of third party and open source code. One the one hand: third party code can greatly accelerate application development by sparing software development groups the task of “reinventing the wheel” in order to implement standard application components. On the other hand, open source and third party code can often contain serious vulnerabilities that easily slip below the radar during quality assurance testing and application audits.
The problem is serious enough to prompt OWASP to make room on its Top 10 for third party software components. Veracode’s own Chris Wysopal recently argued that the prospect of NSA “back doors” in common technology were a lot less of a privacy concern than run of the mill vulnerabilities in shared code.
“Inserting backdoors into systems requires quite a bit of fore-thought and planning,” Wysopal said. “It is far easier for anyone, from the NSA to the cybercriminal to simply hack into a system through the insecurities prevalent in third party software used by every enterprise.”
The problem of third party code is particularly complex when you talk about open source components. For one thing: open source is the salt and pepper of the software world. Open source components are often used to build out proprietary software products. And, as security researchers have noted: many of the so-called “smart devices” that are populating the physical world run variants of Linux, the open source operating system.
But because those source code repositories are managed cooperatively and collectively by volunteers, security often takes a back seat to feature development and integration work. Open source ends up suffering from a variation of the economic principle of the “tragedy of the commons.” In other words, the more it is used, the more depleted it becomes, as each user takes what they need, but fails to give back – managing the resource for the betterment of the entire community.
That’s why Google’s announcement on Wednesday that it will provide cash incentives to developers who improve the security of open source software is a major development.
In case you missed it: Google security researcher Michal Zalewski used a post on the company’s Security Blog yesterday to say that Google would provide “financial incentives” for developers to help make critical open source technologies like OpenSSH, BIND, DHCP and OpenSSL more secure.
Zalewski was careful to say that this isn’t about finding a security hole in those components. Rather: it’s about fixing the code – or, what he calls “down-to-earth, proactive improvements that go beyond merely fixing a known security bug.”
“Whether you want to switch to a more secure allocator, to add privilege separation, to clean up a bunch of sketchy calls to strcat(), or even just to enable ASLR - we want to help,” he wrote.
Developers are encouraged to submit their patches directly to the open source project in question. If the patch is accepted and merged into the main repository, the developers can send the details to Google, who will pay a reward ranging from $500 to $3,133.7 for the work.
Google taking the initiative on this is a major development – but more needs to be done. As Chris Wysopal and Josh Corman of Akamai said during our discussion of supply chain security, the widespread use and reuse of open source can amplify the effects of security vulnerabilities.
“When you have all these social media applications using the same kind of code, a bug found is force multiplied to all the sites depending on it,” Corman said.
Still, independent software development firms are often ignorant of – or turn a blind eye to – the way third party and open source components are woven into proprietary codebases.
“Often when you think of the code you build, you’re forgetting that your developers will borrow lots of code of unknown origin,” Corman told me.
Wysopal said that, while individual companies can always ‘fork’ open source software to adapt it for their own purposes, or to fix security flaws, that puts the onus on the development organization to continue maintaining that code in perpetuity, while barring them (possibly) from future bug fixes and updates that are added to the public repository.
“Whether it’s a commercial entity that’s an independent software vendor or an open source software vendor, its always best to work with the supplier. Tell them about the issues you’ve found. Ask them questions about their process,” he said.
Read more about Google’s rewards program for “proactive security improvements” to open source projects here.