Key takeaways

• Software supply chain security is measured in response time: how quickly an organization finds a vulnerable component and reaches the team that owns the fix, then confirms remediation.
• An SBOM delivers security value once it is continuously updated and linked to deployed versions, application owners and a remediation process.
• Vulnerability priority depends on exploitability, exposure and business criticality, so a critical CVE in an isolated development environment can wait behind a lower-scored one in an internet-facing service.
• CRA reporting obligations, in force since 11 September 2026, set a 24-hour window for actively exploited vulnerabilities, and DORA requires in-scope financial entities to track and remediate third-party libraries behind critical or important functions.

Since 11 September 2026, manufacturers covered by the Cyber Resilience Act (CRA) have had 24 hours to report an actively exploited vulnerability once they become aware of it, with a fuller notification due within 72 hours. Compare that window with what happens inside many organizations when a critical vulnerability is announced. Teams spend days establishing which systems are affected, and remediation waits behind that search.

One structural issue explains why. CISOs and CTOs usually hold a reliable list of the applications they run, but a harder question waits one layer down: which third-party components are inside those applications, where each one is deployed and which team owns the fix.

A single application may depend on hundreds of open-source packages, transitive dependencies and container images, while different teams maintain separate versions and deployment pipelines. This article describes how to turn that estate into a continuously maintained dependency inventory connected to deployed assets and ownership, and how to convert vulnerability intelligence into prioritized remediation that holds up under CRA and DORA scrutiny.

Why is software supply chain security an incident-response problem?

The pressure arrives on the day a vulnerability in a widely used library is disclosed. Security needs an answer about exposure across the whole software estate, and that answer has to be assembled from repositories, pipelines and deployed versions that separate teams maintain in their own ways. Exposure stays open for as long as that assembly takes.

Seen from the incident-response side, supply chain security is a measure of uncertainty. The organization has to confirm that a component is present and locate where it runs, then find the team that owns it. Manual searches slow every step.

Producing an SBOM is one step toward those answers. A continuously maintained dependency inventory, linked to deployed assets and to the teams that own them, turns vulnerability intelligence into prioritized remediation actions. That is the fuller objective.

What makes an SBOM useful for vulnerability management?

An SBOM is an inventory. Its security value depends on how accurate and current it is, and on whether it connects to deployed software and the teams responsible for it.

Many organizations generate SBOMs at release time and stop there. The document then describes what was built on release day, while production runs whichever version was deployed last, and the two records drift apart. Runtime versions often go untracked as well, which leaves security teams searching for the owner of a vulnerable component by hand.

Many teams treat buying an SBOM or software composition analysis (SCA) tool as the point where supply chain security gets solved. The tool produces data. The surrounding process, continuous monitoring and operational ownership of every finding, is what turns that data into security.

A related assumption treats open-source software as inherently unsafe. The underlying risk lies in visibility and maintenance, plus controlled consumption, meaning clear rules on which packages and sources teams may use. Controlled consumption in turn depends on seeing every package in the chain, including the ones that arrive indirectly.

Where do transitive dependency vulnerabilities hide?

Direct dependencies are the packages a team declares in its own manifest, and they tend to receive most of the scanning attention. The harder risk lives in transitive packages pulled in by those dependencies, and in build tools, container base images and CI/CD components. At these layers supply chain risk becomes difficult to trace, because the component lives outside every file the application team maintains.

One anonymized enterprise case shows how this plays out. A vulnerability was announced in a widely used open-source library, and several application teams initially reported themselves unaffected, based on a check of their declared dependencies. A deeper dependency analysis showed that the vulnerable package reached multiple applications transitively through a shared framework, and one of those applications was an internet-facing service.

The organization then had to establish which deployed versions were affected and identify the owning teams. It also had to verify whether the vulnerable code path was in use. Each step ran by hand, across multiple repositories.

A component can belong to an application’s supply chain and still be absent from its direct dependency list. A reliable dependency graph, linked to deployed assets and ownership, would have shrunk the investigation into a targeted remediation process.

The same visibility issue extends to the machinery that builds and ships software. Organizations tend to underestimate the importance of securing the build and delivery process itself. CI/CD credentials, artifact repositories, dependency sources and release integrity all belong in scope, since each of them shapes what code finally reaches production.

How should teams prioritize vulnerabilities beyond CVSS scores?

A complete inventory produces a long list of findings, and the order in which teams work through it determines how much risk remains open at any given moment. Many practitioners rank that list by CVSS score alone.

The score describes a vulnerability in general terms. It says little about the specific system where the component runs. A critical CVE in an isolated development environment can wait behind a lower-scored vulnerability in an internet-facing, business-critical service.

