IN Brief:
- MOSA enables defence programmes to reuse modular software and integrate new capabilities more rapidly across platforms.
- SBOM visibility, provenance checks, security testing, and hardening are critical to managing vulnerabilities introduced through shared components.
- Common security gate criteria can help prevent reusable software from creating systemic risk across autonomous and ISR programmes.
Joseph M. Saunders, Founder and CEO of RunSafe Security
The FY 2021 and FY 2025 National Defense Authorization Acts (NDAAs) strengthened the Modular Open Systems Approach (MOSA) by expanding statutory requirements for modular interfaces, data rights, and public standards, making open architecture a more enforceable acquisition norm.
For uncrewed and autonomous systems, this shift is consequential. ISR and autonomous platforms built on open architectures can integrate new sensors, updated autonomy frameworks, and emerging AI capabilities without waiting for a new program of record. Life-cycle costs drop when components can be swapped rather than replaced wholesale. Interoperability improves when systems share common interfaces rather than proprietary ones.
However, the security implications of that shared foundation have to keep pace with the acquisition policy itself.
MOSA’s efficiency depends on reuse. Software modules developed by a prime, a subcontractor, or the open-source community become building blocks across multiple programs. That is the design intent. But each time a component crosses a trust boundary, it carries whatever vulnerabilities, provenance gaps, or unverified assumptions were present when it was built. A compromised or poorly hardened module reused across ten programs does not create ten isolated problems but creates one systemic vulnerability embedded across the force.
Visibility Comes Before Verification
Autonomous and ISR programs can be particularly exposed. The AI and autonomy frameworks powering these systems are often updated frequently, deeply integrated into mission-critical logic, and may combine proprietary, government-developed, and open-source components. With a large attack surface, the consequences of a compromised component are spread across platforms or missions.
What programs need is visibility into those components to reduce security risks. Software Bills of Materials (SBOMs) give program offices the baseline inventory they need. SBOMs often include information on the components in the stack, where each originated, who built it, and its verification history. Without that visibility, security assessments are incomplete by definition. SBOM requirements are increasing as software supply chain risks escalate. Adversaries have demonstrated sustained interest in embedding access through software components that reach operational systems long after initial compromise.
SBOM visibility is necessary but not sufficient. Knowing a component exists in the stack is different from knowing whether it meets the program’s security requirements. Verification requires active assessment: testing against known vulnerability classes, reviewing provenance documentation, and confirming that hardening has been applied before integration rather than flagged as a remediation item afterward.
Trusted Frameworks Require Common Standards Across the Ecosystem
The distributed nature of MOSA supply chains is what makes common security standards essential. Primes, subcontractors, and open-source contributors do not operate under the same development practices, testing regimes, or security cultures. A module that meets one contractor’s internal standards may carry unmitigated vulnerabilities or undocumented dependencies that introduce risk that the receiving program is not positioned to detect.
Trusted frameworks for reuse require gate criteria applied consistently across contributors. Documented provenance, evidence of security testing, and hardening against vulnerability classes relevant to the operational environment should be conditions for entry into the shared ecosystem, not items addressed after integration is complete. For AI and autonomy components specifically, programs need to understand not just what a module does, but also the assumptions that govern its development, the data it was trained or tested on, and the behaviour it may exhibit under conditions outside that envelope.
Safeguarding modular ecosystems across primes and subs means treating the software supply chain as a shared attack surface rather than a collection of separate vendor relationships. That requires coordination on standards, shared visibility into component provenance, and the organisational will to enforce gate criteria even when schedule pressure pushes in the opposite direction.
The agility MOSA promises is real, and the operational case for open architectures in autonomous and ISR systems is strong. Realizing that promise without creating systemic software risk requires treating security verification as a structural feature of the modular ecosystem, built into how components are developed, shared, and integrated across the programs that depend on them.
Open architectures are only as trustworthy as the components inside them.
This article originally appeared in the March/April 2026 edition of IN Defence. Read the full issue here.
