OMB Memorandum M-22-18, issued on 14 September 2022, was the first sweeping federal requirement that software producers attest to NIST SSDF (SP 800-218) practices before selling covered software to agencies. M-23-16, issued on 9 June 2023, extended the deadlines and added software-type definitions. The CISA Secure Software Self-Attestation Common Form became final in March 2024. Four years of subsequent updates — the CISA SBOM Minimum Elements revision of September 2024, the FedRAMP Rev. 5 transition completed July 2024, and the OMB-CISA repository guidance announced at RSA 2025 — have reshaped what "compliant" looks like in 2026.
This is an operational update. The rules have not softened. They have, in fact, hardened around specific SBOM expectations, provenance requirements, and the federal government's ability to verify producer claims at scale. Software producers who signed the form in 2024 and assumed they were done for the year face a different reality in 2026.
What does M-22-18 actually require software producers to attest to?
M-22-18 requires federal agencies to obtain a self-attestation from software producers before using any covered software, defined in M-23-16 as software developed after 14 September 2022 that is new, a major version, or delivers continuous updates to existing software. The attestation is made using the CISA Secure Software Self-Attestation Common Form (OMB Control Number 1670-0037), and it maps to a subset of NIST SSDF practices: PO.1.1, PO.3.2, PO.5.1 and PO.5.2, PS.1.1, PS.2.1, PS.3.1, and PW.4.1 through PW.4.4, among others.
The producer signs, under penalty of perjury, that they follow the listed practices. Where they do not, M-23-16 allows a Plan of Action and Milestones (POA&M) and requires agency approval. The agency cannot use the software until the attestation is on file — the CISA Repository for Software Attestation and Artifacts (RSAA) became the collection point in early 2024.
What changed in 2024 and 2025 that matters for 2026?
Three updates reshape the practical work. First, the CISA SBOM Minimum Elements update published in September 2024 aligned federal SBOM expectations with the NTIA July 2021 document but added explicit support for dependency transitive depth and component relationship tracking. Producers who emitted flat SBOMs in 2024 are discovering that federal buyers now expect hierarchical dependency data.
Second, the CISA Secure by Design pledge, launched in May 2024 at RSA and signed by more than 200 vendors by year-end, created a voluntary but public commitment set that federal buyers cite when evaluating vendors. The pledge includes multi-factor authentication by default, elimination of default passwords, CVE transparency, and SBOM provision. While non-binding, the pledge has become a procurement differentiator, and the absence of a signature is now a line item in some agency source selection documents.
Third, the FedRAMP Rev. 5 transition, completed in July 2024 for existing ATOs, threads SP 800-53 Rev. 5 controls — including SR-1 through SR-12 on supply chain — into the FedRAMP continuous monitoring program. FedRAMP cloud services now inherit C-SCRM expectations that sit alongside the M-22-18 attestation regime rather than replacing it.
How do federal buyers verify producer claims?
Until 2024, verification was mostly paper-based. The RSAA collected signed forms, agencies referenced them at acquisition, and no systematic verification existed. That has changed. CISA's 2024-2025 updates to the attestation workflow include machine-readable submissions, cryptographic signing of attestation artifacts, and integration with CISA's Vulnrichment project (launched May 2024) for CVE-to-SBOM mapping.
The 2024 CSRB report on the Microsoft Exchange Online Storm-0558 intrusion, published 2 April 2024, drove home that self-attestation without verification creates residual risk. Subsequent OMB guidance has quietly begun to demand that producers make SBOMs available on request and, in certain contract vehicles, provide continuous build provenance aligned with SLSA v1.0.
The October 2023 SEC complaint against SolarWinds and its CISO, though partially dismissed in July 2024 by Judge Engelmayer in the Southern District of New York, preserved the theory that public security claims are actionable. Federal buyers cite that theory when they insist on verifiable attestations rather than marketing language.
What SBOM practices now count as the federal floor?
A compliant 2026 SBOM must be machine-readable in SPDX 2.3 or CycloneDX 1.5 (or newer), emitted from the actual build pipeline rather than hand-curated, and must cover each component with supplier, component name, version, unique identifier, dependency relationships, SBOM author, and timestamp — the CISA Minimum Elements. For federal software where the producer claims "known unknowns" — libraries whose components are genuinely not enumerable — the producer must declare the limitation explicitly rather than silently omit.
CISA's guidance on SBOM sharing, updated November 2024, sets expectations for how producers deliver SBOMs to federal buyers: directly via the RSAA, via a producer-hosted endpoint, or through an industry exchange. It also expects a machine-verifiable signature on the SBOM. The absence of a signature is now a line-item concern in agency review.
Provenance is moving from "encouraged" to "expected." SLSA v1.0, released April 2023, and the in-toto attestation framework have reached enough maturity that large federal buyers — GSA, VA, and DoD's SWFT effort — are asking for build provenance as a companion to SBOMs.
How does this interact with the Secure by Design pledge?
The Secure by Design pledge is voluntary. M-22-18 attestation is mandatory for covered software used by federal agencies. But the overlap is deliberate. The pledge's seven goals — MFA, default passwords, CVE transparency, security patches, vulnerability disclosure, evidence of intrusions, and reducing classes of vulnerabilities — overlap substantially with SSDF practices attested to under the Common Form.
In 2026, signed pledge commitments increasingly serve as evidence that the attested practices are real. CISA's 2025 one-year pledge update, published in May 2025, named 68 signatories with published progress reports and called out several for public transparency on default-password elimination and MFA adoption. That document has become an informal verification layer for federal buyers.
What should software producers change in 2026?
Four practical shifts belong on the 2026 roadmap. First, generate SBOMs from the build, not after. If your release engineering cannot emit a signed SBOM as part of the build artifact set, that is now the highest-priority SSDF gap. Second, adopt SLSA v1.0 provenance for at least Level 2. The investment is modest for most CI/CD stacks and the payoff is the ability to answer "did we build what we shipped?" from cryptographic evidence.
Third, modernize your vulnerability disclosure. A PSIRT mailbox is necessary but not sufficient. Federal buyers want a published policy, a defined response timeline, and a coordinated disclosure track record. The ISO/IEC 29147 and 30111 standards, referenced in the SSDF PW.4 family, remain the reference.
Fourth, treat your attestation as a living document. CISA's FAQ explicitly permits updated attestations when circumstances change, and federal buyers may request one if your environment shifts. The producer who files once and forgets is the producer whose next breach triggers scrutiny.
How does this flow down to subcontractors?
Flow-down is specified in M-23-16 and clarified in CISA's March 2024 FAQ. The prime contractor is responsible for ensuring that third-party components — open source and commercial — meet the same SSDF expectations when integrated into covered software. The prime may obtain attestations from subcontractors or may accept upstream producers' publicly available attestations, but the prime carries the obligation.
Open source components are handled differently. The prime attests that its SSDF practices apply to the use of open source components — provenance verification, vulnerability monitoring, license compliance — rather than attesting on behalf of unaffiliated maintainers.
How Safeguard.sh Helps
Safeguard.sh operationalizes the 2026 attestation reality. Eagle detection ingests SBOMs from your build pipeline, reconciles them against CISA KEV, NVD, and vendor PSIRT feeds, and flags the divergences that would invalidate an attestation claim. Build provenance artifacts (SLSA, in-toto) are validated and stored alongside the SBOM, so your "we built what we shipped" answer is cryptographic, not hopeful.
The zero-day pipeline continuously watches for new exploit research and broker activity affecting components in your attested inventory; when a match appears, the impacted attested software and the affected agency customers surface together. SBOM lineage tracks components across subcontractor boundaries, which is the exact pattern M-23-16 flow-down addresses.
For TPRM, Safeguard.sh monitors subcontractor and upstream maintainer attestation posture, Secure by Design pledge signatures, and disclosure policy changes. Lino compliance mapping translates M-22-18, M-23-16, SSDF practice identifiers, CISA Minimum Elements, and FedRAMP Rev. 5 SR controls into concrete engineering evidence, with the audit trail federal investigators expect. Griffin AI remediation proposes the exact pipeline change, policy update, or attestation revision required when a control drifts, closing gaps before they become compliance events.