)
Security is a significant part of the job of any Open Source maintainer – including mine. I work on the OpenStack Vulnerability Management team because I believe that managing the process of identifying, fixing and announcing vulnerabilities genuinely matters. But when I look at where time and money (and increasingly, LLM tokens) get spent – in companies and in open source projects alike – it’s overwhelmingly reactive. We triage CVEs. We chase vulnerability reports. We generate whatever artifacts, or features, an auditor asks for. Prioritizing this reactive security work is rational; but it’s only part of the job.
Where security investment actually goes
There are two large blind spots with security revolving around these processes that require investments of time and energy.
First of all, they tend to focus on the project’s code and the project’s paperwork – which may not address the security needs of a user deploying an entire stack. No software runs in a vacuum – there’s an entire platform of tools supporting it and configuration. For OpenStack, this might include virtual networking tools like OVN or hypervisors like KVM – and the operating systems they run on. A code-focused security audit may not, for instance, know if you’re running a vulnerable version of KVM, or have configured a service in an insecure manner.
Secondly, it’s anchored to a single, specific use case – whoever is performing the security audit has to assume a persona or use case at the exclusion of others. Many times this reactive approach to security leads to something that can be considered “secure,” but may still be missing one critical question an operator has when they’re configuring the software or reading an advisory: “How much of this impacts my environment?”
Passing an audit tells you a snapshot of the code, running under a specific configuration, cleared a bar. Closing a CVE tells you one known hole is patched. Neither tells an operator whether their configuration – their network layout, their auth choices, their trust boundaries – makes sense for their environment. That’s the holistic view, and it requires deeper knowledge of architecture than any single project in your technology stack can provide as an upstream. Only the operator can assemble the pieces of their system together to see from this level.
There’s a clear separation of responsibilities here: an upstream open source project provides a software that is secureable, but the operator is responsible for following directions and configuring the environment properly to ensure safety.
This means we can only make software that can be secured, rather than “secure” being a property of a software project. As a project maintainer, that means I have to think about use cases beyond my own.
A flexible posture is only useful if it’s written down: operators need a documented security model that tells them what the project protects against, what it doesn’t, and where the knobs are to make adjustments. Being explicit helps insure that people know why decisions were made, and where there are opportunities for improvement.
It’s not the project’s job to pick your threat model
Here’s the part I think is under-appreciated: it is not an open source project’s job to choose or dictate a threat model for its users. That is ultimately the responsibility of the individual deployer.
Take Ironic. You can deploy it as part of a full OpenStack cloud – Keystone auth, TLS everywhere, network isolation via Neutron, RBAC via Keystone – a full multi-tenant isolated cloud. You can also deploy it in an isolated, sterile environment: like a lab with no auth, an isolated network and just one admin provisioning their own hardware. Both are legitimate, supported use cases, and they have wildly different security requirements and concerns.
If the project decided only the paranoid configuration was acceptable – secure-by-force, not just secure-by-default – it would be making a risk decision on behalf of operators it knows nothing about. The lab admin doesn’t need multi-tenant isolation. A CI environment doesn’t need TLS between two processes on a loopback interface. Forcing your security model on all users doesn’t make those users more secure; it makes the software harder to use, and it trains people to work around security features – which can be worse than not having security features at all.
Some operators are fine with less security, or none. That’s OK – as long as those operators understand and accept that risk. And there’s the catch: you need information to accept a risk. Which brings us to project documentation. Operators should have clear information at hand – even in the example config files directly – about how each option they change impacts their security stance.
The project’s job:
- Ship reasonable, secure defaults for the common cases
- Keep insecure configurations possible, but explicit – an operator should have to choose them
- Document the security model: what each component trusts, what each interface exposes, what assumptions each configuration makes
The operator’s job:
- Read that documentation and map it onto their environment
- Choose configurations deliberately – including the insecure ones
- Own the resulting risk decisions and take responsibility for their outcomes
Creating detailed, quality project documentation around security modelling and use cases can reap benefits beyond just informing an operator about risk. For instance, it can help properly set the scope for security issues being reported – by documenting risk and known workarounds we provide clear expectations for security researchers. LLM tooling raises the stakes: an LLM has no industry experience, no unwritten context. If our docs assume knowledge of bare-metal norms, an LLM consuming them won’t fill the gap – and neither will the operator relying on it. As a result, security documentation must be explicit enough for someone without that foundation.
Conclusion
Security is a cultural aspect of open source communities. It’s not a property of code or the state of having zero open CVEs. A project cannot be “secure” in the abstract – it can only be securable and honest about its limitations. A community can be “secure” by understanding, prioritizing, and promoting security work – encouraging contributors to consider use cases beyond their own.
The invisible work of writing the documentation to allow an operator to make informed decisions around security, is load-bearing infrastructure for open source as well. Only by working to invest in open source in the long term – not chasing fads or CVEs – can we break the cycle of reactivity. Let’s do it together.
For more insights from Jay Faulkner or other G-Research Open Source Software engineers please check out our YouTube and the GR-OSS OUT Podcast.
- Do the invisible security work, too - August 13, 2026
