SR-4(4): Supply Chain Integrity — Pedigree

SR-4(4): Supply Chain Integrity — Pedigree requires you to validate the internal composition and provenance of critical or mission-essential technologies, products, and services by using defined pedigree methods and conducting pedigree assessments. Operationally, that means you must identify “critical” components, demand traceability evidence from third parties, verify it, and retain auditable artifacts. ¹

Key takeaways:

• Define what “critical or mission-essential” means for your system, then scope pedigree activities to that list.
• Build a repeatable pedigree workflow: collect provenance, validate composition, assess integrity, and document outcomes.
• Evidence wins exams: keep supplier attestations, SBOMs/traceability records, verification results, and decision logs.

The sr-4(4): supply chain integrity — pedigree requirement is one of the fastest ways an assessor will test whether your supply chain risk program is real or just policy. “Pedigree” here is practical: you are expected to prove where key technologies came from and what is inside them, not simply trust a third party’s marketing claims. This requirement applies most sharply where compromise would be high-impact: identity services, endpoint agents, network infrastructure, hypervisors, cryptographic modules, CI/CD tooling, and managed services with privileged access.

For a Compliance Officer, CCO, or GRC lead, SR-4(4) is operationalized by answering three questions with evidence: (1) Which components are critical or mission-essential in this environment? (2) What provenance and composition evidence do we require before onboarding or change? (3) How do we validate that evidence and record acceptance decisions when it is incomplete? If you can’t show a documented pedigree process and recurring artifacts, you will struggle in audits because this control is designed to be assessed through tangible procurement, engineering, and vendor management records. ²

Regulatory text

Requirement (verbatim excerpt): “Employ {{ insert: param, sr-04.04_odp.01 }} and conduct {{ insert: param, sr-04.04_odp.02 }} to ensure the integrity of the system and system components by validating the internal composition and provenance of critical or mission-essential technologies, products, and services.” ¹

Operator interpretation of the excerpt:

• “Employ [pedigree methods]”: you must define and use specific mechanisms to establish provenance and composition (for example: supplier traceability documentation, SBOM collection, tamper-evident chain-of-custody records, signed artifacts, or authenticated distribution channels). The standard leaves the parameters organization-defined; your job is to pick methods that match your risk. ¹
• “Conduct [pedigree assessments]”: you must perform an assessment activity, not just collect paperwork. That can include validating signatures/hashes, comparing received SBOMs to observed binaries, checking acquisition channels, reviewing sub-tier supplier disclosures, and recording results and exceptions. ¹

Plain-English meaning (what SR-4(4) is really asking)

SR-4(4) asks you to prove integrity for your most important technologies by establishing a “pedigree” that answers: Where did this come from, what is inside it, and why should we trust it? The control expects verification. If you only store a third party’s SOC report and call it done, you are likely missing the “internal composition” and “provenance” validation expectation for critical components. ²

Who it applies to

Entity scope

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually or used as the governing control baseline. ²

Operational scope

• Systems/components designated critical or mission-essential. You must define this threshold (risk-based) and apply pedigree requirements to the technologies, products, and services that meet it. ¹

What you actually need to do (step-by-step)

Use this as a control implementation procedure you can hand to Procurement, Security Engineering, and Vendor Management.

1) Name the control owner and decision authority

• Assign a primary owner (often Security/GRC) and approvers (Product Owner for the system, Security Architecture, Procurement).
• Define who can accept pedigree exceptions and what documentation is required for acceptance.

Output: RACI for SR-4(4) and a short procedure doc mapped to your intake/onboarding workflow.

2) Define “critical or mission-essential” for your environment

Create scoping criteria you can defend in an exam. Common criteria:

• Privileged access to production or sensitive data
• Controls identity, authentication, authorization, or cryptography
• Sits on the network path (DNS, proxies, gateways)
• Runs with kernel/admin privileges (agents, EDR, MDM)
• Builds or deploys code (CI/CD, artifact repos)

Output: A “Critical Components Register” tied to your system inventory.

3) Define your pedigree methods (the “employ …” part)

Pick a minimum set of pedigree methods you will require for in-scope items. Examples you can operationalize:

• Provenance evidence: supplier identity, authorized resellers, manufacturing/distribution chain, service delivery locations, subcontractor disclosure where relevant.
• Composition evidence: SBOM for software, component lists for hardware/firmware where available, dependency disclosures for managed services.
• Integrity evidence: signed builds, hashes for downloads, secure update mechanism description, tamper-evident packaging/chain-of-custody for hardware.
• Change transparency: release notes, vulnerability disclosure process, notification commitments for material supply chain changes.

Output: A “Pedigree Evidence Standard” that lists required artifacts by category (software, hardware, SaaS/managed service).

4) Build the pedigree assessment workflow (the “conduct …” part)

Define how you validate what you collect. Your procedure should include:

• Intake gating: no production deployment for critical items until minimum pedigree evidence is collected and reviewed, or an exception is approved.
• Validation checks (examples):
  • Confirm software is acquired from authorized channels and validate publisher signatures where feasible.
  • Compare SBOM claims to what engineering can observe (package manifests, container layers, dependency scans) when feasible.
  • Verify hardware/firmware provenance documentation aligns with procurement records and receiving logs.
• Risk rating and disposition: approve, approve-with-conditions (for example: compensating controls), or reject.
• Exception handling: document missing evidence, compensating controls, approval, and an expiry or re-validation trigger.

Output: A repeatable checklist embedded into third-party onboarding and change management.

5) Integrate with procurement, third-party due diligence, and change management

SR-4(4) fails most often because it lives in a PDF, not in operational rails.

