When a widely-used open-source library is compromised, the blast radius is the entire financial sector that depends on it. DORA responds by reaching past your direct vendors into the subcontracting chain — your “fourth parties”. For engineering teams, the practical tool that makes this chain visible is the Software Bill of Materials (SBOM).
Why the supply chain is a DORA concern
Under Articles 28–30 and the 2025 RTS on subcontracting, financial entities must understand and manage the chain of providers behind a critical function — not just the vendor they contracted with. A modern application is mostly third-party code: frameworks, libraries, base images, SaaS dependencies. Each is a potential entry point and a potential single point of failure.
SBOM: making the chain visible
An SBOM is a machine-readable inventory of every component in a piece of software — libraries, versions, licences. It is to your codebase what the Register of Information is to your vendors: the artefact that turns “we are not sure what we depend on” into a managed, queryable list.
- Generate an SBOM (CycloneDX or SPDX) automatically in your build pipeline.
- Scan it continuously against known-vulnerability feeds — so a new CVE in a dependency raises an alert, not a surprise.
- Map critical-function applications to their dependency chains, including the providers behind them.
- Feed material subcontractors into the client’s third-party register and contract obligations.
Contract it, not just code it
Visibility is half the job; the other half is contractual. Article 30 expects sub-outsourcing conditions and notification of changes. Pair your SBOM/supply-chain monitoring with the right clauses — covered in the Certified DORA Contract Manager course — and the discipline in our piece on becoming a compliant software vendor.
Go deeper
The Third-Party Risk Management Expert certification covers fourth-party oversight, concentration risk and exit; browse the full DORA certification catalogue.
