Debunking myths about open-source security

In this Help Net Security interview, Stephanie Domas, CISO at Canonical, discusses common misconceptions about open-source security and how the community can work to dispel them. She explains how open-source solutions, contrary to myths, offer enterprise-grade maturity, reliability, and transparency.

Domas also shares key factors organizations should prioritize in open-source adoption to enhance security and balance innovation with stability.

What are the biggest misconceptions about open-source security, and how can community members and professionals work together to dispel them?

There are three main misconceptions about open-source security that stand out to me. These are that open-source security software and technologies aren’t mature enough to be enterprise-grade, that they’re less reliable, and that they’re “too open to be safe.”

For much open source, this couldn’t be further from the truth. Mature open-source software has robust quality processes akin to any proprietary software: we’re talking timely patching schedules, robust long-term support often reaching 10 or 12 years, mature roadmaps, and large, active communities that constantly improve the performance, features, and functionality of the software.

The maturity perception is a sore myth in professional circles. If open source weren’t reliable, we wouldn’t see 90% of organizations using open source and 99.9% of all software codebases containing open source code. The supply-side and demand-side values of open source are phenomenal: a paper I was reading recently estimated that on average companies would need to spend three and a half times more on their software development if open-source software didn’t exist.

And finally, the idea that transparency of source code is a negative for cybersecurity is plainly false. Security through obscurity is universally considered a poor strategy. I’d go even further to say security is enhanced by more eyes on code, and having your codebase scrutinized by thousands of people who have a passion for finding problems is a pretty great path to safer code.

I think software professionals at large need to take the time to understand the open source landscape, recognize where it has enterprise-grade maturity, and acknowledge the unique value proposition of transparency to domains such as security. Not all open source is created equal, but there is a lot of open source that is just as resilient, tested and featureful as proprietary offerings. We need to tell more stories about how open source software changes lives and revolutionizes businesses if we want to get more adoption at the enterprise level.

What qualities should organizations prioritize in an open-source environment and package management solution to strengthen security?

I think the strongest qualities you can look for in your open source environment and package management solution are a minimal attack surface, its degree of interoperability, and evidence of security maintenance and maturity.

A minimal attack surface is an obvious need: you want your security tool to present as few vectors and opportunities as possible to attackers. However, given that threats are evolving all the time, CISOs are constantly exploring new tools and technologies to combat them. The last thing you want is to pick a specific framework, stack or vendor only to be locked into that decision because of a years-long contract or a massive migration that eats up all of your developers’ time and resources.

Interoperability is also important – not just because you want your tools to play nicely together, but also because you want to secure the entire stack as a single entity, rather than securing lots of smaller pieces, packages and libraries. Poorly configured connectors, APIs and operators aren’t just the glue holding everything together, they’re also a crack for bad actors to try to break through.

Lastly there’s security maintenance and maturity. This is a little tricky because there’s no one obvious thing to look for, but rather it’s the sum of the project parts. Some of these parts include: coordinated vulnerability disclosure programs, an active codebase with active maintainers, bug tracking systems, robust documentation and clear security patch commitments.

Many CISOs express concern about open-source vulnerabilities. How can security leaders balance innovation with security when incorporating open-source technologies?

I’m not surprised by that, given how much of a tough balancing act that can be. One thing I will point out is open source is not inherently more likely to have a vulnerability than proprietary code. However, with open source you will know about it. I’m a believer that information is power, and I can better control my risk posture if I understand the risk of the things I’m using, but of course there are valid concerns to be had about the public nature of open-source vulnerabilities. The key with responsible consumption and maintenance of open source is that leaders must closely consider their adoption plans and make intentional, well-researched decisions from there.

The first consideration is to be really intentional and thorough with your chosen license type – preferably after spending some time with your legal team hashing out your options. Defining clear policies for license types is a great first filter, and helps to combat the feeling of being overwhelmed by options. For this reason I always recommend that CISOs create a clear and uncomplicated Open-Source Software internal strategy document that outlines what open-source software you currently use, what licenses you work with, what use cases and criteria you accept and what limitations there are.

The next consideration is to ask how much support you need for this tool, and whether this tool offers that support. Is a community-best-effort model enough? Or do you require a more formal support structure, and how large should that community of supporters be? This tends to be a good baseline for adopting a tool that will enjoy growth across its lifecycle, instead of falling victim to a hype cycle and becoming abandoned.

There is often a tradeoff with innovation and stability: do you want to consume the cutting edge, knowing it might still have bugs, or consume stable releases? It likely depends on your use case. But you must be intentional about it, and make sure you don’t get the wrong type of solution for your situation.

What recommendations do you have for organizations regarding setting up vulnerability disclosure and reporting mechanisms in open-source projects?

The number one recommendation I have is that they should create a clear and easy-to-understand reporting policy document. Make it clear to the community and users where to go to learn about the current security posture of a solution, as well as where to report security concerns. It’s also critical to have pre-established decisions on who is responsible for communicating what, when, where, how and in what time limit is vital.

Could you share any recent trends in open-source security that professionals should keep on their radar in 2025?

I have a particular interest in confidential computing as a very fascinating technology that has big security implications. Confidential computing enables data to be encrypted while in use, and while broadly this is interesting, it also has the potential to significantly impact AI. AI has been massively popular, and as more people build more exciting projects and tools with AI, the next considerations will inevitably be “how do I deploy AI models and keep them secure?” and “How can I train AI models on shared data while maintaining privacy?”.

AI represents a leap forward for developers, but also for malicious actors – our next generation of cybersecurity practices should be prepared for this new era in vulnerabilities and exposures, and I think confidential computing is a powerful response to that need.