RiskXchange
Cyber supply chain risk management

Cyber supply chain risk management, where the attack actually arrives.

Cyber supply chain risk management — C-SCRM — is the practice of managing the security risk that reaches you through the things you buy: suppliers, software, components and the update channels that connect them. It differs from general supply chain risk in what it is defending against. A shipping delay is a continuity problem; a compromised build server at a vendor is an intrusion that arrives pre-authorised, through a channel you told your systems to trust. This page covers the attack paths, what NIST SP 800-161 asks for, and the controls that work.

Last reviewed by Darren Craig

What C-SCRM is, and how it differs

Same suppliers, different threat model.

Supply chain risk management in its usual sense is about continuity and dependency: can this supplier deliver, what happens if it cannot, where is the concentration. Cyber supply chain risk management asks a narrower and sharper question — through which of these relationships could an attacker reach us, and what would we see if they did.

The distinction is not academic, because the controls diverge. Dual-sourcing a component is excellent continuity practice and does nothing about a malicious update. Conversely, code signing and build provenance do nothing for a supplier that goes into administration. Programs that treat the two as one discipline tend to inherit the procurement controls and miss the security ones, because procurement owns the supplier relationship and gets there first.

The other structural difference is trust inheritance. Most third-party risk materialises as an incident at the vendor that affects your data. Cyber supply chain risk frequently materialises as an incident at you, executed through software or access you deliberately granted — which is why it defeats perimeter thinking and why detection is so much harder.

The attack paths that matter

Five routes, all of them used in the field. They are listed in rough order of how hard they are to detect after the fact.

  • Compromised software updates
    An attacker reaches the vendor’s build or distribution pipeline and ships malicious code through the legitimate update channel. Signed, expected, and installed by your own patch policy — the reason this sits at the top of the list.
  • Dependency and package compromise
    Malicious or hijacked open-source packages entering through the build. Typosquats, maintainer account takeovers and abandoned packages transferred to new owners. What you shipped contains code nobody at your organization ever reviewed.
  • Managed service provider access
    MSPs, IT outsourcers and support vendors hold privileged access across many customers at once, which makes them efficient targets. One compromise, many victims, and the access used is the access you granted.
  • Vendor credential and token theft
    Integration credentials, API tokens and OAuth grants issued to a supplier and never rotated. Long-lived, over-scoped, and rarely inventoried — the quiet majority of real-world third-party intrusions.
  • Hardware and firmware tampering
    Interference at manufacture or in transit. Rarest of the five and the most expensive to address, which is why it belongs in scope for defence and critical national infrastructure and rarely justifies the spend elsewhere.

Software supply chain risk

The subset that has grown fastest, and the one an SBOM exists to serve.

Software supply chain risk is C-SCRM applied to code — everything that reaches production having been written, built or distributed by someone else. For most organizations that is the overwhelming majority of what runs.

The practical problem is inventory, exactly as it is in the wider discipline. When a critical vulnerability lands in a widely used library, the question “are we affected?” should take minutes. For organizations without a component inventory it takes weeks, and the answer arrives after the window in which it was useful. That gap is what a software bill of materials is for: not a compliance artefact, but the thing that makes the question answerable.

Four controls carry most of the weight:

  • Component inventory. An SBOM per application, kept current through the build rather than assembled on request.
  • Provenance and signing. Verify that what you deploy is what the vendor built. This is the control that specifically addresses the update-channel attack.
  • Build pipeline integrity. Your own pipeline is a supply chain others depend on. The controls you expect of vendors apply to you.
  • Dependency review. Know what enters the build, and treat a transfer of maintainership as a change worth noticing.

What NIST SP 800-161 asks for

The reference most C-SCRM programs are measured against.

NIST SP 800-161 Rev. 1 is the primary US reference for C-SCRM, and it is a programme standard rather than a control checklist. Its central argument is that supply chain security cannot be delegated to procurement or bolted on at assessment time — it has to run through the whole system lifecycle, with the same governance as any other enterprise risk.

What it expects, in practice:

  • A C-SCRM function with actual ownership — named, resourced, and positioned to influence acquisition decisions rather than review them afterwards.
  • Criticality analysis — identifying the systems and components whose compromise would matter most, and concentrating effort there.
  • Supplier requirements in contracts — security obligations, notification duties, provenance evidence and flow-down to subcontractors.
  • Continuous monitoring of suppliers — not annual attestation.
  • Response planning for supplier compromise — a scenario most incident response plans do not cover, because the intrusion arrives through a trusted channel and the initial indicators look like normal operation.

For US federal suppliers this connects to FAR and DFARS obligations and, for defence contractors, to CMMC. In the EU and UK the equivalent pressure comes from NIS2 Article 21, which makes supply chain security an explicit management-body duty, and from DORA for financial entities.

Where RiskXchange fits

RiskXchange covers the supplier-facing half of C-SCRM: discovering who is actually in the chain including fourth parties, scoring each one from the outside, watching for material change between assessments, and holding the evidence a regulator or auditor will ask for. Concentration analysis across the portfolio addresses the exposure that per-vendor assessment structurally cannot show.

The honest boundary: we do not sign your builds or scan your dependencies. Software supply chain integrity inside your own pipeline is a different toolchain, and a C-SCRM programme needs both halves. See supply chain risk management for the continuity framing, or SBOM for the component inventory side.

Questions

C-SCRM, answered.

What is cyber supply chain risk management?
The practice of managing security risk that reaches an organization through what it buys — suppliers, software, components and update channels. It covers the attack paths that use trusted relationships as a route in, and the controls, contract terms and monitoring that address them.
What does C-SCRM stand for?
Cyber Supply Chain Risk Management, the abbreviation used in NIST SP 800-161.
How is C-SCRM different from supply chain risk management?
Threat model. General supply chain risk management is largely about continuity and dependency — can the supplier deliver, and what happens if not. C-SCRM asks which relationships an attacker could reach you through. The supplier list overlaps almost entirely; the controls do not.
Is an SBOM required for C-SCRM?
Not universally mandated, but it is the practical prerequisite for answering “are we affected?” when a vulnerability lands in a common library. US federal software suppliers face SBOM expectations through Executive Order 14028 and subsequent OMB guidance; for everyone else the case is operational rather than regulatory.
Where should a C-SCRM programme start?
Criticality analysis, then inventory. Establish which systems would hurt most if compromised, then find out who and what they depend on — including the suppliers behind your suppliers. Starting with questionnaires produces evidence about a population you have not yet established is the right one.
Does NIS2 or DORA require cyber supply chain risk management?
Both impose supply chain security duties without using the C-SCRM label. NIS2 Article 21 makes it an explicit management-body responsibility for in-scope entities; DORA requires financial entities to manage ICT third-party risk with a register of contractual arrangements. A programme built to SP 800-161 covers most of what either asks for.
Keep reading

The rest of the chain.

Supply chain risk management
The continuity and dependency framing, assessment and mitigation.
SBOM
Formats, minimum elements, and getting one out of a supplier.
NIS2 explained
Article 21 and the suppliers you answer for.
Third-party risk management
The discipline both sit inside.

Find the chain behind your chain.

Book a 30-minute call and we will map your suppliers and their suppliers from the outside — no questionnaire, no cooperation required.

Book a 30-min demo →See pricing