Patrick Carey, Black Duck Software
Open source code – in the form of libraries and frameworks – plays an important role in much of today’s software development. But it’s not without its risks.
Many people assume that the open nature of the code means that it is heavily scrutinised and that , according to Linus’ Law, “given enough eyeballs, all bugs are shallow”.
But open source code has been found to contain flaws so potentially serious that they get their own brand names, such as Heartbleed and Shellshock. And some of these vulnerabilities have been sitting in the code, waiting to be exploited, for years.
To some degree, the number of high-profile vulnerabilities illustrates how important open source software is to modern technology – and how it is growing. Gartner predicts that open source will be 80% of the Global 2000 code base by 2018.
And maybe we’re becoming more security conscious – there are more researchers digging into software to find the flaws.
Patrick Carey, director of product marketing at Black Duck Software, believes that the discovery of these major flaws actually shows that the open source model is working. Because not only are there many developers creating software, there are also many researchers testing that software for flaws.
But whereas with proprietary software you have the likes of Microsoft pushing updates and patches to you, with open source organisations need to take on the responsibility of monitoring what vulnerabilities are being discovered and what remedies are available.
Many organisation that are making use of open source frameworks and software packages are engaging in a leap of faith – trusting that it has been adequately tested and found to be secure. But Carey believes that organisations can, and should, be building a review of the risk profile of open source elements into their software development life cycle (SDLC) – and preferably in the early phases where open source components are being selected.
The necessary vulnerability data is out there – but it can be difficult to tap into, to track, and if organisations are doing it at all, they’re doing it via manual processes. Fortunately, there are efforts to aggregate it and present it in as easier to manage format. This is important because, if you don’t know what’s in your code, you can’t stay on top of the risks.
Employing open source solutions brings with it an issue that is generally not present in code that is fully developed in-house – the code is constantly updated and that may introduce new vulnerabilities. So even after your solution ships, you still need to monitor the open source components for new issues.
This is a community effort and – for those organisations willing to participate fully – not only can they safely leverage the full power of open source code, but when vulnerabilities are discovered, they will know exactly to what degree they are exposed and what they need to do to mitigate the problem.