An approved component list records which libraries, frameworks and commercial components your teams may use, at which versions, with provenance data and a named owner. SSDF PW.4.1 supports this idea: acquire well-secured components and keep maintaining them. Keep the list small, reviewed and tied to your build.
What PW.4.1 says
PW.4.1 asks you to acquire and maintain well-secured software components, such as libraries, modules, middleware and frameworks, from commercial, open-source and other third parties. The NIST examples include reviewing a component in the context of its expected use, repeating the review if the use changes substantially, and obtaining provenance information such as an SBOM for each component.
Other examples describe hosting sanctioned and vetted open-source components in a repository, keeping a list of approved commercial components and versions with their provenance data, and designating components that must be included in the software you build.
What goes in each row
| Field | Why |
|---|---|
| Component and version range | Defines what is allowed |
| Owner | Someone answers questions and decides on upgrades |
| Intended use | The review depends on the context |
| Provenance or SBOM reference | Supports later vulnerability checks |
| Review date | Shows the entry is maintained |
| Replacement plan | Covers end of life |
Steps
- Export what you use today from your lockfiles and build output.
- Group by how critical each component is, so reviews start where risk is highest.
- Review top tier components for maintenance activity, known vulnerabilities and the way you use them.
- Publish the list where developers work, and make requests for new components a simple ticket.
- Enforce at build time where practical, so the list is a control and not a document.
- Re-review on a schedule and when a component's use changes.
Keep it from going stale
Lists fail when requests are slow. Set a target response time for new component requests and stick to it. Also note the NIST example about keeping older versions of components until all transitions from them are finished: do not delete a version from the list while services still run on it.
Handling requests quickly
The most common reason developers bypass an approved list is delay. Agree a response target for new component requests and publish it. For low-risk additions, a lightweight check of maintenance status, license and known vulnerabilities can be enough. For higher-risk components, schedule a fuller review. Track how many requests are approved, declined and pending, since those numbers show whether the list is helping or being routed around.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a dependency inventory shows direct and indirect components, which is the raw material for an approved list.
Quick check
Must every transitive dependency be on the list?
Not necessarily. Many teams approve direct components and rely on scanning for what they pull in. Document your approach and why.
Is an approved list required by SSDF?
It appears as a notional example, not as a requirement. Other approaches can satisfy the intent of PW.4.1.
Safeguard provides SBOM and dependency scanning and policies and gates, which can help check builds against a list you define. The free scan is 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.
