Executive Order 14028, NIST SSDF, and the CISA Secure Software Development Attestation
a practical guide to producing SBOMs and secure-SDLC evidence that federal buyers will actually accept.
If you sell software to a US federal agency, you must self-attest that you build it in line with NIST's Secure Software Development Framework (SP 800-218). That mandate flows from Executive Order 14028 §4, was operationalized by OMB M-22-18 and M-23-16, and is collected on the CISA Secure Software Development Attestation Form released March 11, 2024.
This page breaks down what the EO, the OMB memos, the SSDF practice groups (PO, PS, PW, RV), the AI profile in SP 800-218A, and the CISA form actually require, then shows how to assemble the SBOM and secure-SDLC evidence behind each attestation statement. Every step cites the underlying control so you can defend it during an agency review.
A signed attestation is now the price of entry for selling software to the US government.
Executive Order 14028 made software supply chain security a federal procurement gate. Section 4 directed NIST to define secure development practices and mandated SBOMs, build provenance, and secure build environments (EO 14028 §4). OMB then turned that into a hard requirement: M-22-18 (Sept 14, 2022) requires agencies to obtain a self-attestation of SSDF conformance before using a vendor's software, and M-23-16 (June 9, 2023) reset the collection deadlines to the release of CISA's Common Form.
The attestation is signed by a company executive and carries legal weight under the False Statements and False Claims Acts. An agency can stop using your software if you cannot or will not attest. The scope is broad: software developed or majorly updated after Sept 14, 2022, including SaaS, is in play.
The form does not ask for marketing claims. It asks whether specific SSDF practices are in place across development environment security, trusted source-code supply chain and provenance, automated code analysis, and vulnerability response (SP 800-218 PO/PS/PW/RV). Vendors who already generate SBOMs, run automated source and dependency analysis, and operate a disclosure process can attest with evidence on hand. Those who do not face a scramble before their next federal renewal.
Find it before attackers do. Catch it if they try. Fix it fast.
Across these requirements, O3 runs one continuous loop on your own software so issues surface, get caught, and get fixed before they become an incident.
Test like an AI-assisted attacker
An agentic pentest probes your app across 50+ vulnerability classes the way a real attacker chains them, so exploitable flaws surface in your build before someone outside finds them.
Detect and block exploitation at runtime
A kernel-level eBPF agent watches process trees and syscalls, recognises an attack sequence as it unfolds, and restricts the offending process on the spot rather than taking down the host.
Auto-patch what is reachable
Reachability ranks what genuinely matters, then autofix opens a pull request with the change, so remediation starts inside tight fix windows instead of sitting in a queue.
From alert flood to a short list
KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.
Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.
The clock by finding type
Indicative fix windows. Tightest where exposure and active exploitation meet.
How to determine whether the EO 14028 attestation applies to your software
The mandate reaches any software producer whose product is used by a federal agency. Knowing your scope before an agency asks saves a fire drill at renewal.
How to satisfy SSDF Prepare the Organization (PO) and development-environment security
The attestation's first area is a secure development environment: separated access, multi-factor authentication for developers, and logging. These map to SSDF PO and PS.1.
How to protect code integrity and provenance under SSDF PS
Protect the Software (PS) covers tamper protection, integrity verification, and provenance for everything you ship, including third-party components.
O3 reads SLSA and cosign provenance to confirm artifact origin, and runs Gitleaks-based secret scanning so leaked credentials are caught before a signed release. O3 verifies provenance; it does not generate signing keys or run your signing infrastructure.
How to manage third-party components and run automated code analysis under SSDF PW
Produce Well-Secured Software (PW) is the core AppSec area: secure reuse of components (PW.4), code review and analysis (PW.7), and testing (PW.8). It is where most attestation evidence lives.
O3 covers PW.4, PW.7, and PW.8 directly: SAST with code-property-graph taint tracing source to sink, SCA against OSV with function-level reachability to rank whether a vuln is actually exploitable, malicious-dependency detection, and CycloneDX SBOM generation enriched with deps.dev and VEX.
How to run vulnerability response and disclosure under SSDF RV
Respond to Vulnerabilities (RV) requires you to find vulnerabilities in released software, analyze root cause, and remediate, plus operate a disclosure process. This is the attestation's fourth area.
O3 supports RV.1-RV.3 with continuous SBOM monitoring, EPSS plus KEV prioritization, and autofix with auto-PR to shorten remediation time. Governance of the disclosure program itself stays with your security team.
How to produce an SBOM that meets the NTIA and CISA minimum elements
The attestation expects SBOMs in a recognized format. The NTIA 2021 baseline and CISA's 2025 Minimum Elements update define the required data fields and practices.
O3 generates CycloneDX SBOMs covering the NTIA and CISA minimum elements, with dependency depth and VEX, plus specialized BOMs (CBOM, QBOM, AIBOM, HBOM) for cryptographic, quantum-readiness, AI, and hardware inventory.
How to apply SSDF to AI models using SP 800-218A
If you produce or ship generative AI or dual-use foundation models, SP 800-218A (July 2024) augments the SSDF with AI-specific tasks across the same PO/PS/PW/RV families, supporting EO 14110.
O3 generates an AIBOM inventorying AI models and datasets in CycloneDX, giving the AI-component transparency SP 800-218A calls for. Model-level safety controls such as prompt-injection blocking are outside O3's scope.
Every requirement, mapped to the evidence that satisfies it.
All 22 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.
Turn the SSDF practices into attestation-ready evidence
O3 produces the technical evidence that backs a Secure Software Development Attestation: CycloneDX SBOMs that meet the NTIA and CISA minimum elements, SAST with reachability for PW.7, SCA and malicious-dependency detection for PW.4, EPSS plus KEV prioritization and autofix for the RV family, and SLSA/cosign provenance verification for PS. See how it maps to your next federal renewal.
Read EO 14028 on the Federal Register- Yes, for software used by US federal agencies. Under OMB M-22-18 and M-23-16, agencies must obtain a self-attestation of NIST SSDF (SP 800-218) conformance before using a vendor's software. The CISA Common Form, released March 11, 2024, is the standard artifact agencies collect.
- A company executive (typically the CEO or a designated senior official) signs the form, which makes the attestation a legally binding statement under the False Statements and False Claims Acts. A vendor may alternatively submit a third-party assessor (3PAO) attestation in place of self-attestation.
- Per OMB M-22-18, software developed after Sept 14, 2022, major version updates after that date, and software with continuous changes such as SaaS are in scope when used by a federal agency. Free and open-source software a producer incorporates is treated as part of the product.
- The form maps to SSDF practice families across four areas: secure development environment (PO/PS.1), trusted source-code supply chain and provenance including SBOMs (PW.4, PW.7-PW.8), automated code security analysis and component monitoring (PW.7, RV.1), and a vulnerability disclosure and response process (RV).
- SP 800-218 (v1.1, Feb 2022) is the core SSDF with practice groups PO, PS, PW, and RV. SP 800-218A (July 2024) is a community profile that augments the SSDF with AI-specific tasks for generative AI and dual-use foundation models, covering training-data provenance and model integrity, in support of EO 14110.
- The NTIA 2021 baseline requires supplier, component name, version, other unique identifiers, dependency relationships, author, and timestamp, delivered in a standard format such as CycloneDX or SPDX. CISA's 2025 Minimum Elements update expands the data fields and generation practices and reflects current SBOM maturity.
- OMB M-23-16 tied deadlines to the release of CISA's Common Form: agencies collect attestations for critical software roughly 3 months after release and for all other software within about 6 months. Producers should confirm specific dates with each agency customer.
- No. An SBOM satisfies the component-inventory and transparency expectations (PW.4 and the NTIA/CISA minimum elements), but the attestation also requires secure development environment controls, automated code analysis (PW.7), testing (PW.8), and a vulnerability disclosure and response process (RV). The SBOM is one piece of evidence among several.
See O3 Security in Action
See why security and engineering leaders trust O3
to secure their entire software supply chain.