What is the CISA Secure Software Development Attestation Form and who has to submit it?

The CISA Secure Software Development Attestation Form (commonly called the CISA SSDA or the CISA Attestation Form) is the one-page self-attestation form that software producers sign and submit through CISA's Repository for Software Attestations and Artifacts (RSAA) when they sell software to United States federal agencies. The form attests that the software was developed in line with the four practice statements that distill the NIST Secure Software Development Framework (SP 800-218) into the federal procurement read. The producer's CEO, or a designee with delegated signing authority recorded in writing, signs the attestation under the False Claims Act and federal procurement integrity rules. The attestation is required by OMB M-22-18 (Sept 2022), as updated by OMB M-23-16 (June 2023), which implement Section 4(e) of Executive Order 14028 on Improving the Nation's Cybersecurity. Producers must submit a separate attestation for each software product sold to each agency unless the producer files a common attestation that covers a product portfolio. Agencies that buy critical software at higher risk tiers may require additional artefacts (SBOM, third-party assessment, POAM for any gap the producer cannot attest to fully) alongside the form.

What is in the CISA Attestation Form template and how is the template different from the CISA-published blank form?

The CISA-published blank form is a short PDF that names the attestation language, the practice clusters, and the signatory block. The blank form does not name the evidence the producer has to keep behind the signature. The template here is the producer-side workbook that turns the one-page attestation into a defensible operating artefact. The template carries fourteen sections: cover identity block naming the producer entity, the product or product family in scope, and the federal agencies the attestation is filed against; signatory authority block naming the CEO or designee with the dated delegation memo; practice cluster 1 (separated and secure software development environment) row-by-row attestation language, control objective, supporting evidence pointer, named-owner, last-verified date, and POAM if attestation cannot be made fully; practice cluster 2 (provenance and integrity, including SBOM and SLSA artefacts) the same row structure; practice cluster 3 (vulnerability disclosure programme and management) the same row structure; practice cluster 4 (good coding practices and secure-by-design alignment) the same row structure; supporting evidence index naming the underlying SSDF practice from SP 800-218 each row reads against; POAM register with finding identifier, gap description, named owner, target completion date, compensating control, and renewal review cadence; 3PAO assessment register where a third-party assessment organisation has audited the practice cluster; renewal cadence calendar with the named amendment triggers; SBOM provision commitment naming the format (CycloneDX 1.5 or 1.6, SPDX 2.3, SPDX 3.0), the NTIA Minimum Elements coverage, the publication channel, and the agency-specific delivery mechanism; VEX statement commitment where the producer publishes VEX (CSAF 2.0 or CycloneDX VEX 1.5); audit-trail commitment binding the signed attestation to a named document custodian; common attestation declaration where the producer files one attestation covering a portfolio of products with the named exception register for products outside the common scope; document control footer with version, effective date, next review date, named custodian, and approval chain.

Does the CISA SSDA Attestation Form replace the NIST SSDF programme that backs it?

The attestation form is a federal procurement read against the underlying SSDF programme. The form does not replace the programme; the programme is the operating discipline that lets the producer defend the signature. The SSDF is NIST SP 800-218, which names four practice groups and roughly thirty practices across them: Prepare the Organization (PO) covering programme governance, roles, and toolchain; Protect the Software (PS) covering source code integrity, signing, and provenance; Produce Well-Secured Software (PW) covering threat modelling, secure design, code review, security testing, and dependency review; Respond to Vulnerabilities (RV) covering vulnerability identification, disclosure, and remediation. The CISA Attestation Form selects from these practices and distills them into four practice clusters that map cleanly to the SP 800-218 practices the producer attests to. A defensible attestation requires the producer to keep the SSDF programme document, the practice-by-practice mapping, the evidence pointers, the POAM list, and the operating record current. The template in this artefact is the form-side workbook; pair it with the wider SSDF programme document for the practice-side rollout.

What is a POAM and when does a producer need a POAM behind the attestation?

A POAM (Plan of Action and Milestones) is the federal-procurement instrument that records a known gap against an attested practice, the compensating control the producer applies in the interim, the named owner, the target completion date, and the renewal review cadence. The producer files a POAM when it cannot attest to a practice cluster fully but can demonstrate that the gap is known, owned, compensated, and on a path to closure. The POAM has to be specific (which practice or sub-practice is the gap), specific in time (named target completion date with monthly or quarterly milestones), specific in owner (named role and named person), and specific in compensating control (what the producer does today while the gap is open). A POAM is not a vague intent. A POAM is also not a permanent state: most federal agencies will accept a POAM of up to twelve to eighteen months on a non-critical gap and substantially shorter (thirty to ninety days) on a critical gap. The producer's POAM register pairs each open POAM to the underlying finding identifier in the wider vulnerability programme so the gap closes when the finding closes. The template's POAM register section names the seven columns the federal agency reads against the attestation.

How does a producer use the template alongside SecPortal to keep the attestation defensible?

SecPortal does not submit the SSDA to CISA on behalf of the producer (the submission flows through the RSAA portal under the producer signing officer authority), does not replace the legal review and signing chain (general counsel and the signing officer carry that), and does not replace the 3PAO assessment engagement workflow where one is commissioned. What SecPortal does is carry the supporting evidence chain that backs each attested practice cluster and each POAM. The signed SSDA itself lives as a versioned record under document management with the named custodian, the named signing officer, the dated delegation memo, the effective period, and the renewal review trigger. The supporting evidence pack lives on the live workspace: SAST and SCA findings from code scanning against connected repositories (GitHub, GitLab, Bitbucket), external scanner findings from domain scanning, authenticated scanner findings from authenticated scanning, bulk-imported third-party scanner findings (Burp, Nessus, generic CSV) for the wider provenance evidence, the SBOM artefacts under document management with version history, the POAM register against finding overrides for any open POAM, the named-actor sign-off chain on the activity log with 30, 90, or 365-day retention by plan, the compliance tracking mapping against NIST SSDF, EO 14028, OMB M-22-18 and M-23-16, NIST CSF 2.0, NIST SP 800-53, ISO 27001, SOC 2, OWASP ASVS, OWASP SAMM, CIS Controls, the retesting workflow pairing each remediated finding to verified-fixed evidence the SSDA references, and the AI report generation drafting the executive summary and the cluster-by-cluster narrative the signing officer reads before signing. Honest scope: SecPortal does not issue or stamp the attestation, does not file the form, does not provide legal counsel, does not replace 3PAO assessment, does not ship Jira, ServiceNow, Slack, PagerDuty, SIEM, SOAR, GRC, or CMDB push connectors, and does not provide federal contracting registration services.

How does the CISA SSDA Attestation Form relate to FedRAMP, FISMA, NIST SP 800-53, and other federal compliance regimes?

FedRAMP is a federal cloud security authorisation programme that authorises a cloud service offering for federal use against NIST SP 800-53 controls; FISMA is the federal information security management act that names the federal agency information security programme baseline; NIST SP 800-53 is the control catalogue the FedRAMP authorisation reads against. The CISA SSDA is the federal procurement attestation that the software the federal agency is buying was developed in line with the NIST SSDF (SP 800-218), which is a different document from SP 800-53 (the deployment-side control catalogue). The SSDA reads the development-side practices; FedRAMP reads the deployment-side controls. A FedRAMP-authorised cloud service provider still has to file the SSDA for the software the federal agency is buying; conversely, a producer with an SSDA on file is not automatically FedRAMP-authorised. The evidence overlap is real: SBOM artefacts, vulnerability disclosure programme operation, secure-development-environment evidence, and provenance evidence are read by both regimes. The template's framework crosswalk section names the SSDA-to-SSDF mapping, the SSDA-to-NIST CSF 2.0 mapping, the SSDA-to-NIST SP 800-53 mapping, the SSDA-to-ISO 27001 mapping, and the SSDA-to-SOC 2 mapping so the same supporting evidence reads against the parallel regimes.

How does the EU Cyber Resilience Act and other non-US regimes affect the CISA SSDA?

The EU Cyber Resilience Act (Regulation 2024/2847, in force October 2024, with general application from December 2027 and earlier obligations for incident reporting from September 2026) introduces parallel attestation expectations for products with digital elements sold in the EU market. Producers under CRA scope have to maintain a vulnerability handling process across the product lifetime, a coordinated vulnerability disclosure mechanism, free security updates throughout the support period, a software bill of materials, and conformity assessment documentation. The CRA-side attestation is the EU Declaration of Conformity under Annex V, which references the underlying technical documentation. Producers selling into both the US federal market and the EU market should align the supporting evidence pack so the same SAST, SCA, DAST, secret scanning, SBOM, VDP operating record, and POAM register reads against both the CISA SSDA and the EU CRA technical documentation. The CRA timeline accelerates over 2026 and 2027 for non-US producers; the template's framework crosswalk section names the SSDA-to-CRA mapping so producers can run a single supporting evidence chain against both regimes. Similar parallel regimes are emerging in the UK (NCSC and the wider product security regulation), Canada (the Canadian Centre for Cyber Security guidance), and Australia (the Cyber Security Strategy 2023 to 2030 and the proposed security of critical infrastructure act amendments).

How is the CISA SSDA Attestation Form template different from the SBOM policy template and the AI System AUP template?

The SBOM policy template carries the producer-side workforce policy on SBOM generation, signing, publication, inbound vendor SBOM acceptance, retention, and crosswalk; it is the policy posture. The CISA SSDA Attestation Form template here is the filled-form artefact workbook that turns the SSDA into a defensible operating record with the supporting evidence pack and the POAM register. The two templates reference each other: the SBOM policy provides the workforce rule the SSDA practice cluster 2 (provenance and integrity) attests against, and the SSDA template provides the federal procurement read of the underlying SBOM policy commitment. The AI System AUP template carries the workforce-facing rule on AI tool use; it does not cover SSDF or federal software producer attestation. A producer that sells software to federal agencies needs all three documents: the AI System AUP (workforce AI behaviour), the SBOM policy (SBOM posture and operating model), and the SSDA Attestation Form workbook (federal procurement attestation). The three documents form a coherent stack with the SSDF programme document, the vulnerability management policy, the secure coding policy, the threat modelling policy, the secure code review policy, the vulnerability disclosure policy, the dependency review policy, and the secrets management policy sitting alongside.

Free Tool

