CISA SSDA Form Explained: Secure Software Development Attestation

What the SSDA Actually Is

The Secure Software Development Attestation, published and collected by CISA on behalf of the federal procurement community, is a self-attestation by a software producer that the software it sells to federal agencies was developed in accordance with the secure development practices defined in the NIST SSDF. It is a federal government Common Form, meaning a single attestation can be filed once and reused across multiple federal customers rather than re-signed per agency. The current collection is hosted in the CISA Repository for Software Attestations and Artifacts (RSAA), and producers submit either through the agency they are selling to or directly into the central repository.

The form is short. It identifies the producer (legal name, address, primary point of contact), identifies the software product or product line being attested to, asks the signing officer to attest that the producer follows the four practice clusters described in the form (which mirror the SSDF practice families), notes whether the producer is using a third-party assessment organisation (3PAO) to corroborate the attestation, and is signed by an officer of the company empowered to bind it. The officer signs under penalty of False Claims Act exposure. That last point is what makes the form load-bearing: the signature is not ceremonial, it is a legal assertion the producer is staking in writing.

The SSDA is not the SSDF. The SSDF is the practice catalogue that lists what secure-software-development work looks like. The SSDA is the federal-procurement evidence package that says the producer does that work. The SSDA reads against SSDF, but it does not enumerate every SSDF practice. It selects a subset of practice clusters that the federal government has determined are load-bearing for the attestation, and it expects the producer to be able to demonstrate the rest of the SSDF posture if asked.

Who Must Attest, and When

OMB Memorandum M-22-18 (issued September 2022) directed federal agencies to require attestations from software producers selling them software whose deployment is covered by the memorandum. M-23-16 (issued June 2023) extended the deadlines and clarified scope. The collection cycle is rolling, but the practical posture for any vendor with federal customers is: if you sell, renew, or ship a major version of software used by a federal agency, you are inside the attestation window.

The scope as published includes software developed after a stated effective date, software where major version changes have been deployed since that date, and software for which the federal customer has continuous service contracts that extend across the attestation cycle. There are exclusions: free and open-source software developed without a producer entity, software developed in-house by the federal agency, and certain narrowly-scoped exceptions. Open-source components inside a producer's product are covered by the producer's attestation, not by the open-source maintainers.

Practically, this means three populations of buyers ask for the form: federal agencies directly, federal system integrators reselling commercial software into agency contracts, and increasingly state, local, and commercial buyers who have adopted the SSDA as their own baseline because it is cheaper than running a bespoke vendor security questionnaire. Internal AppSec teams at vendors find themselves drafting the same evidence package multiple times per quarter. The answer is to operate it as a single recurring record rather than a bespoke response per buyer.

SSDA vs SSDF vs SLSA vs SbD

The supply-chain regulatory and standards landscape is dense. The four artefacts most often confused are SSDA, SSDF, SLSA, and CISA Secure by Design. Each answers a different question and produces a different artefact.

The four artefacts compose. A producer who has implemented SSDF practices, runs a SLSA-compliant build, and has signed up to the SbD pledge holds the supporting record the SSDA reads against. A producer who only files the SSDA without the underlying evidence is making a legal assertion they cannot defend, which is exactly the failure mode the False Claims Act exposure punishes. On the federal customer side, the same producer evidence is what the NIST SP 800-161r1 C-SCRM framework reads against under the SR control family, integrating the producer-side artefacts with the consumer-side supply chain risk register.

The Four SSDA Practice Clusters

The SSDA condenses the SSDF into four practice clusters the signing officer attests to. The clusters mirror SSDF families but consolidate them into language an officer can defensibly read at signing time.

A producer signing the SSDA is asserting that all four clusters are in place at the time of signature. Where they are not, the producer files a Plan of Action and Milestones (POAM) describing the gap and the remediation schedule alongside the form.

The Plan of Action and Milestones (POAM)

The POAM is the escape valve for producers who cannot fully attest. The form allows a producer to attest with exceptions, provided each exception is described in a POAM that names the gap, the remediation work, the milestones, the owner, and the target completion date. Federal customers can accept software backed by a POAM rather than a clean attestation, at their discretion.

POAMs are not a way to defer the work indefinitely. The expectation is that the POAM is a credible, dated remediation plan. A POAM that lists every cluster as in-progress with no closure date is the same as no attestation. The POAM is audited if the federal customer chooses to read it, and it is part of the attestation package the producer is signing under False Claims Act exposure.

Internally, treat the POAM as a finding ledger. Each open gap is a finding with a severity, an owner, a target close date, and a defensible audit trail. The ledger has to be reconcilable across the SSDA cycle: a federal customer who reads the POAM at signing time and reads it again at renewal expects the gaps to have either closed or moved on the documented schedule, not vanished or been silently renamed.

