Answer a US federal secure software attestation request in 2026: the CISA form, its SSDF mapping and the evidence behind each statement

The attestation came from Executive Order 14028 and two OMB memoranda, and most of that structure has since been withdrawn. The sequence matters because contracts, solicitations and agency forms written in 2024 still quote the old requirements. This is what the documents say; whether a particular contract still binds you is a question for your contracting officer and your counsel.

• 12 May 2021: Executive Order 14028 section 4(e) lists secure development practices, 4(k) tells OMB to require agencies to follow NIST's guidance, and 4(n) asks for contract language requiring suppliers to attest. EO 14028 has not been revoked.
• February 2022: NIST publishes SSDF 1.1 (SP 800-218) and its software supply chain security guidance under section 4(e).
• 14 September 2022: OMB M-22-18 requires agencies to use only software whose producer attests to the government-specified practices, allows a POA&M when a producer can't attest to some, and lets agencies ask for SBOMs and other artifacts.
• 9 June 2023: OMB M-23-16 extends the deadlines, excludes third-party components and freely available software from collection, and requires an agency that accepts a POA&M to request an OMB extension.
• 8 March 2024: OMB approves the common form under the Paperwork Reduction Act as control number 1670-0052, expiring 31 March 2027; CISA releases it on 11 March 2024 and opens the online Repository for Software Attestations and Artifacts (RSAA) on 18 March 2024.
• 16 January 2025: Executive Order 14144 calls for machine-readable attestations and artifacts in the RSAA, CISA validation of a sample, public posting of results and FAR contract language.
• 6 June 2025: Executive Order 14306 strikes those provisions. Its replacement text for the SSDF subsection keeps only NIST's tasks, with new dates: an SSDF consortium at the NCCoE by 1 August 2025, SP 800-53 patch guidance by 2 September 2025, and a preliminary SSDF update by 1 December 2025 with a final version within 120 days of it. The follow-on steps for OMB to adopt the update and for CISA to revise the form are not in it.
• 17 December 2025: NIST publishes SSDF 1.2 (SP 800-218 Rev. 1) as an initial public draft; comments closed on 30 January 2026, and on 11 October 2026 NIST still listed it as a draft.
• 23 January 2026: OMB M-26-05 rescinds M-22-18 and M-23-16.
• 6 March 2026: FAR Case 2023-002, Supply Chain Software Security, is withdrawn; the Unified Agenda says it was closed because the OMB direction it implemented had been rescinded.

M-26-05 makes each agency head responsible for the security of software and hardware on its network and asks agencies to set assurance policies that match their own risk determinations. Agencies must keep a complete inventory of software and hardware. They may use the resources built under M-22-18, including the attestation form, and may adopt contract terms requiring a producer to provide a current SBOM on request; for a cloud platform, the memo says such a term should require an SBOM of the runtime production environment. It points agencies to SP 800-218 and its appendices, CISA's SBOM minimum elements (cited in their August 2025 draft; CISA published the final 2026 Minimum Elements for an SBOM on 29 July 2026, replacing NTIA's 2021 list) and CISA's hardware bill of materials framework.

In practice a request now arrives in one of three forms: the attestation form itself, often because a 2024 contract or ordering process still asks for it; an agency's own questionnaire or contract clause on secure development; or an SBOM request. The same per-release evidence answers all three. /frameworks/ssdf-product-lifecycle/ builds that evidence for one product, /domains/supply-chain/sbom/generate-release-inventory/ produces the SBOM, and /frameworks/compliance-evidence-reuse/ reuses it across frameworks.

The form is eight pages of instructions and form plus a two-page appendix. Each part has an engineering input, even where a lawyer or contracts lead fills it in.

The SSDF tasks in the table are the form's own appendix, which CISA describes as a mapping provided for reference. It relates statement 4 as a whole, so 4a, 4b and 4c share one list. The evidence column is what to keep for the release and period you attest; statements 1a to 1f are about your environments during the period, and 2 to 4b are about the release itself.

Keep an index per attested release that names the product, the artifact digest, the attestation period and one entry per piece of evidence, with the statement it supports and the SSDF tasks it shows. Store the evidence itself in the systems that produced it, and the index next to the release. The example is for a fictional product; its REL-4 entry is about a different digest and claims a task the form doesn't relate to 4b, and nothing supports 1b.

