CISA Secure Software Attestation Form: What It Is and Its Status in 2026

The CISA Secure Software Development Attestation Form is a four-statement declaration, signed by a software producer's CEO or a designee, that the producer builds its software using a set of practices drawn from NIST's Secure Software Development Framework (SSDF, SP 800-218). From 2024 it was effectively a condition of selling software to US federal agencies. Since OMB Memorandum M-26-05 of 23 January 2026, it is no longer required government-wide: each agency decides whether to ask for it, and many still will.

Updated 25 October 2026: this guide was first published on 16 January 2026, when OMB M-22-18 still applied and the attestation was mandatory for most software sold to federal agencies. OMB M-26-05 rescinded M-22-18 and its companion M-23-16 on 23 January 2026, and the FAR Council withdrew the matching contract rule, FAR Case 2023-002, on 6 March 2026. We have rewritten the post to explain what the form is, how it got here, what applies now, and what a vendor should do with an attestation it may already have signed. If you only need the policy change itself, read our explainer on how OMB M-26-05 ended the federal software attestation mandate.

This guide explains public policy documents and is not legal advice. For a specific contract or solicitation, ask your counsel or the contracting officer.

Key takeaways

• The form still exists. CISA hosts it, its OMB control number (1670-0052) is valid until 31 March 2027, and M-26-05 says agencies "may choose to use" it.
• It is no longer required government-wide: M-22-18 and M-23-16 are rescinded, FAR Case 2023-002 is withdrawn, and EO 14306 struck the EO 14144 plan to file attestations in CISA's repository.
• Section III holds four statements: secure build environments, trusted source code supply chains, provenance, and vulnerability checking with a disclosure program. Each maps to SSDF tasks. A CEO or designee signs; a qualifying third-party assessment or a POA&M are the alternatives.
• Agencies must still keep a complete software and hardware inventory and set risk-based assurance policies. They may require a current SBOM on request, covering the runtime production environment for cloud platforms.
• SSDF 1.2 (SP 800-218 Rev. 1) is still a draft. Keep a form and evidence pack ready per product, stop calling the form legally required, and fix every trust page and questionnaire answer that does.

What the Secure Software Development Attestation Form is

The form is a common, multi-agency document that CISA built with OMB so that every agency would collect the same minimum promises from software producers instead of inventing its own. CISA's resource page describes it as based on NIST SP 800-218 version 1.1 and says it "incorporates selected best practices" from that publication. It is not the SSDF itself. The SSDF is a much larger set of practices and tasks; the form picks the subset that Executive Order 14028 section 4(e) called out and turns them into four signed statements.

The PDF, labelled Version 1.0, has several pages of instructions, the form in three sections, a burden statement and an appendix that maps each statement to EO 14028 clauses and SSDF tasks. That appendix is the most useful part for anyone preparing evidence.

Which software the form was written for

The instructions set out when a product needed an attestation under M-22-18 as amended. Any one of three conditions was enough:

1. The software was developed after 14 September 2022, the date M-22-18 was issued.
2. The software was developed before that date but had a major version change afterwards. The form gives the example of semantic versioning moving from 2.5 to 3.0.
3. The producer delivers continuous changes to the code, as with software as a service or any product shipped through continuous delivery.

That third condition is why almost every cloud product fell inside the scope. A hosted service never sits still long enough to be "developed before" anything.

What the form does not cover

Both the instructions and Section I list four categories that are out of scope:

1. Software developed by federal agencies.
2. Open source software that a federal agency obtains freely and directly.
3. Third-party open source and proprietary components incorporated into the software end product the agency uses.
4. Software that is freely obtained and publicly available.

The third exclusion is the one most often misread. It does not mean open source inside your product is ignored. M-23-16 explains that the attestation is collected from the producer of the end product "because the producer of that end product is best positioned to ensure its security," and that the minimum requirements already include steps for managing third-party components. In other words, the agency does not ask each upstream maintainer to sign anything; it asks you, and your signature covers how you select, track and patch what you pull in. The note under Section I says producers attest to the practices "for code developed by the producer," while Section III statements 2 and 3 cover third-party components explicitly.

