Are We Exposed To Emerging Supply Chain Threats?

The hardest question isn't how serious a threat is, it's whether it affects you

A new critical vulnerability lands. It scores above 9 out of 10, the kind of score that gets flagged the moment MITRE or NIST publish it. Internally, that part is manageable. You check your asset register, work out whether you run the affected software, and start patching.

Then someone asks the harder question - what about our suppliers?

One of the things that decides how seriously a vulnerability gets treated is how widely it applies. A supply chain is just lots of organisations connected to each other. If a vulnerability is widespread enough, something in your supply chain is probably running it, even if nothing in your own environment is.

You know what software you use. But what you don't know is what software your suppliers use. 

Answering "are we affected" for your own organisation is a known exercise. Answering it for your suppliers usually isn't. 

‍

What counts as an emerging supply chain threat?

The most common example is a critical software vulnerability, a CVE serious enough to affect a wide range of organisations. But this isn't the only kind.

A threat can also be a supplier suffering a cyber incident directly or an outage that has nothing to do with security, a supplier's systems going down because of an IT failure rather than an attack. The CrowdStrike-Microsoft outage in 2024 is a good example. It wasn't a security vulnerability, it was a faulty update that took systems offline and the disruption still spread down supply chains to organisations who'd never heard of the supplier at the root of it.

Threats can also come from outside technology altogether. A shift in geopolitical tension can raise the threat level for organisations in certain regions or sectors. Threat intelligence groups also track specific attacker groups, and those groups sometimes target particular industries for a period of time, which raises the threat level for anyone operating in that space, including their suppliers.

Security teams hear about these threats through several channels. Software providers publish notifications, CVE databases and threat intelligence feeds surface new vulnerabilities daily and NCSC (and similar bodies) publish guidance. Sometimes the first anyone hears of it is the news, or the supplier itself.

That volume is part of the problem. Vulnerabilities get published constantly, sometimes several a day, and most of them will never touch your organisation or your supply chain. Working out which ones matter is where this gets difficult, and that's the next question.

‍

Severity only matters if the threat applies to you

A vulnerability scoring 9.8 out of 10 sounds like something you have to act on immediately, but severity is only half the picture. The other half is applicability, whether the affected technology is something you or your suppliers actually use.

You care about severity. But you also care about whether you use the piece of software being talked about, because if you don't, the score is irrelevant to you.

For your own organisation, applicability is usually simple to check. You know your asset register, so you know whether you're running the affected software. For your supply chain, it's a different exercise entirely. You don't know what your suppliers run, so you don't automatically know whether a vulnerability applies to them either.

That's why a 10 out of 10 vulnerability in technology nobody in your ecosystem uses can be safely ignored, while a much lower-scoring vulnerability in something several of your critical suppliers depend on might need immediate attention. Severity tells you how bad something could be in theory, whereas applicability tells you whether it's actually your problem.

‍

Direct exposure is easier to establish than supply-chain exposure

Inside your own organisation, you know your assets and you know your software. If a vulnerability is announced, you can check directly whether it applies to you, and you can patch or mitigate it yourself.

Your supply chain doesn't work like that. You may not know what technology your suppliers run underneath the service they provide you and you may not know what their suppliers depend on either. You're relying on them to tell you, and most supplier relationships aren't set up to make that quick.

Something like Microsoft SharePoint is straightforward. If there's a vulnerability in SharePoint and you use it directly, that's effectively an internal problem, even though Microsoft is technically a third party. You deal with it the same way you'd deal with any of your own software.

It gets harder when the vulnerability sits in something behind the service you're using. Log4j is the clearest example of this. It's a piece of open-source code that gets used inside all sorts of other software and services. It's not a company, and it's not something you'd ever have had on a list of your critical suppliers, because it isn't a supplier at all. But if one of your suppliers used a product built on Log4j, you were exposed the moment that vulnerability became public, whether or not you'd ever heard of Log4j.

The deeper an issue sits in the chain, the further it is from anything you can check yourself, and the more you're depending on someone else to notice it, understand it, and tell you about it.

‍

A supplier incident is not automatically your incident

This is the distinction that causes the most unnecessary panic...

A threat is the potential of an incident occurring. It isn't an incident on its own. Once a vulnerability is identified, some organisations will be exposed to it, and a smaller number of those will actually be compromised. Being vulnerable and being breached are two different states, and most organisations sit in the first one without ever moving into the second.

The same logic applies down your supply chain, with one extra layer. An incident happening at one of your suppliers is not automatically an incident for you. It might be. It might not be. That depends entirely on what that supplier does for you, what data they hold, and whether the specific thing that went wrong at their end actually reaches you.

This matters because of what happens when organisations get it wrong. Some will trigger their own incident response procedures the moment they hear a supplier has had an incident, even when there's no confirmed impact to them at all. That creates a lot of work and a lot of noise for no reason, and it pulls attention away from the suppliers where something might actually need checking.

