Modern software applications rely on hundreds of third-party libraries and dependencies. A single application might use dozens of open-source packages, each with its own nested dependencies. When a vulnerability emerges in any one of these components, it can cascade through your entire technology stack in hours.
Log4j demonstrated the pattern clearly: a transitive library in a low-visibility service became a systemic risk within days. Financial entities cannot protect against supply chain attacks if they don't know what's in their software.
01
The cascade of visibility DORA requires
DORA's Register of Information establishes your baseline visibility into critical and important business functions and the ICT service providers supporting them. When you complete templates B_06.01 and B_02.01, you document which ICT service types each provider delivers under your contracts. These ICT service types are essentially your ICT assets, the systems and applications you use day to day in your critical and important business functions.
This is how the Register of Information links directly to your asset register. But your compliance obligations don't stop there.
Each ICT asset is built from components. A modern application contains dozens or hundreds of third-party libraries, each with its own nested dependencies. Your asset register tells you which systems you have, but you also need to track what's inside those systems. Both layers of visibility are required to meet DORA's ICT risk management requirements. This is a mandatory requirement resulting from your vulnerability management procedure.
The cascade flows from business function to software component: critical or important business functions, to ICT service providers, to ICT service types they provide, to the specific ICT assets supporting those functions, to the libraries and components within each asset. You cannot manage ICT third-party risk effectively if you only have visibility at the top two or three levels of this cascade.
02
DORA's library tracking requirements
DORA establishes the obligation to manage ICT risk and vulnerabilities at Level 1. The RTS on ICT Risk Management Framework then specifies exactly how vulnerability management and asset visibility must be operationalized, including tracking third-party components.
Article 10 of the RTS on ICT Risk Management Framework requires financial entities to develop vulnerability management procedures that explicitly track the usage of third-party libraries, including open-source libraries, used by ICT services supporting critical or important functions.
The requirement goes beyond simple awareness. Financial entities must monitor version updates and track changes to third-party libraries on an ongoing basis, working in collaboration with their ICT third-party service providers where appropriate. For off-the-shelf ICT assets not supporting critical functions, entities must track library usage to the extent possible.
Apply this proportionately based on your entity's size and complexity, but assume full traceability for anything supporting critical or important functions. This is not optional documentation. It is a mandatory control that supervisors will verify during DORA compliance reviews.
03
The practical implementation tool
While DORA doesn't mandate a specific technology, the regulation expects financial entities to maintain ongoing visibility of third-party components provided by your ICT suppliers as part of vulnerability management. In practice, the cleanest way to achieve that visibility is a Software Bill of Materials, a machine-readable inventory of all software components and dependencies, including nested open-source libraries.
Using standard formats like SPDX or CycloneDX, SBOMs integrate with software composition analysis and vulnerability feeds so you can answer, within hours: where is this library used, which version is running, which critical functions depend on it.
04
Why this matters now
Software supply chain attacks are accelerating. AI-assisted coding and automated CI/CD pipelines can introduce new vectors, including indirect dependency poisoning and malicious package updates that compromise entire dependency chains.
When a popular library is compromised, financial entities need to know within hours whether they are exposed. Article 10's library tracking requirements exist precisely for this scenario. You must be able to trace from the compromised component back through your Register of Information: which ICT assets use this library, which ICT service types do those assets represent, which critical business functions depend on those services, which providers are responsible for remediation.
You cannot protect what you cannot see. DORA recognizes that financial services operational resilience depends on complete visibility through every layer of the technology stack.
05
Where to find the detailed requirements
The library tracking requirements are specified in Article 10, paragraph 2, point (d) of the RTS on ICT Risk Management Framework.
For broader context on ICT asset management requirements, review Article 4 and Article 5 of the same RTS, which establish the overall policy framework for managing ICT assets and their lifecycles.
The Register of Information templates that establish your baseline visibility are specified in the ITS on Standard Templates, particularly templates B_06.01 for function identification and B_02.01 for contractual arrangements.
Originally published on DORA Solutions Insights.