Greater security can be obtained with transparency
As federal agencies race to modernize, adopting zero trust architectures and cloud-first policies, one foundational truth is becoming harder to ignore: free and open source software (FOSS) isn’t a risk — it’s a requirement for real security.
More than a decade ago, the Department of Defense (DoD) made this clear in its FOSS guidance. It wasn’t just a legal green light — it was a strategic signal. In today’s cybersecurity landscape, with escalating supply chain threats and mounting pressure for transparency, that message is more relevant than ever.
Transparency Is Security
A persistent myth in government IT says public code is dangerous because it’s visible. But security through obscurity is a fallacy. If no one can see a system’s weaknesses, no one can fix them — often not until discovered and exploited by an attacker.
Open source flips that dynamic. As the DoD noted in their own FAQ: “Continuous and broad peer-review… improves software reliability and security.” Visibility invites inspection, audit, and rapid patching. That’s not a vulnerability. That’s how trust is earned.
Zero Trust Demands Visibility
The federal government’s zero trust strategy is rooted in verification, not assumption. Every system component must be continuously evaluated.
FOSS fits that model. Unlike proprietary software — often a black box — open source is inspectable by design. Teams can evaluate risks in real time, monitor dependencies, and ensure compliance. If you can’t see it, you can’t secure it.
The Supply Chain Runs on Open Source
Recent breaches like SolarWinds and Log4Shell made one thing clear: almost all modern software — proprietary or not — relies on FOSS components. Indeed, the “2025 Open Source Security and Risk Analysis” report that examined over 950 codebases across 16 industries found that 97% of the codebases contain open source.
That’s why Software Bills of Materials (SBOMs) are now essential. SBOMs list all components and origins in a software package. FOSS projects that publish SBOMs, sign releases, and follow best practices are often easier to evaluate than commercial tools whose inner workings are hidden.
Without an SBOM, a product is a security gamble. With FOSS, agencies can see everything — every dependency, every contributor.
To support this shift, the Open Source Security Foundation (OpenSSF) has developed the Best Practices Badge Program and a Project Security Baseline maturity model to help agencies identify which projects are investing in secure development, responsible disclosure, and community-driven resilience.
Government Must Support What It Uses
Using mature FOSS is not enough. Agencies must invest in its resilience.
That means contributing to the security of FOSS projects they depend on — through funding, audits, or patches. The DoD’s Code.mil platform embodied this logic: software built with public money should be reusable, improvable, and inspectable by the public.
Security is not a product. It’s a process. And that process improves with every good faith contributor.
What Agencies Should Do Now
- Update outdated FOSS policies that treat open source as inherently risky.
- Require SBOMs for all procurements — open or closed source.
- Evaluate FOSS based on practice, not myth — look for mature projects with active communities and documented security processes.
- Default to open when developing custom code unless national security prohibits it.
- Contribute to (at least some of) the projects essential to the Agency’s mission — FOSS is freely available, but it takes effort to create and maintain.
Conclusion: Open Is the Safer Bet
The old narrative painted open source as a liability. Today, it’s the opposite. FOSS is aligned with zero trust, empowers teams to audit and respond rapidly, and enables shared defense.
The DoD understood this years ago. It’s time the rest of the government caught up.
In cybersecurity, opacity breeds risk. Openness breeds trust.