My company, Veracode, published our most recent State of Software Security Report yesterday (disclaimer: I’m one of the authors). The report mines data from hundreds of thousands of application scans to paint a picture of the risk profile of software.
This year we included data on risk from open source components. The idea is that it’s common, especially in Java development but also in Javascript, Python, PHP and other languages, to use libraries and frameworks that were developed by the open source community for certain foundational parts of the application’s functionality. Why write a new object persistence layer (to pick one example) when you could simply use a free off-the-shelf one and focus on writing the actual behavior of the application?
Turns out there’s one major issue with this approach: all software, even open source software, is buggy, and some of those bugs are vulnerabilities: they can be exploited to compromise the confidentiality or integrity of the data the application accesses, or impair the availability of the application itself. And widely shared components create a big target of opportunity for attackers, who can focus on finding vulnerabilities in the shared components for a payoff of attacking hundreds or thousands of applications.
The open source community generally stays on top of fixing these vulnerabilities as they’re discovered. Look at any popular Java framework like Struts or Spring—you’ll see dozens or hundreds of point releases fixing all sorts of defects, including security vulnerabilities. So what’s the problem?
The problem is that developers don’t upgrade to newer versions of the components they use. From the developer’s perspective, there’s almost zero benefit, and a high downside, to a component upgrade: it takes time out from developing features that the business has asked for, and there’s a non-zero risk that upgrading the component will break functionality in the application. From their perspective, the possibility of a hack via the component is remote, so the upgrades don’t get done.
This attitude makes sense in the short term, but in the long term is fatal for security. Because vulnerabilities do get found in older components. The best description I’ve heard of this phenomenon comes from Josh Corman (who says he heard it from someone at Microsoft): “Software doesn’t age like wine, it ages like milk.” As developers widely adopt components, the attack surface for newly discovered vulnerabilities in those components becomes broad indeed.
It’s not open source’s fault, but I do think it reflects a misunderstanding of the cost/benefit analysis for using open source. Yes, open source is free of commercial licensing fees, but it is not free of downstream maintenance costs. It’s as if someone gave you a car. Just because it’s free doesn’t mean you don’t have to periodically change the oil.
Likewise, developers who adopt open source components should set expectations with the business that they’ll need to reserve some of their development time for basic maintenance, like component upgrades. Doing so proactively helps improve predictability—and avoid the likelihood of having to do an emergency update that disrupts the roadmap.