Following the leaders
Orphan projects and lax inspection should not obscure that some leading lights in the industry are well along the virtuous path to secure code.
Commercial Linux firms like Canonical, Red Hat, and Google already invest heavily in the security and integrity of open source. Wealthy, open-source-friendly firms such as Netflix and Facebook have directed considerable resources to projects that improve open source quality as well.
At Mozilla, responsibility for security is split among three teams, according to Engineering Manager Jason Duell. One team triages security issues as they're discovered. A second does “fuzzing” (black box testing of compiled code) to find vulnerabilities, and a third team develops such security and privacy features as Mozilla’s Content Security Policy.
Duell says that fuzzing and rigorous testing of developed code has been a mainstay of Mozilla’s development culture since before he arrived six years ago. But Mozilla has changed other development practices as awareness of the threat to open source has grown.
“We've changed various practices to be inline with the fact that adversaries are watching our public source repository for commits,” Duell says. For one, security fixes to Mozilla code are coordinated to land prior to release to give attackers a smaller window to work with. Large new features get security team audits prior to release.
At Canonical, which makes Ubuntu Linux, a fast-growing security team audits Canonical’s code -- a total of 35,000 software packages that are released as part of Ubuntu through a variety of channels, according to Dustin Kirkland, Canonical’s Cloud Solutions Product Manager.
As with Mozilla, Canonical’s security operations span a number of different initiatives, from feature development to code audits. To Corman’s point, Kirkland says that supply chain risk is a major concern. Canonical devotes considerable resources to assessing the viability of open source components that are bundled with its core operating system.
“With open source technology, we’re looking at whether it's better to adopt it or to fork it, then develop and extend it,” said Kirkland, who is a 20-year open source veteran and distribution maintainer of more than 20 open source projects. The company has come under fire from within the open source community when it opts to fork existing open source code, but Kirkland cites the ability to fork as one of open source’s strengths.
“We’re not going to create own versions of OpenSSL and GPG,” says Kirkland. “But having alternatives to encryption libraries is important. There needs to be diversity, especially as we’re learning how vulnerable some of these components are.”
We’re all open source now
As uncomfortable as that may be, experts say there’s no going back. Weinberg spent a good part of his career as what he calls a “defender of the faith,” countering attempts by commercial vendors like Microsoft to discredit the open source movement. He says the wall that once separated “open source” and “closed source” was torn down long ago.
“There’s no such thing as proprietary software anymore because there’s very little software without some dependency on open source,” he said. “The world has moved to ‘community developed’ software in one form or another.”
“I really think it’s a shared responsibility,” says Kirkland of Canonical. “When you consider how dependent all of us are on a whole stack of open source software, you have to hope that [security] becomes a shared responsibility and that it isn’t left up to the the Linux Foundation and Red Hat to figure out this stuff.”
In other words, we can gnash our teeth and tear at our hair over the likes of Heartbleed, but in 2015, all companies that make, use, or rely upon software are de-facto open source software companies whether they know it or not. That makes them part of the problem and its solution.
This story, "The state of open source security" was originally published by InfoWorld.