Third-Party Assessment Organisations (3PAOs)

The SSDA allows a producer to back the self-attestation with a third-party assessment from a qualified 3PAO. The 3PAO independently reads the producer's evidence against the SSDF practices the SSDA cites, and issues a report that the producer attaches to the form. 3PAO involvement is currently optional under the published collection rules, but federal customers have begun preferring or requiring it for higher-risk procurements, and some commercial buyers reading the SSDA off-cycle treat 3PAO backing as a baseline.

The 3PAO is reading evidence the producer holds. If the producer's evidence is fragmented across spreadsheets, scanner consoles, ticket queues, and personal knowledge, the 3PAO assessment is expensive and slow. Producers who keep the attestation evidence on a single record consolidate the 3PAO read into a structured walk-through rather than a hunt.

The Supporting Evidence Stack

The form itself is short. The defensible record behind it is not. A producer ready for the attestation cycle holds, at minimum, the following supporting evidence per software product covered by the form. None of this is required to be attached to the form. All of it has to be available within reasonable notice to a federal customer or a 3PAO that asks.

Producers commonly underestimate the size of this stack the first time they attest. The remediation cycle for a producer who has not previously aligned with the SSDF can run six to twelve months before the first defensible attestation. The renewal cycle, once the stack is stood up, is materially shorter because most of the artefacts are already produced as part of the engineering programme.

The Renewal Cycle

The SSDA is not a one-time signature. The federal expectation is that the attestation reflects the producer's current state, and that the producer re-attests on a documented cadence (typically annually) or when material changes to the software or the development programme make the prior attestation inaccurate. Major version releases, acquisitions, divestitures, build platform changes, and material changes to the development team posture are all triggers that invalidate a prior attestation.

Treat the cycle as a recurring engagement record rather than a memo to file. Each cycle has its own evidence pack, its own POAM if one is needed, its own signing officer named, and its own date. The audit trail across cycles is what a 3PAO or a federal customer reads when they want to confirm the producer is running the discipline rather than re-signing the same form annually.

False Statement Penalties

The signature on the SSDA is a representation under penalty of False Claims Act exposure. A producer that signs the form while materially misrepresenting its development practices can face civil penalties under 31 U.S.C. 3729, treble damages on the value of contracts where the misrepresentation was material, and potential debarment from federal procurement. There is also Department of Justice attention: the DOJ Civil Cyber-Fraud Initiative, launched in 2021, has already produced public settlements involving cybersecurity-attestation misstatements.

The practical implication is that the signing officer needs to read the attestation against actual evidence, not against a sales narrative. Producers that treat the SSDA as a sales-enablement signature rather than a security- evidence signature accumulate a misalignment that is expensive when an adverse event surfaces it. This is why internal AppSec, product security, and GRC owners increasingly insist on a single workspace where the attestation evidence is live and reconciled before the officer signs.

Common Failure Modes

Where the SSDA Sits in the Wider Programme

The SSDA does not stand alone. It is the federal-procurement read of a producer's SSDF-aligned development programme. A producer who has invested in the supporting record is also better positioned for ISO 27001 supplier review, SOC 2 vendor management, customer security questionnaires (SIG, CAIQ), and the inbound vendor-risk reading from large enterprise customers. The work is the same; only the audience changes.

Internal AppSec, product security, and GRC owners increasingly position the SSDA evidence pack as the canonical source of truth that other reads cite. The vendor security questionnaire response workflow consumes the same SSDA evidence to draft customer responses at deal velocity. The cross-framework control crosswalk reuses the same canonical control library against ISO 27001 Annex A, SOC 2 CC, PCI DSS Requirement 6, NIST SP 800-53, and the SSDF practice catalogue. The audit-evidence retention and disposal workflow governs how long each artefact stays in the record. The control gap remediation workflow closes the gaps named in POAMs.

The SSDA is one read against the same canonical record that ISO 27001 audits, SOC 2 examinations, customer questionnaires, and the producer's own internal posture readings consume. Treating the SSDA as a separate process is why teams burn out drafting the same evidence five different ways.

How SecPortal Helps Producers Stand the Stack Up

SecPortal does not file the SSDA on the producer's behalf. The platform is not a CISA submission portal, it does not auto-attest, and it does not act as the signing officer. What SecPortal does is hold the supporting evidence stack on a single workspace so the signing officer, the 3PAO, the federal customer, and the renewal-cycle owner can all read the same record.

