If you're reading this with a healthy dose of scepticism, good. Security decisions deserve scrutiny - and open source gets more than its fair share of them.
Here's what's usually behind the concern: it's not really about technology. It's about accountability. With proprietary software, there's a vendor. Someone you can call. Someone whose job it is to make sure things work and stay secure.
With open source, the question feels more like: who's actually responsible here? And, how do I know that I’m safe?
These are rooted in accountability, trust and resilience - and they are valid concerns. So, let's answer it honestly, including where the reputation came from in the first place.
“If anyone can see the code, doesn't that make it easier to attack?”
On the surface, this seems very logical. But some of the world's most security-conscious governments have looked at this closely and landed somewhere different.
Take Estonia as an example. It built its entire government services infrastructure, X-Road(external link), on open source in 2001. In 2007, it faced one of the largest coordinated cyberattacks in history. That infrastructure stayed up. NATO's response was to establish its Cyber Defence Centre of Excellence in Tallinn(external link), recognising Estonia's approach as a model worth learning from.
France is another example. It’s national cybersecurity agency, ANSSI(external link), updated its policy in early 2026 to commit to publishing its own security tools as open source. Not because they had to. Because they concluded it made those tools more trustworthy, not less.
The US Department of Defense is another good example. It runs its own open source platform, Code.mil and publicly states that “the idea open source is less secure is a misconception(external link)”.
These are just a few examples of governments with everything to lose if they get security wrong. Their conclusion: visibility doesn't weaken security. More often, it strengthens it.
The reason is straightforward. Vulnerabilities can exist in any software, whether it is open or closed. What matters is how quickly they're found and fixed. Open source code can be reviewed by anyone, which means more people looking for and solving problems - faster. This is referred to as Linus Law(external link) – the many eyes theory. Essentially, for every person looking for an exploit, there is an entire community working equally as hard to prevent and patch potential exploits.
“How can it be secure if it’s just a bunch of volunteers keeping the software safe?”
The gap between that assumption and the reality is bigger than most people expect.
The words "volunteers" and "hobbyists" conjure a specific image: well-meaning enthusiasts coding in their spare time, nobody really in charge, no consequences if something goes wrong. If that were accurate, the scepticism would be entirely justified. You wouldn't run your organisation on software maintained by a loose collective of people with no accountability to anyone or a lack of visibility in how those ‘volunteers’ keep platforms resilient.
But that doesn't really hold up in reality. Sure, some contributors are volunteers. But most open source software and projects are backed by paid developers, commercial organisations, managed service providers, and formal foundations - all operating under governance structures that define who is responsible for what, how decisions get made, and what happens when something goes wrong.
Structured open source governance has existed since 1955, that’s before the internet existed. The SHARE user group began formally collecting and distributing free software with documented distribution dates. Open source community governance is over 70 years old(external link).
The Apache Software Foundation(external link) is one well-known example: an independent non-profit that oversees its own portfolio of open source projects. It covers over 290 projects used by billions of people and is formally sponsored by Amazon, Google, and Microsoft. Foundations like Apache exist across the open source world, each governing its own set of projects with the same rigour.
What this looks like day-to-day: when a developer contributes code to a well-run open source project, it goes through a documented review and approval process before anyone else can use it. Take Koha(external link), the open source library management system created in New Zealand two decades ago and now used in more libraries worldwide than any other library software. Before any code change ships, it passes through a patch writer, a signer, a QA team of twelve people, and a release manager. Every decision is logged and on the public record of who did what and when. The accountability is real.
“We don't have the internal expertise or time to keep on top of security. We just need something that is safe and works.”
The good news is that with open source, you don't have to. That work is already happening continuously and globally, by people with a direct interest in keeping the software safe. You benefit from it whether you know it's happening or not.
Here’s an example. A few years ago, Andrew Bartlett, a Wellington-based developer and one of the world's leading experts on Samba which is the open source software that connects Linux systems with Microsoft Windows networks, noticed something that felt off. A small detail in how computer account names were handled didn't sit right with him. He sat with it.
Working through the implications, he realised the detail pointed to a serious flaw in Microsoft Windows(external link), specifically in the system that controls who is allowed access to what across corporate and government networks. He raised it with Microsoft - initially they said it was by design. Andrew kept digging. His Catalyst colleague Jennifer Sutton built a fully working exploit that proved exactly how serious it was - any normal user account could be used to take over an entire organisation's network.
What followed was six months of careful, coordinated work between Catalyst and Microsoft's engineers to make sure the fix was properly built and tested before anyone outside knew it existed.
Open source specialists (external link)and managed service partners have a deep curiosity to notice what others miss, and the integrity to see it through – even if it isn’t on the open source project they are responsible for. Knowing where to find that expertise, and how to make it work for you, is where a good open source partner(external link) comes in. They can:
- do the heavy lifting for you when it comes to resilience,
- give you one point of contact to work with the entire community,
- track security advisories and the wider open source ecosystem,
- proactively patch, test and roll out fixes,
- contribute back where appropriate, strengthening the commons that their customers rely on.
“If all of the above is true, why do people still say open source isn’t secure?”
Open source's security reputation has real roots. In the early days, many projects were informal, inconsistently maintained, and some lacked the governance structures that good software requires. Some smaller projects still do. The concern wasn't invented.
But here's a telling indicator of how that picture has changed: the world's largest software companies have spent billions acquiring open source projects over the past decade. Microsoft bought GitHub(external link) (the platform that hosts the majority of the world's open source code) for $7.5 billion. IBM acquired Red Hat(external link), one of the biggest open source businesses in the world, for $34 billion. Google has poured resources into Kubernetes(external link), now the global standard for running software at scale. These aren't companies that take security lightly. They aren't investing at that level in something they consider a liability.
The early reputation simply hasn't kept pace with where open source actually is today. Which is exactly why it's worth asking the question.
Solutions to improve digital resilience
Real resilience means knowing what you're running, understanding what went wrong when something breaks, and being backed by a trusted technology partner if you don’t have the expertise in-house. Real accountability means knowing what’s happening, by whom and why. Together, those are where real trust in your technology can be found.
We've been helping New Zealand organisations ask better questions about their digital resilience since 1997, and are backed by a worldwide open source community and cloud infrastructure built and operated right here in Aotearoa.
Our team are happy to answer any questions(external link) you may have about open source security and how you can improve your digital resilience.
