We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALNIST SP 800-161 Rev. 1

NIST SP 800-161 Rev. 1 Provenance and SBOM Supplier Controls

Specify and verify origin, build, dependency, custody, authenticity, and change evidence for critical software and components.

Provenance records origin and change history; an SBOM inventories software components. Both are risk inputs, not security verdicts, and should be selected, verified, and acted on for the exact item or release.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
2

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

SP 800-161 says provenance should be documented for systems, system components, and associated data throughout the system development life cycle. It says enterprises should consider SBOMs for applicable software classes. Provenance records origin and change history; an identifies software components and dependencies. Neither one establishes that a delivered item is authentic, untampered, vulnerability-free, or acceptable for a particular use.

Section 1

Decide what provenance evidence must support

Decide which critical software, hardware, firmware, services, and data need traceable origin and change evidence; which evidence the supplier must provide; how the enterprise will bind it to the item or release; and which verification checks occur before acceptance and after change.

For an , specify the covered product and release, required format and fields, generation point, delivery and correction process, integrity protection, update triggers, and permitted handling. SP 800-161 discusses purchased, open source, and in-house software as applicable classes; the governing federal direction, contract, customer requirement, or internal policy must determine which software actually requires delivery and in what format. For broader provenance, decide which origin, ownership, development, build, distribution, custody, maintenance, and change records matter for the risk decision. The needed evidence varies for software, firmware, hardware, data, and services.

  • Bind every or provenance record to an exact item, version, build, release, or delivery; a supplier-level document is not enough when the decision concerns a specific artifact.
  • Name who can validate the record, ingest its data, investigate gaps, and approve acceptance or remediation.
  • Treat the publication's guidance as risk-based NIST guidance. It creates no universal supplier deadline or update interval. A contract, policy, or other governing instrument must establish any mandatory format, delivery time, minimum content, correction period, and refresh cadence for the specific relationship.
Sources for this answer
NIST SP 800-161 Rev. 1 Update 1 C-SCRM
Appendix A, control SR-4, addresses provenance throughout the SDLC, applicable SBOM production, digital signing, and the need to keep vulnerability management and supplier assessment operating alongside SBOM use.
NIST Secure Software Development Framework
Official NIST resource for secure software-development practices that complement the broader acquisition and supply-chain risk guidance in SP 800-161.
Recommended next step

Tie provenance evidence to each item or release

Define the covered item, required evidence, verification owner, analysis process, acceptance decision, and refresh trigger.

Assessment workflow
Open Assessment Autopilot

Track SBOM and provenance requests, release binding, verification, findings, and remediation.

Explore next step
Talk to Sorena
Review the evidence model

Check item identity, required content, integrity, analysis capability, and refresh gaps.

Explore next step
Section 2

Scope the requirement to the decision

Start with the decision the evidence must support: supplier selection, product acceptance, release approval, vulnerability response, incident investigation, counterfeit detection, maintenance, or disposal. Then identify the item and life-cycle stage. A requirement written only for 'the product' is ambiguous when the supplier ships several editions, builds, platforms, or deployment models.

Separate the supplier's claim from the acquirer's verification. Receipt proves only that a file arrived. Verification should establish the claimed producer or source, the covered item, integrity, required content, and whether unresolved gaps change the acceptance or risk decision. If the evidence cannot be verified, record the uncertainty and choose remediation, a compensating check, authorized acceptance, an alternate source, or rejection.

  • Software: identify the product, version, build or release, platform, dependency scope, and whether the describes source, build, or delivered binary content.
  • Hardware and firmware: identify the model, revision, firmware, manufacturer, authorized source, custody or distribution path, and relevant replacement parts.
  • Services and data: identify the service version or environment, producer, transformations, upstream dependencies, and material changes that require refreshed evidence.
Sources for this answer
NIST SP 800-161 Rev. 1 Update 1 C-SCRM
Appendix A, SR-4, applies provenance to systems, components, and associated data across the SDLC. Related acquisition and authenticity controls support risk-based scoping and verification.
Section 3

Owner and evidence checklist for software provenance and SBOM supplier requirements