{
  "product": "Kestrel Collector",
  "release": "5.3.0",
  "artifact": "sha256:4f6c2a9e0b8d71c35e2f9a1b7d40c6e83f5a9b2c1d7e0f4a6b8c3d5e7f9a1b2c",
  "period": ["2026-07-01", "2026-09-30"],
  "evidence": [
    {"id": "ENV-1", "statement": "1a", "date": "2026-09-01", "ssdf": ["PO.5.1"],
     "kind": "Network diagram and firewall export: build runners isolated from development and production"},
    {"id": "ENV-2", "statement": "1c", "date": "2026-09-30", "ssdf": ["PO.5.2"],
     "kind": "IdP export: MFA and device policy enforced on source control, CI and the artifact registry"},
    {"id": "ENV-3", "statement": "1d", "date": "2026-08-15", "ssdf": ["PO.5.1"],
     "kind": "Approved build-tool list and exceptions"},
    {"id": "ENV-4", "statement": "1e", "date": "2026-09-30", "ssdf": ["PO.5.2"],
     "kind": "Secrets manager configuration; secret scanning with push protection"},
    {"id": "ENV-5", "statement": "1f", "date": "2026-09-12", "ssdf": ["PO.3.3"],
     "kind": "Alert routing for CI and registry audit logs; incident tickets"},
    {"id": "REL-1", "statement": "2", "date": "2026-09-14", "ssdf": ["PS.1.1", "PW.4.4", "PW.7.1"],
     "artifact": "sha256:4f6c2a9e0b8d71c35e2f9a1b7d40c6e83f5a9b2c1d7e0f4a6b8c3d5e7f9a1b2c",
     "kind": "Branch ruleset export, review records and dependency scan for the release"},
    {"id": "REL-2", "statement": "3", "date": "2026-09-14", "ssdf": ["PS.3.2", "PW.4.1"],
     "artifact": "sha256:4f6c2a9e0b8d71c35e2f9a1b7d40c6e83f5a9b2c1d7e0f4a6b8c3d5e7f9a1b2c",
     "kind": "Signed SLSA provenance and CycloneDX SBOM attached to the image"},
    {"id": "REL-3", "statement": "4a", "date": "2026-09-14", "ssdf": ["PW.7.2", "PW.8.2"],
     "artifact": "sha256:4f6c2a9e0b8d71c35e2f9a1b7d40c6e83f5a9b2c1d7e0f4a6b8c3d5e7f9a1b2c",
     "kind": "SAST, SCA and DAST results for the release candidate"},
    {"id": "REL-4", "statement": "4b", "date": "2026-09-13", "ssdf": ["PW.1.1"],
     "artifact": "sha256:0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e",
     "kind": "Release gate decision with open findings and exceptions"},
    {"id": "VDP-1", "statement": "4c", "date": "2026-09-20", "ssdf": ["RV.1.3", "RV.2.2"],
     "kind": "Published disclosure policy with response times; two reports triaged and fixed"}
  ]
}

The script holds the form's appendix as data. It rejects evidence for a statement that isn't on the form, release evidence about another artifact, evidence dated outside the period and SSDF tasks the form doesn't relate to that statement, then lists the evidence for each statement and the ones with none. For the index above it prints REL-4: about sha256:0d1e…, not the attested release, reports no evidence for 1b and 4b, and exits 1. A statement with no evidence is not one to attest to: list it for the agency with your mitigations and a POA&M.

Run it with python3 check_attestation.py evidence-index.json in the release pipeline, so the evidence summary the signer reviews comes from the same records as the release.

"""Check an evidence index against the CISA Secure Software Development Attestation Form."""

import json
import sys

