When an enterprise customer asks for your secure development policy, they usually want to see that you have written down how code goes from commit to release. NIST's SSDF 1.2 initial public draft, released on 17 December 2025, gives the vocabulary. Its first task, PO.1.1, asks organizations to "identify and document all security requirements" for their development infrastructure and processes, and its example says to review them "at least annually."
For vendors selling into the EU, Annex I Part II of Regulation (EU) 2024/2847 adds vulnerability handling duties that a policy should also cover.
What's affected
Any team without a short, current policy it can send to a buyer. One page is enough if every line is something you really do.
What to do now
Use these sections, in this order. Each one points at the source it answers.
- Purpose and scope. Which products and repositories the policy covers. Name the owner and the review date (SSDF PO.1.1).
- Roles. Who approves releases, who triages vulnerabilities, who owns the build system (SSDF PO.2).
- Source and access. All code and configuration live in a managed repository, access is least privilege, accounts are individual and use MFA (SSDF PS.1).
- Review and testing. Every change is reviewed by a second person, and automated security checks run in CI (SSDF PW.7, PW.8).
- Third party components. How components are approved, tracked in an SBOM and checked for known vulnerabilities (SSDF PW.4; CRA Article 13(5) and Annex I Part II point 1).
- Release integrity. What you publish with each release, such as hashes, signatures or an SBOM, and where you archive it (SSDF PS.2, PS.3).
- Vulnerability handling. Intake address, triage targets, fix and disclosure process, and a coordinated vulnerability disclosure policy (SSDF RV.1.3; CRA Annex I Part II points 2, 4 and 5).
- Updates. How you test and roll out updates, and how long each version is supported (SSDF PS.4 in the draft; CRA Article 13(8) sets a support period of at least five years for products it covers, unless expected use is shorter).
- Exceptions. Who can approve a deviation, for how long, and where it is logged.
- Review. At least annually, and after any security incident that touched your development infrastructure.
Keep it to what you can evidence. If a sentence has no ticket, log or setting behind it, remove it.
Quick check
How often does the SSDF 1.2 draft's example suggest reviewing security requirements?
At least annually, or sooner if there are new requirements or a major incident targeting development infrastructure.