Evidence should bind the supplier's claim to the exact component or software release accepted. Security and engineering owners need a way to verify signatures, hashes, build or source attestations, dependency identities, authorized distribution, authenticity checks, and material changes.

Define who can ingest and analyze and provenance data and who acts on findings. Collecting a file without validating its format, completeness, release match, or vulnerability and policy implications does not improve the risk decision.

  • Item or release identifier, supplier and producer, origin, authorized distribution path, version, build, custody, and change history as applicable.
  • format and required fields, dependency identifiers, generation method and time, signature or other integrity evidence, delivery channel, and release-binding check.
  • Authenticity, integrity, tamper, source-composition, binary-composition, vulnerability, and acceptance-test results proportionate to criticality.
  • Exceptions, unknown dependencies, provenance gaps, compensating checks, risk decision, owner, remediation, and reassessment trigger.
Sources for this answer
NIST SP 800-161 Rev. 1 Update 1 C-SCRM
Appendix A, SR-4, calls for documented provenance and digitally signed SBOMs, and warns that organizations need the capability to ingest, analyze, and act on SBOM data.
Section 4

Common provenance and SBOM mistakes

An is an inventory input, not a security verdict. It may be incomplete, stale, unbound to the deployed release, or unable to show whether a listed vulnerability is exploitable or mitigated in context. NIST warns organizations not to deprioritize existing C-SCRM capabilities because an SBOM is available.

Provenance evidence also needs protection: verify signatures or trusted channels, preserve integrity and access controls, and avoid exposing sensitive supply-chain details beyond the people and systems that need them.

  • Do not accept an for one edition, build, platform, or supplier as evidence for a different deployed release.
  • Do not require data the enterprise lacks the tooling, authority, or process to validate and act on; define the operational use before collection.
  • Do not treat provenance as software-only: hardware, firmware, data, maintenance, distribution, and replacement components can also require traceability.
Sources for this answer
NIST SP 800-161 Rev. 1 Update 1 C-SCRM
Appendix A, SR-4, states that SBOM transparency complements rather than substitutes for existing C-SCRM capabilities and may not improve posture when the organization cannot analyze and act on the data.
Section 5

Practical workflow for software provenance and SBOM supplier requirements

Put provenance and requirements into acquisition and release gates, scale them by criticality, and connect them to vulnerability, integrity, supplier-risk, incident, and change-management processes.

The output should show what was received, how it was verified, which exact item or release it covers, what findings it produced, and what decision or action followed.

  • 1 | Scope | Identify critical software, hardware, firmware, services, and data and the decision provenance must support.
  • 2 | Specify | Put item identity, format, minimum content, signing, delivery, update, correction, retention, and flow-down expectations into the agreement.
  • 3 | Verify | Bind evidence to the delivered item or release and validate the claimed source, integrity, required content, and currency for the decision.
  • 4 | Analyze and act | Feed dependencies and provenance findings into vulnerability, integrity, supplier-risk, acceptance, and incident decisions.
  • 5 | Refresh | Require updated evidence and reassessment after releases, component or build changes, supplier or ownership changes, new vulnerabilities, incidents, provenance failures, or a change to the governing requirement.
Sources for this answer
NIST SP 800-161 Rev. 1 Update 1 C-SCRM
Appendix A connects provenance, acquisition, authenticity, integrity, supplier assessment, and monitoring controls; SR-4 supplies the SBOM-specific cautions used in this workflow.
Primary sources

References and citations

NIST Secure Software Development Framework
csrc.nist.gov
Referenced sections
  • Official NIST resource for secure software-development practices that complement the broader acquisition and supply-chain risk guidance in SP 800-161.
NIST SP 800-161 Rev. 1 Update 1 C-SCRM
doi.org
Referenced sections
  • Appendix A connects provenance, acquisition, authenticity, integrity, supplier assessment, and monitoring controls; SR-4 supplies the SBOM-specific cautions used in this workflow.
Related guides

Explore more topics

