SSDF practices PW.1 and PW.2 expect you to model security risk during design, track requirements and decisions, and have someone who did not design it, or an automated process, review the design. Evidence is a threat model, a decision log with exceptions, and a recorded review.
What the practices say
PW.1 is about designing software to meet security requirements and mitigate risks. PW.2 is about reviewing the design to verify it meets those requirements and addresses the identified risks.
| Task | What it asks |
|---|---|
| PW.1.1 | Use risk modeling, such as threat modeling, attack modeling or attack surface mapping |
| PW.1.2 | Track and maintain security requirements, risks and design decisions |
| PW.1.3 | Build in support for standard security features instead of proprietary ones |
| PW.2.1 | Have a qualified reviewer not involved in the design, or automated checks, review it |
Risk modeling artifacts
The examples include more rigorous assessment for high risk areas such as sensitive data, authentication and access control, using data classification, and reviewing vulnerability reports for earlier software. A usable output is a one or two page model listing assets, entry points, threats and mitigations.
Decision tracking
PW.1.2 examples say to record the response to each risk and the rationale for any approved exception, keep records usable for auditing and maintenance, and re-evaluate exceptions periodically. A table in the design doc works:
| Risk | Response | Owner | Exception review date |
|---|---|---|---|
| Example risk | Mitigation chosen | Name | Date |
Independent review
PW.2.1 allows a qualified person who was not involved in the design, or automated processes in the toolchain. The examples add: have the designer correct failures, change the design if requirements cannot be met, and record findings as artifacts in the specification, issue tracker or threat model.
Keep it proportionate
Not every change needs a full model. A sensible rule is to require a short threat note for anything that handles sensitive data, changes authentication or exposes a new interface, and to skip it for small internal tweaks. Write that rule down. The PW.1.1 examples themselves call for more rigorous assessment in high risk areas, so a risk based threshold fits the practice and keeps the effort where it matters.
Quick check
Do we need a formal threat modeling tool?
No. The practice names threat modeling, attack modeling and attack surface mapping as forms of risk modeling. A written model reviewed by a second person can meet it.
Can the designer review their own design?
PW.2.1 asks for a reviewer not involved in the design, or automated processes. A self review alone does not match the wording.
Where tooling helps
Safeguard offers compliance and evidence automation and policies that can require a review record before release. The modeling itself is human work. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
