Quick-reference card
| Field | Detail |
|---|---|
| Control ID | SR-04 |
| Control Name | Provenance |
| Framework | NIST SP 800-53, Revision 5 |
| Control Family | Supply Chain Risk Management |
| Baselines | — |
| Relevance | Organization (Third Party) |
| Risk Severity | High |
What this control requires
SR-04 requires organizations to document, monitor, and maintain the origin and integrity of every system, component, and data asset they acquire. That means tracking who built it, who owned it, where it traveled, and what changed along the way. Without this chain of custody, you can’t verify that the software or hardware running in your environment is the same artifact the vendor originally shipped.
In practice, provenance tracking covers the full lifecycle of a system component. You need procedures that assign responsibility for creating and maintaining provenance records, transfer those records when ownership changes between organizations, and detect unauthorized modifications to the records themselves. The goal is non-repudiation. If someone tampers with a component or its documentation, your provenance baseline should make that tampering visible.
This requirement also extends to contracts and procurement agreements. Provenance considerations don’t end once a component enters your environment. They should be woven into your system development life cycle and supply chain agreements so that every handoff between parties maintains an unbroken record of origin and change.
Why it matters
Most organizations treat vendor trust as binary. Once a supplier passes an initial security assessment, every future update from that vendor inherits the same level of trust. SR-04 exists because that assumption has proven catastrophic.
The core risk is substitution and tampering. An attacker who compromises a vendor’s build pipeline can inject malicious code into a legitimate product, and every downstream customer will install it without question. Provenance tracking is the mechanism that converts implicit trust into verified trust, giving you a way to confirm that what you received matches what the vendor intended to ship.
SolarWinds Orion supply chain compromise
Beginning no later than October 2019, attackers attributed to Russia’s Foreign Intelligence Service (SVR / APT29 / Cozy Bear) compromised SolarWinds’ software build environment and injected a backdoor into legitimate update packages for SolarWinds’ Orion IT monitoring platform. FireEye named the backdoor SUNBURST after discovering it during their own breach investigation. Orion is used by approximately 33,000 organizations, including major US federal agencies and Fortune 500 companies. When customers downloaded what appeared to be a routine software update (versions 2019.4 through 2020.2.1), they installed SUNBURST along with it.
Approximately 18,000 organizations downloaded the malicious build. The attackers then selectively activated the backdoor against roughly 100 high-value targets, including the US Treasury, Commerce Department, DHS, parts of the Pentagon, and FireEye itself. The breach ran approximately 14 months before discovery in December 2020, when FireEye noticed an attacker registering a new device for their multi-factor authentication (MFA). CISA issued Emergency Directive 21-01 ordering federal agencies to disconnect affected Orion products.
The SolarWinds attack illustrates exactly the failure SR-04 is designed to prevent. Customers had no mechanism to verify that the signed update package they received hadn’t been tampered with during the build process. The attack weaponized the implicit trust organizations extend to software updates from vendors they’ve already assessed and approved. SR-04 places that trust relationship on a verified footing by requiring documented provenance baselines and integrity checks.
What attackers exploit
- Build pipeline compromise. Attackers infiltrate a vendor’s development or build environment and inject malicious code before the product is signed and distributed, as demonstrated in the SolarWinds campaign.
- Counterfeit or tampered hardware. Components sourced through unauthorized resellers or gray-market channels may contain backdoors or inferior parts that lack verifiable provenance documentation.
- Forged or missing transfer records. When ownership of a component changes hands without proper documentation, attackers can introduce modified versions at handoff points without detection.
- Weak integrity verification. Organizations that accept vendor-signed packages without independent hash verification or provenance baseline comparison leave themselves exposed to supply chain substitution attacks.
How to implement
Verifying provenance for vendor-supplied components is one of the harder supply chain risk management challenges because you’re relying on evidence produced outside your own environment. Self-attestation alone isn’t sufficient. You need a verification approach that combines questionnaire responses with independent checks and contractual requirements.
Questionnaire and assessment questions
Start by asking vendors to describe their provenance tracking practices. Effective questionnaire items include the following.
- How does your organization document the origin and chain of custody for software components used in your products?
- What integrity verification methods (cryptographic signing, hash validation, reproducible builds) do you apply to build artifacts before release?
- Do you maintain a software bill of materials (SBOM) for each product version, and can you provide one on request?
- How do you detect and respond to unauthorized modifications to your build pipeline or distribution channels?
- What procedures govern the transfer of provenance records when third-party components or subcontractors are involved?
Evidence to request
Beyond questionnaire responses, request concrete artifacts that demonstrate provenance tracking in practice. These include software bills of materials for the specific products you use, build pipeline security documentation describing access controls and integrity checks, code signing certificates and the verification procedures tied to them, and change logs that document every modification to components from development through delivery.
Red flags to watch for
Certain responses should raise concerns during vendor assessments. Watch for vendors who can’t produce an SBOM or don’t know what one is. Be cautious when a vendor relies entirely on manual processes for build integrity without automated verification. Gaps in chain-of-custody documentation, especially when subcontractors are involved, signal weak provenance controls. Vendors who resist providing signed artifacts or reproducible build evidence may lack the infrastructure to support provenance verification.
Verification beyond self-attestation
Supplement vendor responses by validating cryptographic signatures on delivered packages against the vendor’s published signing keys. Compare file hashes to those published in the vendor’s release notes or security advisories. Where possible, review the vendor’s third-party audit reports (SOC 2 Type II or ISO 27001 certificates) for evidence that build and release processes are covered. The UpGuard Vendor Risk platform can help you continuously monitor vendor security posture and track whether vendors maintain the controls they’ve attested to.
Evidence examples
| Evidence Type | Example Artifact |
|---|---|
| Supply chain risk management policy and procedures | Policy defining provenance responsibilities, including who creates, maintains, and monitors provenance records for acquired systems and components |
| System and component inventory with provenance data | Documentation of critical systems and components showing origin, development history, ownership chain, and location for each item |
| Ownership and custody chain records | Logs showing the chronological history of ownership, custody, location changes, and modifications to critical system components |
| Inter-organizational transfer agreements | Contracts and agreements specifying provenance documentation requirements, transfer procedures, and integrity verification obligations for vendors and partners |
| Integrity verification records | Cryptographic hash logs, code signing certificates, and SBOM documents used to validate that components match their documented provenance baselines |
| System architecture and development lifecycle documentation | Architecture diagrams and development lifecycle procedures showing where provenance checks are incorporated into acquisition and deployment workflows |
Cross-framework mapping
| Framework | Control(s) | Coverage |
|---|---|---|
| ISO 27001:2022 | 5.21 Managing information security in the ICT supply chain | Partial |
| ISO 27001:2022 | 8.30 Outsourced development | Partial |
Related controls
- CM-08 — System Component Inventory: provides the baseline inventory that provenance records are maintained against, ensuring every component has a documented origin.
- MA-02 — Controlled Maintenance: governs maintenance activities that can alter system components, requiring provenance updates when modifications occur.
- MA-06 — Timely Maintenance: ensures maintenance actions happen within defined windows, reducing the risk of undocumented changes that break the provenance chain.
- RA-09 — Criticality Analysis: identifies which systems and components are most critical, helping prioritize where provenance tracking resources should be focused.
- SA-03 — System Development Life Cycle: defines the lifecycle phases where provenance documentation should be created and maintained, from acquisition through disposal.
- SA-08 — Security and Privacy Engineering Principles: establishes the engineering standards that support provenance integrity, including secure design and supply chain transparency.
- SI-04 — System Monitoring: detects unauthorized changes to systems and components that would indicate a provenance violation or tampering event.
Frequently asked questions
What is NIST SP 800-53 SR-04?
SR-04 is the NIST SP 800-53 control that requires organizations to document, monitor, and maintain valid provenance for systems, system components, and associated data. Provenance in this context means the chronological record of origin, development, ownership, custody, location, and changes to a component throughout its existence. The control ensures organizations can verify that what they’re running matches what was originally produced and delivered, preventing undetected tampering or substitution in the supply chain.
What happens if SR-04 is not implemented?
Without SR-04 controls in place, organizations lose the ability to verify the integrity and origin of the systems and components they depend on. Attackers can exploit this gap by injecting malicious code during the build or distribution process, as demonstrated in the SolarWinds Orion compromise where approximately 18,000 organizations installed a tampered update. The absence of provenance baselines means tampered components can operate undetected for months or years. Regulatory assessors will also flag missing provenance documentation as a significant finding during audits.
How do you audit SR-04?
Auditing SR-04 starts with verifying that the organization maintains documented provenance baselines for its critical systems, components, and associated data. Assessors examine whether ownership and custody chain records exist and whether integrity verification mechanisms (such as cryptographic hash validation and code signing) are in place and actively used. The audit also evaluates procedures for monitoring provenance records for unauthorized changes and for transferring provenance documentation between organizations during component handoffs. Evidence typically includes supply chain risk management policies, inter-organizational agreements, SBOMs, and system architecture documentation that shows where provenance checks occur in the development and acquisition lifecycle.
What is the difference between provenance and pedigree in NIST 800-53?
Provenance tracks the chronological history of a component, covering its origin, ownership chain, location changes, and any modifications made over time. Pedigree, by contrast, focuses on the quality and integrity of the processes used to develop, manufacture, or handle that component. You can think of provenance as “where this component has been” and pedigree as “how well it was made and handled at each step.” Both concepts support supply chain risk management, but provenance (SR-04) emphasizes verifiable custody records while pedigree addresses process assurance and quality controls.