deenx-default

False security: why scanners and service provider promises are not enough

Many companies believe they have their open source supply chain under control — because they use a tool, have created an SBOM, or rely on their service provider's assurance. This assumption is understandable — and wrong. The regulatory requirements go considerably further. Here is why.

SCA tools find only reported vulnerabilities — not all known ones #

SCA tools (Software Composition Analysis) scan your components against multiple databases — CVE, GitHub Security Advisories, NVD, package manager warnings, and others. That is considerably more than a pure CVE scan. But all these databases share the same structural problem: they contain only vulnerabilities that someone has actively reported.

The distinction is critical:

The EU laws do not require freedom from reported vulnerabilities. The CRA requires in Annex I Part I No. 2a freedom from "known exploitable vulnerabilities" — and the due diligence obligation for FOSS integration (Art. 13(5)) requires checking against all known vulnerabilities. NIS2 requires in Art. 21 measures reflecting the "state of the art". No law limits itself to what is in databases.

Those who rely on SCA tools alone cover the reported fraction — and miss the known majority.

Silent fixes: the known but unreported majority #

For every reported vulnerability, there are four to eleven security-relevant corrections that flow into the code without an entry in any database. Maintainers often fix problems silently (silent fixes) — in a regular commit, without security notice, without advisory, without CVE number.

These silent fixes are not a fringe phenomenon. They are the majority of all security corrections. The problem was known — to the maintainer who fixed it. But it was never reported — and is thus invisible to every SCA tool in the world.

For your company, this means: between the moment a maintainer silently fixes a security issue and the moment you apply the update, you are vulnerable — without knowing it. OTTRIA detects silent fixes through active code analysis and participation in the projects.

SBOMs decay #

An SBOM is a snapshot. On the day of creation, it correctly shows which components in which version are in your product. One day later, it begins to age.

Projects release updates. New transitive dependencies are added. Maintainers change. Licences change. Projects are archived or deleted. None of this is automatically reflected in your SBOM.

DORA requires in Art. 8(6) regular updates to the ICT asset inventory upon any material change. NIS2 presupposes current knowledge of all components through the supply chain obligation (Art. 21(2)(d)). The CRA requires the SBOM as a continuous process. A static SBOM meets none of these requirements.

Supply chain security is not a one-time inventory. It is a permanent activity.

Decision Debt: the silent liability #

In many open source projects, there are architecture decisions that have been deferred for years. Outdated APIs that nobody replaces. Security-relevant refactorings that nobody has time for. Technical debt that grows from commit to commit.

These problems do not appear in any vulnerability database. There is no CVE for a poor architecture decision, no warning for an outdated cryptography library that still technically works but no longer meets the state of the art.

For your company, Decision Debt is more dangerous than a known bug — because you do not even know the risk exists. Only those who actively work in the code and know the projects from the inside recognise these risks.

"State of the art" is not static #

DORA requires a risk management framework in accordance with "relevant international standards" (Art. 6(2)). NIS2 requires measures reflecting the "state of the art" (Art. 21(1)). The GDPR requires in Art. 25(1) and Art. 32(1) likewise the "state of the art" — and additionally that integrity, availability, and resilience are ensured "on a permanent basis". All three formulations are deliberately open-ended.

What meets the state of the art today may be insufficient tomorrow. New attack methods, new findings, new standards such as ISO/IEC 18974 continuously shift what is considered "appropriate".

A CVE scanner was state of the art five years ago. Today it is necessary but not sufficient. Those who must argue before a supervisory authority why their measures are appropriate need more.

The documented GDPR fines paint a clear picture: outdated or unmaintained software is the most common single trigger. Advanced Computer Software Group (ICO, 2025, GBP 3.1 million, unpatched critical vulnerability CVSS 10.0 for two years, "ad hoc patch management", first UK processor fine under UK GDPR), Dedalus Biologie (CNIL, 2022, EUR 1.5 million, approximately 500,000 health records, Art. 28/29/32), British Airways (GBP 20 million, manipulated JavaScript library), Deutsche Wohnen (EUR 14.5 million, outdated archiving software), Morele.net (PLN 2.8 million, unpatched vulnerability) — the same pattern everywhere: the vulnerability was known, the fix was available, nobody had the overview. That is precisely what open source governance is for — and precisely the gap addressed by Art. 83(2)(d) GDPR, which expressly considers documented measures under Art. 25 and 32 as a mitigating factor in fine assessment.

There is no database for severe bugs #

CVE databases capture security vulnerabilities. But what about errors that threaten business operations without being security vulnerabilities in the traditional sense? Crashes under load, data loss with certain inputs, incompatibilities after updates — for this category of problems, there is no structured database and no scanner.

DORA requires in Art. 10(1) the identification of "potential individual material vulnerabilities". This expressly includes operational risks.

Whole-of-IT: responsibility does not end with your own code #

DORA and NIS2 pursue a whole-of-IT approach. The obligations for risk control cover not only your own software but the entire stack — including all open source components, their transitive dependencies, and the services of your ICT third-party service providers (DORA Art. 28, NIS2 Art. 21(2)(d), CRA Art. 13(5)).

Many companies underestimate the scope of this obligation. The SBOM shows 800 projects — but the actual attack surface comprises thousands of transitive dependencies that no human can manually oversee.

Five years of update guarantees — the promise nobody can keep #

The CRA requires in Art. 13(8) five years of security updates for every product with digital elements. Software service providers and agencies that develop software on behalf of clients are legally manufacturers — and give their customers corresponding update guarantees. Many of these commitments are well-intentioned but not sustainable.