• Add pedigree requirements to third-party contract clauses and purchase order terms for in-scope components.
• Add a purchase-to-production control point: the team that can approve a new critical component must confirm pedigree completion.
• Tie material changes (new subcontractors, major version upgrades, supplier acquisitions) to a re-assessment trigger.

Output: Updated templates (MSA/SOW security addendum), intake forms, and change control tickets with pedigree fields.

6) Make evidence reviewable and recurring

Even if you do not set a fixed calendar cadence, define recurring triggers:

• New critical component onboarding
• Major version upgrades or architecture changes
• Supplier change notices, security advisories, or incident notifications

Output: An evidence repository structure and a tracker for pedigree status by critical component.

Required evidence and artifacts to retain (exam-ready)

Store artifacts in a way an assessor can trace from “critical list” → “pedigree collected” → “validation performed” → “decision recorded.”

Minimum evidence set (recommended):

• Critical Components Register (what is in scope and why)
• Pedigree Evidence Standard (what you require for each class of item)
• Completed pedigree checklists per critical third party/component
• Provenance artifacts: supplier attestations, reseller authorization letters, chain-of-custody records (as applicable), service subcontractor lists (as applicable)
• Composition artifacts: SBOMs, component manifests, dependency lists
• Integrity verification artifacts: screenshots/logs of signature validation, hash verification records, secure update mechanism review notes
• Exceptions: risk acceptance memo, compensating controls, approvals, re-validation trigger
• Contract evidence: executed clauses requiring notice, disclosure, and evidence delivery for in-scope items

Daydream fits well here as the system of record for mapping SR-4(4) to an owner, a procedure, and a recurring evidence packet, so you can answer assessors with a single control view instead of hunting across email and ticketing.

Common exam/audit questions and hangups

Expect questions like:

• “Show me your definition of ‘critical or mission-essential’ and the list for this system.”
• “For one critical SaaS provider, show provenance and composition evidence, and show how you validated it.”
• “How do you ensure teams can’t bypass pedigree review and deploy anyway?”
• “Show exceptions. Who approved them, and what compensating controls were applied?”
• “How do you detect supplier changes that should trigger re-assessment?”

Typical hangup: teams can produce documents, but cannot show validation steps. SR-4(4) includes “conduct” pedigree assessments; a folder of PDFs without review notes and outcomes is weak support. ¹

Frequent implementation mistakes (and how to avoid them)

1. Treating pedigree as procurement-only paperwork
   Fix: require Security Engineering validation steps for integrity/composition, even if Procurement collects the documents.

2. No “critical component” scoping logic
   Fix: write scoping criteria and keep a living register tied to your system inventory.

3. SBOM collection with no follow-up
   Fix: define what you check (format, completeness, match to deployed artifact, review of high-risk dependencies) and record the result.

4. Exceptions that never expire
   Fix: require a re-validation trigger (for example: before renewal, before major upgrade, or after supplier incident) and track it.

5. No linkage to change management
   Fix: add pedigree reassessment triggers to change tickets for critical tech and to third-party change notice intake.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SR-4(4), so you should treat this as an assessment-readiness control rather than a cited enforcement driver in this guidance. The practical risk is straightforward: weak pedigree increases exposure to counterfeit components, unauthorized distribution, dependency tampering, and sub-tier supplier compromise, and it makes incident response slower because you cannot quickly establish provenance and composition. ²

Practical 30/60/90-day execution plan

First 30 days (establish the rails)

• Assign SR-4(4) owner, approver, and exception authority; publish a one-page procedure.
• Define “critical or mission-essential” criteria; draft the first Critical Components Register for one high-value system.
• Draft the Pedigree Evidence Standard (what you will ask third parties for, by type).

Days 31–60 (pilot and integrate)

• Pilot pedigree collection and assessment on a small set of critical third parties (one SaaS, one software component, one infrastructure component).
• Add pedigree fields to onboarding and change tickets for critical components.
• Update contract/security addendum language to request provenance/composition evidence and change notifications.

Days 61–90 (scale and make it auditable)

• Expand the Critical Components Register across additional systems or business units.
• Create an evidence repository structure and a tracker (component → evidence → validation → decision → next trigger).
• Run a tabletop audit: pick one critical component and rehearse producing end-to-end evidence in a single sitting; fix gaps.

Frequently Asked Questions

What counts as “pedigree” evidence for a SaaS or managed service where there is no SBOM?

Focus on provenance and service composition: subcontractor disclosures where relevant, service delivery architecture summaries, secure build/deploy practices, and integrity controls around updates. Document what you requested, what you received, and what you validated as your pedigree assessment. ¹

Do we need to do this for every third party?

Scope SR-4(4) to “critical or mission-essential” technologies, products, and services, using criteria you can defend. Apply lighter due diligence to lower-risk third parties, but keep the critical list explicit and current. ¹

What does “validate internal composition” mean in practice for software?

Collect composition evidence (commonly an SBOM or dependency manifest) and perform at least one independent check, such as comparing it to scan outputs or deployed package manifests. Record the check, results, and disposition in your pedigree assessment. ¹

Our third party refuses to provide SBOMs. Can we still pass an assessment?

You can proceed with a documented exception if the risk decision is explicit, approved by the right authority, and paired with compensating controls and a re-validation trigger. An assessor will still expect to see that you attempted to obtain evidence and performed an assessment, not a silent acceptance. ¹

How do we operationalize pedigree for hardware purchases through distributors?

Require authorized reseller documentation, chain-of-custody or receiving controls where feasible, and a documented verification step tied to procurement and inventory records. Keep the linkage between purchase records and the specific deployed component so provenance is traceable. ¹

Where should this evidence live so audits are painless?

Put SR-4(4) artifacts in a single evidence system organized by critical component and third party, with each item showing request, receipt, validation, and decision. Many teams use Daydream to map the control to an owner and recurring evidence so the audit pull is consistent.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5