DORA — the European Union’s Digital Operational Resilience Act — is a set of rules intended to strengthen IT security for financial entities in the EU. It covers a number of areas, including risk management, incident response, information sharing, and more.
One DORA provision that we’ve heard a lot about from our customers relates to SBOMs (software bill of materials). This is because DORA requires financial entities to develop vulnerability management procedures that include tracking “third-party libraries, including open source.”
Although the text of the DORA regulation and its accompanying Regulatory Standards Technical Document (which is where specifics of software tracking requirements are communicated) don’t explicitly use the word “SBOM,” a machine-readable, structured software inventory — e.g. what’s commonly considered a modern SBOM — is the most practical way to ensure compliance. This is a similar dynamic to PCI DSS 4.0 and its “inventory of bespoke and custom software” requirement.
In this blog, we’ll analyze the specifics of DORA’s SBOM provision and offer guidance for financial organizations looking for the most effective ways to comply. But first, let’s briefly review what led to DORA and what other areas the regulation covers.
DORA Overview and Enforcement
DORA was entered into force by the European Union on January 16, 2023, and the regulation (and accompanying enforcement activities) officially took effect on January 17, 2025.
DORA was enacted in part due to a 2020 study that highlighted “systemic cyber risk” due to the “high level of interconnectedness” across financial organizations and their technologies. The concern, of course, was that a serious vulnerability impacting one component or system could threaten the broader sector and cause significant damage.
Broadly, DORA focuses on several key pillars:
- ICT risk management
- ICT third-party risk management
- Digital operational resilience testing
- ICT-related incidents
- Information sharing
- Oversight of critical third-party providers
As is often the case for EU regulations, DORA comes with significant enforcement teeth. ESAs (European Supervisory Authorities) are empowered to access any document or data they need to assess compliance, and to conduct on-site investigations. Organizations that fail to comply with DORA are also subject to steep penalties.
The exact amount will vary by entity type and role in the financial system (among other factors). But, for example, DORA Article 35 notes that critical ICT third-party service providers are subject to fines of up to “1% of the average daily worldwide turnover… in the preceding business year.”
What DORA Says About SBOMs
Like we mentioned, the text of DORA doesn’t mention “SBOM” or “software bill of materials. However, it does require financial organizations to “track” all software components — a task most efficiently met with an SBOM.
The specifics of DORA’s software tracking requirement are found in Article 15: “Further harmonisation of ICT risk management tools, methods, processes and policies.”
The provision requires ESAs to create technical standards that lay out specific practices and processes to fulfill a number of DORA’s key objectives. This includes a set of vulnerability management procedures.
Software Tracking
Article 10 in this technical standards document requires (among other things) that financial entities track:
(i) third-party libraries, including open-source libraries, used by ICT services supporting critical or important functions;
(ii) ICT services developed by the financial entity itself or specifically customised or developed for the financial entity by an ICT third-party service provider;
What’s important to note about this text is the scope of software that must be tracked. Financial entities must maintain an inventory — most easily accomplished with a machine-readable SBOM — of all types of software components, including open source.
Software Monitoring
Article 10 also notes that:
Financial entities shall, where appropriate in collaboration with the ICT third-party service provider, monitor the version and possible updates of the third-party libraries. In case of ready to use (off-the-shelf) ICT assets or components of ICT assets acquired and used in the operation of ICT services not supporting critical or important functions, financial entities shall track the usage to the extent possible of third-party libraries, including open-source libraries.
This part of the regulation makes clear that DORA requires more than simply producing a one-time software inventory. Rather, the financial entity will need a way to monitor all software components on an ongoing basis. And it will need to work with software suppliers to ensure the software inventory stays updated as new versions of an application are released.
This is another reason why a machine-readable SBOM — which, along with SBOM tooling, facilitates continuous monitoring — is the practical option for complying with these requirements.
How to Fulfill DORA’s SBOM Requirements
It’s most logical to break down the regulation’s SBOM requirements into three phases:
- First-party library analysis and SBOM generation
- Ingesting policy-compliant SBOMs from third parties (and across internal or external teams and product lines)
- Production monitoring by aggregating first- and third-party SBOMs to facilitate continuous monitoring
First-Party Library Analysis and SBOM Generation
Meeting DORA’s software tracking requirements starts by inventorying both the open source and internally maintained components in the software your teams write and build. Organizations can easily do this by using a tool like FOSSA. When you integrate your projects with FOSSA and run a scan, we will inventory your first- and third-party packages, libraries, binaries, or components (which will surface vulnerabilities and license compliance issues in addition to a list of dependencies). You’ll then have the option to generate an SBOM in either CycloneDX or SPDX (and with a customizable set of data fields).
Ingesting Policy-Compliant SBOMs from Third Parties
Financial organizations must also track the components in software acquired from third-party providers. This will mean requiring your software suppliers to provide accurate SBOMs (on a regular cadence, preferably aligned with new version releases) as a condition of doing business.
The “policy-compliant” descriptor is important here as well. To effectively use third-party SBOMs for vulnerability management, it’s vital that the documents include certain data fields (like PURL, VDR, and/or VEX) and be produced in certain formats. That’s why we strongly recommend financial institutions that require SBOMs from suppliers be very explicit about the policy requirements those SBOMs must meet. (We should also note that FOSSA has a recently released feature that makes this much more straightforward.)
Combining SBOMs for Continuous Monitoring
Regardless of the SBOM point of origin, continuous monitoring (e.g. to track the version, possible updates, and new vulnerability introduction) is also an important part of DORA compliance. Our recommendation is to store all SBOMs in one system with the following capabilities to assist in effective issue response::
- Alerts for new vulnerabilities
- A global package inventory
- Revision history for SBOMs and libraries
The other benefit of having SBOMs in one place is, of course, that it will make it much easier to respond to requests from regulators and display proof of vulnerability exploitability disposition (e.g. affected, not_affected, fixed, under_investigation).
Get Started with FOSSA SBOM Management
FOSSA makes it easy for organizations to handle DORA’s SBOM essentials. From generating SBOMs to ingesting and analyzing them, financial organizations across the globe are already successfully using FOSSA to ensure compliance with regulatory requirements.
Additionally, FOSSA’s vulnerability management solution fulfills other DORA requirements in Article 10 of the regulatory technical standards document. This includes automated vulnerability scanning, vulnerability prioritization and remediation, exploitability disposition (e.g. with VEX documents), global package inventory, and revision history over time.
For more information on how we can help your organization meet DORA and other SBOM compliance requirements, please get in touch with our team.
FOSSA Principal Product Manager Cortez Frazier Jr. contributed to this blog post.