CISA Secure Software Attestation Form Template
a fourteen-section workbook for the federal SSDA covering identity, signatory chain, the four practice clusters, POAM, 3PAO, SBOM, VEX, audit trail, renewal cadence, and framework crosswalk

A free, copy-ready CISA Secure Software Development Attestation (SSDA) workbook. Fourteen structured sections covering cover identity and software in scope, signatory authority and False Claims Act exposure, practice cluster 1 (separated and secure software development environment), practice cluster 2 (provenance, integrity, SBOM, SLSA), practice cluster 3 (vulnerability disclosure programme and management), practice cluster 4 (good coding practices and secure-by-design), supporting evidence index, POAM (Plan of Action and Milestones) register, 3PAO (Third-Party Assessment Organization) register, SBOM provision and VEX statement commitment, audit trail and document custodian, renewal cadence and ten named amendment triggers, framework crosswalk against NIST SSDF SP 800-218, EO 14028, OMB M-22-18 and M-23-16, NIST CSF 2.0, NIST SP 800-53 Rev. 5, FedRAMP, NIST SP 800-37, ISO/IEC 27001:2022, SOC 2, PCI DSS, EU Cyber Resilience Act Annex I and Annex V, OWASP ASVS, OWASP SAMM, CIS Controls v8.1, and document control footer. Built for federal software producers, AppSec teams, product security teams, internal security teams, GRC and compliance teams, security engineering teams, CISOs, and security architects that need a defensible producer-side workbook the inspector general, the 3PAO assessor, the federal agency contracting officer, the qui tam relator, and the Department of Justice civil enforcement read against the signed SSDA.

Get Started Free

No credit card required. Free plan available forever.

Fourteen sections that turn the one-page CISA attestation into a defensible operating workbook

The CISA Secure Software Development Attestation (CISA SSDA) is the one-page form United States federal software producers sign and submit through the CISA Repository for Software Attestations and Artifacts (RSAA) under OMB M-22-18 (Sept 2022) and OMB M-23-16 (June 2023), implementing Section 4(e) of Executive Order 14028. The form is short. The producer-side workbook behind it has to be defensible against an inspector general inquiry, a federal agency follow-up, a qui tam relator review, and a Department of Justice civil enforcement action under the False Claims Act. The fourteen sections below convert the one-page form into the operating record the signing officer can defend.

Pair the workbook with the wider CISA SSDA form guide for the form-level walkthrough, the NIST SSDF implementation guide for the practice-by-practice rollout the SSDA reads against, the secure SDLC policy template for the thirteen-section secure development policy that maps directly to NIST SSDF PO.1 and PW family practices and backs the attestation cluster 1 obligations, the SBOM policy template for the producer-side workforce policy on SBOM generation and publication, the vulnerability disclosure policy template for the VDP rule that backs cluster 3, and the vulnerability management policy template for the underlying VM operating model. Copy the section that fits your stage and complete the placeholders as the SSDF programme matures.

Copy the full SSDA workbook (all fourteen sections) as one block.

1. Cover identity, software in scope, and federal agencies

Open the CISA SSDA Attestation workbook with the producer identity, the software product or product family the attestation covers, and the federal agencies the attestation is filed against. The OMB M-22-18 (Sept 2022) and OMB M-23-16 (June 2023) common-attestation route lets the producer file one attestation against a portfolio rather than one form per product per agency; the cover identity block names the scope explicitly so the federal agency reviewer reads the boundary before reading the practice clusters.

Producer identity:
- Producer legal name: {{PRODUCER_LEGAL_NAME}}
- Producer DUNS / UEI (System for Award Management Unique Entity Identifier): {{PRODUCER_UEI}}
- Producer CAGE code: {{PRODUCER_CAGE_CODE}}
- Producer SAM.gov registration status: {{PRODUCER_SAM_REGISTRATION_STATUS}}
- Producer business street address: {{PRODUCER_ADDRESS_LINE_1}}
- Producer city, state, postal code: {{PRODUCER_ADDRESS_LINE_2}}
- Producer country of incorporation: {{PRODUCER_COUNTRY_OF_INCORPORATION}}
- Producer point of contact (named individual): {{PRODUCER_POC_NAME}}
- Producer point of contact role: {{PRODUCER_POC_ROLE}}
- Producer point of contact email: {{PRODUCER_POC_EMAIL}}
- Producer point of contact telephone: {{PRODUCER_POC_TELEPHONE}}

Software product or product family in scope:
- Product or product family name: {{PRODUCT_FAMILY_NAME}}
- Product description (one paragraph, plain language, written for the federal agency contracting officer reading the attestation): {{PRODUCT_DESCRIPTION}}
- Software type (commercial off-the-shelf product, commercial product with material modifications, custom software, open source distribution with proprietary additions): {{SOFTWARE_TYPE}}
- Deployment model (on-premises license, software-as-a-service, hybrid cloud, FedRAMP-authorised cloud service): {{DEPLOYMENT_MODEL}}
- Software version covered (version range or commit identifier): {{SOFTWARE_VERSION_COVERAGE}}
- Critical software determination per OMB M-21-30 (yes or no, and if yes, the named critical software class): {{CRITICAL_SOFTWARE_DETERMINATION}}
- Open source declaration (is the product open source, embeds open source, or distributes open source): {{OPEN_SOURCE_DECLARATION}}
- SBOM provision commitment (CycloneDX 1.5, CycloneDX 1.6, SPDX 2.3, SPDX 3.0): {{SBOM_FORMAT_COMMITMENT}}
- SBOM publication channel and delivery mechanism: {{SBOM_PUBLICATION_CHANNEL}}
- VEX statement commitment (CSAF 2.0, CycloneDX VEX 1.5, OpenVEX): {{VEX_FORMAT_COMMITMENT}}

Federal agencies the attestation is filed against:
- Common attestation (one form against the producer portfolio): {{COMMON_ATTESTATION_YES_NO}}
- Named agencies (where the attestation is filed per agency rather than as a common attestation): {{NAMED_AGENCIES_LIST}}
- Contract identifiers (where the attestation is filed against named contracts): {{CONTRACT_IDENTIFIERS_LIST}}
- Submitted through CISA RSAA (Repository for Software Attestations and Artifacts): {{SUBMITTED_THROUGH_RSAA_YES_NO}}
- RSAA submission identifier (after submission): {{RSAA_SUBMISSION_IDENTIFIER}}

Attestation scope exclusion (the named products or product families the producer carries that are out of scope of this attestation):
- Excluded products or product families: {{EXCLUDED_PRODUCTS}}
- Rationale for exclusion: {{EXCLUSION_RATIONALE}}
- Separate attestation filed for excluded products: {{SEPARATE_ATTESTATION_REFERENCE}}

Effective period:
- Attestation effective date: {{ATTESTATION_EFFECTIVE_DATE}}
- Attestation last review date: {{ATTESTATION_LAST_REVIEW_DATE}}
- Attestation next scheduled review date: {{ATTESTATION_NEXT_REVIEW_DATE}}
- Renewal triggers reference (see Section 12 of this workbook): see Section 12 named amendment triggers

2. Signatory authority and False Claims Act exposure

OMB M-22-18 names the CEO or a delegated designee as the signatory. The signature is made under the False Claims Act (31 U.S.C. 3729 et seq.) and the federal procurement integrity statutes. Capture the named signing officer, the dated delegation memo if the CEO delegates, the general counsel review record, the named legal review date, and the named filing date so the inspector general inquiry reads a clean signing chain.

Signing officer:
- Signatory name: {{SIGNATORY_NAME}}
- Signatory title at time of signature: {{SIGNATORY_TITLE}}
- Signatory legal authority basis (CEO, delegated designee under written delegation, sole proprietor): {{SIGNATORY_AUTHORITY_BASIS}}
- Where signatory is a delegated designee, the dated delegation memo from the CEO is on file as: {{DELEGATION_MEMO_REFERENCE}}
- Delegation memo effective date: {{DELEGATION_MEMO_EFFECTIVE_DATE}}
- Delegation memo expiry or renewal date: {{DELEGATION_MEMO_EXPIRY_DATE}}

False Claims Act and federal procurement integrity acknowledgement (the signing officer reads and accepts the following before signing):
- I, the undersigned, am the Chief Executive Officer of the producer or a designee with delegated signing authority recorded in writing.
- I am authorised to bind the producer to the attestations made on this form.
- I make this attestation under the False Claims Act (31 U.S.C. 3729 et seq.) and the federal procurement integrity statutes.
- I understand that a materially false attestation may result in civil and criminal liability, treble damages, civil penalties, suspension or debarment from federal contracting, and criminal prosecution where the false statement is knowing and willful.
- I understand that personal liability under the False Claims Act and the related federal procurement integrity statutes is not extinguished by corporate indemnification.
- I have reviewed the underlying SSDF programme document, the practice cluster mapping, the supporting evidence index, the POAM register, and the 3PAO assessment register (where applicable) before signing.

Legal review record:
- General counsel review completed by: {{GC_REVIEWER_NAME}}
- General counsel review date: {{GC_REVIEW_DATE}}
- Outside counsel review (if applicable): {{OUTSIDE_COUNSEL_REVIEW}}
- Legal review record stored at: {{LEGAL_REVIEW_RECORD_STORAGE}}
- Open legal questions resolved before signing: {{LEGAL_QUESTIONS_RESOLVED}}

Internal sign-off chain (the named roles that confirm the attestation is defensible against an inspector general inquiry before the signing officer signs):
- Chief Information Security Officer (security content owner): {{CISO_REVIEW_NAME_AND_DATE}}
- AppSec or product security lead (the practitioner-side rollout owner): {{APPSEC_LEAD_REVIEW_NAME_AND_DATE}}
- GRC and compliance owner: {{GRC_OWNER_REVIEW_NAME_AND_DATE}}
- Internal audit (where the organisation has an internal audit function): {{INTERNAL_AUDIT_REVIEW_NAME_AND_DATE}}
- Procurement and federal sales lead: {{FEDERAL_SALES_LEAD_REVIEW_NAME_AND_DATE}}
- General Counsel or designee: {{LEGAL_REVIEW_NAME_AND_DATE}}
- Signing officer: {{SIGNING_OFFICER_NAME_AND_DATE}}

