SSDF practice PO.1 asks you to identify and document security requirements in three places: your development infrastructure and processes, the software you build, and the third-party components you buy or reuse. Then you keep those requirements current. The evidence is a set of written, dated, owned policies.
The three tasks in plain words
| Task | What it covers | A reviewer will ask |
|---|---|---|
| PO.1.1 | Security of dev infrastructure and processes | Who protects repos, build systems and developer laptops, and where is it written? |
| PO.1.2 | Requirements the software you build must meet | What must every release satisfy, and how do you check? |
| PO.1.3 | Requirements for third-party commercial components | What do you tell suppliers, and is it in contracts? |
NIST notes the practices are a subset of what an organization may need to do, and that their order does not imply priority. So you do not have to write all three in one sitting.
What the examples suggest
The NIST examples for PO.1.1 mention policies for securing development infrastructure, including endpoints, and for open-source and other third-party components. PO.1.2 examples include risk-based architecture requirements, checks at key points in the life cycle, retention rules for each release, notice of end of support, and a process for exception requests with periodic review of approved exceptions.
These are notional examples. They show what an implementation could look like. They are not a checklist you must complete.
How to keep it short and useful
A short document that people read beats a long one that sits in a wiki.
- Write one page per task, in plain sentences.
- Name an owner and a review date at the top of each page.
- State requirements as things a person could check, such as "all release branches require review before merge."
- Link each requirement to the place the check happens: a pipeline, a ticket template or a settings export.
- Keep a change log so a reader can see when it was last updated.
Keep it current
Several examples suggest reviewing requirements at least once a year, or sooner when new requirements arrive, a major vulnerability is found in released software or an incident hits your development infrastructure. Put that trigger list in the document itself and add a calendar reminder for the annual review.
If you have written requirements already for another purpose, such as a security policy for an audit, reuse the text. Add a short cross reference rather than maintaining two versions that drift apart.
What reviewers often find
Reviewers most often find requirements that are written but not tied to anything. A line saying all code is reviewed means little if the repository does not enforce it. When you draft each requirement, ask what setting, pipeline step or ticket would prove it, and note that next to the sentence. If nothing could prove it, either add a check or soften the requirement until it is true. This small habit makes later evidence collection far quicker and keeps your claims honest.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one control or document can be mapped to several framework entries, which is the same idea as reusing one policy for PO.1.
Quick check
Do we need three separate documents for PO.1?
No. One document with three sections works, as long as each task is clearly addressed and has an owner and a review date.
Is PO.1 a certification we can earn?
No. The SSDF is a set of recommended practices published by NIST. You can describe how your own practices line up with it, but there is no certificate attached to it.
Safeguard can help with the evidence side: its compliance and evidence automation and policies and gates features let teams record checks as they run. You can start with the free scan at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
