Open Source Software in Defense: Policy, Security Risks, and Best Practices

The question of whether open-source software (OSS) is appropriate in defense systems was largely resolved in the 2000s and 2010s: the answer is yes, with appropriate management. The US Department of Defense's 2009 policy memo on open-source software was among the first formal statements that OSS must be evaluated on the same criteria as proprietary software — no blanket prohibition, no blanket preference, but case-by-case assessment. This permissive-but-managed stance is now effectively universal among defense procurement frameworks in democratic nations.

The current challenge is not whether to use OSS but how to manage it rigorously. Modern defense software typically incorporates hundreds of open-source components — operating system libraries, cryptographic libraries, networking stacks, data processing frameworks. The XZ Utils backdoor incident of 2024, in which a malicious actor spent two years building credibility in an open-source project before inserting a sophisticated backdoor, demonstrated that OSS supply chain risks are not theoretical. This article examines the current policy landscape, the real risk categories, and the governance practices that effective programs apply.

DoD and Allied OSS Policy: The Current Permissive-but-Managed Stance

The US DoD's current position on OSS is captured across several policy documents: the 2009 CIO memo, the 2016 Defense Innovation Board software acquisition practices recommendations, and the 2022 DoD Software Modernization Strategy. The consistent thread is that OSS is neither inherently more nor less secure than proprietary software — security depends on the specific component, the development practices of its community, and the governance applied by the consuming organization.

DoD programs are generally permitted to use OSS subject to: license review to ensure license terms are compatible with the program's distribution requirements; vulnerability assessment of the specific version being incorporated; and ongoing monitoring for new vulnerabilities in incorporated components. Some programs are subject to additional restrictions based on classification level, the sensitivity of the data processed, or specific contractual requirements.

Allied defense organizations generally mirror this approach. The UK Ministry of Defence's technology guidance permits OSS use subject to intellectual property clearance and security assessment. German Bundeswehr programs use open-source components extensively, particularly in infrastructure-level software, subject to BSI guidance on open-source security assessment. The alignment across allies is substantial enough that international programs typically do not face OSS policy conflicts between partners.

Supply Chain Risks: Typosquatting, Malicious Updates, and Abandoned Libraries

The OSS supply chain attack surface encompasses several distinct risk categories, each requiring different mitigation approaches.

Typosquatting. Attackers register package names that are close to popular legitimate packages — transitive misspellings, alternative spellings, or common typos. A developer who mistypes a package name installs malicious code instead of the intended library. Typosquatting attacks have been observed in npm, PyPI, and RubyGems and have targeted developer credentials, environment variables, and deployment secrets. Mitigation requires package name verification at point of installation and dependency lockfiles that pin exact package names and versions.

Malicious updates. A legitimate, widely-used package can become a vehicle for malware if its maintainers are compromised, coerced, or replaced by hostile actors. The XZ Utils incident is the most sophisticated example, but simpler cases — maintainer account compromise leading to a malicious version upload — occur regularly. Mitigation requires pinning specific versions rather than accepting latest-version updates automatically, verifying package signatures where available, and monitoring for anomalous changes in package behavior between versions.

Abandoned libraries. Open-source projects are frequently maintained by individual volunteers or small groups. When maintainers stop active development, the project may continue to be used by downstream software while accumulating unpatched vulnerabilities. The Log4Shell vulnerability affected a project with active maintenance; many real-world vulnerabilities affect components that have been effectively unmaintained for years. Mitigation requires tracking the maintenance status of dependencies and having a policy for replacing or forking unmaintained components that handle security-sensitive functions.

License compliance. Open-source licenses impose obligations on consumers. Copyleft licenses (GPL, AGPL) may require disclosure of derived source code — creating legal and security risks for defense programs that cannot disclose source code due to classification or competitive concerns. License incompatibility can also affect distribution to allies or contractors. License review must be systematic, not ad hoc.

OSS Approval Process: License Review, Vulnerability Scanning, and Provenance

Effective OSS governance in defense programs requires a defined approval process that every new dependency must pass before being incorporated into the codebase. The process should cover three areas.

License review determines whether the component's license is compatible with the program's intended use. This requires understanding the program's distribution model (internal use, delivery to a specific customer, commercial distribution), the license obligations imposed by each candidate component, and whether those obligations create conflicts. Programs that use components with incompatible licenses discover the problem at contract delivery or legal review — both expensive and schedule-impacting times to resolve.

Vulnerability scanning evaluates the specific version of the component being considered for inclusion against known vulnerability databases (NVD, OSV.dev, GitHub Advisory Database). The evaluation should cover not just the component itself but its transitive dependencies — the dependencies of the dependency — since vulnerabilities in transitive dependencies affect the incorporating system. Vulnerability scanning at point of inclusion is necessary but not sufficient; it must be repeated continuously as new vulnerabilities are disclosed.

Provenance assessment evaluates the trustworthiness of the component's development and distribution. This includes: the identity and track record of the maintainers; whether the project has a security disclosure process; whether releases are signed; whether the project's development practices (code review, testing, CI) provide reasonable assurance of intentional quality. A component with strong technical security properties but developed by unknown parties with no security disclosure process presents a different risk profile than a component with equivalent properties developed by a well-known foundation with transparent governance.

SBOM as an OSS Dependency Management Tool

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all software components in a system — including open-source libraries, commercial off-the-shelf components, and internally developed modules — with their versions, licenses, and dependency relationships. SBOM is increasingly mandated for defense software: US Executive Order 14028 (2021) requires SBOM for software sold to federal agencies, and allied nations are implementing equivalent requirements.

For OSS management specifically, SBOM provides two capabilities that are otherwise difficult to achieve at scale. First, it enables automated vulnerability correlation: when a new vulnerability is disclosed (e.g., a CVE is published for a specific version of OpenSSL), it can be automatically correlated against the SBOM to identify all programs that incorporate the affected version. Without SBOM, this correlation requires manual inventory — which is slow, error-prone, and unlikely to be performed consistently.

Second, SBOM enables license compliance monitoring across the full dependency tree, including transitive dependencies. Manually tracking licenses across hundreds of dependencies and their transitive dependencies is not feasible; automated SBOM tooling makes it manageable.

Effective SBOM programs integrate SBOM generation into the CI/CD pipeline so that the SBOM is always current with the actual deployed code, rather than being a point-in-time document that drifts from reality as components are updated. The SBOM format standards (CycloneDX, SPDX) are mature and tooling support is broad. There is no longer a technical barrier to SBOM adoption — the remaining barriers are organizational: prioritizing SBOM as a program requirement and allocating engineering capacity to implement and maintain the tooling.