Signature block:
- Signature: {{HANDWRITTEN_OR_DIGITAL_SIGNATURE}}
- Printed name: {{SIGNATORY_PRINTED_NAME}}
- Title: {{SIGNATORY_TITLE_AT_SIGNATURE}}
- Date of signature: {{DATE_OF_SIGNATURE}}
- Location of signature: {{LOCATION_OF_SIGNATURE}}
- Witness or notary (if required by procurement vehicle): {{WITNESS_NOTARY_RECORD}}

3. Practice cluster 1: separated and secure software development environment

Practice cluster 1 attests that the producer maintains a separated build environment with documented access control, secrets management, ephemeral build infrastructure, signed artefacts, and integrity protection of the build pipeline. Underlying SSDF practices: PO.5 (implement security in the SDLC), PS.1 (protect all forms of code from unauthorised access and tampering), PS.2 (provide a mechanism for verifying software release integrity), PS.3 (archive and protect each software release), PO.3 (implement supporting toolchains). The row template carries the attestation language verbatim, the underlying control, the named supporting evidence, the named owner, the last verified date, and the POAM identifier where the producer cannot attest fully.

Attestation row template (use one row per attested sub-practice):

Row 1.1: Software development is performed in secure environments separated from production environments.
- Attestation language (verbatim from the CISA SSDA): "The software is developed and built in secure environments. Those environments are secured by the following actions, at a minimum: separating and protecting each environment involved in developing and building software."
- Underlying SSDF practice: PO.5.1, PS.1.1, PS.1.2
- Control objective: Separation of development, build, integration, and production environments is enforced through documented access control, network boundary, and identity boundary.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_1_1}} (named document identifier in document management workspace)
- Named owner: {{NAMED_OWNER_1_1}}
- Last verified date: {{LAST_VERIFIED_DATE_1_1}}
- Attestation status (Yes / Yes-with-POAM / No): {{ATTESTATION_STATUS_1_1}}
- POAM identifier (where Yes-with-POAM or No): {{POAM_IDENTIFIER_1_1}}

Row 1.2: Multi-factor authentication and conditional access are enforced across the build environment.
- Attestation language (verbatim): "regularly logging, monitoring, and auditing trust relationships used for authorisation and access to any software development and build environments and among components within each environment."
- Underlying SSDF practice: PO.5.2, PS.1.1
- Control objective: Multi-factor authentication is required for all access to the build environment. Conditional access policies restrict the access to the build environment to authorised devices, locations, and authorised users.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_1_2}}
- Named owner: {{NAMED_OWNER_1_2}}
- Last verified date: {{LAST_VERIFIED_DATE_1_2}}
- Attestation status: {{ATTESTATION_STATUS_1_2}}
- POAM identifier: {{POAM_IDENTIFIER_1_2}}

Row 1.3: Secrets management is enforced in build environments; secrets are not stored in source code or unencrypted in logs.
- Attestation language (verbatim): "enforcing multi-factor authentication and conditional access across the environments relevant to developing and building software in a manner that minimises security risk."
- Underlying SSDF practice: PS.1.1, PO.5.1
- Control objective: Credentials, API keys, encryption keys, signing keys, and TLS keys used by the build pipeline are stored in a vault with hardware-backed protection where applicable, with access only by named build identities; secrets are not in source code or logs.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_1_3}}
- Named owner: {{NAMED_OWNER_1_3}}
- Last verified date: {{LAST_VERIFIED_DATE_1_3}}
- Attestation status: {{ATTESTATION_STATUS_1_3}}
- POAM identifier: {{POAM_IDENTIFIER_1_3}}

Row 1.4: Build environment integrity is protected; signed releases are verifiable.
- Attestation language (verbatim): "taking consistent and reasonable steps to document as well as minimise use or inclusion of software products that create undue risk within the environments used to develop and build software."
- Underlying SSDF practice: PS.2.1, PS.3.1, PO.5.2
- Control objective: Each released software artefact has a verifiable signature; build provenance is captured (SLSA Level 2 or higher where applicable); release integrity can be verified by a downstream consumer.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_1_4}}
- Named owner: {{NAMED_OWNER_1_4}}
- Last verified date: {{LAST_VERIFIED_DATE_1_4}}
- Attestation status: {{ATTESTATION_STATUS_1_4}}
- POAM identifier: {{POAM_IDENTIFIER_1_4}}

Row 1.5: Encrypted boundaries and integrity protection of source code and software in storage and in transit.
- Attestation language (verbatim): "encrypting sensitive data, such as credentials, to the extent practicable and based on risk."
- Underlying SSDF practice: PS.1.2, PS.3.2
- Control objective: Source code repositories, build artefacts, and release artefacts are protected by encryption at rest with hardware-backed key custody where applicable, encryption in transit, and verifiable integrity hashes.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_1_5}}
- Named owner: {{NAMED_OWNER_1_5}}
- Last verified date: {{LAST_VERIFIED_DATE_1_5}}
- Attestation status: {{ATTESTATION_STATUS_1_5}}
- POAM identifier: {{POAM_IDENTIFIER_1_5}}

Row 1.6: Logging, monitoring, and incident response coverage of the build environment.
- Attestation language (verbatim): "implementing defensive cybersecurity practices, including continuous monitoring of operations and alerts and, as necessary, responding to suspected and confirmed cyber incidents."
- Underlying SSDF practice: PO.3.2, PS.1.1, RV.1.1
- Control objective: Build environment activity is logged with named retention, monitored against the named detection baseline, and connected to the named incident response runbook.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_1_6}}
- Named owner: {{NAMED_OWNER_1_6}}
- Last verified date: {{LAST_VERIFIED_DATE_1_6}}
- Attestation status: {{ATTESTATION_STATUS_1_6}}
- POAM identifier: {{POAM_IDENTIFIER_1_6}}

4. Practice cluster 2: provenance and integrity, SBOM, SLSA

Practice cluster 2 attests that the producer maintains provenance of all components in the software, generates a software bill of materials (SBOM) in a machine-readable format, attests to the integrity of build-time artefacts (SLSA Level 2 or higher provenance where applicable), and signs releases with verifiable signing material. Underlying SSDF practices: PS.2, PS.3, PW.4, PO.5. The row template carries the named SBOM format, the SBOM publication channel, the provenance attestation format, the named owner, the last verified date, and the POAM identifier.

Row 2.1: Software produces and maintains provenance data for internal and third-party code incorporated into the software.
- Attestation language (verbatim): "the software producer makes a good-faith effort to maintain trusted source code supply chains by employing automated tools or comparable processes to maintain provenance data for internal and third-party code incorporated into the software."
- Underlying SSDF practice: PS.3.1, PW.4.4, PO.5.2
- Control objective: Provenance data for first-party code (commit identifier, build identifier, signed build attestation) and third-party code (package source, version, integrity hash, license) is captured automatically through the build pipeline.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_2_1}}
- Named owner: {{NAMED_OWNER_2_1}}
- Last verified date: {{LAST_VERIFIED_DATE_2_1}}
- Attestation status: {{ATTESTATION_STATUS_2_1}}
- POAM identifier: {{POAM_IDENTIFIER_2_1}}

Row 2.2: Software producer makes a good-faith effort to ensure third-party software components are not vulnerable.
- Attestation language (verbatim): "the software producer employs automated tools or comparable processes that check for security vulnerabilities."
- Underlying SSDF practice: PW.4.5, PW.4.6
- Control objective: Continuous SCA (software composition analysis) runs against the dependency tree of the software; known-vulnerable dependencies are blocked or routed through the documented exception process; dependency reviews are part of the merge gate.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_2_2}}
- Named owner: {{NAMED_OWNER_2_2}}
- Last verified date: {{LAST_VERIFIED_DATE_2_2}}
- Attestation status: {{ATTESTATION_STATUS_2_2}}
- POAM identifier: {{POAM_IDENTIFIER_2_2}}

Row 2.3: SBOM is produced in a machine-readable format and made available to the federal agency.
- SBOM format committed: {{SBOM_FORMAT_COMMITTED}} (CycloneDX 1.5, CycloneDX 1.6, SPDX 2.3, SPDX 3.0)
- NTIA Minimum Elements coverage attested: {{NTIA_MINIMUM_ELEMENTS_COVERAGE}} (supplier, component name, version, unique identifier, dependency relationship, SBOM author, timestamp)
- SBOM publication channel: {{SBOM_PUBLICATION_CHANNEL}}
- SBOM update cadence on material change: {{SBOM_UPDATE_CADENCE}}
- SBOM signing approach (Sigstore Cosign, in-toto, raw signature): {{SBOM_SIGNING_APPROACH}}
- Underlying SSDF practice: PW.4.4, PW.4.5
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_2_3}}
- Named owner: {{NAMED_OWNER_2_3}}
- Last verified date: {{LAST_VERIFIED_DATE_2_3}}
- Attestation status: {{ATTESTATION_STATUS_2_3}}
- POAM identifier: {{POAM_IDENTIFIER_2_3}}

Row 2.4: Build artefacts are signed and the signing material is protected.
- Attestation language: "the software producer signs released artefacts in a manner that allows a consumer to verify the integrity of the artefacts."
- Signing approach: {{SIGNING_APPROACH}} (Sigstore Cosign, Notation, GPG, native package signing)
- Signing key custody (hardware-backed HSM, cloud KMS with HSM-backed root, FIPS 140-3 validated module): {{SIGNING_KEY_CUSTODY}}
- Signing key rotation cadence and trigger events: {{SIGNING_KEY_ROTATION_CADENCE}}
- Underlying SSDF practice: PS.2.1, PS.3.1
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_2_4}}
- Named owner: {{NAMED_OWNER_2_4}}
- Last verified date: {{LAST_VERIFIED_DATE_2_4}}
- Attestation status: {{ATTESTATION_STATUS_2_4}}
- POAM identifier: {{POAM_IDENTIFIER_2_4}}

Row 2.5: SLSA provenance attestation is generated at the named level.
- SLSA level attested (Build L2, Build L3): {{SLSA_LEVEL_ATTESTED}}
- SLSA provenance generation tooling: {{SLSA_PROVENANCE_TOOLING}}
- SLSA verification approach by downstream consumer: {{SLSA_CONSUMER_VERIFICATION_APPROACH}}
- Underlying SSDF practice: PS.2.1, PS.3.1
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_2_5}}
- Named owner: {{NAMED_OWNER_2_5}}
- Last verified date: {{LAST_VERIFIED_DATE_2_5}}
- Attestation status: {{ATTESTATION_STATUS_2_5}}
- POAM identifier: {{POAM_IDENTIFIER_2_5}}

