Development and Security Have Different Perspectives on Open Source Components
Open source components are a blessing and a curse. From a developer’s perspective, they’re a no-cost way to speed the development process. But they can be a curse security-wise. Many open source components contain vulnerabilities that put the organization at risk of getting breached and failing compliance audits. In fact, recent Veracode research looked at all the Java applications we scanned in an 18-month period. Ninety-seven percent of these applications had at least one component with a known vulnerability.
Despite the risk, the use of open source components is proliferating. Veracode has found that applications now have an average of 46 such components.
There are several reasons for the increase in adoption of open source software, and for the lax attitude surrounding their security: First, open source adoption drives a competitive advantage, allowing an organization to deliver innovation and features more quickly by leveraging existing software libraries and frameworks. Second, open source adoption attracts top talent and is often seen as superior to proprietary or closed source solutions.
Battling myths about the security of open source components
Some posit that open source components are by their nature more secure than internally developed code. With all those eyes on the code, surely any major security-related defects would be noticed, right? Considering the well-known Heartbleed vulnerability, wrong. The underlying vulnerability in the OpenSSL library had existed for several years, and this library had been scrutinized by legions of open source contributors.
In a recent article, Jeff Atwood suggests that there are several fallacies regarding this “many eyes equals more security” theory: there is a difference between usage and development eyeballs (in terms of skillset), it is easier to review your own code than someone else’s, and there are not enough qualified eyeballs.
And if open source software is going to be open to public scrutiny and review, doesn’t this mean that it will be more easily exploited? On the other hand, a closed source system is inherently no more secure than an open source one. With a closed source system, the end user is at the mercy of the supplier for a fix or patch. In the case of open source, a suitably motivated user could implement a fix him or herself (and contribute back to the community).
Caught between security and speed
Adding to the security challenges of open source components, it is increasingly software developers who are determining which software components will be used in the enterprise.
Gone are the days when an enterprise would conduct a lengthy due diligence process and vendor review of a proprietary software solution such as an ERP or CRM solution. This has made the job of the legal and security professional that much more challenging: if it is no longer possible to review software as it enters the enterprise because
Visibility is key
In the end, enterprises can’t stop using open source components, or rely on the open source community to keep components vulnerability-free. They have to have visibility into what components they are using and where. Only then can they rapidly patch vulnerable components when a vulnerability is disclosed.
Get more details on the challenges surrounding, and solutions for, third-party software security in our new Third-Party Software Security Toolkit.
And stay tuned for my next post when I’ll dive into best practices surrounding the use of open source components …
Related Posts
