Trackr.Live The landing site for Trackr Services
§ Trackr.Live

SR — Supply Chain Risk Management

SR is the youngest family in NIST SP 800-53. It did not exist in Rev 4. There was no Supply Chain Risk Management family, no SR-anything; what little supply-chain language existed lived scattered across SA and a few program-management controls. Rev 5 pulled it together into its own family because the threat model had moved. The compromise that matters is no longer only the attacker hammering your running system from outside. It is the attacker who got to your supplier, your build pipeline, your firmware vendor, or the broker three hops up your hardware sourcing chain, and rode a trusted update straight through your perimeter. SolarWinds is the shorthand everyone uses, and it is the right shorthand. C-SCRM, Cyber Supply Chain Risk Management, is NIST’s structured answer to that class of problem, and SR is where it lands in the catalog.

A hardware component traveling a chain-of-custody path through several supplier waypoints, with verification seals at each stage and one waypoint flagged as unverified.

A quick framing point that the family’s newness makes easy to get wrong: SR is a control catalog family from SP 800-53. It is not a stage of the RMF. The RMF is the SP 800-37 process (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor). SR controls get pulled in at Select based on your baseline and overlays, written up and implemented at Implement, graded at Assess, and any C-SCRM gap that doesn’t pass lands in the POA&M and rides continuous monitoring like everything else. The spine the rest of the family hangs off is SR-2, the supply chain risk management plan. Without a real SR-2 plan that names this system’s actual suppliers, the rest of SR is a stack of disconnected assertions.

What’s in the family

SR runs SR-1 through SR-12, and unlike AC there is nothing withdrawn to flag. AC carries Rev 4 ghosts (withdrawn controls an old SSP still cites). SR has no such history, because there is no Rev 4 SR artifact to retire. Every SR control number you see is live, brand new, or an enhancement under one of the twelve.

  • SR-1, Policy and Procedures. The family -1. Org-level C-SCRM policy and the procedures under it. Mandatory, inherited by everything below it, first thing pulled.
  • SR-2, Supply Chain Risk Management Plan. The planning anchor. SR-2(1) establishes a dedicated SCRM team. A real SR-2 plan ties to this system’s supplier inventory; a template with the system name search-and-replaced into it is the most common way this control is faked.
  • SR-3, Supply Chain Controls and Processes. The actual controls and processes that protect the supply chain feeding the system, integrity and configuration of components included.
  • SR-4, Provenance. One of the two headliners. Establishing and maintaining the provenance of systems, components, and associated data, with enhancements covering identity, integrity, and validation of that provenance. Provenance is the maintained claim about where a thing came from and who has touched it since.
  • SR-5, Acquisition Strategies, Tools, and Methods. How you structure acquisitions to manage supply-chain risk, including the contract mechanisms and tooling that enforce it.
  • SR-6, Supplier Assessments and Reviews, with SR-6(1) adding testing and analysis. Assessing the suppliers themselves, not just the parts they ship.
  • SR-7, Supply Chain Operations Security. OPSEC applied to the supply chain. It exists in the catalog but sits in no 800-53B baseline at any level; it only enters a system through an overlay or tailoring decision.
  • SR-8, Notification Agreements. Agreements that bind suppliers to notify you of compromises, changes, or relevant events. This is the contractual channel that makes upstream incident awareness possible at all.
  • SR-9, Tamper Resistance and Detection, with SR-9(1) extending it across multiple stages of the SDLC. Can you tell if something was physically or logically tampered with between the supplier and your receiving dock.
  • SR-10, Inspection of Systems or Components. Actually inspecting received systems and components for tamper, counterfeit, or unexpected modification.
  • SR-11, Component Authenticity. The other headliner, the anti-counterfeit control. SR-11(1) is anti-counterfeit training, SR-11(2) is configuration control for component service and repair, SR-11(3) is anti-counterfeit scanning.
  • SR-12, Component Disposal. Disposing of components so that data and the components themselves don’t leak out the back end. This one overlaps MP-6 hard, and the overlap is where it gets dropped.

Why SR-4 and SR-11 carry the family: supply-chain compromise almost always lands as either a part you can’t prove the origin of, or a part that is not what it claims to be. Counterfeit hardware and tampered firmware sourced through gray-market brokers are SR-11’s whole reason to exist. Unverifiable provenance, the inability to answer “prove this came from who you think and wasn’t altered en route,” is SR-4’s. The other ten controls are mostly machinery that makes those two answerable.

SBOM belongs in this conversation, with a caveat. The software bill of materials is the provenance artifact that EO 14028 pushed into federal acquisition, and it is the most concrete thing most programs now collect in the name of supply-chain assurance. But be precise: SBOM is not a named 800-53 control. There is no “SR-SBOM.” An SBOM is an enabler of SR-4-style provenance, a machine-readable input to the provenance claim, not the claim itself and not a control you can point an assessor at.

SR versus SA, because this is the part people get wrong

SR and SA overlap, and the overlap confuses people badly enough that it’s worth pinning down. System and Services Acquisition (SA) governs the acquisition process and the secure development of the thing you are building or buying. SA-4 is the acquisition process itself, SA-8 is security engineering principles, SA-11 is developer testing, SA-15 is the development process, SA-22 is unsupported components. SA is about how rigorously the thing was built and bought, and how much you can trust the developer’s discipline.