5. Practice cluster 3: vulnerability disclosure programme and management

Practice cluster 3 attests that the producer operates a vulnerability disclosure programme (the VDP), receives reports from external researchers, triages and remediates vulnerabilities under named SLAs, and publishes advisory or VEX statements where appropriate. Underlying SSDF practices: RV.1 (identify and confirm vulnerabilities on an ongoing basis), RV.2 (assess, prioritise, and remediate vulnerabilities), RV.3 (analyse vulnerabilities to identify their root causes). The row template carries the VDP intake channel, the SLA tiering, the publication channel, the named owner, the last verified date, and the POAM identifier.

Row 3.1: A vulnerability disclosure programme is in operation, with a published intake channel and named safe-harbour terms.
- Attestation language (verbatim): "the software producer operates a vulnerability disclosure programme and accepts, reviews, and addresses disclosed software vulnerabilities in a timely fashion."
- VDP intake channel (web form, dedicated email, security.txt RFC 9116 reference): {{VDP_INTAKE_CHANNEL}}
- VDP scope statement (what is in scope and what is out of scope for the disclosure programme): {{VDP_SCOPE_STATEMENT}}
- VDP safe-harbour language (the publicly published commitment to researchers): {{VDP_SAFE_HARBOUR_LANGUAGE}}
- Underlying SSDF practice: RV.1.1, RV.1.2
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_3_1}}
- Named owner: {{NAMED_OWNER_3_1}}
- Last verified date: {{LAST_VERIFIED_DATE_3_1}}
- Attestation status: {{ATTESTATION_STATUS_3_1}}
- POAM identifier: {{POAM_IDENTIFIER_3_1}}

Row 3.2: Reports are triaged on a named cadence with named SLAs by severity tier.
- Severity tier 1 (critical) triage SLA: {{TIER_1_TRIAGE_SLA}}
- Severity tier 1 remediation or mitigation SLA: {{TIER_1_REMEDIATION_SLA}}
- Severity tier 2 (high) triage SLA: {{TIER_2_TRIAGE_SLA}}
- Severity tier 2 remediation SLA: {{TIER_2_REMEDIATION_SLA}}
- Severity tier 3 (medium) triage SLA: {{TIER_3_TRIAGE_SLA}}
- Severity tier 3 remediation SLA: {{TIER_3_REMEDIATION_SLA}}
- Severity tier 4 (low) triage SLA: {{TIER_4_TRIAGE_SLA}}
- Severity tier 4 remediation SLA: {{TIER_4_REMEDIATION_SLA}}
- Underlying SSDF practice: RV.2.1, RV.2.2
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_3_2}}
- Named owner: {{NAMED_OWNER_3_2}}
- Last verified date: {{LAST_VERIFIED_DATE_3_2}}
- Attestation status: {{ATTESTATION_STATUS_3_2}}
- POAM identifier: {{POAM_IDENTIFIER_3_2}}

Row 3.3: Confirmed vulnerabilities are remediated and verified-fixed evidence is recorded.
- Attestation language (verbatim): "the software producer remediates vulnerabilities discovered prior to release and discloses material vulnerabilities discovered prior to or after release."
- Underlying SSDF practice: RV.2.2, RV.3.1
- Control objective: Each confirmed vulnerability has a remediation path, a verified-fixed evidence pointer, and a closure record. Where the vulnerability cannot be remediated immediately, a compensating control is recorded and the vulnerability is held under the documented risk acceptance with named expiry.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_3_3}}
- Named owner: {{NAMED_OWNER_3_3}}
- Last verified date: {{LAST_VERIFIED_DATE_3_3}}
- Attestation status: {{ATTESTATION_STATUS_3_3}}
- POAM identifier: {{POAM_IDENTIFIER_3_3}}

Row 3.4: VEX statements are published where appropriate.
- VEX format committed: {{VEX_FORMAT_COMMITTED}} (CSAF 2.0, CycloneDX VEX 1.5, OpenVEX)
- VEX publication channel: {{VEX_PUBLICATION_CHANNEL}}
- VEX status assignment rule (not_affected, affected, fixed, under_investigation): {{VEX_STATUS_ASSIGNMENT_RULE}}
- Underlying SSDF practice: RV.2.2, RV.3.2
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_3_4}}
- Named owner: {{NAMED_OWNER_3_4}}
- Last verified date: {{LAST_VERIFIED_DATE_3_4}}
- Attestation status: {{ATTESTATION_STATUS_3_4}}
- POAM identifier: {{POAM_IDENTIFIER_3_4}}

Row 3.5: Root-cause analysis is performed for material vulnerabilities, and the analysis feeds into the upstream SSDF practices.
- Attestation language (verbatim): "the software producer has a vulnerability disclosure policy that complies with International Organization for Standardization (ISO) 29147 and a vulnerability handling policy that complies with ISO 30111."
- Underlying SSDF practice: RV.3.1, RV.3.2, RV.3.3
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_3_5}}
- Named owner: {{NAMED_OWNER_3_5}}
- Last verified date: {{LAST_VERIFIED_DATE_3_5}}
- Attestation status: {{ATTESTATION_STATUS_3_5}}
- POAM identifier: {{POAM_IDENTIFIER_3_5}}

6. Practice cluster 4: good coding practices and secure-by-design

Practice cluster 4 attests that the producer applies threat modelling, secure design, code review, and security testing (SAST, SCA, DAST, secret scanning) during development. Underlying SSDF practices: PW.1, PW.2, PW.4, PW.5, PW.7, PW.8. The row template carries the design-stage controls, the coding-stage controls, the testing-stage controls, the named owner, the last verified date, and the POAM identifier.

Row 4.1: Threat modelling is performed at design stage and re-run on material change.
- Attestation language (verbatim): "the software producer designs software to meet security requirements and mitigate security risks identified through threat modelling."
- Underlying SSDF practice: PW.1.1, PW.1.2, PW.1.3
- Control objective: Threat models are produced for new components and on material change; threat model output drives the security requirements that the SAST, SCA, DAST, and code review pipelines verify.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_4_1}}
- Named owner: {{NAMED_OWNER_4_1}}
- Last verified date: {{LAST_VERIFIED_DATE_4_1}}
- Attestation status: {{ATTESTATION_STATUS_4_1}}
- POAM identifier: {{POAM_IDENTIFIER_4_1}}

Row 4.2: Secure coding practices are documented and applied across the codebase.
- Attestation language (verbatim): "the software producer creates source code by adhering to secure coding practices."
- Underlying SSDF practice: PW.5.1, PW.5.2
- Control objective: Secure coding standards are published and adhered to; named secure coding training is delivered to engineers; secure coding compliance is checked through SAST and code review.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_4_2}}
- Named owner: {{NAMED_OWNER_4_2}}
- Last verified date: {{LAST_VERIFIED_DATE_4_2}}
- Attestation status: {{ATTESTATION_STATUS_4_2}}
- POAM identifier: {{POAM_IDENTIFIER_4_2}}

Row 4.3: Code review is performed before merge for security-relevant primitives.
- Attestation language (verbatim): "the software producer reviews and/or analyzes human-readable code to identify vulnerabilities and verify compliance with security requirements."
- Underlying SSDF practice: PW.7.1, PW.7.2
- Control objective: Security-relevant code (authentication, encryption, access control, cryptographic primitives, input validation, output encoding, session management) is reviewed by a named secondary reviewer before merge; AI-assisted commits are identified and reviewed under the AI-assisted code rules.
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_4_3}}
- Named owner: {{NAMED_OWNER_4_3}}
- Last verified date: {{LAST_VERIFIED_DATE_4_3}}
- Attestation status: {{ATTESTATION_STATUS_4_3}}
- POAM identifier: {{POAM_IDENTIFIER_4_3}}

Row 4.4: SAST is operated continuously on the codebase.
- Attestation language (verbatim): "the software producer tests executable code to identify vulnerabilities and verify compliance with security requirements."
- SAST tooling in use: {{SAST_TOOLING_IN_USE}}
- SAST trigger (per pull request, scheduled, both): {{SAST_TRIGGER_FREQUENCY}}
- SAST coverage scope (the language and framework coverage): {{SAST_COVERAGE_SCOPE}}
- Underlying SSDF practice: PW.7.1, PW.8.1
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_4_4}}
- Named owner: {{NAMED_OWNER_4_4}}
- Last verified date: {{LAST_VERIFIED_DATE_4_4}}
- Attestation status: {{ATTESTATION_STATUS_4_4}}
- POAM identifier: {{POAM_IDENTIFIER_4_4}}

Row 4.5: SCA is operated against the dependency tree.
- SCA tooling in use: {{SCA_TOOLING_IN_USE}}
- SCA trigger (per pull request, scheduled, both): {{SCA_TRIGGER_FREQUENCY}}
- SCA known-vulnerable dependency block rules: {{SCA_BLOCK_RULES}}
- Underlying SSDF practice: PW.4.5, PW.4.6, PW.8.1
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_4_5}}
- Named owner: {{NAMED_OWNER_4_5}}
- Last verified date: {{LAST_VERIFIED_DATE_4_5}}
- Attestation status: {{ATTESTATION_STATUS_4_5}}
- POAM identifier: {{POAM_IDENTIFIER_4_5}}

Row 4.6: DAST and authenticated scanning are operated against running software.
- DAST tooling in use: {{DAST_TOOLING_IN_USE}}
- Authenticated scanning approach: {{AUTHENTICATED_SCANNING_APPROACH}}
- Cadence of DAST and authenticated scans: {{DAST_AUTHENTICATED_CADENCE}}
- Underlying SSDF practice: PW.8.1, PW.8.2
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_4_6}}
- Named owner: {{NAMED_OWNER_4_6}}
- Last verified date: {{LAST_VERIFIED_DATE_4_6}}
- Attestation status: {{ATTESTATION_STATUS_4_6}}
- POAM identifier: {{POAM_IDENTIFIER_4_6}}