M-23-16 added two more clarifications. Proprietary software that is free and publicly available, such as a web browser, is out of scope, but demonstrations or pilots of products that are not otherwise free remain in scope. Software built by a federal contractor can count as agency-developed, and so fall out of scope, only if the contracting agency can ensure secure practices across the whole development life cycle; the agency CIO makes that call.

Section I: what is being attested

Section I asks for the attestation type (new, following an extension or waiver, or revised) and the scope (company-wide, an individual product, or multiple products or specific versions). For anything narrower than company-wide, the producer lists each product name, version number and release or publish date. It then restates the four exclusions above.

A footnote on the version column matters more than it looks. It says attestations "are binding for future versions of the named software product" until the producer tells the agencies it no longer conforms. A signed form is therefore not a snapshot of one release; it is a continuing promise.

Section II: who the producer is

Section II is contact information: company name, full address, country and website, then a primary contact for the document. The contact "may be an individual, role, or group," and the email may be an alias or distribution list. The instructions say every field is required and that "Incomplete forms will not be accepted."

Section III: the four attestation statements

Section III is the substance. The signer attests that, to the best of their knowledge, the producer "presently makes consistent use of" the following practices in developing the software named in Section I. We have paraphrased the statements; the appendix of the form gives the EO 14028 clause and SSDF tasks for each.

Below the four statements is one more promise: the producer will notify every agency it gave the form to "if and when" it stops using those practices. Combined with the footnote in Section I, this means the attestation has no expiry date. It is valid until you say it is not.

Three things stand out when you read the statements next to the SSDF.

The form is heavy on Prepare the Organization (PO) and Protect the Software (PS) tasks, and especially PO.5, "Implement and Maintain Secure Environments for Software Development." NIST lists PO.5 as the most noteworthy practice added in SSDF version 1.1, and six of the eleven lines in the table above cite it. Build systems, not just source code, were the concern.

The language is qualified throughout: "good-faith effort," "to the greatest extent feasible," "comparable processes." The form demands that each practice exists and is used consistently, not a particular tool or a perfect record.

Statement 4c is the one that catches small vendors. It requires an operating vulnerability disclosure program, not just a security email address. If you signed the form, you promised a program with timelines that you meet.

Who signs, and what the signature means

The instructions say the form "must be signed by the Chief Executive Officer (CEO) of the software producer or their designee." The designee must be an employee of the producer and "have the authority to bind the corporation." A product manager or an outside consultant cannot sign it. Section III has a signature block with the date in YYYY-MM-DD format, name and title.

The Privacy Act statement at the top of the form adds the warning that gave the attestation its weight: "Willfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001, a criminal statute." That statute is about false statements to the federal government in general. M-26-05 did not repeal it. If your company has signed and submitted the form, the statement you made is still a statement you made, and the promise to notify agencies when practices lapse is still in the document they hold. This post is general information, not legal advice; ask your own counsel how any signed attestation applies to your situation.

The third-party assessment alternative

Instead of a signature, a producer could check a box in Section III saying that a third-party assessor organization (3PAO) has evaluated conformance to every element of the form, and attach the assessment. The instructions set the conditions:

• The 3PAO must be FedRAMP certified, or approved in writing by an appropriate agency official.
• The assessor must use relevant NIST guidance that includes every element of the form as the assessment baseline.
• When a producer relies on an assessment, it "need not sign the form."
• The agency must make sure the assessment is not posted publicly, by the vendor or by the agency.

M-22-18 had also allowed agencies to require a third-party assessment instead of a self-attestation "due to the criticality of the service or product," using the definition of critical software in OMB M-21-30. Under M-26-05 that remains an option for any agency that judges the risk to justify it, now without a government-wide floor.

When a producer cannot attest: the POA&M route

The form's "Additional Information" section describes what happens if a producer cannot attest to every practice. The agency may still use the software if the producer:

1. Identifies the practices it cannot attest to.
2. Documents the practices it has in place to mitigate the associated risks.
3. Submits a plan of action and milestones (POA&M) to the agency.

M-22-18 introduced this route and said the documentation must not be posted publicly. M-23-16 tightened it: an agency that accepted a POA&M had to request an extension of the attestation deadline from OMB at the same time, with a copy of the POA&M attached, and had to stop using the software if the documentation was unsatisfactory or if it failed to file the extension request. Where several agencies used the same product, OMB could designate a lead agency to coordinate a common POA&M.

