DoWI 8430.01: SBOMs Are Now a Condition to Operate

Executive summary. On September 8, 2026, DoW Instruction 8430.01, Accelerated Mission Software, took effect. Most of it is about delivering software faster: CI/CD, reuse, modern acquisition. But one section changes the ground rules for every vendor whose software touches a DoW network: software must now be backed by machine-readable evidence of what is in it, how it was built, and how it was tested. That means SBOMs for custom and commercial software, verifiable build provenance, continuous vulnerability monitoring, and a duty for vendors to report critical or actively exploited vulnerabilities. If you sell software, SaaS, or services into the DoW, this is the document your next contract will be quoting.

What DoWI 8430.01 is

DoWI 8430.01 was issued by the Office of the DoW Chief Information Officer, approved on August 31, 2026 and effective September 8, 2026. Its stated purpose is to establish policy and procedures for software modernization and management across the DoW, and to promote software reuse under Public Law 118-187. It treats software as “a strategic asset to be managed as an enduring capability throughout its lifecycle”.

Who it applies to

Formally, the instruction applies to DoW Components: the Military Departments (including the Coast Guard), the Joint Staff, the Combatant Commands, the Defense Agencies and Field Activities, and every other DoW organization (paragraph 1.1). It covers acquisition and non-acquisition programs containing software, including national security systems and defense business systems, regardless of dollar value.

The scope of the software is what matters to vendors. The glossary defines covered software as “any software, including firmware, operating systems, applications, and cloud-based services that are developed, acquired, integrated, or operated by or on behalf of the DoW”, and defines software to include custom-developed, COTS, GOTS, SaaS, and open-source software. The one carve-out is software developed under Budget Activities 1-4 (basic and applied research, advanced technology and component development), and even that comes back into scope once it moves into acquisition or operational use.

The requirements that matter for vendors

1. Evidence is a condition for operation

Paragraph 3.5.a is titled “Verifiable Assurance as a Condition for Operation”. It states that all software operated on DoW networks and systems will be supported by machine-readable evidence of its component composition, build integrity, and application security. Paragraph 3.5.g then makes that evidence a required input to risk management, used to assess security controls. In practice: no evidence, no easy path to an authorization.

Note what the instruction does not do: it does not name an evidence format. Paragraph 3.5.a(2) says the specific standards will be defined and maintained by the DoW CIO on the Cybersecurity Knowledge Service. Watch for that guidance.

2. SBOMs for custom and commercial software

DoW Components must generate and maintain SBOMs for custom software and capture SBOMs for COTS software (2.8.k), keep an accurate SBOM for all covered software (3.5.b), and include every third-party component, open-source package, COTS product and their transitive dependencies in the SBOM of the system they are integrated into (3.5.i(4)). The instruction defines an SBOM as a formal, machine-readable inventory of software components, their dependencies and their hierarchical relationships, which should be comprehensive or explicitly state where it cannot be.

“Capture SBOMs for COTS software” is the line that reaches commercial vendors. The DoW cannot produce an accurate SBOM for your product without you.

3. Build provenance and attestations

Covered software must be produced by a secure, automated, and observable build process that generates machine-readable provenance (a verifiable history of the software’s origin and build) and attestations that provide pedigree, described as “a cryptographically verifiable chain of custody and integrity for the software and its components” (3.5.c(1)). Signed builds and SLSA-style provenance stop being nice-to-haves.

4. Continuous vulnerability management and disclosure

Software must be validated against a common security baseline that includes continuous vulnerability management, with static and dynamic analysis and dependency scanning integrated into pipelines (3.5.f(8)). Deployed software, explicitly including COTS, must be continuously monitored for vulnerabilities and supply chain risks (3.5.h(1)).

Then the clause aimed squarely at suppliers: DoW Components will require vendors and developers to report any discovery of critical or actively exploited vulnerabilities to the designated authority within a timeframe set by the DoW CIO, “as a condition for deployment or continued use” (3.5.h(2)). If you cannot tell a customer within hours that a newly disclosed CVE affects your product, that becomes a contract problem.

