The lesson of Anthropic’s Mythos disclosure is uncomfortable for every financial entity: AI can now surface zero-day vulnerabilities — including a 27-year-old flaw in hardened OpenBSD and a 16-year-old FFmpeg bug tested five million times — faster than human researchers ever could. The defensive bottleneck has shifted. It is no longer “is our own code secure?” It is the far harder question: do we even know what is inside the software we run? The answer is a Software Bill of Materials (SBOM), and under DORA it has quietly become a frontline control.

What changed: zero-days at machine speed

A modern banking or insurance application is mostly other people’s code — open-source libraries, frameworks, base images, transitive dependencies five levels deep. For years, obscure flaws in those components stayed buried because finding them required scarce, expensive human attention. AI-assisted vulnerability discovery removes that constraint. When the cost of finding a deep, decades-old flaw collapses, the stock of “undiscovered” vulnerabilities in your dependency tree starts converting into discovered ones — for defenders and attackers alike.

The new exposure. Your risk is no longer just the code you wrote. It is every component you depend on, including the ones you do not know you depend on. You cannot defend — or patch — what you cannot see.

What an SBOM actually is

An SBOM is a machine-readable inventory of every component in a piece of software — each library, its version, its licence, and ideally its supplier. The two dominant standards are CycloneDX (OWASP) and SPDX (Linux Foundation). A good SBOM captures not just your direct dependencies but the transitive ones — which is exactly where the dangerous, forgotten components hide.

Think of it as doing for your codebase what the Register of Information does for your vendors: turning “we are not entirely sure” into a queryable, governed list.

Why the SBOM is now a frontline control

The value of an SBOM is measured in the minutes after a new vulnerability is announced. Picture the next “Log4Shell” moment — a critical flaw in a ubiquitous library, dropped on a Friday evening.

  • Without an SBOM: days of manual hunting across hundreds of applications to answer “are we affected, and where?” — while attackers, possibly AI-assisted, are already scanning for it.
  • With a current SBOM: a single query returns every affected system in minutes. Your mean-time-to-patch — the control that matters most when zero-days surface faster — collapses from weeks to hours.

In a machine-speed world, the SBOM is what makes fast, evidence-based response possible. It is the difference between a contained incident and a reportable breach.

How to operationalise it (not just generate it)

An SBOM that is produced once and filed away is theatre. The control is the process:

  • Generate automatically in your build pipeline (CI), for every application and release — so the SBOM is always current, never a stale snapshot.
  • Store and version SBOMs centrally, mapped to the applications and the critical or important functions they support.
  • Scan continuously against vulnerability feeds, so a newly-disclosed CVE in any dependency raises an alert automatically.
  • Cut the noise with VEX (Vulnerability Exploitability eXchange): record which flagged vulnerabilities are actually exploitable in your context, so teams act on real risk instead of drowning in alerts.
  • Push it down the chain — require SBOMs from your software vendors, and reflect material providers and their subcontracting chains in your third-party governance.

How this maps to DORA

None of this is optional under the Digital Operational Resilience Act — an SBOM is how you actually deliver several DORA obligations at once.

  • Pillar 1 — ICT risk management. DORA expects a maintained inventory of ICT assets and their dependencies, plus vulnerability and patch management. An SBOM is the dependency inventory, and it is what makes patch velocity measurable. See the ICT Risk Management Professional certification.
  • Pillar 4 — ICT third-party risk. Your providers’ software carries the same hidden flaws Mythos found. Requiring SBOMs, tracking the subcontracting chain and reflecting it in the Register of Information and your concentration analysis is core Article 28–30 work — including exposure to designated Critical ICT Third-Party Providers.
  • Pillar 2 — incident reporting. When a vulnerability is exploited, an SBOM lets you scope impact fast enough to classify and notify within DORA’s 4-hour / 72-hour windows instead of guessing.
The supervisory line. “We generate SBOMs in CI for every critical-function application, scan them continuously, govern patch velocity, and require SBOMs from our material providers.” That is a concrete, evidenced answer — not a policy that hopes for the best.

Common pitfalls

  • SBOM as a document, not a feed. Generated once for an audit, never scanned again — zero defensive value.
  • Ignoring transitive dependencies. The forgotten, five-levels-deep library is exactly where the AI-found zero-day lives.
  • No VEX, so alert fatigue. Without exploitability triage, teams stop reading the alerts — and miss the one that matters.
  • Stopping at your own code. Your vendors’ opacity is your exposure; demand transparency down the chain.

Turn visibility into capability

SBOM is one control in a broader shift: defending a financial entity against AI-era, machine-speed threats. Our Certified DORA AI-Resilience Specialist certification puts SBOM, patch velocity and machine-speed defence in their DORA context — ending in a verifiable certificate. For the working detail, see the DORA professional reference and tools.

This article is analysis for resilience and compliance teams, not legal or security advice. SBOM standards: CycloneDX (OWASP), SPDX (Linux Foundation).