The sequence runs: threat, something that could affect organisations, then exposure, where you or a supplier may be using the affected technology, then supplier incident, where a supplier has confirmed impact, and only then your incident, where there's confirmed impact to your organisation. Each step is a separate question, and none of them can be assumed from the one before it.

‍

Why most teams struggle to answer "are we affected"

Even once you know the right question to ask, most teams don't have the information sitting ready to answer it.

Supplier information tends to be spread across different systems, if it exists in a usable form at all. Assessment data goes out of date and nobody has a reliable, current view of which suppliers use which technologies, or a clear enough picture of supplier criticality to know who to prioritise. And when something urgent comes up, there's often no reliable contact route into the supplier at all, just a general inbox or an account manager who may not know the answer either.

Faced with that, the default response is to email every supplier and ask them directly.

That's a bad approach for almost everyone involved. It creates a flood of low-value work for suppliers who are often dealing with the same question from dozens of other customers at once, at the exact moment they should be focused on fixing the actual problem, if they have one. And it creates a flood of unstructured responses for the organisation that sent it, most of which won't be useful, because there was no way to tell in advance which suppliers actually mattered for this specific threat.

The more mature version of this looks different. Organisations that have already done the work of understanding which suppliers are critical, and which suppliers hold their most sensitive data, don't need to invent a new set of questions for each one. They can ask the same three questions broadly, then use that same criticality and sensitivity picture to decide which responses need attention first.

This is the same underlying groundwork we covered in our guide to identifying critical suppliers. 

‍

The three questions that actually matter

Once you've worked out which suppliers actually matter for this specific threat, what you ask them is simple. It's the same three questions every time, regardless of the nature of the vulnerability or threat.

Do you use this software? Is it even applicable to you?

If you do, have you patched it, or do you know when you will? That tells you the exposure window, how long the problem has existed and how much longer it's likely to run.

Have you found any evidence of compromise?

Those three answers give you almost everything you need. The first tells you whether the threat is relevant at all. The second tells you how exposed the supplier has been and for how long. The third tells you whether exposure has already turned into something worse.

Every emerging threat published follows roughly this same pattern of questions. It doesn't need to be more complicated than that, and trying to make it more complicated usually just slows down the answer.

What you do with the response is the part that depends on judgement. A supplier confirming they use the software but have already patched it is a different situation to one confirming they use it, haven't patched it, and don't have a date for when they will. Both are useful answers. They just point to different next steps, cutting off access, adding monitoring, or simply logging it and moving on.

‍

How quickly should yoube able to answer?

There's a real difference between how fast you should know your direct exposure and how fast you should know your supply-chain exposure.

Direct exposure should be fast. Within a few hours, ideally, since you're only checking your own environment. Most organisations can't actually do this quickly, usually because their internal asset records aren't kept current, but there's no good reason it should take longer than that.

Supply-chain exposure takes longer, because you're depending on suppliers to respond. With current supplier information and a working communication route already in place, a reasonable picture across your most important suppliers should be achievable within roughly a day. That's specifically for the suppliers that are critical to you, or that hold your most sensitive data.

This benchmark is not a regulatory deadline. Nothing in law says you have 24 hours. The reasoning behind it is about reducing chaos rather than meeting a compliance requirement.

That said, two regulatory trends push in the same direction, particularly in financial services and critical national infrastructure. There's a growing expectation to understand critical third parties well enough to respond quickly when something happens to them.

And more broadly, vulnerability management as a discipline is increasingly expected to extend into the supply chain, since so much of an organisation's exposure now sits outside its own direct control. 

‍

The capability should be built before the threat appears

None of this can be created after a major vulnerability has already appeared. Supplier criticality, current supplier information, working contact routes, all of that has to already exist.

That's not something you can build in the middle of a scramble. It has to be sitting there in advance, ready when it's needed.

This is also why, at Risk Ledger, we don't think emerging-threat response should be its own separate process. We built it into the normal running of a Risk Ledger customer's supply chain programme, so the supplier data, criticality, and contact routes needed to answer these questions are already current when a threat appears.

Our clients don't have to do anything extra to get emerging threat information. It happens as part of how the platform already works, not as a six-monthly fire drill.

These events don't happen often. Some organisations publish only a handful of genuine emerging threats a year. But when one does happen, it tends to land at the worst possible time, often over a holiday period, and the teams scrambling for supplier information in the moment remember exactly how painful that was.

The organisations that handle this well aren't the ones with the most complete map of every supplier. They're the ones who did the groundwork before they needed it.

Could you identify your supply-chain exposure within 24 hours?

Assess how much visibility you currently have into supplier criticality, dependencies and exposure, and where the gaps could slow you down when the next major threat lands.

Take the Supply Chain Exposure Assessment →

‍

What security teams ask next

• Which Suppliers Should We Contact First When A Supply Chain Threat Emerges?
• What Does Good Supply Chain Threat Response Look Like?
• What Hidden Supplier Dependencies Could Increase Our Risk?
• Put this into practice: Take the Supply Chain Exposure Assessment

‍