NIST SSDF Self-Assessment (SP 800-218)

Write down the security rules your development process, your build infrastructure and your software must meet, keep them current, and pass the relevant ones on to suppliers of components you reuse.

Example evidence: A secure development policy or standard; a security requirements baseline for products; supplier contract clauses or questionnaires covering secure development.

Everyone who touches the software lifecycle knows their security duties, is trained for them, and leadership has visibly committed to secure development.

Example evidence: A RACI or role descriptions covering security in the SDLC; role-based secure development training records; a signed policy or leadership statement.

Decide which security tools each pipeline must include, run those tools securely, and have them produce records that show the practices actually happened.

Example evidence: A toolchain standard (which scanners and checks run where); hardening and access settings for CI/CD and security tools; retained scan logs and pipeline artefacts.

Set clear pass or fail criteria for security checks during development (for example, no unresolved critical findings at release) and collect the data to show whether each release met them.

Example evidence: Documented release gates or security acceptance criteria; pipeline policy checks; dashboards or reports showing gate results per release.

Separate and protect development, build, test and distribution environments, and harden the laptops and workstations developers use.

Example evidence: Network or account separation between environments; MFA and conditional access on source control and CI; endpoint hardening baselines for developer machines; access reviews and audit logs.

Store source code, built code and configuration-as-code with least-privilege access, so only authorised people, tools and services can read or change it.

Example evidence: Repository permission model and access reviews; branch protection with required reviews; signed commits where used; audit logs of repository changes.

Give the people who obtain your software a way to check that what they received is what you released, such as published hashes or code signatures.

Example evidence: Signed release artefacts; published checksums; signing key management procedures; customer-facing instructions on how to verify a release.

Keep a protected copy of each release with its supporting data, and record where every component came from (for example in a software bill of materials, SBOM), so you can investigate problems later.

Example evidence: Immutable release archive with retention rules; an SBOM per release; build provenance records; documented retention period.

Assess security risk at design time, for example with threat modelling, record the security decisions you make, and use standard security services (identity, logging, access control) instead of building your own.

Example evidence: Threat models or design risk assessments; architecture decision records with security rationale; use of shared identity and logging platforms.

Have someone not involved in the design, or an automated check, confirm the design meets the security requirements and addresses the identified risks.

Example evidence: Design review records or sign-offs; security architecture review tickets; findings tracked to closure.

Prefer well-secured libraries and components over writing your own, and check that third-party components meet your requirements for their whole life, not just when first added.

Example evidence: An approved component list or intake process; software composition analysis results; dependency update policy; records of component risk reviews.

Follow secure coding practices suited to your languages and environment, such as validating input, encoding output and avoiding unsafe functions.

Example evidence: A secure coding standard per language; linters or IDE security plugins in use; developer training records.

Use compilers, interpreters and build tools with security features, decide which settings to use, and apply those approved settings consistently.

Example evidence: Documented approved compiler and build flags; build configuration in version control; pipeline checks that the approved configuration is used.

Decide where code review and automated code analysis (such as static analysis) are needed, run them against your secure coding standard, and log findings in the team’s issue tracker.

Example evidence: Code review policy; required pull-request reviews; static analysis results; findings triaged in the issue tracker.

Decide which kinds of testing of running code you need (for example dynamic scanning, fuzzing or penetration testing), carry them out, and log findings in the team’s issue tracker.

Example evidence: A security test plan; dynamic scan or fuzzing results; penetration test reports; findings triaged in the issue tracker.

Ship with secure default settings, and document each security-relevant setting so administrators know what it does.

Example evidence: A secure configuration baseline; default configuration files in version control; administrator hardening guide.

Keep looking for vulnerabilities in your software and its components after release, take reports from customers, researchers and public sources, and have a disclosure and remediation policy.

Example evidence: A published vulnerability disclosure policy or security.txt; monitoring of advisories for components you use; intake and investigation records.

Work out the risk of each vulnerability, decide how to respond, and fix or mitigate it in line with that risk.

Example evidence: A triage and prioritisation procedure; remediation timelines by severity; security advisories issued; tickets showing fixes delivered.

Find out why each vulnerability happened, look for patterns, fix the same class of bug elsewhere, and change the process so it does not recur.

Example evidence: Root-cause analysis records; trend reports by weakness type; variant hunts after a finding; SDLC changes made as a result.