# Section III statements and the SSDF 1.1 tasks the form's appendix relates to each.
ENVIRONMENT = ["PO.5.1"]
FORM = {
    "1a": ENVIRONMENT,
    "1b": ENVIRONMENT,
    "1c": ["PO.5.1", "PO.5.2"],
    "1d": ENVIRONMENT,
    "1e": ["PO.5.2"],
    "1f": ["PO.3.2", "PO.3.3", "PO.5.1", "PO.5.2"],
    "2": ["PO.1.1", "PO.3.1", "PO.3.2", "PO.5.1", "PO.5.2", "PS.1.1", "PS.2.1",
          "PS.3.1", "PW.4.1", "PW.4.4", "PW.7.1", "PW.8.1", "RV.1.1"],
    "3": ["PO.1.3", "PO.3.2", "PO.5.1", "PO.5.2", "PS.3.1", "PS.3.2", "PW.4.1",
          "PW.4.4", "RV.1.1", "RV.1.2"],
}  # fmt: skip
# The appendix maps statement 4 as a whole; each of 4a to 4c still needs its own evidence.
FOUR = ["PO.4.1", "PO.4.2", "PS.1.1", "PW.2.1", "PW.4.4", "PW.5.1", "PW.6.1", "PW.6.2",
        "PW.7.1", "PW.7.2", "PW.8.2", "PW.9.1", "PW.9.2", "RV.1.1", "RV.1.2", "RV.1.3",
        "RV.2.1", "RV.2.2", "RV.3.3"]  # fmt: skip
FORM.update({"4a": FOUR, "4b": FOUR, "4c": FOUR})
# Statements about the attested software rather than its environments.
RELEASE_BOUND = {"2", "3", "4a", "4b"}


def check(index):
    problems, covered = [], {statement: [] for statement in FORM}
    for item in index["evidence"]:
        where, statement = item["id"], item["statement"]
        if statement not in FORM:
            problems.append(f"{where}: no statement {statement!r} on the form")
            continue
        if statement in RELEASE_BOUND and item.get("artifact") != index["artifact"]:
            problems.append(f"{where}: about {item.get('artifact')}, not the attested release")
            continue
        if not index["period"][0] <= item["date"] <= index["period"][1]:
            problems.append(f"{where}: dated {item['date']}, outside the attestation period")
            continue
        unrelated = sorted(set(item.get("ssdf", [])) - set(FORM[statement]))
        if unrelated:
            problems.append(f"{where}: the form doesn't relate {', '.join(unrelated)} to {statement}")
        covered[statement].append(where)
    gaps = [statement for statement, items in covered.items() if not items]
    return covered, gaps, problems


if __name__ == "__main__":
    with open(sys.argv[1]) as f:
        index = json.load(f)
    covered, gaps, problems = check(index)
    for problem in problems:
        print(problem)
    for statement, items in covered.items():
        print(f"{statement}: {', '.join(items) or 'no evidence; list it with mitigations and a POA&M'}")
    sys.exit(1 if gaps or problems else 0)

The form's instructions describe the route M-22-18 created: identify the practices you can't attest to, document the practices you have in place to mitigate the risk, and submit a plan of action and milestones. Under M-23-16 an agency that accepted a POA&M also had to ask OMB for an extension, and the form's text still says so. M-26-05 rescinded both memoranda and named no replacement process, so ask the requesting agency how it now handles a POA&M. Under M-22-18, POA&M documentation was not to be posted publicly by the vendor or the agency.

The alternative to signing is a third-party assessment. The form accepts one from a Third Party Assessor Organization that is FedRAMP certified or approved in writing by an appropriate agency official, which used relevant NIST guidance including every element of the form as its baseline. Check the box in Section III and attach the assessment; the producer then need not sign, and the agency must keep the assessment from being posted publicly. A third-party assessment costs more and takes longer, but it answers agencies that ask for independent assurance, which M-26-05 lets each agency decide for itself.

• Write each POA&M item as a gap against a statement, with the SSDF tasks it affects, the mitigation in place now, an owner and a dated milestone.
• Don't sign a company-wide attestation to cover one product's evidence; choose individual products or specific versions in Section I.
• Keep the attestation, its evidence index and any POA&M together, because a revised attestation should show what changed.

Requirements vary, and the common form expects them to. Read every request against the contract or solicitation it comes from, and ask the contracting officer which document governs. The items below are ones the primary sources show.

