The task of managing cybersecurity risks in supply chain management isn’t just “nice to have” anymore. It’s basic survival. Modern supply chains aren’t a neat line from supplier to factory to customer; they’re a living network of companies, contractors, platforms, software components, and outsourced services, all stitched together with APIs, portals, shared data, and a lot of trust.

And trust, in security, is a dangerous thing to hand out by default.

Take a step back and picture what we actually mean by “supply chain” in 2025 terms. It’s suppliers and manufacturers, yes—but it’s also distributors, logistics platforms, SaaS tools, payment providers, outsourced support desks, open-source maintainers, and the developers who produce the libraries your developers quietly pulled in because it solved a problem in ten minutes.

That’s the bit that tends to get missed. The supply chain is digital whether you like it or not. Even if your organisation doesn’t “build software”, you’re still consuming it, relying on it, and depending on it to operate. Which means you inherit its vulnerabilities and you inherit its compromises too.

I ended up looking at this from an awkward angle recently: the software supply chain from the viewpoint of a developer and supplier into large organisations. It changes how you think. You stop seeing software as a product and start seeing it as an ecosystem—dependencies piled on dependencies, updates rolling in continuously, and risk that doesn’t politely wait for your annual vendor review cycle.

Security issues in the software supply chain can be painfully direct: malware in a dependency, code injection, compromised build pipelines, stolen signing keys, or a trusted update mechanism being used as a delivery vehicle. When it goes wrong, it doesn’t just create a technical problem. It creates business damage: data loss, service disruption, reputational harm, and a bill that arrives in multiple currencies—money, trust, and time.

SBOMs: the “what’s in the box?” problem

This is where Software Bills of Materials (SBOMs) come in. I first got hands-on with SBOMs while helping a client evaluate risk in packages they were ingesting from suppliers and bundling into their own product. And if you’ve not worked with SBOMs before, the simple explanation is: it’s an inventory list of what software components make up a given application.

Think of it like the ingredients label on food. It tells you what’s inside, including third-party and open-source components that don’t show up in the glossy marketing brochure.

Why does that matter? Because you cannot manage what you cannot see. If you don’t know what components are in the software you run, you can’t realistically answer basic questions like: “Are we exposed to this vulnerability?” or “Which systems need patching?” or “Is this dependency even still supported?”

An SBOM doesn’t magically make your software secure, but it gives you something most organisations are chronically missing: visibility. It lets you track components, monitor them for newly disclosed vulnerabilities, and make informed decisions about patching, compensating controls, or replacement. It also forces uncomfortable but necessary conversations about lifecycle—support status, compatibility impacts, and what happens when you can’t patch without breaking the business.

SolarWinds: the moment everyone started paying attention

The SolarWinds incident is still the story that gets referenced because it’s the perfect example of how supply chain compromise scales. The attackers didn’t need to break into every target directly. They tampered with the supply chain once and let distribution do the rest.

One of the hardest parts for many organisations responding to that event was simply figuring out what they had, where it was installed, and what was impacted. That’s where SBOMs earn their keep: they help you quickly identify affected components and reduce the “fog of war” when you’re trying to scope an incident under pressure.

It’s also why SBOM adoption has moved from “interesting idea” to “expected practice” in certain sectors. Not because SBOMs are trendy, but because the alternative is guessing in the middle of a crisis.

If you want a solid explainer, GitLab’s SBOM guide is a decent starting point: The ultimate guide to SBOMs

If you want a straightforward breakdown of the SolarWinds incident itself, this is useful background reading: SolarWinds hack explained: Everything you need to know

SBOMs aren’t a silver bullet (and pretending they are is risky)

Here’s the important part: SBOMs are not a panacea. They’re an input. They help you understand your exposure, but they don’t prevent compromise on their own. If you stop at “we’ve got SBOMs now”, you’ve basically just built a better inventory of the things you could still get wrong.

To manage cybersecurity risk in the software supply chain properly, you need secure engineering practices that reduce the chance of shipping vulnerable or compromised artefacts in the first place. That means building security into the development lifecycle rather than bolting it on at the end: secure coding, testing, dependency management, and vulnerability assessment as part of the normal flow of delivery.

A software assurance programme can help pull this together into something repeatable and auditable. Done well, it’s not paperwork—it’s a set of habits and controls that keep you honest. This is also where threat modelling becomes incredibly valuable, because it forces you to think about how the software can be attacked before the attacker does it for you.

Supply chain risk management: not just software

It’s also not only about code. Classic supplier due diligence still matters. You need to know who you’re relying on, what access they have, what data they touch, and whether they can demonstrate mature security controls. Contracts need to reflect reality too, with explicit cybersecurity clauses that define responsibilities, notification timelines, and expectations for monitoring and remediation.

And when something does go wrong—because eventually it will—you need an incident response plan that treats supply chain compromise as a first-class scenario. The “what do we do if a supplier is breached?” question should not be answered for the first time during an actual breach. Clear comms, containment approaches, recovery strategy, and legal/regulatory steps need to be thought through in advance.

Managing cybersecurity risks in supply chain management is now part of the core job of running a modern business. Visibility through tools like SBOMs helps, but resilience comes from combining that visibility with secure development practices, assurance, supplier controls, and the ability to respond quickly when the chain gets tugged from the wrong end.

Over the next few weeks I’ll dive into more detail in each of these areas and, if you haven’t already started, here is where to begin: I highly recommend starting with Eric Byres’ talk from the SANS ICS Security Summit in 2022, “Making Use of All Those SBOMs”: Making Use of All Those SBOMs by Eric Byres at SANS ICS Security Summit in 2022