A platform can supply dated records that support several SSDF practices, such as inventories, scan results, and approvals. It cannot attest for you. NIST SP 800-218 describes practices, and the attestation form is a statement your company makes. Use the platform as an evidence source, and keep legal and leadership review in the loop.
What the SSDF is
NIST published SP 800-218, the Secure Software Development Framework Version 1.1, in February 2022. NIST describes it as a core set of high-level secure software development practices that can be integrated into each SDLC implementation. CISA's Secure Software Development Attestation Form is based on it. CISA's page also notes that agencies may choose to use that form, and may include contractual requirements for an SBOM on request. Read the current text of what a specific buyer asks for, since requirements differ by agency and contract.
Where platform data helps
| SSDF area | Evidence a platform can supply |
|---|---|
| Protect software | Inventory of components, signed or checksummed SBOMs per release |
| Produce well secured software | Scan results on each change, policy gate logs |
| Respond to vulnerabilities | Finding history, time to fix, exception approvals |
| Prepare the organization | Written policy rules, owner mappings, access logs |
These records are inputs. They show the practice ran. They do not show your whole secure development process.
What it cannot cover
- Training and role definitions for your engineers
- Threat modeling and design review notes
- Code review quality
- Build environment hardening outside what the platform sees
- Third party attestations from suppliers
You will need other records for those, and a person to write the narrative.
Build an evidence folder
- Pick the buyer's questions or the form's statements.
- For each, list where evidence lives today.
- Export from the platform with dates: SBOMs, scan logs, policy versions, exception records.
- Store exports in a controlled location with an index.
- Review quarterly so the evidence reflects the current year.
Wording discipline
Describe what you do and show proof. Avoid absolute claims. Say that dependencies are scanned on each pull request and results are retained, not that your software is secure. If an attestation is requested, the signing officer should read each statement against real records first. This guide is not legal advice, so have counsel confirm obligations that apply to your contracts.
A worked example
Take a hypothetical software vendor that receives a customer request to describe its secure development practices, referencing the SSDF and the CISA attestation form. The compliance manager builds an evidence index instead of writing from memory.
For each statement in the request she writes down the practice, the control the company runs, and where the proof lives. For the practice about maintaining an inventory of components, the proof is the dated SBOM per release, stored with checksums. For the practice about checking for known vulnerabilities, the proof is scan results retained for each pull request and release, plus the policy that defines blocking rules. For the practice about responding to vulnerabilities, the proof is the finding history with owners and fix dates, and the exception log with approvals.
She finds two gaps. Training records are kept by another team, and threat modeling notes are scattered. She asks those owners to supply records and writes an honest note in the index that the threat modeling process is informal for two products. Before anything is signed, the company's counsel reviews the statements. The signing officer reads each statement against the index.
Evidence index template
| Practice or statement | Control we run | Evidence | Owner | Last refreshed |
|---|---|---|---|---|
| Component inventory | SBOM per release | Dated SBOM files | Platform owner | |
| Known vulnerability checks | Scan on every pull request | Scan logs, policy file | Security lead | |
| Vulnerability response | Triage and fix tracking | Finding history, exceptions | Security lead | |
| Secure build | Hosted CI, protected branches | CI config, branch rules | Platform owner |
Add rows for each statement in the request. An empty evidence cell is a finding for you to resolve.
What good platform evidence looks like
Good evidence is dated, attributable, and repeatable. It shows what ran, when, and with which rules. It can be reproduced on request. Weak evidence is a screenshot with no date or a dashboard that cannot be exported. When you evaluate a platform, ask for an export of each type and check that it carries timestamps and identifiers.
Keeping the index fresh
- Refresh evidence every quarter.
- Re-check before each attestation or large customer response.
- Note any change in tooling, because evidence may change shape.
- Keep old versions, since a buyer may ask about a past period.
Where limits apply
CISA's page notes that agencies may choose to use the attestation form and may include contractual requirements for an SBOM. What a given buyer requires depends on that buyer and the contract. This post describes how to organize evidence, not what any law or contract demands, and counsel should confirm obligations for your situation.
Try it yourself
Click through it at your own pace, or open it full screen. See how one piece of scan evidence can map to more than one control.
Safeguard provides compliance and evidence automation alongside SBOM and dependency scanning and policies and gates, so exports carry dates. It does not issue attestations on your behalf. You can start with the free scan at gold.safeguard.sh/scan.
Quick check
Does using a platform make us SSDF compliant?
No. It supplies evidence for some practices. Compliance depends on your whole process and what the requesting party accepts.
How often should evidence be refreshed?
At least quarterly, and before any attestation is signed.
Who signs an attestation?
That is set by the requesting party and your own governance. Have counsel and a company officer review it, and do not sign statements you cannot back with records.
Sources
Last reviewed: 19 October 2026.
