Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- The NIST (National Institute of Standards and Technology) Secure Software Development Framework (SSDF) asks you to keep verifying third-party components, including open source ones, against your own requirements.
- A vulnerability scan is only part of verification, and the SSDF’s examples also cover maintenance status and integrity.
- Open source usually has no supplier obliged to show that a component meets your requirements, so your team gathers that evidence.
- That evidence includes provenance, a record of each component’s origin and changes. A component list alone doesn’t capture it.
- Verification comes down to four decisions: requirements, evidence, safeguards before the build, and a plan for unmaintained components. Start with requirements.
If a customer asks how you verify the open source libraries in your product, the NIST Secure Software Development Framework (SSDF) has probably shaped the question. One of its tasks, PW.4.4 in the Produce Well-Secured Software group, asks producers to verify third-party components, open source ones included, against requirements they define themselves.
A clean scan report covers known vulnerabilities, but PW.4.4’s examples also point to whether a component is still maintained and whether its integrity can be confirmed. The task itself doesn’t define “verify,” name a tool, or say what evidence to keep.
That leaves you to write the requirements and produce the proof. And for open source components, there’s usually no contract behind the library, so no supplier is obliged to hand you that proof.
Where the NIST SSDF Stands in 2026
NIST publishes the SSDF as Special Publication (SP) 800-218. The current final version is Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, from February 2022. It sorts its practices into four groups, each with a two-letter code: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Each practice has an ID, such as PW.4, and its tasks add an additional number, such as PW.4.4.
Version 1.1 is written for software producers and software acquirers, and it says nongovernmental organizations may use it voluntarily. It describes its practices as a basis for risk-based planning and says they aren’t meant to be a checklist. NIST presents the SSDF as a common vocabulary acquirers can use with their suppliers, so a requirement usually reaches you through a buyer’s policy or a contract that points to it.
Note: NIST released an initial public draft of SP 800-218 Revision 1, Secure Software Development Framework (SSDF) Version 1.2, on December 17, 2025, in response to Executive Order 14306. As of October 2026, version 1.1 is still the final version. The draft keeps PW.4.4 and the provenance task, PS.3.2, with the same numbering and wording, and adds two new practices, along with example text, under PW.4.4. This article follows version 1.1.
What PW.4.4 Says and What It Leaves Open
PW.4.4 asks producers to verify that acquired commercial, open source, and other third-party software components comply with requirements the organization defines throughout their life cycles. That wording leaves the requirements to you and names open source components outright. It also keeps the check running for as long as you use the component, well past a one-time review at adoption.
Beyond that, NIST offers seven notional implementation examples.
| PW.4.4 example | What it covers | Basis |
|---|---|---|
| Examples 1 and 2: check for publicly known vulnerabilities that vendors haven’t fixed yet, including automatic detection in the toolchain | Known flaws in the component | SP 800-218 version 1.1, notional |
| Example 3: use existing results from commercial vetting services | Outside vetting results | SP 800-218 version 1.1, notional |
| Example 4: confirm the component is still actively maintained and hasn’t reached end of life (EOL), including that newly discovered vulnerabilities are being remediated | Support status and remediation of new flaws | SP 800-218 version 1.1, notional |
| Example 5: make a plan of action for components no longer maintained or soon to be unavailable | Your response when support ends | SP 800-218 version 1.1, notional |
| Example 6: confirm integrity through digital signatures or other mechanisms | Integrity of the artifact | SP 800-218 version 1.1, notional |
| Example 7: review, analyze, or test the code | The code itself | SP 800-218 version 1.1, notional |
Checking for known vulnerabilities covers two of those seven examples, so a scan report alone answers part of the task. A scan for known flaws doesn’t usually tell you whether an artifact is intact or whether anyone still maintains the component, and Examples 4 and 6 cover those questions.
The SSDF 1.2 draft adds an eighth PW.4.4 example: regularly review third-party libraries for ownership changes and evaluate the impact of each change. A known-vulnerability scan usually doesn’t flag an ownership change, so this example would need its own check.
For an unmaintained component, Example 5’s plan of action usually takes one of three forms: replace it, patch the version you run, or accept the risk in writing. The middle option means someone has to write and test the fix, and that someone is you unless you’ve arranged for somebody else to.
Open Source Often Has No Supplier to Hand You Evidence
PO.1.3, the SSDF’s task for dealing with suppliers, covers communicating requirements to third parties who provide commercial components. Its examples include adding requirements to contracts, requiring suppliers to attest that their software meets those requirements, and requiring provenance data and integrity-verification mechanisms for all components of their software.
Open source code you ship falls under PW.4.4 but not PO.1.3, so the SSDF asks you to verify it without a task to set terms with its authors. In practice, a library usually comes with no contract, so there’s typically no counterparty obliged to hand you provenance or integrity evidence. Someone on your side has to produce or collect it.
Your requirements come first, and PO.1.1 is the SSDF’s own starting point for writing them. Its second example is to define policies for securing your development processes, including those for open source and other third-party components. Write them before you evaluate any tooling. PW.4.4 measures components against your requirements, and a tool’s default checks tend to stand in for them if you skip the step.
A short requirements document can cover which maintenance activities are acceptable, what happens when a component loses its upstream support, who approves an exception, and how integrity is confirmed. PO.1.3’s fifth example describes a process for handling requirements a component doesn’t meet, including periodic review of approved exceptions. You can run the same process for open source components.
From the SSDF: PW.4.1, the SSDF’s task for acquiring components includes two examples describing steps your team can take without a supplier. One is to obtain provenance information, such as a software bill of materials (SBOM) or a composition analysis, for each component. The other is hosting sanctioned, vetted open source components in one or more repositories.
Without a supplier in the middle, there’s usually nothing between a maintainer’s release and your build unless you add a safeguard. Options include confirming signatures where publishers provide them, rebuilding from source, or screening what arrives before it reaches your build environment. The SSDF’s notional examples mention some of these, including signatures in PW.4.4 and building from source in PW.4.1.
Provenance Under PS.3.2 Is More Than a Component List
PS.3.2 belongs to the SSDF’s Protect the Software group. It asks producers to collect, safeguard, maintain, and share provenance data for all components of each release, and it names an SBOM as one example of where that data can live. For open source components, there’s usually no supplier obliged to hand it to you.
NIST defines provenance, borrowing from Special Publication 800-53, as the chronology of a component’s origin, development, ownership, location, and changes. By that definition, a list of names and versions answers what’s in a release, and the chronology answers where each piece came from and what’s happened to it. A component list doesn’t automatically carry the second, so check whether your SBOM records that history or only the list.
The examples under PS.3.2 include sharing the data with acquirers and your own response teams, protecting its integrity so recipients can verify it, and updating it whenever a component updates. PS.3.2 says “all components” and doesn’t use the word “transitive”. Applying it to dependencies you never chose directly is an inference, but one that follows from the word all. Decide whether transitive dependencies are in scope based on your requirements, and record the decision.
Two other terms come up alongside SBOMs. SLSA (Supply-chain Levels for Software Artifacts) is a separate supply chain security specification, and its Build Level 3 describes a hardened build platform that protects against tampering during the build. VEX (Vulnerability Exploitability eXchange) documents, as described by the Cybersecurity and Infrastructure Security Agency (CISA), indicate a product’s status for a given vulnerability, such as affected, not affected, or fixed. Both give you evidence for SSDF tasks. SLSA provenance records who built a package, with what process, and from what inputs, which is part of the history PS.3.2 asks you to keep. A VEX record shows whether a known vulnerability affects a component, which is what PW.4.4’s first example asks.
What the Federal Attestation Form Asked About Components
Federal buyers used to ask about third-party components directly. Under Office of Management and Budget (OMB) memos M-22-18 and M-23-16, agencies had to obtain attestations from software producers, and CISA and OMB released the Secure Software Development Attestation Form for that purpose on March 11, 2024.
Section III of the form has producers attest to a good-faith effort to maintain trusted source code supply chains, using automated tools or comparable processes that address the security of third-party components and manage related vulnerabilities. It also has them attest to maintaining provenance for third-party components “to the greatest extent feasible.” The form’s appendix maps those items to SSDF tasks that include PW.4.4 and PS.3.2.
The form doesn’t cover the third-party open source and proprietary components built into the product an agency uses. However, producers who use those components still attest that they’ve taken the Section III steps to reduce the risk of relying on them.
On January 23, 2026, OMB memo M-26-05 rescinded M-22-18 and M-23-16. Agencies may still use the form and may require SBOMs by contract, and the memo lists SP 800-218 as a reference they can use. It says there’s “no universal, one-size-fits-all method” for securing the software and hardware that agencies run, leaving each agency to set assurance policies that fit its risk profile.
| Document | What it says | Current status | Basis |
|---|---|---|---|
| SP 800-218 version 1.1 | Defines PW.4.4 and PS.3.2 | Final, February 2022 | NIST guidance |
| SP 800-218 Revision 1 draft (SSDF 1.2) | Keeps both tasks, adds new material | Initial public draft | NIST draft guidance |
| OMB M-22-18 and M-23-16 | Required agencies to obtain attestations | Rescinded January 23, 2026 | OMB policy |
| Attestation form | Producers attest to practices drawn from the SSDF | Optional for agencies | Agency form (CISA and OMB) |
| OMB M-26-05 | Agencies set their own assurance policies | Current | OMB policy |
With M-22-18 and M-23-16 rescinded, whether a buyer asks how you verify components or track their provenance depends on that buyer’s policy and contract.
Deciding What Verification Means for Your Dependencies
In practice, verification comes down to four decisions: which requirements a component has to meet, what proof you keep, what stands between an upstream release and your build, and what you do when an upstream maintainer stops supporting that component. The first two are policy work that only your team can do. The last two are where tooling can take over the repetitive work.
SecureChain from TuxCare sits between upstream releases and your build. It screens the source code of open source packages for malware and suspicious patterns, rebuilds packages from that source in hardened, isolated environments, and keeps patching them under a service-level agreement while upstream is active. Endless Lifecycle Support (ELS) continues to provide fixes after upstream maintenance ends, covering the “patch-the-version-you-run” option described earlier. Coverage spans JavaScript, Python, Java, Go, Rust, and PHP. TuxCare also provides SBOMs, VEX records, and SLSA Level 3 provenance for each package.
If you’re deciding how to handle open source packages that go unscreened or unmaintained, ask us what SecureChain covers.
FAQ
What Is the NIST SSDF?
The NIST SSDF is the Secure Software Development Framework, which NIST, the U.S. standards agency, publishes as Special Publication (SP) 800-218. It groups secure development practices into Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. The current final version is 1.1, from February 2022.
Who Is the NIST SSDF Written for?
Software producers, such as commercial vendors and internal development teams, and software acquirers, including federal agencies and other organizations, are the two primary audiences. NIST, the U.S. standards agency, says nongovernmental organizations may use the Secure Software Development Framework (SSDF) voluntarily. A company building on open source components counts as a producer.
Does the SSDF Cover Open Source Software?
Partly. In the Secure Software Development Framework (SSDF), the task for verifying third-party components (PW.4.4) and the task for acquiring them (PW.4.1) both name open source components. The task for communicating requirements to suppliers (PO.1.3) names only commercial components. NIST (the U.S. standards agency) lists an SSDF baseline for open source software among actions it’s considering, and as of October 2026, it hasn’t published one.
What Are Notional Implementation Examples in the SSDF?
In the Secure Software Development Framework (SSDF), notional implementation examples are sample tools, processes, or methods that could help carry out a task. The U.S. standards agency NIST says no example or combination is required, and they aren’t the only options.
Does NIST Certify Anything Under the SSDF?
NIST, the U.S. standards agency, publishes the Secure Software Development Framework (SSDF) as guidance, and its SSDF materials describe no certification program. The federal attestation form accepts a producer’s self-attestation or a third-party assessment, and the Office of Management and Budget (OMB) no longer requires the form government-wide.