5. Third-party and open-source risk

Before adopting a third-party component, Components must assess its sustainment, source trustworthiness, dependencies (including license obligations), security posture, integrity protections such as signed releases and reproducible builds, and foreign influence risk (3.5.i(2)). Non-trivial open-source components get a deeper review of governance, community health and license compliance (3.5.i(3)). Vendors should expect questions about what is inside their product, not just about the product itself.

6. AI-generated code

Developers stay fully accountable for code generated or modified with AI, and AI-generated code is treated as unverified input (3.6.a). It goes through the same review and security testing as hand-written code (3.6.c). Teams must also keep a record of the models, versions and significant datasets used to generate or test software, included in the evidence package “analogous to the SBOM” (3.6.f).

7. SaaS needs FedRAMP

SaaS offerings must hold a FedRAMP authorization appropriate to the information impact level and comply with the Cloud Service Provider Security Requirements Guide (3.7.b(4)). The instruction also recommends SaaS contracts include data portability, incident reporting, continuous monitoring and exit assistance.

The upside: evidence buys reciprocity

The instruction is not only stick. Software platforms and factories that produce standard machine-readable evidence (SBOMs, build provenance, security scans, operational health data) support continuous authorization, and authorizing officials will accept this standard evidence to grant reciprocity, avoiding redundant assessments (3.4.d). Vendors who can hand over clean evidence get through authorization faster.

What this means if you sell to the DoW

DoWI 8430.01 does not directly bind contractors. It binds the DoW Components that buy from them. But Components can only comply by getting SBOMs, provenance and vulnerability disclosures from their suppliers, so the requirements will flow down through solicitations and contract clauses. Expect to be asked for:

• an SBOM for every release, including transitive dependencies, in a machine-readable format,
• build provenance and signed attestations,
• evidence of dependency scanning and continuous vulnerability management,
• a committed timeline for reporting critical or actively exploited vulnerabilities, and
• for SaaS, a FedRAMP authorization at the right impact level.

What to do now

• Generate SBOMs in CI. Produce a CycloneDX or SPDX SBOM on every build with open-source tools such as Syft or Trivy, and keep them versioned with each release.
• Collect SBOMs from your own suppliers. Your SBOM must include their components too. Start asking now.
• Sign your builds. Add provenance and signing (for example cosign and SLSA provenance) to your pipeline.
• Match SBOMs against vulnerability data continuously, not once at release, so you learn about a new CVE in a shipped component before your customer does.
• Write down your disclosure process. Who decides a vulnerability is critical, who notifies the customer, and how fast.
• Track AI usage. Record which AI models and versions touch your code, and make sure AI-assisted changes get human review.

How OscalIQ helps

OscalIQ is an OSCAL-native compliance platform, and it now treats the SBOM as first-class evidence for a system:

• SBOM import. Upload CycloneDX (JSON or XML) or SPDX 2.x JSON SBOMs per system, whether you generated them or a supplier sent them. Components are kept as a searchable inventory with versions, licenses and package URLs.
• Continuous vulnerability matching. Every component is checked against the OSV.dev open vulnerability database, plus any vulnerabilities embedded in the SBOM itself, with severity, CVE ids and the fixed version for each finding. Re-check any time to pick up new disclosures.
• From finding to POA&M in one click. Any SBOM vulnerability becomes a POA&M item linked back to the component, ready to track to remediation.
• Prioritized by real risk. OscalIQ prioritizes each item by whether it appears in the CISA Known Exploited Vulnerabilities catalog and whether the affected asset is internet-reachable according to your inventory, the same contextual model behind FedRAMP VDR and VER.
• Your choice on data sharing. OSV matching sends only package names and versions, and can be switched off per upload to keep an SBOM fully local.

DoWI 8430.01 turns software evidence from paperwork into a gate. If you want to see your SBOMs, findings and POA&M in one OSCAL-native place, get in touch and we will walk you through OscalIQ.

Source: DoW Instruction 8430.01, Accelerated Mission Software, September 8, 2026, available on the DoW Directives Division website. Paragraph references above are to that document.