Supply chain and dependency risk

Why this matters

Most of the code your organisation runs was written by someone else. A modest application pulls in hundreds of third-party libraries, each of which pulls in its own, and a vulnerability anywhere in that tree is a vulnerability in your product.

This is the area where the traditional model — scan the host, patch the software — helps least, because the vulnerable component is not installed software. It is a dependency compiled into an application, and no host scanner will see it. The exam expects you to know how that risk is identified, judged and answered.

The lesson

Transitive dependencies and why the count explodes

A direct dependency is one your code declares. A transitive dependency is one your dependencies declare, recursively.

The arithmetic is brutal. A project declaring 20 direct dependencies commonly resolves to several hundred packages, and occasionally to thousands. Most of that tree is invisible to the developers who wrote the application, and nobody chose it deliberately.

Consequences that matter:

• Your attack surface includes code nobody in your organisation has read.
• A single popular library sits deep in thousands of applications, so one disclosure produces a global emergency — the pattern of the large open-source incidents of recent years.
• Updating is not always simple. Fixing a transitive dependency may require a direct dependency to release an update first; you cannot always fix your own exposure.
• Version resolution differs per ecosystem, so what is actually installed may not be what the manifest suggests. Lock files record the resolved truth and should be committed and scanned.

Also inside this surface: build-time dependencies and plugins, which are frequently forgotten and run with considerable privilege. A compromised build plugin can alter the artefact itself, which is the most damaging supply-chain outcome there is.

SBOMs and what they let you answer

A software bill of materials is a machine-readable inventory of components in a piece of software — names, versions, licences, and sometimes provenance. The common formats are SPDX and CycloneDX.

The question an SBOM answers, and it is the important one: "are we affected by this new vulnerability, and where?"

Without one, answering takes days of asking teams to check their projects, and the answer is partial and out of date on arrival. With one, it is a query, and an organisation that can answer it in an hour behaves very differently in the first day of a major disclosure from one that takes a week.

What SBOMs support beyond that:

• Continuous re-evaluation. A component that was clean when shipped becomes vulnerable when a new CVE lands, with nothing in your code changing — the registry-scanning point from lesson 21 in another form.
• Licence compliance, which is often what funds the tooling.
• Customer and regulatory obligations, increasingly required in procurement and in some jurisdictions by law.

Their limits, which are exam-relevant:

• An SBOM is a snapshot at build time and decays.
• Completeness varies — vendored code, statically linked libraries and dynamically loaded components are often missed.
• A supplier's SBOM is a claim, and depends on how they generated it.
• It tells you a component is present, not that it is reachable — which is the next section.

Reachability: is the vulnerable code even called

The most useful refinement in modern dependency management, and the answer to "we have 4,000 dependency findings and no way to work through them".

A component being present does not mean its vulnerable function is used. A library may be pulled in for one utility while the flaw is in a parser your application never invokes. Reachability analysis traces whether the vulnerable code path can actually be called from your application.

In practice this routinely removes a large majority of findings from the urgent pile, and the ones that survive are meaningfully more likely to matter. It concentrates limited capacity on real exposure, which is the same argument EPSS makes in lesson 22 from a different direction.

How to reason about it as an analyst:

• Is the vulnerable function called, directly or through a path your code takes?
• Is the vulnerable feature enabled in the configuration you deploy?
• Does exploitation require input the attacker controls, and does any reach this component?
• Is the component used at build time only, and therefore absent from the running artefact?

Two cautions. Reachability analysis can be wrong, particularly with reflection, dynamic loading or plugin architectures. And "not reachable today" is a property of the current code — a future change can make it reachable without anyone noticing the risk changed. So it is a prioritisation input rather than a permanent dismissal, and the finding should stay recorded.

Vendor risk and third-party assessments

Beyond libraries, the organisation depends on suppliers: SaaS platforms, managed services, contractors with network access, hardware with firmware.

What assessment usually involves:

• Questionnaires, which are self-reported and of limited value on their own.
• Certifications and audit reports — ISO 27001, SOC 2 — which show a control framework exists and was assessed at a point in time. Read the scope and the exceptions; the scope is frequently narrower than the buyer assumes.
• Penetration test summaries from the vendor.
• Contractual terms: notification obligations and their deadlines, right to audit, security requirements, liability, data location.
• Continuous monitoring of a vendor's external posture.

The analyst's practical contribution is usually narrower and more useful than the paperwork:

• Know which vendors hold your data or have access to your systems, and at what level. This is the vendor equivalent of the asset inventory, and it is usually in worse condition.
• Understand the blast radius of each: what a compromise of that supplier would give an attacker in your environment. A monitoring agent with an agent on every host is a different proposition from a marketing tool.
• Know the notification terms, because during an incident involving a supplier the first question is what they are obliged to tell you and by when.
• Monitor for disclosures affecting your suppliers the way you monitor for disclosures affecting your software.

The hard truth to carry: a supplier's vulnerability becomes your incident, and your ability to respond depends almost entirely on preparation done before it happened.

Responding to a dependency advisory under pressure

The scenario the exam likes, and the one that actually occurs: a widely used library has a critical, actively exploited vulnerability, disclosed this morning, and everyone wants an answer now.

A workable sequence:

1. Establish the facts first. Affected versions, the conditions required, whether a fix exists. Early reporting is frequently wrong about the affected range, and acting on the first tweet wastes the day.
2. Determine exposure. Query the SBOM, the dependency manifests, the container images, the package inventories. Answer where, not just whether.
3. Narrow by reachability and configuration, per above.
4. Prioritise by exposure: internet-facing first, then internal, then development.
5. Mitigate immediately where a fix is not yet available — remove reachability, disable the feature, apply a WAF rule. Virtual patching, from lesson 24.
6. Hunt retrospectively. Assume exploitation may already have occurred and search for the indicators, per lesson 13. This step is skipped constantly and is where the actual incident is found.
7. Remediate, verify, and track to completion.
8. Communicate honestly — what you know, what you are still checking, when the next update comes. The reporting lessons cover how.

Two points worth internalising because they are what separates a controlled response from a chaotic one. Preparation determines speed: the organisations that answer within hours are the ones that already had an inventory and an SBOM, not the ones that worked harder on the day. And the hunt matters as much as the patch — patching closes the door, and it tells you nothing about whether somebody already came through it.

Topics this lesson owns

• [x] Transitive dependencies and why the count explodes
• [x] SBOMs and what they let you answer
• [x] Reachability: is the vulnerable code even called
• [x] Vendor risk and third-party assessments
• [x] Responding to a dependency advisory under pressure