Choose SLSA, NIST SSDF or both: SLSA vs NIST SSDF for your buyers
When buyers ask for a supply chain claim, the first decision is which framework answers which question. SLSA covers build and source integrity for a specific pipeline, while NIST SSDF covers the development practices of the whole organization across its Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities groups. For most teams with external buyers, the honest starting point is both: SLSA proves that a given artifact came from a controlled build of a traceable source, and SSDF shows that the people and processes around that build are governed. Neither is a certification, and neither is a badge a buyer can accept on trust. Each needs evidence that an auditor or procurement reviewer can inspect, such as build provenance, retained logs, branch protection settings and records of vulnerability response.
Lead with SLSA when the buyer's question is narrow and artifact-level, for example whether a released binary or container image was built on a hardened, hosted build service from a protected source revision. Start by naming the build track level you can evidence for each release pipeline, and confirm against the current SLSA specification, which defines the Build track levels and the Source track, that your provenance and source controls meet the level you claim. Lead with SSDF when the question is about the organization, such as US federal buyers asking whether your secure development practices are documented and followed across products. Map each SSDF task to an owner, a policy and a repeatable record. Teams that sell into both markets should not treat the two as alternatives. Use SSDF to govern the program and SLSA to prove the outputs of the pipelines that the program covers.
Combining them is usually worth the effort when several products share pipelines or when a buyer asks for both a practice statement and artifact evidence. Confirm with your buyers which evidence format they will accept, and ask whether they expect a self-attestation or a third-party assessment, because the answer changes what you must retain. Plan for the cost of this work: the people who maintain pipelines, the time spent collecting provenance and the review cycles that keep the records current are all recurring. Ask any implementation partner to price these as written deliverables with named evidence, not as a general promise of compliance.
How SLSA and NIST SSDF differ on scope, evidence and buyers
This table compares SLSA and NIST SSDF on document type, unit of assurance, structure, evidence and buyers. Read it to see which framework answers a given buyer question, and which gaps the other one must fill.
| Factor | SLSA | NIST SSDF |
|---|---|---|
| Type of document | A specification with levels and tracks that describe build and source integrity guarantees | A special publication (SP 800-218, Version 1.1, February 2022) describing practices and tasks |
| Unit of assurance | A single build or a source repository, traced from source to artifact | The whole organization and its development life cycle, including how software is produced and how vulnerabilities are handled |
| Structure | Build track levels L0 to L3, plus a Source track for source code management requirements | Four practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV) |
| How it is evidenced | Provenance and build records showing that the artifact can be traced to its source and was not tampered with, checked against the level requirements | Documented policies, tooling and records that show each practice is in place, for example vulnerability disclosure policies under RV.1.3 or third-party component checks under PW.4.4 |
| Who typically asks | Open-source consumers and teams that need to verify how a released artifact was built | US federal buyers and agencies that reference SSDF in acquisition and secure software attestation requirements (confirm the exact clause with the buyer) |
| What it does not cover | Organizational policy, vulnerability response, and whether the code itself is free of flaws | Specific build provenance levels or cryptographic proof for each artifact; confirm with the buyer whether a provenance level is also required |
What SLSA evidence proves and what SSDF practices miss
SLSA and SSDF answer different questions about the same software. SLSA evidence speaks to how a specific artifact was built and where its source came from, while SSDF practices describe what the organization commits to doing across its life cycle. The cards below show where each stops, so a team can see which gaps need a separate control.
Build integrity and traceability
SLSA Build track levels L0 to L3 increase the guarantees that a built artifact has not been tampered with and can be traced back to its source. The useful check is whether a given release carries provenance from a build platform that the consumer can verify, and whether the build steps ran in an isolated environment. Provenance describes one build. It does not show that the team's other builds followed the same path.
Source track requirements
The SLSA Source track sets requirements for source code management, so a consumer can judge how changes reached the branch that was built. Ask whether protected branches, reviewed changes and retained history are enforced by the platform, not by convention. The Source track does not evaluate the quality of the code itself, and a clean source record does not show that the code is free of flaws.
Third-party component verification under PW.4.4
SSDF task PW.4.4 asks the organization to verify that acquired commercial, open-source and other third-party components meet its requirements throughout their life cycles. Automatic detection of known vulnerabilities in the toolchain is one example the framework gives. Confirm which components are checked, how often the check runs after release, and who acts on a finding. A dependency that passes at intake can become exposed later without any change to the team's own code.
Vulnerability disclosure under RV.1.3
SSDF task RV.1.3 calls for a policy on vulnerability disclosure and remediation, with a vulnerability disclosure program and a product security incident response team given as examples. A written policy shows intent and a defined path for reports. It does not show that any given release was patched on time or that reporters received a response. Ask for the policy, the response record and the time taken to ship fixes to supported versions.
Policy exists but the build is unchecked
A team can hold an SSDF-aligned policy and still ship a specific build without any provenance check. Policy describes the practices the organization intends to run, while SLSA evidence has to be produced for each artifact and verified by whoever consumes it. Illustratively, a release pipeline with no signed provenance leaves a buyer unable to confirm the build origin, even when the policy is current. Ask which artifacts carry provenance and where a verifier checks it.
Consumer-side verification gap
SLSA provenance only helps when someone downstream checks it before deployment. Open-source consumers, federal buyers and product makers preparing for the EU Cyber Resilience Act each need a defined step that rejects unverified artifacts. Confirm whether deployment tooling enforces provenance checks, or whether verification is a manual task that depends on a person remembering to run it.
Who asks for SLSA, who asks for NIST SSDF and what the EU CRA means
US federal buyers often ask suppliers to describe how their secure development practices work across the life cycle, and NIST SSDF is the framework most likely to appear in that request because it is organized as practice groups. SLSA fits narrower questions about how a built artifact was produced and whether it can be traced to source. The supplied facts do not establish which federal clause, memo or acquisition text applies to a given contract, so the team should read the solicitation itself.
- Practice-level evidence: A request that names SSDF usually expects answers across the Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities groups, in version 1.1 of SP 800-218.
- Third-party component checks: Task PW.4.4 asks teams to verify that acquired and open-source components meet their requirements, for example by building automatic detection of known vulnerabilities into the toolchain.
- Disclosure and response policy: Task RV.1.3 calls for a vulnerability disclosure and remediation policy, with a disclosure program and a product security incident response team given as examples.
- Build integrity questions: A buyer that asks how a released binary was built may point to SLSA levels, which describe increasing guarantees that software has not been tampered with and can be traced to its source.
Confirm the exact SSDF version the solicitation names, whether the buyer accepts self-attestation or requires independent evidence, which artifacts must be retained, and whether SLSA is required or only offered as one option.
Teams that consume open-source components usually need signals about how an upstream project builds and maintains its releases, not a formal attestation from that project. SLSA levels and OpenSSF Scorecard results answer different parts of that question, and SSDF applies to the consuming organization as well when it verifies what it pulls in. Treat these signals as inputs to the team's own intake review, since the supplied facts do not show that any single signal guarantees a component is safe.
- Automated repository checks: OpenSSF Scorecard runs checks such as Branch-Protection, Dangerous-Workflow, Pinned-Dependencies and Token-Permissions, scores each from 0 to 10 and combines them into a weighted aggregate score.
- Build provenance signals: SLSA levels from L0 to L3 describe increasing supply chain guarantees, so a consumer can ask whether a project's releases carry provenance that traces them to source.
- Consumer-side verification: SSDF task PW.4.4 applies to the team's own intake, so it should verify third-party components against its own requirements instead of relying on upstream claims alone.
- Shared risk vocabulary: Software Supply Chain Failures is A03 in the OWASP Top 10 2025, which gives procurement and architecture reviews a common label for this risk.
Read the Scorecard results for the exact version you deploy, ask maintainers which build and release controls they use, and confirm how they report vulnerabilities before you adopt the component.
Manufacturers placing products with digital elements on the EU market must work out what the Cyber Resilience Act requires of them, and that answer lives in the regulation text and any standards it references, not in a summary. The supplied facts do not set out CRA obligations, conformity routes or dates, and they do not show that the CRA names SLSA or SSDF as a required method. Teams should treat SSDF and SLSA as candidate evidence sources to test against the regulation, not as a checklist of duties.
- Scope and conformity route: Confirm from the regulation text which products and manufacturers are in scope and which conformity assessment route applies to each product category.
- Mapping to existing frameworks: Teams often use the SSDF practice groups as an inventory of development practices and SLSA levels as build evidence, but confirm whether any harmonised standard or referenced specification names either framework.
- Evidence ownership: Assign owners for build provenance, vulnerability handling records and component inventories now, because those records are the kind of material a reviewer is likely to ask for.
- Third-party and open-source components: Confirm how the regulation treats components built by third parties or open-source projects, and whether upstream practices can be relied on or must be verified by the manufacturer.
Confirm deadlines, reporting obligations and the applicable conformity route with the official regulation text, and involve legal counsel and any assessment body that applies to your product before you rely on this summary.
How a team maps SLSA levels onto SSDF practices
This sequence produces a team-owned document that shows which existing build and repository controls provide evidence for which SSDF practices, and where SLSA Build and Source posture stands today. It gives assessors and buyers a traceable starting point for their own questions.
Inventory build systems and repositories in scope
The platform or security lead lists every source repository, build pipeline, build runner and artifact registry that produces software for the product or service under review. For each, record the owner, the language stack, whether the build runs on hosted or self-hosted runners, and which release artifacts it emits. Done means the inventory names every path from commit to shipped artifact, with no build system left unlisted. Shadow pipelines that a single team runs outside the central tooling are the most common gap, so ask each engineering group directly.
Map SSDF practices to existing controls
The security lead and the engineering owners walk through the SSDF practice groups (Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities) and note which controls already operate for each in-scope system. Include code review rules, branch protections, dependency tooling, signing and vulnerability disclosure handling. Where a practice has no control, mark it as a gap rather than assuming coverage. Done means every practice in scope has either a named control and owner or a recorded gap.
Assess current SLSA Build level
Using the SLSA specification at slsa.dev, the build owner compares each in-scope pipeline against the Build track requirements for levels L0 to L3, focusing on whether builds are scripted, whether provenance is generated, and whether the build platform isolates tenants and protects signing material. Record the level each pipeline meets and the evidence behind it. Done means each pipeline has a documented Build level with its supporting artifacts. Confirm the exact requirement wording against the current specification (v1.2) with your own assessor, since requirements are the authoritative text.
Assess Source track posture
The repository owners review source management settings against the SLSA Source track, looking at how changes are reviewed before they reach protected branches, how history is protected from rewriting, and how actors are authenticated to the repository. Record the posture for each repository alongside its Build assessment. Done means every repository in scope has a Source track statement and a list of the settings that support it. Repositories that accept direct pushes to protected branches should be flagged for follow-up before any level is claimed.
Run OpenSSF Scorecard checks as automated evidence
The platform engineer runs OpenSSF Scorecard against each in-scope repository and records the results for Branch-Protection, Dangerous-Workflow, Pinned-Dependencies and Token-Permissions, along with the overall weighted score. Each check returns a score from 0 to 10, so keep the per-check output rather than only the aggregate. Done means each repository has a dated Scorecard report stored with the mapping. Scorecard is automated evidence for specific settings, not proof of a SLSA level or an SSDF practice, and the report should say so. Scorecard source and documentation are at the project's GitHub page.
Record which evidence satisfies which practice
The security lead builds the mapping table with one row per SSDF practice and columns for the control, the SLSA requirement it relates to, the Scorecard check or other artifact that evidences it, the owner and the review date. Use the same row for PW.4.4, which asks that third-party components be verified, and for RV.1.3, which covers vulnerability disclosure and remediation policy, so each supporting artifact is traceable. Done means each in-scope practice has at least one named evidence source or a documented gap with a remediation owner.
Confirm the mapping and keep it current
The team marks the document as its own internal mapping and states that it is not an official crosswalk between SLSA and SSDF. If a buyer, regulator or certification body asks for a formal correspondence, the reader should confirm with NIST, the SLSA project or the relevant assessor whether an official mapping exists before citing one. The owner sets a review trigger tied to pipeline changes, Scorecard reruns and SSDF or SLSA version updates. Done means the document carries a version history, an owner and a list of questions to confirm externally.
What a team receives from each approach
This table compares the records each approach produces, who owns them and how often they need regenerating. Read it to see which evidence a buyer can ask for and which evidence your own team must keep current.
| Artifact | SLSA | NIST SSDF |
|---|---|---|
| Core output | Build provenance for each release, plus source-level records tied to that release under the Source track | A documented practice inventory covering the Prepare, Protect, Produce and Respond groups, with evidence per practice |
| Policy artifacts | Build platform and source control settings described in the claim, usually held as supporting documentation | Policies such as the vulnerability disclosure and remediation policy named in RV.1.3, with an example program and product security incident response team |
| Third-party components | Provenance covers how the artifact was built, not whether each dependency meets your requirements | Evidence under PW.4.4 that acquired and open-source components meet requirements, such as automatic known-vulnerability detection in the toolchain |
| Scorecard reports | Scorecard results from OpenSSF are a useful companion for repository checks such as Branch-Protection and Pinned-Dependencies, scored 0 to 10 | Scorecard results can support evidence for protecting and producing software, but they do not replace per-practice evidence |
| Who owns the artifact | The team that runs the build pipeline and release process, with the platform owner for signing and provenance generation | The product or engineering organization, with security and legal owning policies and the response team owning disclosure records |
| Regeneration cadence | Generated for every release, so it must run inside the build pipeline; confirm your build tooling supports it for each artifact type | Refreshed on a recurring basis as practices change; confirm the review cycle your own policy sets with your assessor |
| What a buyer can request | Provenance and source records for a named release, to confirm the build came from the stated source | The practice inventory and evidence set for the product line, to confirm the practices are in place across the program |
| Common gap | Teams sign a release but cannot show the source revision or build settings behind it | Teams write policies but cannot show dated evidence that the practices ran for each release |
What drives cost and effort for SLSA and SSDF work
Effort for SLSA and SSDF work comes from a small set of recurring decisions about pipelines, evidence and third-party components. The cards below separate one-time setup from ongoing work and show what to ask for in a written quote before any scope is agreed.
Build pipeline changes
Pipeline changes are usually the largest one-time item. Moving a build to a hosted, isolated and signed process is work on your CI system, not on the product, and it is paid for in engineering time for your team or the implementation partner. Ask the quote to list each build system in scope, which SLSA Build track level is targeted, and whether the work includes hardening runners and signing keys.
Evidence collection and provenance
SLSA asks for provenance that identifies how an artifact was built, and SSDF asks you to show that practices were followed. Collecting, storing and linking that evidence is recurring work for every release, not a single deliverable. Ask who owns the evidence store, how long records are kept, and whether provenance is generated automatically or assembled by hand.
Policy and practice documentation
Writing the policies that SSDF practice groups expect, such as vulnerability disclosure and remediation under RV.1.3, is a one-time drafting effort followed by periodic review. Legal, product and security staff all touch these documents. Ask the quote to separate drafting from review and to name who approves each policy.
Scorecard remediation
OpenSSF Scorecard checks such as Branch-Protection, Dangerous-Workflow, Pinned-Dependencies and Token-Permissions produce findings that someone must fix in each repository. The first pass is one-time cleanup; new repositories and workflow changes keep generating findings. Ask how many repositories are in scope and who triages and closes each check.
Third-party component verification
PW.4.4 asks you to verify acquired and open-source components throughout their life cycle, which means continuous checks on dependencies, not a one-off review. Effort rises with the count of third-party components and the number of repositories that pull them. Ask the quote how dependency monitoring is run and who responds when a component is flagged.
Recurring re-attestation and review
Annual review of policies, pipeline configuration and provenance coverage recurs for as long as you claim conformance. This is where many programs underestimate effort, because each new build system or product line restarts part of the work. Ask the quote for the recurring items, the review cadence and what triggers a re-review outside the schedule.
Why supply chain failures appear in the OWASP Top 10 2025
Software Supply Chain Failures is A03 in the OWASP Top 10 2025, the current edition of the OWASP Top 10. For buyers reviewing application risk, the placement signals that compromised build pipelines, tampered dependencies and weak control over third-party components are now part of the mainstream risk conversation for web applications, not only a concern for software vendors. It should prompt a question in your risk register: which applications depend on components and build systems that you cannot currently trace from source to deployed artifact?
The category sits naturally alongside the two frameworks compared on this page. SLSA's Build track levels describe how strongly a build process can show that an artifact was produced as claimed and can be traced to its source, and the Source track addresses source code management. NIST SSDF task PW.4.4 asks you to verify that acquired commercial, open-source and third-party components meet your requirements throughout their life cycles. Neither framework prevents a supply chain failure by itself. A higher SLSA level narrows what an attacker can tamper with in one stage of the pipeline, and SSDF practices describe the organizational work around it. Confirm with each vendor which controls they actually operate before you cite either framework as coverage for this category.
The OWASP Top 10 is an awareness list. It tells you where to look, but it does not define a test or produce evidence that a control works. If a statement of work or procurement document asks a supplier to show they are protected against this category, ask for specific artifacts: the build provenance they generate, the branch and workflow protections on their repositories, how dependencies are pinned and reviewed, and the evidence behind any OpenSSF Scorecard results they cite. Pair that with a verification standard such as OWASP ASVS for the application itself, so the Top 10 entry is backed by testable requirements.
Questions buyers ask before choosing SLSA or NIST SSDF
How much does a SLSA or SSDF mapping cost?
Cost follows the written scope, and the main drivers are the number of repositories, build pipelines and release channels that need evidence. Language and package ecosystem count matters too, as does how mature the current CI configuration already is. DeployOpen does not publish a price list. A quote follows from the written scope, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Mapping and pipeline hardening are usually one-time costs, while evidence collection, upgrades and monitoring recur with each release cycle. Ask the quote to show these lines separately, and ask whether ongoing support is offered as a retainer.
How long until we have first evidence for SLSA or SSDF?
Time to first evidence depends mostly on how much of the pipeline is already automated and documented. A team with defined build definitions, protected branches and recorded provenance has less to set up than a team that builds releases by hand. SLSA v1.2 Build track levels run from L0 to L3, so the target level shapes the work, and a common first step is a documented baseline for one pipeline before extending to others. Ask for milestones in writing as part of the statement of work. Also confirm with your buyer which artifacts they will accept first, since that often decides what gets produced early.
What does a SLSA or SSDF mapping need from our engineers?
Expect time from build, release and security engineers. Build engineers own pipeline definitions and signing steps, and security engineers review the evidence and policies. Release managers or product owners decide which releases fall in scope. SSDF task PW.4.4 asks you to verify that acquired commercial, open-source and other third-party components meet your requirements throughout their life cycles, for example by building automatic detection of known vulnerabilities into the toolchain. That check needs a named owner for dependency intake. Ask the engagement plan to name one owner per practice group before work begins.
Can one person in our organization map SLSA to SSDF alone?
One experienced person can draft a crosswalk for a small product, but the evidence rarely comes from one role. SP 800-218 v1.1 groups practices into Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities, and each group draws on different people. Preparation tasks often involve policy, training and governance owners, while the build and vulnerability response tasks sit with engineering. For a larger organization, ask for a responsibility matrix for each practice and confirm who signs off each claim before anyone reports compliance against the framework.
Does meeting SLSA requirements satisfy an SSDF request?
No, not on its own. SLSA focuses on build and source integrity, including whether software can be traced to its source and has not been tampered with, while SSDF covers the whole development life cycle. A SLSA level can support several Protect the Software and Produce Well-Secured Software tasks, but it does not answer preparation or response tasks such as RV.1.3, which calls for a policy on vulnerability disclosure and remediation. Ask the buyer which SSDF version they reference, since NIST SP 800-218 v1.1 from February 2022 is the one discussed here, and whether they want a self-attestation in their own template.
Are SLSA and NIST SSDF certifications we can show customers?
Neither is a certification. NIST publishes SSDF as a framework, and SLSA is a specification, and neither issues a certificate or attestation report for your organization. Evidence you produce against them is your claim, supported by records that your own assessors, customers or regulators can review. DeployOpen plans and prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors and certification bodies do that work. Ask the buyer what form of proof they accept before you build it, so the evidence matches the request.
Which requirements should we confirm with a buyer first?
Start by confirming which framework and version they name, which SLSA level they expect, and which artifacts count as proof. Next, confirm the in-scope products and release channels, and whether the open-source dependencies you consume are in scope or only the components you publish. If the buyer ties the request to the EU Cyber Resilience Act, confirm with the regulator or legal counsel which obligations apply, because this page does not set them out. OpenSSF Scorecard runs automated checks such as Branch-Protection and Pinned-Dependencies, scoring each from 0 to 10, and can give a quick view of repository hygiene. Also agree on evidence retention, the reviewer and who pays for any external review.
How DeployOpen scopes, delivers and supports supply chain assurance work
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so supply chain controls are set up where your builds actually run. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we scope
- The written scope names which build systems, repositories and release pipelines are in scope for SLSA or SSDF work.
- Scope records which SLSA Build or Source track levels are targeted, and which SSDF practices your evidence must cover.
- Scope lists the buyer requirements that apply, such as federal procurement, open-source consumer expectations or EU CRA obligations.
How we build
- We review build provenance, signing and source management against the SLSA levels named in the agreed scope.
- We map existing pipeline controls to SSDF practice groups, including dependency verification under PW.4.4.
- We configure automated checks, such as OpenSSF Scorecard, where the scope calls for them, and document any gaps found.
How we hand over
- Deliverables include a mapping document tying each SSDF task and SLSA requirement to the evidence your team holds.
- Handover covers runbooks for the pipeline controls, with the configuration files and records your team needs to maintain them.
- We agree in writing which evidence your auditors or customers will receive, and which items remain your responsibility.
How we support
- Ongoing support, upgrades and continuous testing of pipeline controls are available as a retainer after handover.
- Retainers can cover re-mapping evidence when SLSA or SSDF versions change, so the mapping stays current.
- Confirm with us during scoping how support, upgrades and evidence refresh will be priced and scheduled for your environment.
