With ransomware attacks and security breaches impacting organisations globally on a regular basis, security is very much front and centre of every CSO’s agenda. Known vulnerabilities like Heartbleed and the SMB vulnerability exploited in the WannaCry ransomware attack brought many organisations to their knees, causing panic and chaos.
According to Telstra’s 2017 Cyber Security Report, almost 60 percent of surveyed organisations in Australia detected a security incident on at least a monthly basis in 2016. The Telstra report stated seeing increases in security risks across the board with more than half of all businesses experiencing a ransomware attack last year.
With open source software (OSS) gaining popularity among organisations, there is inevitably discussion around the security of OSS, with most people simply wanting to know: “is open source secure?”
Given how much code gets approved for inclusion in open source projects, and the huge community of developers contributing to open source applications, it’s useful to first address what steps are in place to prevent malicious code being injected into widely distributed applications.
Preventing malicious code
The way that open source projects are managed actively works against the inclusion of malicious code. Firstly, the fact the source is open and available to be audited by a large audience means there is much more likelihood of finding deliberate attacks than in closed source. Security checks, such as source code audits, and a community of researchers are there to identify open source vulnerabilities. It was an independent researcher who recently discovered four security holes in OpenVPN. Malicious code would have to be carefully hidden – without leaving trace that it is being hidden – to avoid detection. Obscure code immediately attracts attention.
The second factor is that major open source projects operate in a community where reputation is the critical factor: simply submitting code is not necessarily enough to have it included in the main codeline. The author must be known to, and trusted by, the project maintainer. It's human nature that when a new programmer joins a project, his or her code will be vetted more carefully than already-known contributors. Establishing and maintaining a high reputation requires significant effort, so lends against the rapid or repeated insertion of malicious code.
In contrast, closed-source code is not open for wide review by a large audience, and simply requires a disgruntled employee or the instruction of some agency to add the malicious code.
Rigorous testing It’s important to consider what testing is done with open source software before it is released into the community. Testing varies from project to project so in this sense “open source” is not a homogenous group with identical policies. One of the features of the open source community is the rapid turn-around and release of projects.
For a major project, there may be several different versions of software available at once. For example, a ‘stable’ release, a ‘development’ release and a ‘nightly build’. A stable release can be considered to have gone through the most amount of testing. A development release is a version that developers and testers are working on. A nightly build is a version of the code that has the latest changes integrated and is almost certainly still buggy. Of course, with commercial open source organisations like SUSE, only stable versions are released.
Since this is open source, it is the community itself that does the testing. The community may include commercial organisations, but also includes researchers and hobbyists. Users of open source software have to decide what level of comfort they have for possible bugs when they choose which version to use. One of the biggest contributions non-programmers can make is to try development release software and report back any problems. Again, the potentially wider audience you can achieve means this phase can be more effective and faster than in any proprietary software (the ‘crowd source’ effect).
Hobbyists and non-programmers may only be able to investigate to a certain level but commercial organisations and researchers can perform more involved tests. For example, when commercial open source organisations contribute changes – either as new product features or patches – the software goes through a QA team to test functionality, stability, scalability and for regressions including vulnerabilities, as well as integration testing with partners. There’s generally a heavy use of testing automation and a lot of effort goes into maintaining and refining automated methods. In addition, this rigorous process also relies on individual expertise to review results and find errors.
Confidence is key
At the end of the day, for any software – open source, closed source or embedded – it’s a question of confidence. The attractive thing about open source is there is potential for a much higher degree of confidence than with closed source. It is much harder to hide mistakes, much harder to secretly introduce malicious code and much more likely a programmer wanting to make a name for him or herself will discover (and fix) problems when the source is open and available for review.
Ultimately, if the users of open source software want to perform rigorous and exhaustive examinations of code, they can. The option is not even there for closed source software.