Row 4.7: Secret scanning is operated across source code and build pipelines.
- Secret scanning tooling in use: {{SECRET_SCANNING_TOOLING_IN_USE}}
- Secret scanning trigger (per pull request, scheduled, both): {{SECRET_SCANNING_TRIGGER}}
- Secret scanning remediation pathway (block merge, alert, rotate, all of the above): {{SECRET_SCANNING_REMEDIATION_PATHWAY}}
- Underlying SSDF practice: PW.5.1, PW.7.1
- Supporting evidence pointer: {{SUPPORTING_EVIDENCE_4_7}}
- Named owner: {{NAMED_OWNER_4_7}}
- Last verified date: {{LAST_VERIFIED_DATE_4_7}}
- Attestation status: {{ATTESTATION_STATUS_4_7}}
- POAM identifier: {{POAM_IDENTIFIER_4_7}}

7. Supporting evidence index

The supporting evidence index names every evidence pointer the practice clusters reference. Each entry names the artefact identifier, the artefact storage location, the artefact custodian, the artefact production date, the artefact retention period, and the SSDF practice the artefact reads against. An attestation that cannot point to the supporting evidence is the most common failure mode under an inspector general inquiry.

Evidence entry template (one row per supporting artefact):

Entry header columns:
- Evidence identifier: {{EVIDENCE_ID}}
- Evidence name: {{EVIDENCE_NAME}}
- Evidence type (programme document, policy, runbook, scan report, code review record, audit report, training record, signing material record, build provenance record, SBOM artefact, VEX statement, VDP intake log, vulnerability remediation record): {{EVIDENCE_TYPE}}
- Evidence storage location (document management workspace identifier, repository URL, named folder): {{EVIDENCE_STORAGE_LOCATION}}
- Evidence custodian (named role and named person): {{EVIDENCE_CUSTODIAN}}
- Evidence production date or last refresh date: {{EVIDENCE_PRODUCTION_DATE}}
- Evidence retention period (per the audit evidence retention policy): {{EVIDENCE_RETENTION_PERIOD}}
- SSDF practice the evidence reads against: {{SSDF_PRACTICE_REFERENCE}}
- SSDA practice cluster the evidence reads against: {{SSDA_CLUSTER_REFERENCE}}
- Refresh cadence (continuous, monthly, quarterly, annual, event-driven): {{REFRESH_CADENCE}}

Recommended core evidence entries the SSDA reads against (instantiate one row per entry; add entries specific to your operating model):

- SSDF programme document (the master document that maps the SSDF practices to the producer-side roles, tools, and operating cadence).
- Secure software development environment policy (the operating policy on the build environment separation, access control, and integrity protection).
- Secrets management policy (the operating policy on credentials in the build pipeline; pair with the secrets management policy template).
- Code review policy (the operating policy on code review by named secondary reviewers for security-relevant primitives).
- Secure coding standards document (the language-by-language secure coding standards the engineers code to).
- Threat modelling guideline (the operating guidance on threat modelling cadence and output).
- SAST tooling configuration and last-run report.
- SCA tooling configuration and last-run report.
- DAST tooling configuration and last-run report.
- Authenticated scanning configuration and last-run report.
- Secret scanning configuration and last-run report.
- SBOM artefact for the released product (the current SBOM in the committed format).
- SBOM provision policy (pair with the SBOM policy template).
- VEX statement publication record.
- Signing key custody record (the named HSM or KMS custody arrangement and the rotation cadence).
- Build provenance attestation (SLSA Level 2 or Level 3 attestation files).
- Vulnerability disclosure programme policy (pair with the vulnerability disclosure policy template).
- Vulnerability management policy and SLA policy (pair with the vulnerability management policy template and the vulnerability SLA policy template).
- Security awareness training record (the named training cadence and the workforce-side completion record).
- Security incident response runbook (pair with the incident response runbook template).
- Internal audit report (where the organisation has an internal audit function with SSDA scope).
- 3PAO assessment report (where a third-party assessment organisation has been engaged).
- Customer-side disclosed material vulnerability log (the log of material vulnerabilities disclosed under the VDP).

8. POAM (Plan of Action and Milestones) register

A POAM records a known gap against an attested practice, the compensating control the producer applies in the interim, the named owner, the target completion date, and the renewal review cadence. Where the producer cannot attest to a practice cluster fully, the POAM register is filed alongside the SSDA. The register names the gap specifically, not vaguely; a POAM that has been open for two or three years without closing the gap is read by the inspector general as a non-attestation rather than an in-progress attestation.

POAM entry template (one row per open POAM):

- POAM identifier: {{POAM_ID}}
- POAM opened date: {{POAM_OPENED_DATE}}
- Practice cluster (1, 2, 3, or 4) and row reference: {{POAM_CLUSTER_AND_ROW}}
- SSDF practice the POAM reads against: {{POAM_SSDF_PRACTICE}}
- Gap description (specific, named, narrow; not "we are working on it"): {{POAM_GAP_DESCRIPTION}}
- Risk impact (the named risk the gap introduces and the affected federal agency consumer): {{POAM_RISK_IMPACT}}
- Compensating control (the operational control the producer applies while the gap is open): {{POAM_COMPENSATING_CONTROL}}
- Named owner (named role and named person): {{POAM_NAMED_OWNER}}
- Target completion date (specific date, with monthly or quarterly milestones if longer than ninety days): {{POAM_TARGET_COMPLETION_DATE}}
- Milestone 1 (date, deliverable, named owner, status): {{POAM_MILESTONE_1}}
- Milestone 2 (date, deliverable, named owner, status): {{POAM_MILESTONE_2}}
- Milestone 3 (date, deliverable, named owner, status): {{POAM_MILESTONE_3}}
- Milestone 4 (date, deliverable, named owner, status): {{POAM_MILESTONE_4}}
- Linked finding identifier (the named finding in the wider vulnerability programme the POAM closes when the finding closes): {{POAM_LINKED_FINDING_ID}}
- POAM review cadence (monthly, quarterly, milestone-driven): {{POAM_REVIEW_CADENCE}}
- POAM status (open, on-track, at-risk, milestone-missed, closed): {{POAM_STATUS}}
- POAM closure date and verified-fixed evidence pointer: {{POAM_CLOSURE_RECORD}}

POAM hygiene rules (read by the federal agency reviewer):
- A POAM is specific in scope, specific in time, specific in owner, and specific in compensating control.
- A POAM is not a permanent state; most federal agencies will accept a POAM of up to twelve to eighteen months on a non-critical gap and substantially shorter (thirty to ninety days) on a critical gap.
- A POAM that has missed a milestone is at-risk and triggers a review of the target completion date and the compensating control.
- A POAM that has been extended more than once for the same milestone is read as a programme failure rather than a delay.
- A POAM closure is verified-fixed; the producer cannot self-close a POAM without verified evidence.

9. 3PAO (Third-Party Assessment Organization) register

A 3PAO is an independent assessor that examines the producer practices against a published baseline. The 3PAO route is optional in the baseline SSDA but mandatory at higher critical-software tiers. Where the SSDA cites a 3PAO assessment, the assessor identity, the assessment scope, the assessment date, and the report identifier are named on the SSDA cover identity block.

3PAO engagement record (one entry per 3PAO engagement):

- 3PAO legal name: {{TPAO_LEGAL_NAME}}
- 3PAO accreditation (FedRAMP 3PAO, A2LA accredited, ISO/IEC 17020 conformity assessment body, named federal-recognised accreditation): {{TPAO_ACCREDITATION}}
- 3PAO point of contact: {{TPAO_POC_NAME_AND_EMAIL}}
- Engagement identifier: {{TPAO_ENGAGEMENT_IDENTIFIER}}
- Engagement scope (the practice clusters or specific rows the 3PAO assessed): {{TPAO_ENGAGEMENT_SCOPE}}
- Engagement period (start and end dates): {{TPAO_ENGAGEMENT_PERIOD}}
- Assessment methodology (named assessment methodology): {{TPAO_ASSESSMENT_METHODOLOGY}}
- Sites assessed: {{TPAO_SITES_ASSESSED}}
- Report identifier: {{TPAO_REPORT_IDENTIFIER}}
- Report issuance date: {{TPAO_REPORT_ISSUANCE_DATE}}
- Report storage location: {{TPAO_REPORT_STORAGE_LOCATION}}
- Findings raised in the report (the named findings and the linked POAM identifiers): {{TPAO_FINDINGS_AND_POAM_LINKS}}
- Re-assessment cadence: {{TPAO_REASSESSMENT_CADENCE}}

3PAO scope determination (the rule that decides whether a 3PAO is required):
- The baseline SSDA at the standard critical-software tier is a self-attestation; a 3PAO is not required by default.
- A 3PAO is required where the federal agency contracting officer names the requirement under the critical-software tier rules in OMB M-22-18 paragraph II.B or the agency-specific equivalent.
- A 3PAO is recommended where the producer cannot resource an internal audit function and the SSDA is filed against a large federal procurement.
- A 3PAO is recommended where the producer files against multiple federal agencies and the agency-by-agency review burden would be reduced by a single independent assessment.

3PAO engagement readiness checklist (the producer prepares before the 3PAO arrives):
- The SSDF programme document is current.
- The practice cluster mapping in the SSDA workbook is current.
- The supporting evidence index in the SSDA workbook is current and the underlying artefacts are accessible.
- The POAM register is current with no missing milestones.
- The vulnerability remediation record is current and the verified-fixed evidence is in place.
- The named owners are available for the 3PAO interviews.
- The build environment access is granted to the 3PAO under the named non-disclosure agreement.

10. SBOM provision and VEX statement commitment

The SSDA practice cluster 2 attests that the producer provides an SBOM to the federal agency. The commitment is operational, not just declarative. Name the SBOM format, the publication channel, the update cadence on material change, the signing approach, the NTIA Minimum Elements coverage, the VEX format, the VEX publication channel, and the VEX status assignment rules. Where the SBOM provision falls short on any of these dimensions, the inspector general read against practice cluster 2 is hostile.

SBOM provision commitment:
- Primary SBOM format committed (CycloneDX 1.5, CycloneDX 1.6, SPDX 2.3, SPDX 3.0): {{PRIMARY_SBOM_FORMAT}}
- Secondary SBOM format committed (where the federal agency consumer requires both formats): {{SECONDARY_SBOM_FORMAT}}
- NTIA Minimum Elements coverage (supplier, component name, version, unique identifier including PURL or CPE or SWID where applicable, dependency relationship, SBOM author identity, timestamp): {{NTIA_MINIMUM_ELEMENTS_COVERAGE_STATEMENT}}
- SBOM component depth (top-level components only, second-tier dependencies, full transitive closure): {{SBOM_COMPONENT_DEPTH}}
- SBOM publication channel and federal-agency delivery mechanism (named portal, contractual delivery, on request): {{SBOM_PUBLICATION_CHANNEL}}
- SBOM update cadence on material change (the named trigger and the named lead time): {{SBOM_UPDATE_CADENCE}}
- SBOM signing approach (Sigstore Cosign, Notation, in-toto attestation, raw signing material): {{SBOM_SIGNING_APPROACH}}
- SBOM ingestion path on the federal agency side (named consumer tool or named expected workflow): {{SBOM_AGENCY_INGESTION_PATH}}
- SBOM data accuracy expectation (the named accuracy bar the producer commits to): {{SBOM_ACCURACY_EXPECTATION}}