With M-22-18 and M-23-16 rescinded, the OMB extension machinery has no basis. The POA&M itself is still a sensible way to answer an agency that asks for the form and gets an honest "not yet" on one statement. It simply becomes part of the agency's own risk decision rather than a step in an OMB process.

How the form was submitted

The instructions offered two routes. The online route was the Repository for Software Attestations and Artifacts (RSAA) at softwaresecurity.cisa.gov. The offline route was to email a PDF to the agency, named in the pattern Producer_Product_Version_AttestationDate. The example in the form is Acme_SecuritySuite_4.6.2.1_20230124.

CISA announced the RSAA on 18 March 2024, a week after the form, saying producers could "upload software attestation forms and relevant artifacts." When we requested softwaresecurity.cisa.gov on 25 October 2026, it did not return a page to our client. That may be a temporary or client-specific failure, so check it yourself before relying on the repository either way.

The form carries OMB control number 1670-0052, valid until 31 March 2027, and estimates the burden at 3 hours and 20 minutes per response. That is the time to fill in the form, not the time to make the four statements true.

How the mandate was built, then taken apart

The form only makes sense against the policy that created it. Here is the full sequence, with the effect on a producer at each step.

M-22-18: the original requirement

M-22-18, signed by OMB Director Shalanda Young on 14 September 2022, was the memo that made attestation a condition of use. Its key sentence: "Federal agencies must only use software provided by software producers who can attest to complying with the Government-specified secure software development practices." It treated the self-attestation as the "conformance statement" described in NIST's guidance and said agencies must obtain one for every piece of third-party software in scope, "including software renewals and major version changes."

It also set the agency side of the work. Agencies had 90 days to inventory software in scope with a separate inventory for critical software, 120 days to set up a process for communicating requirements and a central place to hold attestations, 270 days to collect attestations for critical software, and 365 days to collect them for everything else. OMB, CISA and GSA were to define a central repository, and CISA was to produce the common form within 120 days.

M-22-18 also said an SBOM "may be required by the agency in solicitation requirements," in an NTIA minimum elements format or successor CISA guidance, and let agencies ask for other artifacts and evidence of a vulnerability disclosure program. None of its 2022 deadlines held; the form took until 2024.

M-23-16: deadlines tied to the form

M-23-16, issued on 9 June 2023, kept the requirement and moved the clock: attestations for critical software were due three months after OMB approved the common form under the Paperwork Reduction Act, and for all other software six months after that approval. It also set the scope rules and the POA&M extension step described above.

The form and the repository arrive

CISA's page for the form says it released the form on 11 March 2024 and that it was developed "in close consultation with" OMB. A week later, on 18 March 2024, CISA published the RSAA. For the rest of 2024 the practical rule for a vendor was simple: if a federal agency used your software and it met one of the three conditions, the agency needed your signed form, a third-party assessment, or a POA&M with an extension.

EO 14144: from paper to machine-readable filings

EO 14144, signed on 16 January 2025 and published at 90 FR 6755, tried to raise the stakes. Section 2(b) said some providers "commit to following cybersecurity practices, yet do not fix well-known exploitable vulnerabilities." It directed OMB to recommend FAR contract language requiring providers to submit machine-readable attestations, high-level artifacts and a list of their federal civilian agency customers to CISA's RSAA. CISA was to validate a sample against the artifacts and pass results to the National Cyber Director for public posting, and failed attestations could be referred to the Attorney General.

EO 14306: the filing plan struck

EO 14306, signed on 6 June 2025 and published at 90 FR 24723, amended EO 14144. Section 1(a) struck subsections 2(a) and 2(b) outright. That removed the RSAA filing requirement, the customer list, the validation program and the referral language.

It did not remove the SSDF work. EO 14306 rewrote the surviving SSDF subsection with new dates: a NIST consortium at the National Cybersecurity Center of Excellence by 1 August 2025 to show how to implement SP 800-218, an update to SP 800-53 on deploying patches and updates by 2 September 2025, and a preliminary update to the SSDF by 1 December 2025, with the final version to follow "within 120 days of publishing the preliminary update." So in mid 2025 the direction was mixed: no new filing regime, but more SSDF, and M-22-18 still in force.