• The attestation cycle becomes a versioned engagement record with named participants, named officer, target signature date, and the prior cycle linked alongside.
• The form itself, the 3PAO report, the POAM, the prior attestation, and the supporting policy documents land in document management with versioning, timestamp, and author attribution.
• The four practice clusters map to compliance tracking alongside ISO 27001, SOC 2, PCI DSS, and NIST framework mappings, so closing a control reflects across every compliance read at once.
• The POAM ledger is findings management with CVSS-aligned severity, named owner, target close date, and the trail of state changes; every gap closes the same way every other finding closes.
• Vulnerability-handling evidence comes from external scanning, authenticated scanning, code scanning via Semgrep SAST and SCA, and continuous monitoring with scheduled scans, with each finding carrying its own audit trail.
• The audit trail itself is the activity log with timestamped state changes per user, retained on the plan-defined window and exportable to CSV for the 3PAO and the federal customer.
• The development-environment posture lands behind MFA, team management with role-based access controls, and AES-256-GCM encrypted credential storage for credentials referenced by the evidence record.
• The narrative read for the signing officer or the 3PAO can be drafted by AI report generation from the live evidence, named author edits, and named approver signs off; the AI accelerates the draft rather than substitutes for the security author.

The platform is the recurring evidence record, not the legal instrument. The officer still signs the form. SecPortal keeps the underlying record reconcilable cycle over cycle so the signature is defensible.

A Practical Rollout Plan

Producers approaching the SSDA for the first time benefit from a simple sequenced rollout rather than a horizontal compliance push. The order below reflects the dependencies inside the form: development environment first, because everything else depends on access discipline; provenance second, because the attestation reads against the artefacts produced; audit and review third, because that is where the recurring scanner cadence lands; and disclosure and remediation fourth, because that is the runtime side that has to be tested under live conditions.

1. Run an SSDF gap analysis. Map every PO, PS, PW, and RV practice to a current owner and current evidence. Mark practices as in-place, partial, or absent. Use the SSDF implementation guide for the practice-by-practice walkthrough.
2. Stand up the development-environment evidence. Enforce MFA on developer access, document the RBAC model, archive the joiner-mover-leaver runbook, capture the audit trail of access changes.
3. Stand up code provenance. Land an SBOM per release, pin dependencies, configure branch protection and signed commits, and stand up a SLSA-aligned build platform if the SBOM-only baseline is insufficient.
4. Stand up the code-audit cadence. Configure SAST and SCA in the pipeline, configure secret scanning, define the threat-modelling cadence per major feature, archive scanner result history per release.
5. Stand up the vulnerability disclosure programme. Publish the policy, document the intake channel, define the SLA per severity, archive the per-disclosure record. The vulnerability disclosure programme setup guide names the structural pieces.
6. Draft the POAM. For each gap that will not close before the first attestation, name the owner, target date, milestones, and the federal customer notification language. Treat the POAM as a finding ledger.
7. Brief the signing officer. Walk the officer through the four clusters, the evidence behind each, the POAM, and the False Claims Act exposure of the signature. Document the brief.
8. Sign and file. Submit the form to the federal customer or the CISA RSAA repository. Archive the submission alongside the evidence pack. Set the renewal cycle.

Wider Reading

• NIST SSDF implementation guide for the practice-by-practice walkthrough that the SSDA reads against.
• SLSA framework guide for the build-integrity scaffold under the provenance cluster.
• SBOM guide for the component-inventory format the provenance cluster expects.
• VEX guide for the per-CVE exploitability filter that pairs with SBOM in the vulnerability-handling cluster.
• CVE Numbering Authority explained for the upstream identifier-issuance layer producer organisations work within when publishing supply-chain advisories alongside the attestation.
• Common Weakness Enumeration explained for the weakness-classification axis the audit cluster reads against.
• Vulnerability disclosure programme setup guide for the upstream policy and intake design behind the disclosure cluster.
• Vulnerability management programme guide for the operational triage and remediation discipline the RV cluster reads against.
• Vendor security questionnaire response workflow for the customer-facing read that consumes the same SSDA evidence.
• Control mapping cross-framework crosswalks for the canonical control library the SSDA reads against alongside ISO, SOC 2, PCI DSS, and NIST.
• Audit evidence retention and disposal for the lifecycle policy that governs how long each piece of attestation evidence stays in the record.
• Control gap remediation workflow for the gap-to-evidence loop that closes POAM entries.
• NIST, ISO 27001, SOC 2, and CISA Secure by Design for the framework-side reads that share the same evidence stack the SSDA consumes.
• SecPortal for product security teams and SecPortal for GRC and compliance teams for the persona-side reading paths into the SSDA evidence record.