CISA gives OSS equal footing with proprietary code
The guidance tells agencies to stop treating open source as an exotic risk category, the same supply-chain principles apply, and OSS has the advantage that you can actually read the code.
TL;DR
CISA published "Open Source Software: Security Principles and Practices" on July 30, giving federal agencies a lifecycle framework for using, evaluating, contributing to, and publishing open source software. The guidance aligns with Biden's EO 14144 and Trump's June 2025 EO 14306. The headline move: CISA explicitly states OSS carries no more or less risk than proprietary software, the distinction is that with OSS, agencies can directly assess code quality instead of relying on vendor assurances. That's a quiet but significant policy signal after years of agencies treating OSS as inherently suspect.
The guidance marks the culmination of CISA's open source roadmap work that began with the 2023 OSS Security Roadmap and continued through the 2024 OSS Security Summit. But it's the framing that matters here more than the mechanics.
"It is important to recognize that OSS is not inherently more or less secure than proprietary software," CISA writes. "The key distinction is that, with OSS, agencies can directly assess code quality and security, rather than relying solely on vendor assurances." That sentence alone does more work than most federal guidance, it reframes OSS from an exotic threat vector to an asset whose transparency is itself a security control.
The guidance introduces the C4 Framework for trust assessment, covering four dimensions: Code, Community, Contribution, and Consumption. It walks agencies through evaluating OSS project trustworthiness, tracking OSS in asset inventories, and following established patching principles. A substantial section covers agencies as OSS producers, CISA urges a "default open source" approach for custom-developed code, maintaining source code inventories, and securing government reuse rights for contractor-developed software. There's also a section on evaluating open source AI models, reflecting OSS's entanglement with emerging technology.
What the guidance doesn't do is carry explicit enforcement teeth. No compliance deadlines. No audit criteria. No CISO reporting mandates. It's advisory, grounded in existing secure software development frameworks like the SSDF, but not tethered to any specific enforcement mechanism. Agencies that already have mature software asset management and SBOM processes will find this a useful overlay. Agencies that don't will find it aspirational.
The open question is whether CISA's posture (OSS risk parity with proprietary software) gets absorbed by the acquisition workforce or ignored in favor of institutional OSS aversion. The guidance gives program offices the document they need to push back on procurement defaults that treat open source as a liability. Whether they use it is another matter.
Published ·Deep Fathom