SR governs the supply chain feeding that acquisition: provenance, authenticity, tamper, supplier review. Same contract, different question. SA asks whether the vendor builds securely and tests what they ship. SR asks whether you can trust where the parts came from and that nobody swapped one in transit. They meet at the acquisition contract language, which is exactly why they blur. My rule of thumb: SA is the developer’s rigor, SR is the parts’ pedigree. If the question is “did they engineer this well,” that’s SA. If it’s “is this actually the thing they engineered, and can you prove it,” that’s SR. Cross-link SA and keep the two from smearing together in your SSP, because an assessor reading carefully will notice when SR narratives are just rewarmed SA prose.

Baselines and where the controls come from

Baselines live in SP 800-53B, not in the catalog. FIPS 199 sets your categorization, FIPS 200 sets the floor, and 800-53B turns the resulting impact level into a starting control set. CNSSI 1253 overlays national-security systems instead. FedRAMP and DoD (via DoDI 8510.01) layer their own overlays on top.

SR is allocated more sparsely than AC, especially at Low. SR-1 shows up at all levels. A handful of the planning and acquisition controls reach down toward Low (SR-2, SR-3, SR-5, SR-8, SR-10, SR-11, SR-12 appear broadly). Several of the controls and enhancements that do the sharper work, the supplier-review and tamper enhancements like SR-6 and SR-9, tend to first appear at Moderate and High. Treat any specific allocation as directional. Your overlay moves it, and FedRAMP or a DoD impact level will pull enhancements in above the bare 800-53B set.

Control Typical first live at What an assessor actually checks
SR-2 Low A real SCRM plan, not a template, mapped to this system’s actual supplier inventory. “Where’s your supplier list” is the opening question.
SR-3 Low Documented supply-chain controls that touch component integrity and config, traceable to the plan.
SR-4 Overlay only Provenance records that exist and are maintained, not asserted once and abandoned. Show the chain, not a claim.
SR-5 Low Acquisition strategy and contract mechanisms that actually carry the C-SCRM requirements into the buy.
SR-6 Moderate Supplier assessment evidence, independent where it can be, not a vendor self-attestation taken at face value.
SR-8 Low Notification agreements that are actually in the contract, with teeth, not a verbal understanding.
SR-9 High Tamper-evident controls that are verifiable on receipt, not documented and never checked.
SR-10 Low Inspection actually performed on a sample of received components, with records.
SR-11 Low An anti-counterfeit process plus SR-11(1) training records showing people can recognize counterfeit indicators.
SR-12 Low Disposal and sanitization evidence that ties to MP-6, with custody tracked to destruction.

The “first live at” column is directional. Overlays move it, and an enhancement optional at Moderate is often mandatory at High.

Deeper: provenance is not an SBOM. SR-4 wants a maintained chain-of-custody claim, the running answer to “where did this come from and who touched it.” An SBOM is one machine-readable artifact that helps support that answer for software components. The two get conflated constantly, and the conflation is where the control quietly fails. Collecting SBOMs satisfies nothing on its own. If you ingest SBOMs into a repository and have no triage workflow, no process to query them when the next Log4Shell-class CVE drops, no way to say “we have that component in these three systems,” then SR-4 is shelfware. An assessor who hears “we collect SBOMs” should, and a good one will, follow with “show me what happened the last time a critical vuln hit a component you’d collected.” If the answer is silence, the provenance control is paper.

Where it actually goes brittle

SCRM plans go boilerplate. The SR-2 plan that’s a downloaded template with no supplier inventory behind it is the single most common SR failure. The document exists, the date is current, and it describes a generic organization’s generic supply chain rather than this system’s real vendors. An assessor asks for the supplier list and the SCRM plan, holds them next to each other, and watches them fail to connect.

SBOM collection without consumption is the EO 14028-era version of the same rot. Here’s where I’ll plant a flag: for most Moderate systems, the SBOM mandate has produced collection without consumption. SBOMs filed, never queried. SR-4 provenance gets marked satisfied on paper while the question that actually matters, can you prove this firmware wasn’t tampered with upstream, goes unanswered. An SBOM with no ingestion pipeline behind it is a file in a SharePoint folder, and a Log4Shell-class component will sit in it unflagged until someone goes looking, which by definition happens after the disclosure.

Supplier reviews built on self-attestation are the other place I don’t buy the assurance. A vendor questionnaire the vendor fills out about themselves is questionnaire theater. SR-6 done as “we sent them our security questionnaire and they answered yes to everything” is close to worthless, and SR-6(1) testing and analysis exists precisely because somebody noticed that. Independent evidence beats a vendor’s self-graded report card.

Tamper controls (SR-9) get documented and never exercised. Whether anyone actually breaks the seal-check open on receipt, rather than signing for the box and moving on, is what SR-9 and SR-10 turn on. Counterfeit risk (SR-11) concentrates in hardware and firmware sourced through brokers and gray-market resellers, which is also where the provenance chain is thinnest, so SR-4 and SR-11 fail together more often than not. And SR-12 disposal falls between owners: it overlaps MP-6 media sanitization so cleanly that each family’s owner assumes the other has it. The component goes out the door, the data may still be on it, and the handoff was nobody’s job.

The cross-family ties are worth naming because SR rarely stands alone. SR-12 to MP-6 on sanitization and disposal. SR-6 and SR-5 to SA-4 and SA-9 on acquisition and external services. SR-3 to the CM family on component configuration and integrity. SR to RA-3(1), the supply-chain risk assessment that feeds the whole thing. SR-8 to the IR family, since supplier notification is how upstream incidents reach your incident response at all. And the whole family up to PM-30, the supply chain risk management strategy at the program level that SR-2 inherits from.

If your SR narratives could be pasted into any other system’s SSP without changing a supplier name, they’re too generic to pass. SR is a family about your specific suppliers and your specific parts. Catalog paraphrase is the fastest route to Other Than Satisfied.

Sources

Adjacent material on this site