What SR-4 provenance asks for and why teams struggle with it
When an assessor or a contract names SR-4 Provenance, the first thing to confirm is why it is in scope. SR-4 is a base control in the Supply Chain Risk Management family of NIST SP 800-53 Rev. 5, and it is not assigned to any SP 800-53B low, moderate, high or privacy baseline. It therefore applies only because the organization selected it through tailoring or an overlay, or because a customer or regulator required it. Find the decision record, the requirement that triggered it and the systems it covers before planning any work, because that scope determines everything else.
In plain terms, the control asks the organization to document, monitor and maintain valid provenance for defined systems, components and associated data. Provenance means a verifiable record of where something came from and who has held it since: a hardware appliance from its manufacturer through shipping and receiving, a software package from its source repository through build and deployment, or a dataset from its originating system through every transfer. The supply chain risk it addresses is that a component whose origin cannot be shown is hard to trust, hard to recall and hard to investigate after an incident. The control is assurance-related and is implemented by the organization itself, not by a supplier or a tool.
Teams struggle because provenance evidence is scattered. Purchase orders and vendor contracts sit with procurement, build records and signed artifacts sit with engineering, and asset assignments and receiving logs sit with operations, often in separate systems with different identifiers. Release 5.2.0 gives SR-4 one organization-defined parameter, which the organization must fill in to name the systems, components and data in scope, and four control enhancements. Confirm which enhancements your selection includes, then assign an owner for each source of record so the assessor's examine objects, such as critical system documentation, contracts and architecture, can be traced to a single answer.
When SR-4 provenance applies and which scoping choices change the work
SR-4 is not in any SP 800-53B baseline, so its effort depends on whether an organization selected it by tailoring or overlay and how it defined what provenance covers. The cards below cover the decisions that set the workload and the related controls where the same provenance records are reused.
Defining the parameter scope
SR-4 has one organization-defined parameter, which sets the systems, components and associated data whose provenance must be documented, monitored and maintained. A narrow definition limits the records to a few critical systems, while a broad one reaches every hardware, software and data element in the boundary. Write the parameter down with named asset classes so an assessor can trace each one to its records.
Tailoring versus overlay selection
Because SP 800-53B assigns SR-4 to no baseline, the control appears only where the organization selected it through tailoring or an overlay. Record the selection rationale in the system security plan, since an assessor will ask why a system carries SR-4 when its baseline omits it. Changes to that selection later will change the evidence the team must keep.
Third parties that supply components and data
Each supplier of hardware, software, firmware or data extends the provenance chain that the organization must document. Identify which suppliers deliver components inside the scoped boundary, and confirm what origin and custody details their contracts or delivery records already provide. Gaps found at this stage usually lead to supplier questionnaires or contract changes, so the list should be settled early.
FedRAMP Rev5 baseline exclusion
FedRAMP's Rev5 baselines do not require SR-4 at Class B, C or D. A cloud service pursuing one of those classes therefore should not assume SR-4 is mandatory, but contractual or agency requirements may still ask for it. Confirm the applicable FedRAMP class and any agency-specific terms before scoping the work.
Related controls that reuse provenance records
Provenance records also support CM-8, MA-2, MA-6, RA-9, SA-3, SA-8 and SI-4. Inventory (CM-8), maintenance (MA-2, MA-6), risk assessment (RA-9), acquisition (SA-3), engineering principles (SA-8) and monitoring (SI-4) can each draw on the same origin and custody data. Map these controls to one shared record set so the team does not build duplicate evidence for each.
What the SR-4 enhancements add beyond the base control
The SR-4 enhancements move provenance from a record of where a component came from to evidence that a reviewer can check. The base control asks for valid provenance to be documented, monitored and maintained. The enhancements add three themes in their intent: knowing the identity of each component and the supplier behind it, following that component through its life cycle, and validating that it is genuine and unaltered. For a system owner, the practical question is which components and data fall inside the defined scope, because an enhancement is only as useful as the inventory it applies to. Start with the component inventory and the supplier records that already exist, then decide which items must carry full identity and tracking.
Tracking and validation are where most organizations find gaps. A tracking record is only useful if it follows a component from receipt through installation, update and retirement, and validation requires a way to confirm that what is installed matches what was delivered. Teams often meet part of this with a software bill of materials, which Dependency-Track can consume and monitor, and with scanners such as Trivy, which can generate an SBOM from a target. Neither tool proves that a component is genuine on its own. Confirm with the vendor and your own environment which signatures, hashes or build attestations are available for each component class before you claim validation.
None of the four enhancements is assigned to an SP 800-53B baseline in Release 5.2.0, so an organization must select them through tailoring and justify that choice. Record which enhancements you adopted, which you declined, the components they cover and the reason for each decision in the tailoring rationale. A reasonable record might show a narrow scope for critical systems and a stated plan for the rest. Your assessor will test the decision as much as the implementation, so confirm the exact wording of each enhancement in the OSCAL catalog before drafting the rationale.
How an assessor tests SR-4 provenance
This table compares the three SP 800-53A determination statements for SR-4 against the examine, interview and test methods, the assessment objects named in the procedures, the evidence an assessor will ask for, and findings that commonly delay an assessment. Read each row as one step in the assessor's work, and check the evidence column against what your own environment can actually produce.
| Determination statement | Methods and assessment objects | Evidence requested | Common findings |
|---|---|---|---|
| Provenance of defined systems, components and associated data is documented | Examine: documentation of critical systems, critical system components and associated data. Interview: system owners and procurement staff on how origin records are created. | Provenance records for each defined system and component, with the origin, supplier and date of receipt, and the data sets in scope. | Provenance records exist for hardware but not for software, firmware or open-source dependencies. |
| Provenance is monitored over the life of the component | Examine: documentation of critical system components. Test: sample inventory entries and confirm that changes such as updates, replacements or relocations are reflected in provenance records. | Inventory exports with change history, dated updates to provenance records, and records of component replacement or movement. | Inventory is accurate at purchase but not updated after patches, rebuilds or replacement of components. |
| Provenance is maintained and supported by supplier obligations | Examine: contracts and system architecture. Interview: procurement and legal staff on whether suppliers must provide origin data. | Contract clauses requiring supplier origin data, architecture diagrams showing where provenance is recorded, and supplier responses to provenance requests. | Contracts do not require suppliers to provide origin data, so records depend on goodwill or manual follow-up. |
How to implement SR-4 provenance in six steps
This sequence turns SR-4 from a selected control into a working record of where each system, component and dataset came from, who held it, and whether those records still hold up. Each step closes with an artifact an assessor can examine.
Confirm the selection and set the parameter value
Start by confirming that SR-4 is actually in your control set. SP 800-53B does not assign it to any baseline, so it appears only through tailoring or an overlay, and your system security plan should say why it was selected. Next, the compliance lead and system owner set the organization-defined parameter, which names the systems, components and associated data that provenance must cover. Write down which of the four enhancements you adopt, since each one changes the evidence you must keep. The step is done when the SSP entry and the parameter decision are approved by the authorizing official or equivalent owner, and both are dated and versioned.
Inventory the defined systems and components
Using the parameter value, the platform or security engineering team builds a scoped list of the systems, components and data sets that fall under SR-4. For self-hosted open-source platforms, this covers the application stack, container images, operating system packages, libraries and the data stores that hold regulated information. Tools such as Trivy can enumerate packages and dependencies in a target and produce them as a software bill of materials, which gives you a starting list you can verify by hand. The output is a scoped inventory with one owner per entry, reviewed against the architecture documentation that an assessor will examine.
Record origin and chain of custody at procurement and build
For each item in the inventory, record where it came from and every hand it passed through. At procurement, capture the supplier, the source repository or registry, the version or digest, the license, and the person who approved intake. At build, record the build pipeline, the commit or source reference, and the artifact identifier that the pipeline produced. Store these records somewhere append-only or under change control so they cannot be quietly edited. The step is complete when a sample of components can be traced from deployed artifact back to its source and approval without relying on memory.
Connect provenance records to the asset inventory
Provenance records only help when they can be found from the asset they describe. Link each provenance entry to its asset record in your inventory system, such as GLPI's Assets module, which manages computers, software, network equipment and other hardware entered manually or pushed by the GLPI Agent. For running endpoints, the Wazuh Syscollector module collects installed software, operating system details and other inventory data that can be compared against the recorded origin. Confirm the link works in both directions: from any asset you can reach its provenance record, and from any provenance record you can reach a live asset. The output is a reconciled inventory that an assessor can sample.
Add validation checks at intake and deployment
Provenance is only useful if it is checked. At intake, verify that each component matches the recorded source, version and digest before it enters the environment, and that its license is on your approved list. At deployment, compare what is running against the approved artifact record and flag any drift. Dependency-Track can consume CycloneDX SBOMs and VEX and identify components with known vulnerabilities, outdated or modified components and license risk, which gives you a repeatable check across the inventory. Document each check, the person or pipeline that performs it, and the exception process for components that fail. The step is done when a failed check produces a ticket and a recorded disposition.
Set a review cycle with a named owner
Provenance records go stale as components change, so assign one accountable owner for SR-4 and set a review cycle in the supply chain risk management procedures. The owner checks that the scoped inventory matches reality, samples provenance records against live assets, reviews failed validations and confirms that the parameter value and enhancements are still correct. Record each review with its date, reviewer, findings and any plan of action items. Ask your assessor or internal audit team which evidence they expect to see for a review cycle, because the cycle length is a decision you document rather than a value this control supplies. The output is a signed review log that shows the control operating over time.
Evidence that passes an SR-4 provenance test
SP 800-53A has an assessor examine documentation of critical systems, components and associated data, contracts and system architecture. The artifacts below are the records that answer those examinations, and each one stays useful only if it is refreshed between assessments rather than rebuilt for them.
Provenance register for defined components
A register that records, for each component in the organization-defined scope, where it came from, who supplied it, when it was received and how its origin was verified. This is the core SR-4 record, and an assessor will ask whether it covers every component the organization has defined, not only the convenient ones. Keep it current by adding an entry as part of each change ticket that introduces or replaces a component, and review a sample of entries against the defined cycle to confirm they still match the running estate.
Supplier contract clauses on origin data
Contract language that obligates suppliers to state origin, manufacturer, build location and chain of custody for delivered components and data. Assessors read contracts to confirm the obligation exists before the component arrives, so check that clauses apply to renewals and to subcontractors, not only to the original vendor. Review the clause list when procurement adds a supplier, and record which contracts lack origin terms so the gap can be closed at renewal.
Component inventory exports
Dated exports from the asset inventory that list hardware, software, network equipment and their locations, showing the components the organization actually runs. Provenance records are only meaningful if they can be matched to these exports, so an assessor may pick an inventory item and trace it back to its origin record. Schedule exports on a fixed cadence, keep the prior versions, and reconcile the difference between two exports against approved change tickets.
SBOMs and component lists
Software bills of materials in a standard format that name each software component, its version and its supplier, generated for each build or release. An SBOM shows what a product is made of, and the provenance record shows where each part came from, so the two should reference each other. Confirm that SBOMs are generated from the build pipeline rather than typed by hand, and that stored SBOMs are linked to the deployed version they describe.
Intake validation records
Records made when a component is received, showing who checked its identity, compared its hash or serial number against supplier documentation and approved it for use. These records prove that provenance was validated, not merely asserted, and an assessor will look for rejected items as evidence the check is real. Keep the intake log with the change ticket, and sample received items on the defined cycle to confirm the validation steps were completed.
Architecture documents showing capture points
Diagrams and descriptions that show where provenance data is created, stored and consumed, such as the procurement system, the inventory platform, the build pipeline and the SBOM repository. Assessors use architecture documents to decide whether the capture points cover all the defined components. Update the diagram whenever a tool is added or replaced, and confirm the diagram matches the systems the organization operates today.
What meeting SR-4 provenance costs in money and effort
This table breaks SR-4 provenance costs into components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No price or duration is given because none is supported by researched facts, so use the table to structure quote requests. The main takeaway is that design effort and supplier evidence upkeep usually outweigh license spend.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Tooling and licenses | Software vendors or none for open source | Recurring if commercial | Self-hosted open-source tools such as Dependency-Track, Trivy, GLPI and Wazuh can remove most license spend, but hosting and storage still apply |
| Engineering time to design the provenance record | Internal staff or implementation partner | One-time, with later revisions | Number of defined components, system boundaries and the fields each provenance record must capture |
| Procurement and contract changes | Legal, procurement and suppliers | One-time per contract, then renewals | Number of suppliers, whether standard clauses exist, and how many agreements must add provenance and traceability terms |
| Evidence upkeep | Internal operations or a retained partner | Recurring | Rate of component change, inventory accuracy from discovery tools, and how often records are reconciled with contracts and architecture documents |
| External review or testing | Independent testers or assessors | Recurring, usually per cycle | Scope of testing against provenance claims, depth of validation of origin records, and whether testing is fixed-scope or retained |
| Auditor sampling | Independent auditor | Recurring per assessment cycle | Number of components and suppliers sampled, and whether records are complete, consistent and easy to retrieve on request |
Open-source tools that produce SR-4 provenance evidence
SR-4 asks for documented, monitored and maintained provenance of defined systems, components and data. The tools below record what is in an environment and where it came from, which gives an assessor material to examine. None of them decides origin or authenticity alone, so the organization still defines the provenance process and confirms each tool fits its environment.
OWASP Dependency-Track
Dependency-Track consumes and produces CycloneDX SBOMs and VEX, so it can hold a component record for each application and show which components have known vulnerabilities, are outdated or have been modified. It also tracks license use by component using SPDX license IDs. For SR-4, the useful check is whether every deployed component traces back to an SBOM that the organization has reviewed and retained. Confirm how the SBOMs are produced and signed upstream, since the tool only records what it receives.
Trivy
Trivy identifies the OS packages and software dependencies in a target and can output them as a software bill of materials. It can also scan existing SBOMs, which helps when components arrive from suppliers. Teams use the output as a point-in-time record of what a container image or host contains. Validate that scan results match the build pipeline's own records, because a scan reports what is present, not who created it or whether it is authentic.
GLPI assets
The GLPI Assets module manages computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records can be entered manually or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10. For SR-4, asset records tie hardware and software to owners, locations and lifecycle status, which supports the chain of custody for defined systems. Confirm that the records are reconciled with procurement and receiving, since inventory alone does not prove the item came from an approved source.
Wazuh system inventory
The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint. It stores this in the Wazuh indexer for inventory views and reports. For SR-4, this shows what is actually running on each endpoint over time, which can reveal software that is not in the approved record. Check whether collection covers every in-scope system type and how changes are retained for the assessor.
Who owns SR-4 provenance: your team, a partner and the auditor
Your team owns SR-4. The control asks you to document, monitor and maintain valid provenance for the systems, components and associated data you define, so the defined scope, the provenance policy and the supplier obligations are decisions only your organization can make. An implementation partner can draft material, but the accountable owner must approve it and be able to explain it under questioning.
- Scope definition: Decide which systems, components and data sets are in scope for provenance records, and record the reason for each inclusion or exclusion.
- Provenance policy and procedures: Set who records origin and custody, how changes of custody are logged, and how exceptions are approved.
- Supplier obligations: Write into contracts what suppliers must disclose about origin, build location and custody, and confirm that procurement enforces them.
- Sign-off: Approve the scope, the records and the evidence before an assessment, and keep the approval as a dated record.
- Operation: Staff the recurring work of reviewing provenance records when components change.
Before engaging anyone, confirm with your assessor or authorizing official whether SR-4 is selected in your baseline or tailoring, since it is not assigned to any SP 800-53B baseline.
An implementation partner prepares the systems and evidence that show SR-4 is operating. This is usually where outside help adds the most value, because the work involves integrating inventory tools, designing record templates and collecting data from many systems. The partner does not decide what provenance means for your organization and does not certify the result.
- Inventory integration: Connect asset and software inventory sources so that component records can be pulled from the systems of record rather than typed in.
- Record templates: Design the fields for origin, custody transfers, identity and validation, consistent with the scope your team approved.
- Tooling: Configure self-hosted tools, such as the Dependency-Track, Trivy, GLPI and Wazuh platforms, to produce component and software data inside your environment.
- Evidence packages: Assemble the records, configuration exports and change logs an assessor will examine, organized by determination statement.
- Documentation: Write the runbooks that keep the records current after the engagement ends.
The partner should not write the evidence it will later be asked to validate as if it were independent. Agree in the fixed scope who prepares, who reviews and who owns each artifact, and confirm that the partner is not also the assessor.
The independent auditor or assessor tests whether SR-4 is implemented and effective, using the assessment procedure in SP 800-53A. Its findings are its own. It must not design the evidence it tests, because an assessor that builds the records it later examines cannot give an independent view of them.
- Determination statements: The assessor examines documentation, interviews staff and tests whether provenance records exist, are monitored and are maintained for the defined scope.
- Examine objects: Expect requests for documentation of critical systems and components, contracts and system architecture.
- Findings: Findings and any authorization decision belong to the assessor or the authorizing official, not to the partner that prepared the evidence.
- Separation of roles: Confirm before hiring that the assessor has no design role in the same records, which protects the independence of its opinion.
- Questions to ask: Ask how the assessor will sample records, what it will test directly, and what it needs from you in advance.
Before the assessment, confirm the assessor's engagement terms and independence statement in writing.
Common questions about SR-4 provenance cost, effort and scope
Is SR-4 provenance required if my system has no SP 800-53B baseline?
No baseline requires SR-4, so it applies only when your organization selects it through tailoring, an overlay, or a contract or authorizing official that asks for it. SP 800-53B does not assign SR-4 to the low, moderate, high or privacy baseline, and FedRAMP's Rev5 baselines do not require it at Class B, C or D. Check your system's security plan, the contract language and any overlay you have adopted. If one of them names SR-4, treat it as in scope and document the tailoring decision so an assessor can see why the control was selected or excluded.
How much effort does SR-4 add to an existing SP 800-53 program?
The effort depends mostly on how much provenance information you already keep. SR-4 has one organization-defined parameter and four enhancements in Release 5.2.0, and SP 800-53A breaks the base control into three determination statements. The main work is defining which systems, components and associated data are in scope, then showing records of their origin and chain of custody. Effort rises when components come from many suppliers, when software is built in several places, or when no asset inventory exists. Ask any provider to break its estimate into defining scope, collecting records, and keeping them current.
Can we meet SR-4 with in-house staff only?
Often yes, if you have staff who own the asset inventory, the build pipeline and supplier contracts. The work crosses procurement, engineering and security, so the difficulty is coordination rather than tooling. Outside help is most useful for defining the scope, mapping evidence to the three SP 800-53A determination statements, and preparing the examine objects such as contracts and architecture documents. An implementation partner can prepare systems and evidence, but the organization still owns the control and the assessor still tests it.
What does procurement need to provide for SR-4 evidence?
Procurement needs to supply the contract terms that record where components and data come from. SP 800-53A lists contracts among the examine objects for SR-4, so supplier agreements should describe the components or services delivered, the sourcing obligations and how provenance information is returned to you. Engineering supplies the technical side: build records, software bills of materials, and inventory entries that tie each component to its origin. Ask both teams to agree on one list of in-scope items before the assessment starts.
How often does SR-4 provenance evidence need to be refreshed?
SR-4 requires provenance to be maintained, not captured once, so records must stay current as components change. The control text and the 800-53A procedures do not give a fixed interval in the sources reviewed, so confirm the review cycle with your authorizing official, contract or assessor and write it into your supply chain risk management plan. In practice, the trigger is any change to a component, supplier or build, so update records when those events occur rather than only at audit time.
Can a partner issue an SR-4 certification or audit report?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Under FISMA, assessments are carried out by independent assessors, inspectors general or the bodies your contract names, and NIST does not certify compliance. A partner can help you define provenance scope, build inventory and evidence, and run self-hosted tooling that records component origin, then hand the package to an independent assessor who decides whether the control is met.
Which open-source tools can produce SR-4 evidence?
Tools help with the records behind provenance, not the provenance decision itself. Trivy can identify OS packages and software dependencies and produce them as a software bill of materials, and it can scan existing SBOMs. OWASP Dependency-Track, which is Apache-2.0, consumes and produces CycloneDX SBOMs and tracks components by origin and license. GLPI's Assets module and the Wazuh Syscollector inventory can record hardware and installed software on endpoints. Confirm with each project whether a given capability fits your provenance definition before relying on it.
How DeployOpen scopes and prepares SR-4 provenance evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so provenance records for the components and data in scope can be produced from systems you run. We prepare the systems and evidence; your organization owns the control, and an independent assessor reaches the conclusion about it.
How we scope
- Agree in writing which systems, components and associated data SR-4 covers, using the organization-defined parameter your team sets.
- Confirm whether SR-4 is selected in your tailored baseline or overlay, since no SP 800-53B baseline includes it.
- Map the scope to the SR-4 enhancements you select, and record which ones are excluded and why.
How we build
- Connect asset inventory, software bill of materials generation and dependency tracking so each in-scope component has a recorded origin.
- Configure inventory collection from endpoints and network devices, and retain records of changes to component chain of custody.
- Test that provenance records can be retrieved and reconciled against contracts and architecture documentation before handover.
How we hand over
- Deliver a written scope statement, configuration records and a mapping from SR-4 determination statements to the evidence that addresses each one.
- Document procedures for maintaining provenance records, with owners, review frequency and the sources an assessor will examine.
- Provide a list of open items your organization must still resolve, such as supplier contract terms, so the assessment team sees a clear gap view.
How we support
- Fixed-scope engagements are agreed in writing before work starts, with scope, deliverables and timelines defined up front.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask us to confirm the fixed scope, deliverables and retainer terms in a written quote, since we do not publish a price list.