Treating every vulnerability as equally urgent produces backlogs that grow past what any team can work through. Effective prioritization weighs exploitability and exposure alongside the severity score, and it adds business criticality and any compensating controls already in place. The combination that works best joins dependency discovery, exploitability intelligence, business criticality and clear remediation ownership into one process.

A CISO can work toward a clear view of which risks are unacceptable, who owns each one and what action it requires, even as the wider backlog remains a longer-term project.

What do the CRA and DORA require for third-party code dependencies?

Regulators now expect organizations to show that this kind of prioritization happens and that it leaves an audit trail.

The CRA makes secure development and vulnerability handling a product responsibility, and that responsibility covers the software components used in products with digital elements. Its main provisions apply from 11 December 2027. Reporting obligations for actively exploited vulnerabilities and severe incidents arrived earlier, on 11 September 2026. Under those rules a manufacturer has 24 hours from becoming aware of an actively exploited vulnerability to report it, and a fuller notification follows within 72 hours. Effective vulnerability handling is required for the whole support period of the product.

A manual search rarely finishes inside twenty-four hours.

DORA approaches the same issue from the governance side. For in-scope financial entities, ICT third-party risk management is a formal governance requirement, and it reaches down to the third-party libraries used by ICT services that support critical or important functions. Those entities need to track which libraries are in use and monitor their updates, with vulnerability assessment and verified remediation completing the requirement.

Together the two regulations accelerate the move toward continuous software inventory, backed by documented ownership, risk-based remediation and auditable supply chain controls. Knowing which components are in use is the starting point. Organizations also need to show how they monitor those components and demonstrate that identified risks are being managed.

What should a CISO do in the next 30 days to monitor third-party dependencies?

Meeting those expectations starts with a narrow scope. A 30-day plan works when it covers the systems where a compromise would hurt most, and its output is a minimum viable software dependency inventory for those systems:

• Select the 10 to 20 applications that would carry the greatest business or regulatory impact if compromised.
• Generate SBOMs for those applications, covering transitive dependencies and container images.
• Connect each dependency to the deployed version, the application owner and the remediation process.
• Run a focused exercise against a small set of recent high-impact vulnerabilities and measure the time from disclosure to identified exposure, then to assigned ownership and confirmed remediation.

The measured times show where the process breaks. A long delay before exposure is identified means visibility is the weak point. A long delay before an owner is assigned means accountability is unclear. A long delay before remediation is confirmed means the bottleneck sits in execution.

A repeatable process that turns a newly disclosed vulnerability into an actionable, time-bound response delivers more value early on than a complete inventory attempted all at once. A complete enterprise-wide inventory can grow from that process.

FAQ

What is software supply chain security?

Software supply chain security is the discipline of knowing which third-party components sit inside an organization’s applications, where they are deployed and who is responsible for them. It covers open-source packages, transitive dependencies and container images, together with the build pipeline itself. Its main measure is response time: how quickly a newly disclosed vulnerability becomes a prioritized fix with a named owner and verified remediation.

What does an SBOM need to support vulnerability management?

An SBOM supports vulnerability management when it stays accurate and current across the whole software lifecycle. An SBOM generated once per release describes release day, not the version running in production afterward. Each listed component should link to the deployed version, the application owner and a defined remediation process, so a new disclosure leads straight to the team responsible for the fix.

Why do transitive dependencies create hidden risk?

Transitive dependencies enter an application through other packages, so they sit outside the manifest the application team maintains. A team that checks only its declared dependencies can report itself unaffected while a vulnerable library reaches its service through a shared framework. Full dependency analysis, covering build tools, container base images and CI/CD components as well, closes that visibility gap.

What should drive vulnerability prioritization besides CVSS?

Vulnerability prioritization should combine the CVSS score with exploitability, exposure, business criticality and existing compensating controls. The score is generic, and the surrounding context determines the risk to a specific system. A critical CVE in an isolated development environment can reasonably wait while the team fixes a lower-scored issue in an internet-facing, business-critical service.

What does the Cyber Resilience Act require for vulnerability reporting?

Since 11 September 2026, manufacturers of products with digital elements must report an actively exploited vulnerability within 24 hours of becoming aware of it, followed by a fuller notification within 72 hours. Reporting obligations for severe incidents started on the same date. The main CRA provisions apply from 11 December 2027, and manufacturers remain responsible for vulnerability handling, including in third-party components, throughout the product’s support period.

How does DORA apply to third-party libraries?

DORA makes ICT third-party risk management a formal governance requirement for in-scope financial entities. For ICT services that support critical or important functions, this includes tracking the third-party libraries in use and monitoring their updates. Vulnerabilities in those libraries need assessment, and remediation needs verification. Entities also have to demonstrate, through documented ownership and auditable controls, that identified risks are being managed.