How should teams handle counterfeits under NIST SP 800-161 Rev. 1 supply-chain risk management?
Prioritize critical items, use traceable sources, verify authenticity and tamper protection, quarantine suspected counterfeits, and reassess affected risk.
How should teams handle critical suppliers under NIST SP 800-161 Rev. 1 supply-chain risk management?
Identify critical suppliers through mission dependency, component importance, access, concentration, substitutability, and potential impact, not spend alone.
How should teams handle monitoring under NIST SP 800-161 Rev. 1 supply-chain risk management?
Run risk-based supplier monitoring with scheduled revalidation, event triggers, operating signals, escalation thresholds, corrective action, and evidence.
How should teams handle provenance under NIST SP 800-161 Rev. 1 supply-chain risk management?
Collect and verify traceable origin, build, dependency, custody, authenticity, and change evidence for critical systems, components, software, and data.
How should teams handle supplier incidents under NIST SP 800-161 Rev. 1 supply-chain risk management?
Coordinate supplier incidents through joint triage, evidence preservation, containment, recovery, contract communication, corrective action, and reassessment.
How should teams handle supply chain risk response under NIST SP 800-161 Rev. 1 supply-chain risk management?
Choose and document whether to accept, avoid, mitigate, share, or transfer supply-chain risk, with authority, actions, residual risk, and review triggers.
How should teams handle tiering under NIST SP 800-161 Rev. 1 supply-chain risk management?
Build supplier risk categories that drive assurance treatment while keeping them distinct from SP 800-161 risk-management levels and CSF Tiers.
NIST SP 800-161 Rev. 1 C-SCRM Governance Checklist
A NIST SP 800-161 Rev. 1 checklist for assigning C-SCRM decisions across enterprise, mission/business-process, and operational levels.
NIST SP 800-161 Rev. 1 C-SCRM Governance Guide
Design NIST SP 800-161 Rev. 1 C-SCRM governance across the enterprise, mission/business-process, and operational levels with accountable roles and feedback loops.
NIST SP 800-161 Rev. 1 Contract and Monitoring Controls
Translate C-SCRM risk decisions into supplier clauses, subcontractor flow-down, evidence delivery, revalidation, monitoring, incident, continuity, and exit terms.
NIST SP 800-161 Rev. 1 Criticality Analysis Guide
Identify mission-critical functions, systems, components, products, services, suppliers, and single-source dependencies so C-SCRM effort follows potential impact.
NIST SP 800-161 Rev. 1 FAQ: practical implementation questions
NIST SP 800-161 Rev. 1 answers with cited implementation steps, decision criteria, and evidence guidance.
NIST SP 800-161 Rev. 1 implementation playbook
Build a tailored C-SCRM program with strategy, policy, plans, assessments, acquisition controls, monitoring, and evidence across NIST's three risk-management levels.
NIST SP 800-161 Rev. 1 supplier assessment evidence: risk-based records and evaluation criteria
Choose and validate supplier evidence based on criticality, risk, contract requirements, source reliability, freshness, and proof of operating effectiveness.
NIST SP 800-161 Rev. 1 Supplier Risk Tiering
Group suppliers by mission dependency and cyber risk, then tie each category to proportionate due diligence, evidence, contracts, monitoring, and response.
NIST SP 800-161 Rev. 1 vs DORA ICT third-party risk: practical side-by-side comparison
Compare NIST SP 800-161 Rev. 1 and DORA ICT third-party risk with side-by-side scope, owner, trigger, evidence, cadence, assurance, and decision-rule rows.
NIST SP 800-161 Rev. 1 vs ISO/IEC 27036 supplier relationships: practical side-by-side comparison
Compare NIST SP 800-161 Rev. 1 and ISO/IEC 27036 supplier relationships with side-by-side scope, owner, trigger, evidence, cadence, assurance, and decision-rule rows.
NIST SP 800-161 Rev. 1: workflow for collecting and validating C-SCRM supplier evidence
A risk-based NIST SP 800-161 supplier evidence workflow from relationship scope and criticality through request, validation, decision, remediation, and monitoring.
Which contract controls should teams define under NIST SP 800-161 Rev. 1?
Translate supplier risk into measurable security, flow-down, evidence, monitoring, incident, continuity, remediation, and exit clauses under SP 800-161.