The problem is not with the service provider itself, but with what it does not control. A typical enterprise application contains hundreds of open source components. Any one of them can become abandoned within five years — because the maintainer stops, loses interest, or runs out of time. Projects are deleted without warning or change their licence to terms that make continued use impossible. When that happens, there is nobody left to deliver security updates — or the legal basis for using the component ceases to exist entirely. The service provider has given a guarantee it cannot redeem because the source has dried up, disappeared, or become legally inaccessible.

To make matters worse: many service providers do not even know which open source components are in their software. Without a current SBOM, they lack visibility into their own dependencies. They cannot assess which projects are maintained and which are not — let alone whether someone will still be providing security updates for those projects in five years. An SBOM that loses value daily is no foundation for a five-year guarantee.

The consequence: anyone who guarantees five years of security updates without actively supporting the open source projects in their supply chain is making a promise they structurally cannot keep. Active support means: monitoring abandonment risks, detecting deletions and licence changes early, creating patches when needed, maintaining forks, taking over maintainer coordination. Without this operational intervention capability, the guarantee is a piece of paper.

"DORA is implemented" — your service provider's most dangerous statement #

Central IT service providers in the financial sector announce to their clients: "DORA is implemented." This statement sounds reassuring. It is at best misleading — because DORA is not a project with a completion date. DORA is a regime of permanent obligations.

Art. 25(1) DORA prescribes open source analyses as an ongoing testing method — not as a one-time check. Art. 28(1-2) requires the continuous management of all ICT third-party risks. Art. 9(4f) requires documented policies for patches and updates. Art. 8(6) requires updating the ICT asset inventory upon any material change. None of these obligations is ever "implemented" in the sense of "done".

What do these service providers actually do? At best, they maintain an SBOM and operate CVE scanning. That is Layer 1: visibility. But DORA requires more. Art. 13(5) CRA requires manufacturers to exercise "due diligence" when integrating FOSS components — including promoting secure development. Art. 10(1) DORA requires the identification of "potential individual material vulnerabilities" — not just registered ones.

Particularly significant: Art. 10(1) DORA is not limited to security vulnerabilities. It requires the identification of "potential individual material vulnerabilities" — which expressly includes operationally threatening bugs. Crashes under load, data loss with certain inputs, incompatibilities after updates. For this category of problems, there is no database like CVE or NVD. There is no standardised reporting system, no scanner, no established solution. No service provider can claim to have "implemented" this obligation with a standard tool — because the standard tool does not exist. OTTRIA has developed a dedicated process for this that combines automated scanning, AI-supported commit analysis, and manual code review. But this process only works because OTTRIA actively participates in the projects — because operationally threatening bugs cannot be detected from the outside.

Those who maintain an SBOM have created an inventory. Those who scan CVEs have a list of known reports. But who detects the bugs that appear in no database? Who actually promotes the secure development of the components? Who actively participates in the projects?

Open source is public — for auditors and attackers alike #

Here the characteristic in the name comes into play: the "open" in open source means, among other things, public. Everything is visible. To everyone.

An auditor can check: "Your service provider claims to secure your open source supply chain. Show me their commits in the projects of your SBOM." If the answer is silence, the claim is disproven — with publicly accessible data.

And what an auditor can see, an attacker can also see. The same transparency that makes open source strong makes inaction visible. An attacker looking for a target in the financial sector can analyse the SBOMs of deployed products and specifically attack projects where nobody is actively contributing. No commits for months, no response to issues, no security advisories — those are invitations.

"Our SBOM is confidential" — the argument that is not one #

A common objection: the SBOM is not public, so nobody can know the dependencies. That sounds like security through obscurity. In practice, it is an illusion.

SBOMs can be largely reconstructed — without access to the source code, without insider knowledge. Even rough knowledge is sufficient:

An attacker does not need to know the complete SBOM. Rough knowledge is sufficient when it hits the right components. Someone who knows that a financial service provider uses Spring Boot version X does not need a complete bill of materials — they need a vulnerability in Spring Boot.

SBOM confidentiality is not a security concept. It is an information advantage that in practice is thin to non-existent. Actual security comes from someone actively maintaining the components — not from nobody knowing which ones they are.

The illusion of delegation #

DORA is unambiguous: financial institutions remain fully responsible at all times for compliance with ICT requirements, even when outsourcing functions to third parties (Art. 28(1)). The statement "Our service provider has implemented DORA" absolves nothing. It shifts the operational work — but not the responsibility, and not the liability.

When a service provider assures you that DORA is "done", ask specifically: in which open source projects of my SBOM are you active? Which patches have you contributed? Which vulnerabilities have you reported? Which silent fixes have you detected? The answers are publicly verifiable.

OTTRIA can answer these questions. Every commit, every review, every report is publicly visible — for you, for your auditor, and for any supervisory authority.

Associations and non-technical stakeholders do not understand the implications #

A considerable proportion of those affected by DORA and NIS2 have no deep technical understanding of open source ecosystems. Industry associations issue guidance that presents "create an SBOM" and "deploy a CVE scanner" as sufficient. That is understandable — but it does not correspond to what the laws actually require.

Some aspects are already law but not yet defined in detail. The specification through implementing acts and ENISA guidelines is still ongoing. Those who prepare only for the minimum today risk having to make improvements tomorrow.

The full picture #

The individual gaps add up:

No single one of these problems is critical on its own. Together, they form a systematic weakness in your governance — precisely the point where auditors focus and supervisory authorities probe.

What OTTRIA does differently #

OTTRIA does not rely on a single source. We combine CVE monitoring with active code analysis, silent fix detection, project health assessment, and participation in the ecosystem. Not because any single tool is bad, but because no single tool is enough.

The result: a complete picture of your open source supply chain — not just the registered excerpt.

What you concretely receive

OTTRIA in market comparison

Talk to us about your supply chain