At Catalyst, when pitching our open-source offerings against proprietary options, we often encounter the well-trodden myth that “Open source software (OSS) is less secure.” I don’t feel the need to bust this myth here, as this has already been done well by others, and is self-evident in its use by governments, large corporations, NGOs and literally every computing device you have in your home. Even proprietary systems like Windows and MacOS have open-source components.
Instead, I’m going to talk about how an open-source project stays secure. It might seem that with the code being open it’s easy to find and exploit issues, but if we know that isn’t the reality, what do open-source communities have in place to prevent this?
Peer Review
When contributing changes to an OSS project, you have the opportunity to change the way that the software works. Potentially, a malicious contributor could introduce intentional flaws in the software that render it vulnerable to attack. Bugs leading to security breaches could also be introduced through the carelessness of an inexperienced developer. This is no different from a proprietary software developer doing the same, but in OSS, your pool of potential contributors is much wider and new contributors come and go all the time.
The key difference in OSS is that these changes happen in public, and are therefore subject to public scrutiny. Well-managed OSS projects will have a formal peer review process whereby each change is reviewed by another developer, who can identify problems and suggest changes before it is integrated.
In the case of Moodle, the review process has 2 stages. Firstly a peer review is performed by any member of the community, who offers their feedback based on a standardised checklist. Once this review is passed, a second integration review is performed by one of the core Moodle maintainers. This helps ensure that the code is of high quality, has fewer bugs, and vulnerabilities are less likely to slip in unnoticed.
Moodle’s integration workflow
Responsible Disclosure
When a security issue is found, the obvious thing may to be tell everyone about it. After all, we’re developing in the open. However, this often plays into the hands of the attackers; If we publish details of a vulnerability as soon as it is known, it may be exploited before users have a chance to deploy a fix or mitigation.
Under a process of responsible disclosure, security issues are reported privately to a trusted group of maintainers within the project. The issue is then triaged to assess its severity. If it is deemed to be a serious issue, it will then be kept private while a fix is developed, and a release prepared. It is only at the time that the fix is released that details of the issue are made public. This minimises the time between attackers gaining the knowledge to exploit the issue, and users being able to patch their systems.
In Catalyst’s case, our status as a Premium Moodle Partner gives us access to details of security issues and their fixes before they are public. This allows us to ensure our clients’ systems are patched before they even know there was a problem. It even allows us to be the ones to develop the fix.
Bug Bounties
In order to further incentivise responsible reporting of security issues, many OSS projects run a bug bounty program. This allows researchers who discover an issue to claim a financial reward. While it may appear more lucrative for a researcher to sell knowledge of an exploit to someone who wants to use it for malicious purposes, bug bounties offer a safe and legal way to profit from this work.
Global Oversight
A successful open-source project will have contributors from all over the world, using the software in a variety of contexts. A critical security issue reported by someone about to go to bed in Australia can be picked up by someone starting work in the UK. I’m not making that example up, in Catalyst and the Moodle community, that’s how we work!
Catalyst 24/7 follow the sun support
Conclusion
Next time you hear a colleague, manager, or salesperson pedalling the same tired old myths about open source security, you can now say with confidence why they are not true. Don’t let security concerns prevent you from choosing the open-source solution that’s best for your organisation.
