Under SSDF PO.1.3 you define a core set of security requirements for commercial software components and communicate them to suppliers, ideally in acquisition documents and contracts. Typical asks are a vulnerability disclosure program, provenance data and an agreed process for requirements a supplier cannot meet.
What PO.1.3 covers
PO.1.3 is about third parties that provide commercial software components your own software reuses. NIST notes it was formerly PW.3.1 in an earlier draft and moved into the PO group. It is separate from PW.4, which covers how you acquire, review and maintain the components themselves.
What the examples suggest
NIST lists these notional examples:
- A core set of security requirements for components, included in acquisition documents and agreements
- Selection criteria such as the supplier's vulnerability disclosure program, product security incident response capability or adherence to practices you define
- A request that third parties attest their software meets your requirements
- A request for provenance data and integrity verification for all components
- A process for requirements a component does not meet, with periodic reviews of approved exceptions
Provenance here means the history of where a component came from and how it changed. An SBOM is one form of it.
A short requirements list you could send
| Requirement | Evidence you could ask for |
|---|---|
| Public way to report vulnerabilities | Link to a disclosure policy or security contact |
| Timely advisories | Sample advisory or past notices |
| Component inventory | SBOM in a standard format |
| Integrity of releases | Signatures or checksums you can verify |
| Support lifecycle | Published end of support dates |
These rows are a starting point you adapt to your risk. They are not mandated text.
Steps
- Decide which suppliers are in scope, starting with the components that touch sensitive data or run in production.
- Draft the requirements list above, trimmed to what you will really check.
- Add it to your intake form and contract templates.
- Record each supplier's response in a register.
- When a supplier cannot meet an item, log an exception with an owner and a review date.
Your legal team should review contract wording. This post is not legal advice.
Evidence to keep
The template you send, the supplier's answers, any exception records and the date you reviewed them. If a supplier declines, the record of that decision and the compensating step you chose is itself good evidence.
Be consistent
Treat every supplier the same way within a risk tier. A buyer reading your register wants to see a pattern, not a one-off.
Proportion the ask to the risk
Not every supplier needs the full list. A component that handles authentication or sensitive data deserves a detailed review, while a small utility may need just a check of its support status. Define two or three tiers, say which asks apply to each, and record the tier in your register. This keeps procurement moving and shows a reviewer that your requirements are applied with judgment rather than by habit.
Quick check
Does PO.1.3 cover open-source libraries?
The task names commercial software components. Open-source components are addressed through PW.4 and your own policies.
What if a supplier refuses to answer?
Record that, assess the risk, and decide whether to accept it, add controls or switch. NIST's examples describe a process for such cases with periodic review.
Safeguard's SBOM and dependency scanning can help you see what a supplied component brings in. Try 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.