M-26-05: the rescission

M-26-05, signed by OMB Director Russell Vought on 23 January 2026 and titled "Adopting a Risk-based Approach to Software and Hardware Security," is two pages long. We read it from the PDF on whitehouse.gov. It says M-22-18 "imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments," and that the policy neglected hardware threats. It then says M-22-18 and M-23-16 "are hereby rescinded."

What replaces them is short. Agencies must keep a complete inventory of software and hardware, and must develop software and hardware assurance policies that match their own risk determinations and mission needs. They may use the resources built under M-22-18, naming the attestation form. They may adopt contract terms requiring a current SBOM on request, and a footnote says that for a cloud platform the SBOM should cover "the runtime production environment." The memo points agencies to SP 800-218, CISA's draft 2025 Minimum Elements for an SBOM, and CISA's Hardware Bill of Materials framework.

Our M-26-05 explainer goes through the memo line by line and covers the arguments for and against it, so we will not repeat that here.

FAR Case 2023-002: withdrawn

FAR Case 2023-002, "Supply Chain Software Security" (RIN 9000-AO49), was the rulemaking that would have written the form into the Federal Acquisition Regulation. The Spring 2025 Unified Agenda entry described it plainly: "Software producers will be required to comply and attest to complying with certain secure software development requirements by completing a common form." At that point it was still at the proposed rule stage. No final rule was issued.

The later agenda entry on reginfo.gov lists it under Completed Actions with a timetable of "Withdrawn 03/06/2026." Its new abstract says the rule "is closed because it was intended to implement" OMB direction that has since been rescinded, and names M-26-05, M-22-18 and M-23-16.

That withdrawal matters because it closes the route by which attestation would have survived a change of memo. A FAR clause in your contract would bind you regardless of OMB policy. Without it, attestation lives only where an agency chooses to put it: in a solicitation, a contract term or an assurance process.

What CISA's pages say now

CISA has updated how it presents the form. The page at cisa.gov/secure-software-attestation-form now carries an "Archived Content" banner saying the archive "contains outdated information that may not reflect current policy or programs." Its body text still describes the March 2024 release and the M-22-18 requirement, which is why it is archived.

The resource page that hosts the PDF has been rewritten around M-26-05. It says that under M-26-05 agencies must keep a complete software and hardware inventory and set assurance policies aligned with their risk assessments, and that they "may choose to use" the resources created under M-22-18, including the form. The PDF linked from that page is still the version 1.0 form with the 2027 control number, and it still cites M-22-18 as amended by M-23-16 in its authority and instructions. CISA also publishes a Spanish translation.

Where the SSDF stands

The form's practices come from SSDF version 1.1, NIST SP 800-218, finalised in February 2022. That is still the final version. NIST's SSDF project page continues to describe SP 800-218 version 1.1 as the current framework, organised in four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV).

NIST published SP 800-218 Rev. 1, SSDF version 1.2, as an initial public draft on 17 December 2025, as EO 14306 directed. The public comment period closed on 30 January 2026. EO 14306 asked for a final version within 120 days of the preliminary update. As of 25 October 2026, CSRC still lists only the initial public draft, so do not cite version 1.2 as final in a proposal or a trust page.

Separately, NIST has finalised SP 800-218A, an SSDF community profile for generative AI and dual-use foundation models. If you build or fine-tune models and an agency asks how your development practices cover them, that profile is the reference to map to.

M-26-05 still names SP 800-218 as the reference agencies can use. Mapping your practices to the SSDF is therefore worth more under the new policy than under the old one, because every agency writing its own assurance requirements will start from the same framework.

Then and now: what a federal buyer can ask for

The direction of travel is from one uniform form to many agency-specific questions. A vendor that sold to ten agencies used to send the same signed PDF ten times. Now it may get ten different requests: one for the form, one for an SBOM, one for an SSDF-mapped questionnaire, one for hardware provenance, and some for nothing at all.

What a vendor should do today

Here is the practical sequence we would follow, in order. None of it depends on the form being mandatory.

1. Keep a completed form ready for each product

The form is still the cheapest answer an agency can accept. Fill one in for each product line you sell to federal buyers, decide whether the attestation is company-wide or per product, and keep a signed copy ready to send with a fresh date. Do not wait for a request; turnaround on a federal procurement can be days.

