Why DORA requires you to track every software library in your application stack

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 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 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 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 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 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