Name the framework you use as a reference, state which practices you actually run, and give one example of evidence for each. NIST's Secure Software Development Framework, SP 800-218, is a common reference. Say "aligned with" only after you have mapped your practices, and never imply a certificate that does not exist.
What the SSDF is
NIST published SSDF version 1.1 in February 2022 as SP 800-218. Its abstract describes a core set of high level secure software development practices that can be integrated into any software development life cycle model, and says following them should help producers reduce vulnerabilities in released software, limit the impact of those not found, and address root causes.
Two points follow. It is a set of practices, not a certification. And it is deliberately high level, so you decide how each practice shows up in your team.
The answer in three layers
- Reference. "We use NIST SP 800-218 as a reference for our development practices."
- Practices. List the ones you run: code review, automated testing, dependency scanning, a process for handling reported vulnerabilities.
- Evidence. For each, name an artefact: branch protection settings, scan results per release, a vulnerability handling ticket.
A mapping table you can reuse
| Practice area | What you might run | Evidence to keep |
|---|---|---|
| Prepare the organisation | Roles, training, secure toolchain | Role list, training records |
| Protect the software | Access control, signed or checksummed releases | Repo settings export |
| Produce well secured software | Review, testing, dependency checks | Review logs, scan output |
| Respond to vulnerabilities | Intake, triage, fix, disclosure | Tickets with dates |
The four group names mirror the framework's structure, but check the document for the exact practice identifiers before you cite them in an answer.
Overclaim traps
- Saying "SSDF compliant" or "SSDF certified". There is no certificate to hold.
- Listing practices you plan to start. Say planned, with a date.
- Describing a tool as covering practices it does not touch.
- Using the framework name when a customer's contract asks for a formal attestation. Ask the customer exactly what form they need and answer that question; do not assume.
If a customer is a government supplier and asks about secure development attestation, ask them which form they mean and what the contract says, then answer from the form. Do not guess at what is required.
Steps to build the mapping
- Download SP 800-218 from NIST.
- List what your team already does, honestly, in a spreadsheet.
- Match each activity to a practice and mark gaps.
- Attach one dated evidence item to each matched row.
- Assign an owner and a review date to each row.
- Share a summary with customers on request, and keep the detail internal.
See the gate in action
A pull request gate is one visible piece of evidence: it shows a check ran before code merged.
Try it yourself
Click through it at your own pace, or open it full screen. Look for the point where a failing check blocks a merge, since that record is what you would cite as evidence.
Where Safeguard fits
Safeguard's policies, gates and guardrails and its compliance and evidence automation produce dated records of checks run on code, which can sit behind answers like these. The free scan is at https://gold.safeguard.sh/scan.
Quick check
Can we say we are SSDF certified?
No. NIST publishes the framework as recommendations. Say you use it as a reference or have mapped your practices to it.
Do we need every practice?
The framework is high level and you decide how to apply it. Be clear about which practices you run today and which are planned.
Sources
Last reviewed: 19 October 2026.