Before anyone signs, read the Section I footnote again. The attestation binds future versions until you notify the agency otherwise. If a product line is being sunset, acquired or rebuilt on a new platform, scope the attestation so it does not promise more than you can keep.

2. Build an evidence pack per statement

Agencies under M-22-18 could ask for artifacts, and agencies under M-26-05 will ask for whatever their own process requires. Either way, the questions behind each statement are predictable. Build a folder per product with the evidence below and keep it current.

Keep the evidence internal. M-22-18 and the form both said that assessments and POA&M documentation should not be posted publicly, and the same caution applies to architecture diagrams and logs. Share on request, under the agency's handling terms.

3. Stop telling buyers the form is required

The single most common error we now see in vendor material is the sentence "federal agencies are required to obtain an attestation from us under M-22-18." It was true in 2024. It has not been true since 23 January 2026. A contracting officer or an agency security reviewer who knows the policy will read it as a sign that the rest of your security page is also out of date.

Replace it with what is true. Some before and after wording:

4. Update trust pages, questionnaire libraries and proposal templates

Most vendors carry the stale sentence in more places than they think: the trust or security page, the federal page, the answer library behind security questionnaires, proposal boilerplate, capability statements, partner enablement decks and sales email templates. Search all of them. The checklist and script later in this post help.

When you update an answer library, change the reasoning as well as the citation: yes, we attest and the form is available, rather than yes, because the law says so.

5. Make SBOM delivery routine, including for hosted services

M-26-05 keeps the SBOM on request and adds the runtime production environment requirement for cloud platforms. For a hosted product, that means an SBOM of what actually runs in production, not only of the application repository. In practice that is usually the container images or packages deployed, plus the application dependencies inside them.

The OWASP CycloneDX project publishes open source generators for most ecosystems. A minimal set, run in CI against the code and artifacts you ship:

# Node.js project: write a CycloneDX SBOM for the installed dependency tree
npx @cyclonedx/cyclonedx-npm --output-file sbom/app.cdx.json

# Python: SBOM of the environment the service actually runs in
python -m pip install cyclonedx-bom
cyclonedx-py environment > sbom/python-runtime.cdx.json

# Java with Maven: aggregate SBOM for a multi-module build (writes target/bom.json)
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

# Safeguard CLI: scan a repository, a container image or an existing SBOM
safeguard scan --dir .
safeguard scan --image registry.example.com/app/api:2026.10.24
safeguard scan --sbom sbom/app.cdx.json

Then check each SBOM has the basics an agency will look for before you send it. This short check uses only the Python standard library and reads a CycloneDX JSON file:

#!/usr/bin/env python3
"""Basic completeness check for a CycloneDX JSON SBOM before sending it to a buyer."""
import json, sys

def check(path):
    bom = json.load(open(path))
    problems = []
    meta = bom.get("metadata", {})
    if not meta.get("timestamp"):
        problems.append("metadata.timestamp missing")
    if not (meta.get("component") or {}).get("name"):
        problems.append("metadata.component (the product itself) missing")
    if not (meta.get("supplier") or meta.get("manufacturer") or meta.get("authors")):
        problems.append("no supplier, manufacturer or author in metadata")
    comps = bom.get("components", [])
    if not comps:
        problems.append("no components listed")
    no_version = [c.get("name", "?") for c in comps if not c.get("version")]
    no_id = [c.get("name", "?") for c in comps if not (c.get("purl") or c.get("cpe"))]
    if no_version:
        problems.append(f"{len(no_version)} components without a version, e.g. {no_version[:3]}")
    if no_id:
        problems.append(f"{len(no_id)} components without a purl or cpe, e.g. {no_id[:3]}")
    if not bom.get("dependencies"):
        problems.append("no dependency relationships")
    print(f"{path}: {len(comps)} components")
    for p in problems:
        print(f"  - {p}")
    return not problems

if __name__ == "__main__":
    ok = all(check(p) for p in sys.argv[1:])
    sys.exit(0 if ok else 1)