VEX (Vulnerability Exploitability eXchange) statement commitment:
- Primary VEX format committed (CSAF 2.0, CycloneDX VEX 1.5, OpenVEX): {{PRIMARY_VEX_FORMAT}}
- VEX publication channel: {{VEX_PUBLICATION_CHANNEL}}
- VEX status assignment rule (not_affected, affected, fixed, under_investigation, with the named justification rule): {{VEX_STATUS_ASSIGNMENT_RULE}}
- VEX update trigger (per advisory, per material change, per scheduled review): {{VEX_UPDATE_TRIGGER}}
- VEX scope statement (the products and product families the VEX covers): {{VEX_SCOPE_STATEMENT}}
- VEX retention period and archive location: {{VEX_RETENTION_AND_ARCHIVE}}

Out-of-scope statement:
- Producer does not commit to: {{SBOM_OUT_OF_SCOPE_STATEMENT}}
- Producer does not commit to: {{VEX_OUT_OF_SCOPE_STATEMENT}}

Pair the SBOM provision commitment with the SBOM policy template document so the producer-side workforce policy and the federal-agency-side attestation reference the same operating model. The SSDA does not replace the SBOM policy; the SBOM policy backs the SSDA practice cluster 2 attestation.

11. Audit trail, document custodian, and signed attestation chain

The signed CISA SSDA is a controlled record. Bind the signed attestation to a named custodian, a named storage location, a named version-control mechanism, a named access roster, and a named retention cadence. The audit trail names every action on the attestation from the moment a draft was opened through legal review, signatory review, signing, filing, and renewal so the inspector general read sees a clean record rather than a one-off sign-and-file.

Audit trail entries (one entry per named action; capture the chronology):
- Draft opened by: {{DRAFT_OPENED_BY_NAME_AND_DATE}}
- Practice cluster 1 row completion by: {{CLUSTER_1_COMPLETION_NAME_AND_DATE}}
- Practice cluster 2 row completion by: {{CLUSTER_2_COMPLETION_NAME_AND_DATE}}
- Practice cluster 3 row completion by: {{CLUSTER_3_COMPLETION_NAME_AND_DATE}}
- Practice cluster 4 row completion by: {{CLUSTER_4_COMPLETION_NAME_AND_DATE}}
- Supporting evidence index completion by: {{EVIDENCE_INDEX_COMPLETION_NAME_AND_DATE}}
- POAM register completion by: {{POAM_REGISTER_COMPLETION_NAME_AND_DATE}}
- 3PAO assessment reference completion (where applicable): {{TPAO_REFERENCE_COMPLETION_NAME_AND_DATE}}
- SBOM provision commitment completion by: {{SBOM_COMMITMENT_COMPLETION_NAME_AND_DATE}}
- VEX statement commitment completion by: {{VEX_COMMITMENT_COMPLETION_NAME_AND_DATE}}
- CISO review and approval: {{CISO_APPROVAL_NAME_AND_DATE}}
- GRC and compliance review and approval: {{GRC_APPROVAL_NAME_AND_DATE}}
- General counsel review and approval: {{GC_APPROVAL_NAME_AND_DATE}}
- Federal sales lead review and approval: {{FEDERAL_SALES_APPROVAL_NAME_AND_DATE}}
- Internal audit review (where applicable): {{INTERNAL_AUDIT_APPROVAL_NAME_AND_DATE}}
- Signing officer review: {{SIGNING_OFFICER_REVIEW_NAME_AND_DATE}}
- Signing officer signature applied: {{SIGNING_OFFICER_SIGNATURE_NAME_AND_DATE}}
- Filing through CISA RSAA: {{RSAA_FILING_NAME_AND_DATE}}
- RSAA confirmation received: {{RSAA_CONFIRMATION_NAME_AND_DATE}}
- Federal agency contracting officer copy delivered (where applicable): {{AGENCY_COPY_DELIVERY_NAME_AND_DATE}}
- Quarterly evidence health check 1: {{QUARTERLY_CHECK_1_NAME_AND_DATE}}
- Quarterly evidence health check 2: {{QUARTERLY_CHECK_2_NAME_AND_DATE}}
- Quarterly evidence health check 3: {{QUARTERLY_CHECK_3_NAME_AND_DATE}}
- Quarterly evidence health check 4: {{QUARTERLY_CHECK_4_NAME_AND_DATE}}
- Annual sign-off renewal: {{ANNUAL_RENEWAL_NAME_AND_DATE}}
- Out-of-cycle amendment (named trigger and resulting amendment record): {{OUT_OF_CYCLE_AMENDMENT_RECORD}}

Document custodian:
- Custodian role: {{CUSTODIAN_ROLE}} (typically the GRC lead, the compliance officer, or the federal sales operations lead)
- Custodian named person at time of publication: {{CUSTODIAN_NAME}}
- Custodian responsibilities (named): keep the signed attestation current, run the quarterly evidence health check, coordinate the annual sign-off renewal, dispatch the out-of-cycle amendment trigger handling, maintain the audit trail.

Storage and access:
- Storage location of the signed attestation: {{STORAGE_LOCATION_OF_SIGNED_ATTESTATION}}
- Version control mechanism (named): {{VERSION_CONTROL_MECHANISM}}
- Access roster (named roles with named permissions): {{ACCESS_ROSTER}}
- Retention period (per the audit evidence retention policy and the federal contract record retention rules): {{RETENTION_PERIOD}}
- Disposition at the end of retention: {{END_OF_RETENTION_DISPOSITION}}

12. Renewal cadence and named amendment triggers

The CISA SSDA does not auto-expire on a fixed date. The producer is required to re-attest on named events: material change to the software, material change to the practices, POAM milestone passing (closed or extended), open vulnerability disclosed under the VDP that materially affects the practices, CISA or OMB updates the form or the guidance, federal agency requests a renewed attestation against a contract renewal, signing officer changes. Capture the renewal cadence and the ten named amendment triggers below.

Annual sign-off renewal:
- Annual sign-off renewal review by: {{ANNUAL_RENEWAL_REVIEWER_AND_DATE}}
- Annual sign-off renewal trigger (calendar date, fiscal year, contract anniversary, or named event): {{ANNUAL_RENEWAL_TRIGGER}}
- Annual sign-off renewal check (the named questions the reviewer answers): material software change since last sign-off? material practices change since last sign-off? POAM register current? supporting evidence index current? 3PAO assessment current (where applicable)? signing officer current?

Quarterly evidence health check:
- Quarterly check 1 (Q1): {{QUARTERLY_CHECK_1_DATE_AND_REVIEWER}}
- Quarterly check 2 (Q2): {{QUARTERLY_CHECK_2_DATE_AND_REVIEWER}}
- Quarterly check 3 (Q3): {{QUARTERLY_CHECK_3_DATE_AND_REVIEWER}}
- Quarterly check 4 (Q4): {{QUARTERLY_CHECK_4_DATE_AND_REVIEWER}}
- Quarterly check named checklist (the seven questions the reviewer answers): SBOM current and accurate? SAST coverage current? SCA dependency tree current? VDP intake pipeline operational? secret scanning operational? signing material rotated where rotation cadence required? POAM milestones on track?

Ten named amendment triggers (the ten events that force an out-of-cycle amendment to the attestation between annual sign-offs):
- Trigger 1: material change to the software product or product family in scope.
- Trigger 2: material change to the development practices or the toolchain.
- Trigger 3: POAM milestone passing (closed, extended with named reason, or missed).
- Trigger 4: material vulnerability disclosed under the VDP that affects the practices the attestation reads against.
- Trigger 5: CISA or OMB updates the SSDA form or the implementation guidance.
- Trigger 6: federal agency contracting officer requests a renewed attestation against a contract renewal, modification, or transfer.
- Trigger 7: signing officer changes (the CEO changes, the named designee changes, the delegation memo expires).
- Trigger 8: 3PAO assessment is renewed or a 3PAO finding raises a new POAM.
- Trigger 9: producer entity changes (merger, acquisition, divestiture, federal contracting registration change at SAM.gov).
- Trigger 10: a federal investigation, inspector general inquiry, qui tam relator suit, or Department of Justice civil enforcement action raises a question on the underlying attestation.

Out-of-cycle amendment workflow:
- The trigger is observed and recorded by the custodian.
- The trigger is routed to the named CISO, GRC lead, and general counsel for assessment.
- The assessment determines whether the trigger requires an amendment (Yes), a refresh of the supporting evidence index without amendment (No-Refresh), or no action (No).
- An amendment is drafted, reviewed, and signed by the signing officer.
- The amended attestation is filed through CISA RSAA and the prior version is archived.
- The audit trail in Section 11 is updated with the amendment record.

13. Framework crosswalk: SSDA, SSDF, and parallel regimes

The SSDA reads the development-side practices. Other federal compliance regimes (FedRAMP, FISMA, NIST SP 800-53) read deployment-side controls. International parallel regimes (EU Cyber Resilience Act, NCSC product security guidance, Canadian Centre for Cyber Security, Australian Cyber Security Strategy) read parallel attestation expectations. The same supporting evidence stack reads against multiple regimes if the crosswalk is named.

Crosswalk table (one row per related regime; instantiate one row per regime the producer operates against):

Row C.1 (NIST SSDF SP 800-218):
- The SSDA reads against: PO.1, PO.2, PO.3, PO.4, PO.5, PS.1, PS.2, PS.3, PW.1, PW.2, PW.4, PW.5, PW.7, PW.8, RV.1, RV.2, RV.3.
- Operating evidence reference: SSDF programme document.

