Check four things for every third-party component: whether it still receives fixes, whether it has known unremediated vulnerabilities, whether its ownership changed, and whether the artifact you got is the one the producer published. NIST SSDF task PW.4.4 and its draft examples describe each check.
What PW.4.4 says
The task is to verify that acquired commercial, open source and all other third-party components comply with your organization's own requirements throughout their life cycles. The draft SSDF 1.2 lists notional examples, including these:
- Regularly check for publicly known vulnerabilities that vendors have not yet remediated.
- Build automatic detection of known vulnerabilities into the toolchain.
- Ensure each component is still actively maintained and has not reached end of life, including software acquired through a merger or acquisition.
- Determine a plan of action for each component that is no longer maintained or will not be available soon.
- Confirm integrity through digital signatures or other mechanisms.
- Regularly review libraries for ownership changes and evaluate any impact.
A check table
| Check | Signal to look at | Action if it fails |
|---|---|---|
| Still maintained | Date of last release, open security issues, stated support policy | Plan replacement or a supported fork |
| Known vulnerabilities | Scan results against advisory data | Upgrade, mitigate or document an accepted risk |
| Ownership change | Change of maintainer or publisher account | Review recent releases before upgrading |
| Integrity | Signature or checksum matches the publisher's | Block the artifact and investigate |
I did not find a numeric rule, such as "no release in 12 months," in the sources. Pick your own threshold and write it down, because PW.4.4 is measured against your requirements.
Setting your own requirement
- Write a one page component policy: allowed licenses, maximum age since last release, minimum maintainer activity, required signature checks.
- Apply it at the pull request, not once a year.
- Record exceptions with an owner and a review date.
Why buyers ask
CISA's Secure by Demand guide asks how a manufacturer vets the open source components it incorporates. A written policy and a run history answer that directly. See the Secure by Demand questions, and for the related code-level tasks see what SSDF asks for in code review and testing.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the full list of findings with the reachable ones. It shows why triage by use matters when you have many components.
Quick check
Is there a standard age limit for a dependency?
Not in the sources I read. PW.4.4 refers to your own requirements, so define yours.
Does the check apply to commercial components too?
Yes. The task covers commercial, open source and all other third-party components.
Safeguard provides SBOM and dependency scanning, reachability analysis and policies and gates, which can run these checks on each change. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