• Agency-specific instructions and addenda: the form says conformance to agency-specific requirements may be attached as an addendum, and the agency handles the Paperwork Reduction Act for its additions.
• Privacy Act statements and submission addresses: each agency supplies its own statement and the email address for PDF submissions.
• Agency copies of the form: GSA publishes GSA 7700 (revision 05/2024) under the same control number, with GSA's Privacy Act statement and a GSA address for emailed forms.
• Which agencies use the common form: the OMB history for control number 1670-0052 records 41 agency requests to use it in 2024 and 2025, and on 23 September 2026 OIRA approved the Securities and Exchange Commission's request to discontinue its use.
• Submission channel: CISA's form and RSAA pages are now marked as archived content, while the form remains downloadable with a resource page that cites M-26-05; confirm with the agency whether it still accepts the RSAA or wants the PDF.
• SBOMs and artifacts: under M-26-05 an agency may write SBOM-on-request terms into the contract, with a runtime SBOM for cloud platforms, and may ask for other artifacts its own policy calls for.

The form must be signed by the chief executive officer or a designee who is an employee and has authority to bind the company. The signer attests, to the best of their knowledge, that the company presently makes consistent use of the Section III practices in developing the listed software, for code the producer develops; third-party components are covered by the steps in statements 2 and 3 for managing them, not by attestations from their authors. The signer also promises to notify every agency that received the form if the practices stop, and the Section I footnote makes the attestation binding for future versions until that notice.

The form's Privacy Act statement cites 18 U.S.C. § 1001 for willfully false or misleading information. What that means for your company, and whether a contract term adds obligations, are questions for counsel, not for this guide. Engineering's part is to give the signer an evidence summary per statement, the list of gaps, and the date the evidence was checked.

Not on any published schedule. EO 14144 would have had OMB fold practices from the updated SSDF into its requirements and CISA revise the form; EO 14306's replacement text leaves both steps out, and M-26-05 then rescinded the memoranda the form implements. The form still refers to SP 800-218, which is SSDF 1.1. The 1.2 draft adds PO.6 (continuous improvement) and PS.4 (reliable updates); track it separately, as /frameworks/ssdf-product-lifecycle/ does, and keep 1.2 evidence out of a 1.1 attestation until an agency asks for it.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. CISA: Secure Software Development Attestation Form (resource page, citing M-26-05). Revision date 14 May 2024.
2. CISA: Secure Software Development Attestation Form and instructions (PDF). Version 1.0; OMB 1670-0052, expires 31 March 2027.
3. CISA: Secure Software Development Attestation Form page (archived content)
4. CISA: Repository for Software Attestations and Artifacts (RSAA) user guide (archived content). 18 March 2024.
5. OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security. 23 January 2026.
6. OMB M-22-18: Enhancing the Security of the Software Supply Chain through Secure Software Development Practices (archived, rescinded). 14 September 2022.
7. OMB M-23-16: Update to Memorandum M-22-18 (archived, rescinded). 9 June 2023.
8. Executive Order 14028, Improving the Nation's Cybersecurity (Federal Register, via govinfo). 86 FR 26633, published 17 May 2021 (signed 12 May 2021).
9. Executive Order 14144, Strengthening and Promoting Innovation in the Nation's Cybersecurity (Federal Register, via govinfo). 90 FR 6755, published 17 January 2025 (signed 16 January 2025).
10. Executive Order 14306, Sustaining Select Efforts To Strengthen the Nation's Cybersecurity and Amending Executive Order 13694 and Executive Order 14144 (Federal Register, via govinfo). 90 FR 24723, published 11 June 2025 (signed 6 June 2025).
11. Unified Agenda: FAR Case 2023-002, Supply Chain Software Security (RIN 9000-AO49), withdrawn. Withdrawn 6 March 2026.
12. OIRA: OMB control number 1670-0052 history (common form approval and agency use)
13. OIRA: ICR 202311-1670-001, Secure Software Self-Attestation Common Form. Approved with change 8 March 2024.
14. NIST SP 800-218: SSDF 1.1. Version 1.1 (February 2022).
15. NIST SP 800-218 Rev. 1 (SSDF 1.2), initial public draft. SP 800-218 Rev. 1 (initial public draft, December 2025).
16. NIST: Software Supply Chain Security Guidance under EO 14028 Section 4e. 4 February 2022.
17. GSA Form 7700: Secure Software Development Attestation. Revision 05/2024.
18. CISA: 2026 Minimum Elements for a Software Bill of Materials (SBOM). 29 July 2026.

Reference information

Tags

Build integrity and provenanceSecure development lifecycleCompliance and assurance evidenceSupplier and open source risk

SDLC phase

ReleaseSecurity program

Role

Security leaders

Download this guide as Markdown

Continue exploring