Row C.2 (Executive Order 14028 on Improving the Nation's Cybersecurity):
- Section 4(e) names the SSDF as the basis for the federal attestation.
- Operating evidence reference: signed CISA SSDA.

Row C.3 (OMB M-22-18 and OMB M-23-16):
- M-22-18 introduces the attestation requirement for federal agencies acquiring software from producers.
- M-23-16 updates the timelines and the common-attestation route.
- Operating evidence reference: signed CISA SSDA filed through RSAA.

Row C.4 (NIST CSF 2.0):
- The SSDA evidence reads against GV.PO (policy and procedures), GV.RR (roles, responsibilities, and authorities), ID.RA (risk assessment), ID.SC (cybersecurity supply chain risk management), PR.PS (platform security), PR.IR (technology infrastructure resilience), DE.CM (continuous monitoring), RS.MA (incident management), RC.RP (recovery planning).
- Operating evidence reference: NIST CSF profile mapping document.

Row C.5 (NIST SP 800-53 Rev. 5):
- The SSDA evidence reads against SA-3 (system development life cycle), SA-4 (acquisition process), SA-8 (security and privacy engineering principles), SA-11 (developer security testing), SA-15 (development process, standards, and tools), SA-22 (unsupported system components), CA-7 (continuous monitoring), RA-3 (risk assessment), RA-5 (vulnerability scanning), SR-3 (supply chain controls and processes), SR-4 (provenance), SR-5 (acquisition strategies, tools, and methods), SR-6 (supplier assessments and reviews), SR-11 (component authenticity).
- Operating evidence reference: NIST SP 800-53 control assessment record.

Row C.6 (FedRAMP):
- FedRAMP authorisation reads NIST SP 800-53 controls in the deployment-side context.
- A FedRAMP-authorised cloud service provider still files the SSDA for the software the federal agency is buying.
- Operating evidence reference: FedRAMP authorisation package (where applicable).

Row C.7 (ISO/IEC 27001:2022):
- The SSDA evidence reads against Annex A 5.1, A 5.7, A 5.19, A 5.21, A 5.23, A 5.31, A 6.3, A 8.1, A 8.4, A 8.7, A 8.8, A 8.16, A 8.25, A 8.26, A 8.27, A 8.28, A 8.29, A 8.30, A 8.33.
- Operating evidence reference: ISO 27001 Statement of Applicability.

Row C.8 (SOC 2):
- The SSDA evidence reads against CC1, CC2, CC3, CC6, CC7, CC8, CC9 trust services criteria.
- Operating evidence reference: SOC 2 Type II audit report (where the producer has one).

Row C.9 (PCI DSS where the producer accepts payment card data):
- The SSDA evidence reads against PCI DSS Req 6 (Develop and maintain secure systems and software) and Req 11 (Test security of systems and networks regularly).
- Operating evidence reference: PCI DSS Report on Compliance (where applicable).

Row C.10 (EU Cyber Resilience Act, Regulation 2024/2847):
- CRA Article 11 (essential cybersecurity requirements), Article 14 (reporting obligations), Annex I Section 1 (security requirements relating to the properties of products with digital elements), Annex I Section 2 (vulnerability handling requirements), Annex II (information and instructions for the user), Annex V (EU Declaration of Conformity).
- Operating evidence reference: EU Declaration of Conformity and the technical documentation under Annex VII (where the producer operates in the EU market).

Row C.11 (NCSC, Canadian Centre for Cyber Security, Australian Cyber Security Strategy):
- Pair the SSDA evidence stack with the published guidance from each jurisdiction.
- Operating evidence reference: jurisdiction-specific evidence package (where the producer operates in the jurisdiction).

Row C.12 (OWASP ASVS, OWASP SAMM, CIS Controls v8.1):
- ASVS and SAMM verification and assessment evidence reads against the SSDF PW group.
- CIS Controls v8.1 Implementation Group 1, 2, 3 cross-reference the SSDA attestation rows.
- Operating evidence reference: ASVS or SAMM assessment and CIS Controls assessment (where the producer has one).

14. Document control footer

The document control footer makes the attestation workbook a controlled record. Capture the version, the effective date, the next review date, the named custodian, the named approval chain, the named acknowledgement chain (the named workforce reviewers who confirm the attestation), and the named retention rule. The closing block names the operating discipline that pairs the signed attestation to the live operating record.

Document control:
- Document identifier: {{DOCUMENT_IDENTIFIER}}
- Document title: CISA Secure Software Development Attestation Workbook
- Document version: {{DOCUMENT_VERSION}}
- Document effective date: {{DOCUMENT_EFFECTIVE_DATE}}
- Document last review date: {{DOCUMENT_LAST_REVIEW_DATE}}
- Document next scheduled review date: {{DOCUMENT_NEXT_REVIEW_DATE}}
- Document custodian role: {{DOCUMENT_CUSTODIAN_ROLE}}
- Document custodian named person: {{DOCUMENT_CUSTODIAN_NAME}}
- Storage location: {{DOCUMENT_STORAGE_LOCATION}}
- Retention period (per the audit evidence retention policy and federal contract record retention rules): {{DOCUMENT_RETENTION_PERIOD}}

Approval chain (the workbook is published to the workforce under the named approvals):
- Approved by CISO: {{CISO_APPROVAL_SIGNATURE_AND_DATE}}
- Approved by AppSec or product security lead: {{APPSEC_APPROVAL_SIGNATURE_AND_DATE}}
- Approved by GRC and compliance owner: {{GRC_APPROVAL_SIGNATURE_AND_DATE}}
- Approved by general counsel: {{GC_APPROVAL_SIGNATURE_AND_DATE}}
- Approved by federal sales lead: {{FEDERAL_SALES_APPROVAL_SIGNATURE_AND_DATE}}
- Approved by signing officer: {{SIGNING_OFFICER_APPROVAL_SIGNATURE_AND_DATE}}
- Approved by executive sponsor (where applicable): {{EXECUTIVE_SPONSOR_APPROVAL_SIGNATURE_AND_DATE}}

Closing operating statement:
- This workbook is the producer-side artefact that backs the signed CISA Secure Software Development Attestation Form.
- The workbook is reviewed quarterly for evidence currency and annually for sign-off renewal.
- Out-of-cycle amendments follow the ten named triggers in Section 12.
- The signed attestation, the workbook, the supporting evidence index, and the POAM register are read together under any federal agency follow-up, inspector general inquiry, qui tam relator review, or Department of Justice civil enforcement action.
- The workbook does not replace the underlying SSDF programme document; the SSDF programme is the practice-side rollout artefact that the workbook reads against.

Eight failure modes the SSDA workbook has to design against

The signed CISA SSDA fails the federal procurement read, the inspector general read, and the False Claims Act exposure read in recognisable patterns. Each failure has a structural fix that the workbook above is designed to enforce. Read this list before you customise the workbook so the customisation does not weaken the discipline that makes the attestation defensible.

Sign-and-file with no supporting evidence chain

The producer treats the SSDA as a one-time signature and files it without the supporting evidence index, the POAM register, or the audit trail. Under an inspector general inquiry, a federal agency follow-up, or a qui tam relator review, the producer cannot defend the signature. The fix is the workbook here: every attested practice cluster row has a supporting evidence pointer, a named owner, and a last-verified date, and the audit trail in Section 11 records the chronology from draft through filing.

Practice cluster paraphrase rather than verbatim attestation language

The producer paraphrases the practice cluster language on the form rather than attest to the published language verbatim. The auditor reads the paraphrase as either an admission of incomplete adherence or an attempt to soften the obligation. The fix is the verbatim attestation language in each row of clusters 3 to 6 in this workbook, with the producer-side control objective and supporting evidence pointer as a separate row column.

Missing POAM register for known gaps

The producer attests to a practice cluster fully when it has a known gap, rather than file a POAM that records the gap, the compensating control, and the path to closure. A federal agency that discovers the gap later reads the attestation as a materially false statement under the False Claims Act. The fix is the POAM register in Section 8 with specific gap descriptions, specific compensating controls, named owners, target completion dates with monthly or quarterly milestones, and linked finding identifiers.

Permanent POAM that never closes

The producer files a POAM that has been open for two or three years without closing the gap. The inspector general reads a permanent POAM as a non-attestation rather than an in-progress attestation. The fix is the POAM hygiene rules in Section 8: a POAM has a target completion date no more than twelve to eighteen months out on a non-critical gap (substantially shorter on a critical gap), milestone reviews on missed milestones, and a verified-fixed closure rather than self-closure.

Stale SBOM provision

The producer attests to SBOM provision in the form but the SBOM the federal agency receives is months out of date, has missing components, or has format errors that the NTIA Minimum Elements check fails. The agency consumer reads the stale SBOM as a failure to attest to practice cluster 2. The fix is the SBOM provision commitment in Section 10 naming the format, the publication channel, the update cadence on material change, the signing approach, and the NTIA Minimum Elements coverage explicitly, paired with the SBOM policy template document.

Missing 3PAO reference at critical-software tier

The producer attests at a critical-software tier that requires a 3PAO assessment but does not name the 3PAO, the assessment scope, the assessment date, or the report identifier. The federal agency contracting officer rejects the attestation under the OMB M-22-18 paragraph II.B rules. The fix is the 3PAO register in Section 9, with the named 3PAO, the accreditation, the engagement scope, the assessment period, the report identifier, and the re-assessment cadence.

Wrong signing authority below the CEO or properly-delegated designee

The producer signs the SSDA below the CEO or a properly-delegated designee. The signing authority is below the level OMB M-22-18 names, and the attestation is rejected. The fix is the signatory authority block in Section 2 with the named signing officer, the legal authority basis, and the dated delegation memo where the CEO delegates to a designee.

No renewal cadence and no amendment triggers

The producer files the SSDA once and then never reviews it, even when the software materially changes, the practices materially change, the POAM milestones pass, a critical vulnerability disclosed under the VDP affects the attestation, CISA updates the form, or a contract renewal or modification triggers a refresh. The agency follow-up reads the missing renewal cadence as a programme failure. The fix is Section 12, the quarterly evidence health check checklist, the annual sign-off renewal review, and the ten named amendment triggers with the out-of-cycle amendment workflow.

Ten questions the SSDA workbook answers

A defensible CISA SSDA answers each of these ten questions explicitly. Capture the answers in the workbook sections above rather than relying on individual practitioners, AppSec leads, or security analysts to recall them when a federal agency contracting officer, an inspector general, a 3PAO assessor, or a qui tam relator asks. The ten questions are the operational floor of a defensible SSDA; richer programmes answer more, but the ten below are the durable minimum the signing officer reads against before signing.

1.Which producer entity is filing the attestation, and what is the named UEI, CAGE code, and SAM.gov registration status.
2.Which software product or product family is in scope of the attestation, and which federal agencies the attestation is filed against (common attestation or per-agency filing).
3.Who is the named signing officer, what is the legal authority basis (CEO or delegated designee), and where is the dated delegation memo on file.
4.How is the build environment separated from the production environment, and how is the integrity of the build pipeline protected (cluster 1 evidence).
5.How is provenance maintained across first-party and third-party code, and how is the SBOM generated, signed, published, and delivered to the federal agency consumer (cluster 2 evidence).
6.How is the vulnerability disclosure programme operated, what are the named SLAs by severity tier, and how is the verified-fixed evidence recorded against remediated findings (cluster 3 evidence).
7.How is threat modelling, secure coding, code review, SAST, SCA, DAST, authenticated scanning, and secret scanning operated across the SDLC (cluster 4 evidence).
8.Where the producer has a known gap against an attested practice, how is the gap recorded on the POAM register with specific compensating control, named owner, target completion date, and milestone reviews.
9.Where the attestation is filed at a critical-software tier requiring a 3PAO assessment, who is the named 3PAO, what is the assessment scope, what is the assessment period, and where is the report identifier on file.
10.How is the signed attestation reviewed quarterly for evidence currency and annually for sign-off renewal, and how do the ten named amendment triggers drive out-of-cycle amendment between annual reviews.

How the SSDA workbook pairs with SecPortal

The workbook above is copy-ready as a standalone artefact. SecPortal is not a federal contracting registration service, does not submit the SSDA to CISA on behalf of the producer (the submission flows through the RSAA portal under the signing officer authority), does not replace the general counsel and signing officer legal review chain, and does not replace the 3PAO assessment engagement workflow where one is commissioned. What SecPortal does is carry the security-side evidence chain that backs each attested practice cluster row and each POAM. The signed SSDA itself can be held as a versioned record through document management with the named custodian, the named signing officer, the dated delegation memo, the effective period, the renewal review trigger, and the version history recorded on the document control footer.

The audit trail in Section 11 lives on the workspace activity log with named-actor, timestamp, and 30, 90, or 365-day retention by plan; the federal agency contracting officer, the inspector general, and the 3PAO assessor read the chronology of draft, review, sign, file, quarterly health check, and annual renewal from the workspace record rather than from a separate assertion. Access to the workbook and to the underlying SSDF programme document is gated by team management role-based access control with the four roles (owner, admin, member, viewer) shaping who can read and amend the workbook, and protected by multi-factor authentication for the sign-off events on the workspace.

The supporting evidence pack lives on the live workspace. SAST findings against connected repositories on GitHub, GitLab, and Bitbucket live under code scanning with repository connections and pair the cluster 4 attestation rows with the underlying scan output. External and authenticated scanner findings live under external scanning and authenticated scanning for the DAST and authenticated scanning rows of cluster 4. Third-party scanner findings ingested through bulk finding import (Burp, Nessus, generic CSV) populate the wider supporting evidence for the same rows.

The framework crosswalk in Section 13 reads against the compliance tracking feature where NIST SSDF, EO 14028, OMB M-22-18 and M-23-16, NIST CSF 2.0, NIST SP 800-53, ISO 27001, SOC 2, PCI DSS, EU CRA, OWASP ASVS, OWASP SAMM, and CIS Controls mappings read against the live findings record with CSV export. The POAM register in Section 8 lives against findings management with CVSS 3.1 severity, and POAM closures route through the retesting workflows where the verified-fixed evidence is paired to the underlying finding identifier so the POAM closes when the finding closes.

Accepted-risk POAMs that remain open under a compensating control are recorded against finding overrides (where the override carries the eight-field decision chain) and against the wider vulnerability acceptance and exception management workflow for the named expiry, named owner, and named renewal review. The AI report generation workflow drafts the executive summary, the cluster-by-cluster narrative, and the framework-mapping read against the underlying workspace record so the signing officer edits rather than writes from a blank page. The notifications and alerts feature dispatches the quarterly evidence health check, the annual sign-off renewal trigger, and the ten named amendment triggers to the named custodian, the CISO, the GRC lead, and the general counsel with the same audit trail.

For the framework anchors the SSDA reads against, see the framework pages for NIST SSDF, FedRAMP, NIST CSF 2.0, NIST SP 800-53, ISO 27001, SOC 2, EU Cyber Resilience Act, CISA Secure by Design, and NIST SP 800-37. SecPortal does not provide federal contracting registration services, does not file the SSDA on behalf of the producer, does not stamp or seal the attestation, does not provide legal counsel, does not replace 3PAO assessment, and does not ship Jira, ServiceNow, Slack, PagerDuty, SIEM, SOAR, GRC, or CMDB push connectors.

Buyer and operator pairing

The CISA Secure Software Development Attestation Form workbook is the operating record that CISOs and security leaders, GRC and compliance teams, AppSec teams, product security teams, internal security teams, security engineering teams, and security architects publish jointly with general counsel, federal sales operations, and the signing officer when a federal agency contracting officer, an inspector general, a 3PAO assessor, an internal audit function, a board, an audit committee, or a customer security review asks for evidence that the software the federal agency is acquiring was developed in line with the NIST SSDF and that the producer can defend the signature on the CISA SSDA. External advisors (virtual CISOs, compliance consultants, and federal-facing security consultants) use the same workbook to give producer programmes a defensible federal attestation chain rather than a placeholder signature drafted on the eve of a federal procurement decision, an inspector general inquiry, or a contract renewal review.

Loading tool...

Related features

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

Vulnerability management software that tracks every finding

Finding overrides that survive every scan cycle

Find vulnerabilities before they ship

Repository connections for SAST and SCA

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Bulk finding import bring your scanner data with you

Verify fixes and track reopens on the same finding record

AI-powered reports in seconds, not days

Notifications and alerts for the people who carry the work

Audit fieldwork evidence request fulfillment

Cross-framework control mapping

Vendor security questionnaire response workflow

SDLC vulnerability handoff

SBOM management and VEX publishing

Dependency vulnerability triage

Vulnerability fix verification

Vulnerability acceptance and exception management

Security leadership reporting

Carry the signed SSDA, the supporting evidence index, and the POAM register on one workspace rather than across folders

SecPortal pairs the signed CISA SSDA to the live security operating record so the inspector general inquiry, the federal agency contracting officer follow-up, the 3PAO assessment, the qui tam relator review, and the annual renewal all read against one workspace with named-actor activity log. Free plan available.

Get Started Free

No credit card required. Free plan available forever.

CISA Secure Software Attestation Form Templatea fourteen-section workbook for the federal SSDA covering identity, signatory chain, the four practice clusters, POAM, 3PAO, SBOM, VEX, audit trail, renewal cadence, and framework crosswalk

Fourteen sections that turn the one-page CISA attestation into a defensible operating workbook

1. Cover identity, software in scope, and federal agencies

2. Signatory authority and False Claims Act exposure

3. Practice cluster 1: separated and secure software development environment

4. Practice cluster 2: provenance and integrity, SBOM, SLSA

5. Practice cluster 3: vulnerability disclosure programme and management

6. Practice cluster 4: good coding practices and secure-by-design

7. Supporting evidence index

8. POAM (Plan of Action and Milestones) register

9. 3PAO (Third-Party Assessment Organization) register

10. SBOM provision and VEX statement commitment

11. Audit trail, document custodian, and signed attestation chain

12. Renewal cadence and named amendment triggers

13. Framework crosswalk: SSDA, SSDF, and parallel regimes

14. Document control footer

Eight failure modes the SSDA workbook has to design against

Sign-and-file with no supporting evidence chain

Practice cluster paraphrase rather than verbatim attestation language

Missing POAM register for known gaps

Permanent POAM that never closes

Stale SBOM provision

Missing 3PAO reference at critical-software tier

Wrong signing authority below the CEO or properly-delegated designee

No renewal cadence and no amendment triggers

Ten questions the SSDA workbook answers

How the SSDA workbook pairs with SecPortal

Buyer and operator pairing

Related features

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

Vulnerability management software that tracks every finding

Finding overrides that survive every scan cycle

Find vulnerabilities before they ship

Repository connections for SAST and SCA

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Bulk finding import bring your scanner data with you

Verify fixes and track reopens on the same finding record

AI-powered reports in seconds, not days

Notifications and alerts for the people who carry the work

Audit fieldwork evidence request fulfillment

Cross-framework control mapping

Vendor security questionnaire response workflow

SDLC vulnerability handoff

SBOM management and VEX publishing

Dependency vulnerability triage

Vulnerability fix verification

Vulnerability acceptance and exception management

Security leadership reporting

Carry the signed SSDA, the supporting evidence index, and the POAM register on one workspace rather than across folders

Fourteen sections that turn the one-page CISA attestation into a defensible operating workbook

1. Cover identity, software in scope, and federal agencies

2. Signatory authority and False Claims Act exposure

3. Practice cluster 1: separated and secure software development environment

4. Practice cluster 2: provenance and integrity, SBOM, SLSA

5. Practice cluster 3: vulnerability disclosure programme and management

6. Practice cluster 4: good coding practices and secure-by-design

7. Supporting evidence index

8. POAM (Plan of Action and Milestones) register

9. 3PAO (Third-Party Assessment Organization) register

10. SBOM provision and VEX statement commitment

11. Audit trail, document custodian, and signed attestation chain

12. Renewal cadence and named amendment triggers

13. Framework crosswalk: SSDA, SSDF, and parallel regimes

14. Document control footer

Eight failure modes the SSDA workbook has to design against

Sign-and-file with no supporting evidence chain

Practice cluster paraphrase rather than verbatim attestation language

Missing POAM register for known gaps

Permanent POAM that never closes

Stale SBOM provision

Missing 3PAO reference at critical-software tier

Wrong signing authority below the CEO or properly-delegated designee

No renewal cadence and no amendment triggers

Ten questions the SSDA workbook answers

How the SSDA workbook pairs with SecPortal

CISA Secure Software Attestation Form Template
a fourteen-section workbook for the federal SSDA covering identity, signatory chain, the four practice clusters, POAM, 3PAO, SBOM, VEX, audit trail, renewal cadence, and framework crosswalk