The Department of War's Call for Solutions on AI-enabled coding capabilities (CDAO_26-01) arrives at exactly the right moment. Today's AI coding assistants have moved beyond experiments in productivity to becoming the basis for how modern software is built. The DoW is right to close the gap with the commercial sector, and the Call for Solution's emphasis on security, data handling, and IL5 compliance reflects a clear-eyed understanding of what defense-grade deployment requires.
There is, however, a structural risk embedded in the initiative that no IDE plugin or CLI agent can resolve on its own. This isn't a limitation of any specific vendor, but rather an inherent characteristic of how AI coding tools operate. It's also one that grows more significant as adoption scales.
The Dependency Problem at Machine Speed
Every AI coding assistant, regardless of the model behind it, recommends open-source dependencies. Those recommendations are grounded in training data, a static snapshot of the ecosystem as it existed when the model was trained. They're not grounded in the live state of public registries, where the threat landscape changes daily.
Sonatype's 2026 State of the Software Supply Chain research puts measurable shape to this gap. Across 36,780 dependency upgrade suggestions generated by leading AI coding tools, 27.8% pointed to versions that were non-existent, deprecated, or unsafe. Nearly one in three recommendations was wrong. Not in a way a compiler would catch, but that could introduce a build failure, a known vulnerability, or a dependency that has been deliberately substituted by a malicious actor.
This isn't a model quality problem that future training runs will eliminate. Public registries publish thousands of new components every day, including malicious ones. Sonatype's research team has documented more than 3,300 new malicious packages appearing in ecosystems like npm and PyPI every 60 days. When an AI agent recommends a dependency, it has no mechanism to distinguish a legitimate package from a typosquat published last week.
What IL5 Authorization Actually Requires
The Call for Solutions establishes Impact Level 5 authorization as a non-negotiable baseline. What this means operationally is that every component entering the enclave must be defensible to an ATO reviewer, a program manager, or an oversight body. The intake control function is not a nice-to-have; it is an architectural requirement.
The challenge is that the security tooling most organizations rely on for this has a well-documented limitation. In 2025, 64% of open-source CVEs were published without CVSS scores by the National Vulnerability Database. Policies structured around blocking NVD High/Critical findings are, by definition, working from an incomplete signal. In a commercial context, that is a risk management trade-off. In an IL5 environment, it's an audit exposure.
The ML pipeline risk compounds this. The DoW's developer population includes data scientists and ML engineers who work heavily in Python ecosystems, including PyPI, Conda, and increasingly Hugging Face. Malicious actors have documented targeting these pipelines directly: trojanized model files, poisoned training datasets, and typosquatted utility packages. Traditional application security tooling was not designed to cover this surface.
The Layer That Has to Be There
What AI coding tools lack, and what must exist in any credible IL5 deployment architecture, is a policy enforcement layer that operates independently of the AI tool itself. One that evaluates components against live registry intelligence before they enter the pipeline, enforces security and license policy automatically at every build stage, and produces the continuous audit evidence that modern authorization frameworks demand.
Sonatype Repository Firewall performs real-time behavioral analysis of every new component published to a public registry, quarantining known malicious packages and flagging suspicious ones before any developer or AI agent can reference them. To date, it has prevented nearly 3 million malicious downloads. This intake control function extends beyond traditional package ecosystems to Docker container images and Kubernetes deployments, the containerized workflows central to Platform One and Iron Bank.
Sonatype Lifecycle enforces policy-as-code across the full development lifecycle, from IDE to CI gate. Its Reachability Analysis distinguishes vulnerabilities in the execution path from those in unreachable code, allowing teams to prioritize what is genuinely exploitable rather than working through every CVE in a dependency tree. When remediation is needed, it generates automated dependency upgrades that guarantee zero breaking changes across direct and transitive dependencies, reducing mean time to remediate from weeks to hours.
And because continuous authorization requires continuous evidence, Sonatype SBOM Manager maintains a living SBOMs updated in real time, exportable in CycloneDX and SPDX, and extended to track AI model provenance for the AI attribution and traceability capability the Call identifies as a desired outcome. When a new vulnerability is disclosed, impact analysis runs immediately across the entire portfolio. No manual triage. No scramble.
A Note on Disconnected Environments
The Call lists air-gapped deployment as a desired attribute — one that few vendors can demonstrate in production. Sonatype delivers this today through Sonatype Air-Gapped Environment (SAGE), which operates Sonatype Nexus Repository, Sonatype Lifecycle, Sonatype Repository Firewall, and Sonatype Intelligence entirely within the air gap, with no external connectivity. Offline SBOM generation, automated policy enforcement, and pre-vetted component curation behind the wire. Sonatype Nexus Repository is already deployed across numerous defense and intelligence community environments at IL5 and above, providing a strong foundation for authorization reciprocity and rapid deployment.
What This Means for Program Architects
The leading AI coding tool providers will submit compelling proposals to CDAO_26-01. Many will offer impressive model architectures, broad language support, and developer experiences that genuinely accelerate delivery.
But security and compliance posture — also a criterion — requires more than what the AI tool itself can provide. The questions a well-prepared program architect should be asking are: What governs the open-source decisions the AI agent makes? What prevents a malicious dependency from entering the IL5 enclave? What generates the continuous evidence package that the ATO process requires?
Sonatype is not a competing IDE or CLI agent. It's the supply chain governance layer that makes any selected AI coding tool trustworthy in a defense environment. The two are complementary by design. The goal is faster, higher-quality software delivery, which is only achievable when velocity is paired with the controls that make the velocity defensible.
To learn more about how our solutions can help you manage AI development with confidence, speak to one of our experts.
Tom Tapley specializes in securing software supply chains for Federal environments, bringing deep expertise in aligning agency security, compliance, and operational requirements with modern technology solutions. With a proven track record in supporting mission-critical systems, he bridges the gap between evolving federal mandates and scalable, secure software practices.
Tags
Comply with SBOM Regulations
Meet regulatory requirements with Sonatype SBOM Manager – a single solution for SBOM monitoring, management, and compliance.