The stimulation of development and adoption of Open Source Software (OSS) is a recurring recommendation in security and privacy discussions. The rapid growth in Internet has created the prerequisite for in numerous OSS development communities and widespread use. The collaborative effort of those communities has enable alternatives for almost all proprietary (also known as closed source) software.
From a security & privacy perspective the attractiveness of OSS lies mainly in the openness of the source code: anyone can review it and propose a fix for any problems encountered. The drive to publish found vulnerabilities is not hampered by fear of reputation of the vendor and in fact publishing is encouraged. But please note, major open source applications might also have ‘owners’ with reputations to protect!
According to Anderson, vulnerabilities found by a vendor might be withheld from the public, because they are provided to their government for exploitation. Only until outsiders (e.g. other governments, cyber criminals) start exploiting it too, the vendor starts shipping patches. In this sense, OSS and the way it is supported by communities (code checking / review) can help finding and removing and even preventing backdoors enabling massive surveillance in widely used software.
Besides this, OSS also has the potential to decrease Europe’s technological dependence on especially U.S. vendors, with all accompanying advantages in terms of security & privacy. Investing in European OSS instead of in licenses of US vendors can stimulate the European software industry for billions of euro’s.
Bias, bias and statistics
But how secure is OSS when looking at the facts? Discussions around OSS tend to be determined by the bias of the participants however, even if empirical data does not justify claims. In most studies found, empirically no significant differences in security between open and closed source software appear. Although in some cases the researcher finds empirical results that argue that “compared with closed source software, vulnerabilities in open source software: (a) have increased risk of exploitation, (b) diffuse sooner and with higher total penetration, and (c) increase the volume of exploitation attempts.” The level of (absence) of vulnerabilities therefore seems not to be the primary reason to pitch for OSS as security measure.
It’s the process, stupid!
It is not the difference between open and closed, that determines the level of security, but much more the quality of the lifecycle management process. The OSS lifecycle management process with its openness and communities has its advantages, but also its challenges, for which some level of support might be in order.
Challenges and key players
The development and maintenance (the lifecycle management process) of OSS meets a number of challenges that need to be addressed:
- The quality of review process depends heavily on quality (to read and write secure code) and availability of volunteers in most cases. These volunteers might work for companies, paid to support the OSS. But often they are truly (unpaid) volunteers, attached to the OSS, because they use it themselves.
- OSS in more exotic programming languages, or niche or rarely used applications, might not attract a community large and/or expert enough to maintain the application and its security. Even widely used OSS like (once) Truecrypt or OpenSSL have fairly small support communities, that require support in terms of extra volunteers or funding to maintain their work.
- Reviewing and testing code can be boring. For many developers it’s much more attractive to (just) fix what annoys them in the software. This might work out slightly different for commercially distributed OSS, where above average rigorous maintenance processes are deployed because the vendor has a (usually limited) liability for its products and a reputation to protect
- As mentioned above, an attacker doesn’t necessarily need the code to find vulnerabilities. Like closed source, OSS also benefits from penetration testing.
- Distribution of fixes and feedback of found vulnerabilities to the developers are crucial. Likewise the installation of fixes on end-user devices of course, but this is quite similar to closed source (assumed that the OSS in question has a user friendly, automatic update mechanism).
Conclusion and recommendations
OSS is an important ingredient in a strategy in which security and technological independence are important for the EU. The quality of the support processes of OSS is crucial for its security though and those support processes face challenges that cannot be solved without outside funding or other support.
Concrete recommendations include:
- Support and fund important OSS: Open source initiatives, some of them widely implemented in very important systems, like OpenSSL, Truecrypt, GPG etc need funding to keep going and be audited. Heartbleed r and other incidents can be detected earlier with auditing and checking code.
- Support (European) open source soft- and hardware. TrueCrypt is a typical example of a problem of the commons: worldwide use dependent on 2-3 developers In the case of Tor, government and other parties are investing, but governance is independent. Initiatives like OwnCloud need support to work on several platforms (also mobile), and need further development to ensure user adoption.
- Promote Secure Software Development guidelines for all sorts of open and closed software. This should include distribution (to and from developers and to end-users).
- Certification schemes for specific critical types of OSS, potentially supported by technical tests (e.g. penetration tests) should be considered. A recommendation supporting this would be to set up an agenda of critical OSS for Europe.
Want to comment on this post? Please do!
This blogpost is based on early results of a study into mitigating the security and privacy risks of massive surveillance for European citizens. This study is being executed by order of the European Parliament (STOA / LIBE committee). Comments can be used as input for this study. Leaving a comment is considered to be a conscent for use of comments as input.