Run it as python3 sbom_check.py sbom/*.cdx.json. It is a pre-flight check, not a validator for the CISA 2025 minimum elements, which were still a draft when M-26-05 cited them. For the field-by-field picture of one national SBOM standard, our post on the CERT-In SBOM guidelines mapped to CycloneDX shows how a regulator's field list lands in the format.

6. Keep the vulnerability disclosure program real

Statement 4c is easy to sign and easy to let lapse. Publish a disclosure policy with an intake route and response timelines, make sure someone owns the queue, and keep a record of reports handled. It is part of the continuing promise in any form you signed, and the next contractor rules point the same way (see below).

7. Prepare a POA&M format before you need one

If an agency asks for the form and one statement is not fully true, an honest POA&M is better than a signature you cannot stand behind. Keep a template with: the statement and SSDF tasks affected, the current gap, the compensating controls in place now, the milestones with dates and owners, and how you will report progress. Keep it out of public view, as both memos required.

8. Watch SSDF 1.2 and the cryptography rules

Track SP 800-218 Rev. 1 on CSRC and plan to remap your evidence when it is final. Also note that the next government-wide contractor requirements are not about development attestation at all. Executive Order 14412 directs FAR rules on FIPS and post-quantum cryptography compliance and on contractor vulnerability disclosure programs. We cover that in our post on EO 14412 and what federal software vendors need ready for post-quantum questions, and the inventory side in what a cryptographic bill of materials is.

Stale-reference checklist

Use this list to review any document that mentions federal secure software attestation. Each item is a phrase to search for and the fix.

• "M-22-18" or "M-23-16" cited as current. Both rescinded on 23 January 2026 by OMB M-26-05. Cite them only as history.
• "Required," "mandatory" or "must" near "attestation." Attestation is optional per agency. Say you can provide the form on request.
• "FAR Case 2023-002," "RIN 9000-AO49" or "the forthcoming FAR rule." Withdrawn on 6 March 2026.
• "RSAA," "Repository for Software Attestations and Artifacts" or "on file with CISA." The EO 14144 filing requirement was struck by EO 14306 on 6 June 2025. If you did upload a form there in 2024, say that factually and date it.
• "SSDF 1.2" or "SP 800-218 Rev. 1" cited as final. Still an initial public draft as of 25 October 2026.
• Attestation deadlines such as "within 270 days," "by June 2024" or "six months after PRA approval." All belonged to the rescinded memos.
• Old SBOM language such as "SBOM required for critical software under M-22-18." Replace with SBOM on request, and runtime production SBOM for hosted services.
• Missing hardware. If your product ships hardware, M-26-05 asks agencies to assure hardware too. Check whether your federal answers say anything about it.
• Signed forms already submitted. List which agencies hold one and for which products. The notify-on-change promise in Section III still describes what you told them.

For a quick first pass over a folder of text, Markdown, HTML or CSV exports, a single grep finds most of these:

grep -rniE "M-22-18|M-23-16|2023-002|9000-AO49|RSAA|Repository for Software Attestation|machine-readable attestation|SSDF (v|version )?1\.2|800-218 ?Rev|(required|mandatory|must)[^.]{0,60}attest" \
  --include='*.md' --include='*.mdx' --include='*.html' --include='*.txt' --include='*.csv' \
  ./trust ./questionnaires ./proposals

Our M-26-05 explainer includes a fuller standard-library Python script that labels each hit with the policy change and its source. Treat either as a first pass: they match single lines, so read the federal sections of each document end to end as well.

An evidence pack checker

The other half of keeping the form ready is knowing your evidence is current. This script reads a small JSON manifest that maps each Section III statement to evidence files, then reports statements with no evidence, files that are missing, and files older than a threshold you set. It uses only the Python standard library.

#!/usr/bin/env python3
"""Check an attestation evidence pack against the CISA form's Section III statements.

manifest.json example:
{
  "product": "Example API",
  "max_age_days": 180,
  "evidence": {
    "1a": ["arch/build-environments.pdf"],
    "1c": ["idp/mfa-policy-export.json"],
    "4c": ["vdp/policy.md", "vdp/last-report-redacted.md"]
  }
}
Usage: python3 evidence_check.py manifest.json
"""
import json, os, sys, time

STATEMENTS = {
    "1a": "Separated and protected build environments",
    "1b": "Logging and auditing of trust relationships",
    "1c": "MFA and conditional access",
    "1d": "Minimise risky software in build environments",
    "1e": "Encrypt sensitive data such as credentials",
    "1f": "Monitoring and incident response",
    "2": "Trusted source code supply chain",
    "3": "Provenance for internal and third-party code",
    "4a": "Ongoing and pre-release vulnerability checks",
    "4b": "Policy to address vulnerabilities before release",
    "4c": "Vulnerability disclosure program",
}

def main(path):
    m = json.load(open(path))
    base = os.path.dirname(os.path.abspath(path))
    max_age = m.get("max_age_days", 180) * 86400
    now = time.time()
    gaps = 0
    print(f"Evidence check for {m.get('product', '?')}")
    for sid, label in STATEMENTS.items():
        files = m.get("evidence", {}).get(sid, [])
        if not files:
            print(f"  [{sid}] NO EVIDENCE      {label}")
            gaps += 1
            continue
        for f in files:
            p = os.path.join(base, f)
            if not os.path.exists(p):
                print(f"  [{sid}] MISSING FILE     {f}")
                gaps += 1
            elif now - os.path.getmtime(p) > max_age:
                days = int((now - os.path.getmtime(p)) / 86400)
                print(f"  [{sid}] STALE ({days} days) {f}")
                gaps += 1
    print(f"{gaps} gap(s)." if gaps else "All statements have current evidence.")
    return 1 if gaps else 0

if __name__ == "__main__":
    sys.exit(main(sys.argv[1] if len(sys.argv) > 1 else "manifest.json"))

File modification time is a rough proxy for freshness. A policy reviewed last month and saved without changes will look old; record a review date in the file and check that instead if your team prefers.

Common mistakes

Saying the form is legally required. It was, for most software, between 2024 and 23 January 2026. Now it is an agency option. Overstating it erodes trust with exactly the reviewers who know the policy best.

Concluding the form is dead and deleting it. M-26-05 names the form as a resource agencies may use, CISA still hosts it, and its collection approval runs to March 2027. Expect agencies that built processes around it to keep asking.

Forgetting that a signed form is a continuing promise. The Section I footnote and the Section III notification promise both say the attestation lasts until you tell the agency otherwise. A rescinded memo does not withdraw a statement you made.

Reading the third-party component exclusion as "open source does not count." The exclusion means agencies do not collect attestations from component producers. Statements 2 and 3 still require you to manage the third-party code in your product.

Signing for the whole company when one product is behind. Company-wide attestations are convenient, but a single weak product line makes the whole statement untrue. Scope to products, or use a POA&M for the gap.

Sending an application-only SBOM for a hosted service. M-26-05's footnote asks for the runtime production environment for cloud platforms. That usually means the deployed images and their contents, not only the repository lockfile.

FAQ

Is the CISA self-attestation form still required in 2026?

Not government-wide. OMB M-26-05 rescinded M-22-18 and M-23-16 on 23 January 2026, and FAR Case 2023-002 was withdrawn on 6 March 2026. An individual agency can still require the form in a solicitation or contract, so read each request.

Can a federal agency still ask me to sign the Secure Software Development Attestation Form?

Yes. M-26-05 says agencies may choose to use the government-wide resources developed under M-22-18, and it names the form. CISA's resource page repeats that.

Who has to sign the attestation form?

The CEO of the software producer or a designee who is an employee of the producer and has authority to bind the company. If the producer relies on a qualifying third-party assessment instead, the form does not need a signature.

What are the four practices in the CISA attestation form?

Secure development and build environments (with six sub-requirements), a good-faith effort to maintain trusted source code supply chains, provenance for internal and third-party code, and automated vulnerability checking with a policy for pre-release fixes and an operating vulnerability disclosure program.

What is a POA&M in the context of the attestation form?

A plan of action and milestones. If a producer cannot attest to every practice, it identifies the gaps, documents the mitigations in place and submits a POA&M. Under M-23-16 the agency also had to request an extension from OMB; that step no longer applies.

Is SSDF 1.2 final?

No. NIST published SP 800-218 Rev. 1 (SSDF version 1.2) as an initial public draft on 17 December 2025 and closed comments on 30 January 2026. As of 25 October 2026, CSRC lists no final version. SSDF 1.1 remains current.

Do I still need an SBOM for federal customers?

Agencies may adopt contract terms requiring a current SBOM on request. For a cloud platform, M-26-05 says the SBOM should cover the runtime production environment. Be ready to produce one quickly.

Where Safeguard fits

Safeguard does not sign or submit attestations for you, and no tool can make the four statements true on its own. What it can do is produce and keep current much of the evidence behind statements 2, 3 and 4, and make SBOM requests quick to answer.

Today, generally available in Safeguard: SBOM generation and analysis in SPDX and CycloneDX, for repositories, container images and existing SBOM files; vulnerability matching enriched with EPSS and CISA KEV; reachability analysis to rank what your code actually calls; policies and gates evaluated at build, CI and release, which is the kind of pre-release check statement 4a describes; autonomous remediation that opens tested fix pull requests (switched off by default); attestation and signing support for SLSA, Sigstore and in-toto, relevant to the provenance in statement 3; CSAF and VEX upload; and a compliance suite with frameworks, controls, evidence and questionnaires that includes NIST SSDF and EO 14028. The Trust Center, which publishes your posture and helps answer questionnaires, is generally available.

Some of the form is outside what Safeguard covers. Multi-factor authentication policy, network separation of build environments, incident response and the disclosure program itself (statements 1a to 1f and 4c) are organisational controls you evidence from your identity provider, cloud accounts and processes. Safeguard can hold that evidence alongside the rest in its compliance suite, but it does not create it. Safeguard's platform is designed for FedRAMP High, which describes its architecture rather than an authorization, and it is SOC 2 Type II compliant.

The attestation form asks you to manage vulnerabilities in your own code and in the third-party components you ship, before release and on an ongoing basis. Whether or not an agency ever asks for the form, the evidence a reviewer will want is whether vulnerable components leave your pipeline quickly, which is what the section below is about.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real session with the Safeguard CLI. The assistant reads a vulnerability finding and its advisory, asks before any command that changes something, edits package.json to a fixed lodash version, runs npm install and npm test with your approval, prints a summary and pushes nothing. That is the pre-release fix loop statement 4b of the form describes, done in a terminal with a human approving each step.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Federal build environments are often isolated from the internet, and statement 1a asks you to keep them separated; the runner lets you scan code and images where they already live.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. When a federal questionnaire asks about a specific component or SBOM, an assistant connected this way can read your projects and findings so the answer starts from real data instead of memory.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard or start with the CLI documentation.

Quick check

Sources

• OMB Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security (23 January 2026), whitehouse.gov
• OMB memoranda listing, whitehouse.gov
• OMB Memorandum M-22-18 (14 September 2022), archived
• OMB Memorandum M-23-16 (9 June 2023), archived
• CISA, Secure Software Development Attestation Form (archived page)
• CISA, Secure Software Development Attestation Form resource page
• CISA, Secure Software Development Attestation Form, Version 1.0 (PDF, OMB control 1670-0052)
• CISA, CISA Publishes Repository for Software Attestation and Artifacts (18 March 2024)
• Executive Order 14144, Strengthening and Promoting Innovation in the Nation's Cybersecurity, 90 FR 6755 (govinfo)
• Executive Order 14306, Sustaining Select Efforts To Strengthen the Nation's Cybersecurity, 90 FR 24723 (govinfo)
• Unified Agenda, RIN 9000-AO49, FAR Case 2023-002, completed action: withdrawn 6 March 2026 (reginfo.gov)
• Unified Agenda, RIN 9000-AO49, Spring 2025 entry at the proposed rule stage (reginfo.gov)
• NIST SP 800-218, SSDF Version 1.1 (final, February 2022)
• NIST SP 800-218 Rev. 1, SSDF Version 1.2, initial public draft (17 December 2025)
• NIST CSRC, Secure Software Development Framework project
• CISA, 2025 Minimum Elements for a Software Bill of Materials (draft for comment, 22 August 2025)

Related reading: OMB M-26-05 ended the federal software attestation mandate, EO 14412 and post-quantum questions for federal vendors and what a cryptographic bill of materials is.

Last reviewed: 25 October 2026. Federal policy on software assurance is still moving; check the linked OMB, CISA, NIST and reginfo.gov pages for the latest status before relying on a specific requirement.