It is clear the future is in open source. Slowly taking hold for decades with the release of mainstream software such as Apple’s Swift and Microsoft’s .Net framework, the projected revenue of open source software for 2020 is over €57 million. The reason behind this increasing adoption is the ability for enterprises to not only drive competitive advantage, but to also attract top talent. However, with that comes a new set of challenges to overcome.
While helping accelerate application development, the use of open source can put an organisation at risk of getting breached and failing compliance audits. In fact, 44 per cent of applications contain critical vulnerabilities in an open source component.
Vulnerable open source components present massive risk to organisations. For example, the vulnerability exploited in the ransomware attack on the San Francisco Municipal Transportation Agency in November 2016, was in an Apache Commons Collections’ component that ultimately put up to 25 per cent of all Java applications at risk.
The vulnerability of many open source components is certainly no reason to shun the use of them entirely – this is nigh impossible in today’s DevOps environments. However, with today’s cyber threat landscape, it is essential that businesses understand the risks involved and the best practices for open source software. So, where do we start?
Acknowledging the new order
Open source is built by developers for developers, which is why enterprises need to realise that it is now developers who are determining which software components will be used within the business. Take the fact that common open source binary repositories are being given first-class support within developer integrated development environments (IDEs) – such as Nuget in Visual Studio, MavenCentral in Eclipse and IntelliJ – allowing developers to ingest open source components into their projects with minimal effort.
What this means is that the days where an enterprise could conduct a lengthy due diligence process and vendor review of any proprietary software solution that could be potentially used in the business, such as an ERP or CRM solution, are gone. Instead, an enterprise can now unknowingly incorporate open source software of unknown origin into its core product both easily and quickly.
While this certainly makes the job of the legal and security teams far more challenging, it is an opportunity to hit re-set. Rather than reviewing software as previously done, enterprises should be looking at alternative ways to put the necessary governance in place to ensure any open source software is free of vulnerabilities and licensed appropriately.
Debunking the open source security myth
Many in the industry look to the concept of Linus’ Law when it comes to the security of open source software. The thinking is that with copious peer review all but the most trivial flaws will be discovered and eliminated in a collaborative effort. However, there are several fallacies to this theory.
The Heartbleed vulnerability a few years ago disproved the theory since the underlying vulnerability in the OpenSSL library has existed for several years, and this library had been scrutinised by legions of open source contributors. In addition, as Jeff Atwood rightly pointed out, there is a difference between usageand 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.
In addition, if open source software was going to be open to public scrutiny and review, it could be more easily exploited. And when patches are released these will be visible to the attacker, who can simply create a suitable exploit.
In fact, a closed source system is inherently no more secure than an open source one. The key difference is that with a closed source system the end user is at the mercy of the supplier for a fix or patch. For open source, a suitably motivated user could implement a fix themselves (and contribute back to the community). According to Russell Clarke, David Dorwin, and Rob Nash, a closed source system can hardly rely on “security through obscurity” as a prevention against exploit.
Best practices for securing open source software
There are several ways enterprises can take advantage of open source software without risking loss of intellectual property and exposing their systems to vulnerabilities. Here are six security practices to take into consideration:
1. Prescribe a policy: The cornerstone of securing open source software is for an enterprise to draft a policy regarding how it will be utilised within the company. Rather than let the development team assume they are free to use any open source software, provide a guideline based on what risk the company is willing to take.
2. Patch management: A centralised patch management framework is vital to ensure that the most critical vendor patches are applied to infrastructure in a timely fashion. Simply by patching six software packages it is possible to reduce the likelihood of malware significantly.
3. Control your repositories: The notion of open source software is based on developers having direct access to the widest possible selection of open source libraries within their native environments. Based on your policy, you may need to bar access to such repositories either – in extremis – by blocking access at the firewall level, or more pragmatically providing an on premise cached version of known and approved software components.
4. Understand your software supply chain: Any enterprise will be using software from other vendors and COTS components, which means you unknowingly inherit both known and unknown vulnerabilities. Use security testing tools (both static code analysis and software composition analysis tools) to give you a high degree of visibility into inherent risk combined with ensuring vendor contracts mandate a minimum-security level for delivered software components.
5. Understand how to remediate: An enterprise should not rest on its laurels. There needs to be a continuous risk assessment from vulnerabilities within open source and third party components. When a new risk is detected, the security team should proactively work with the development organisation to remediate.
6. Build security and developer relations: Being able to evaluate the security of software relies on knowing the developers. It is critical for developers and the security teams within an enterprise to have an open dialogue and share tools and training so there is a joint level of understanding of what is needed to minimise vulnerabilities within open source.
Open source software has changed the way enterprises do business. Just think that back in 1976 Bill Gates openly argued free software would not encourage the generation of high quality products. And today, Git Hub has launched an Open Source Friday calling for more employees to work on open source projects.
While there is no arguing that open source software does bring a set of new challenges, there a few simple tactics that enterprises can utilise to negate any potential risk and ensure their company is just as secure as when using proprietary or closed source software.
[“Source-itproportal”]
