SR-3 asks you to establish a process to identify and address weaknesses or deficiencies in your supply chain elements and processes, to employ controls that protect against supply chain risks and limit the harm from supply chain events, and to document the selected processes and controls. NIST 800-53 binds US federal systems and, by contract, some others. For other companies it is a reference for a question buyers now ask directly: what do you do about the things you depend on?
What it asks
- A process to find and fix weaknesses in supply chain elements and processes, coordinated with defined parties.
- Controls, chosen by you, that protect the system, component or service and limit the consequences of supply chain events.
- Documentation of the processes and controls in a place you define, such as a security plan.
The control names are organization defined, so there is no fixed checklist. The auditor checks that you picked some, applied them and wrote them down.
What it means in practice
NIST defines supply chain elements broadly: organizations, entities or tools used for research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance and disposal. Supply chain processes include hardware, software and firmware development processes, shipping and handling, personnel and physical security programs, and configuration management tools and measures that maintain provenance.
Elements and processes may come from your own organization, system integrators or external providers. The guidance says weaknesses in them are potential vulnerabilities an adversary can exploit.
Translate that to a software company and the elements are your cloud providers, open source dependencies, build tools, CI services, contractors and SaaS vendors. The processes include how you review new dependencies, how you pin versions, how builds are isolated and how you onboard a vendor.
SR-3 has three enhancements worth knowing: diverse supply base (SR-3.1), limitation of harm (SR-3.2) and sub-tier flow down (SR-3.3). Limitation of harm is the easiest to act on. It asks what keeps one failed supplier from taking everything down.
Evidence to collect
- An inventory of critical suppliers, tools and dependencies.
- The process for finding weaknesses: vendor reviews, dependency scans, advisory monitoring.
- A list of the controls applied, such as version pinning, signature verification, least privilege for third party integrations and network segmentation.
- Records of weaknesses found and the actions taken.
- The document that holds the controls and its review dates.
- Contract language that passes requirements down to sub-suppliers.
Common gaps
- A vendor list that omits build tools and open source.
- Controls that exist in practice but are not written anywhere.
- Weaknesses found in reviews with no follow through.
- Third party integrations holding broad credentials.
- No view of what happens if a single supplier goes away or is compromised.
How to implement it
Begin with the inventory. Mark each item critical, important or minor based on what breaks if it fails or is compromised.
For critical items, record three things: how you assess it, what controls limit its blast radius, and how you would replace it. That table is the heart of the documentation.
Add dependency controls in the pipeline. Pin versions, review new packages before adoption, and scan for known vulnerabilities. The Gold directory can help you look up a package's profile when deciding whether to adopt it.
Reduce harm. Give integrations the narrowest credentials they need, rotate them, and separate environments so a compromised supplier cannot reach everything.
Write it up in one place and review it on a schedule, and after any supplier incident.
Try it yourself
Run your manifest through the free in-browser dependency scan at gold.safeguard.sh/scan and note any weak points. Add each to your supply chain weaknesses log with an owner and a decision.
Quick check
Does SR-3 apply to open source dependencies?
The definition of supply chain elements includes entities and tools used in development and operations, so dependencies and build tools fit comfortably.
What is the point of SR-3.2, limitation of harm?
It asks you to design so that a supply chain failure causes limited damage, for example through narrow credentials and segmentation.
