FAQ — Frequently asked questions

You have questions. We have answers — honest, concrete, and with legal references where it matters.

Scope #

I have hundreds of projects in my SBOM — can you cover them all? #

Yes. OTTRIA does not work with a fixed catalogue but with your specific SBOM. Whether 80 or 800 projects — we cover them all, including transitive dependencies. This fundamentally distinguishes us from catalogue providers that only support selected projects. The effort scales through our network of more than 650 specialists and the community effect: projects relevant to multiple clients are managed collectively. The legal obligation for supply chain security (Art. 28 DORA, Art. 21(2)(d) NIS2) makes no exception for less well-known dependencies.

Are there components you do not cover? #

Our focus lies exclusively on open source components that are publicly accessible. Proprietary software, in-house developments, or closed third-party systems are outside our scope. This also applies to internal "open source" projects: if the source code is not publicly accessible, we can neither monitor nor maintain it. Likewise, we do not perform any work on your internal systems — we work in the open source world, not in your infrastructure. This is a deliberate security decision: OTTRIA should not be an additional attack vector. For everything outside open source, we recommend partners from our network.

What happens with new dependencies automatically? #

When your SBOM changes — through new dependencies, updates, or removals — we capture that as part of ongoing SBOM maintenance. New components are automatically included in monitoring, risk-assessed, and documented. You do not need to make a separate notification. Continuous inventory updates are a legal obligation (Art. 8(6) DORA, Art. 21(2)(d) NIS2, Annex I Part II No. 1 CRA) and a core part of our service.

Differentiation #

How do you differ from SCA tools like Black Duck or FOSSA? #

SCA tools are a good first step — they scan your SBOM and show registered CVEs. But they only show known, registered vulnerabilities. The laws require more: the CRA requires freedom from known exploitable vulnerabilities (Annex I Part I No. 2a), and for FOSS integration even checking against all known vulnerabilities (Art. 13(5) CRA). OTTRIA also detects silent fixes — on average 4 to 11 per registered CVE — and actively resolves problems instead of just listing them. Scanners are Layer 1 (visibility). OTTRIA is Layer 2 (intervention) and Layer 3 (governance).

How do you differ from HeroDevs or TuxCare? #

HeroDevs and TuxCare are catalogue providers: they offer extended lifecycle support for a fixed selection of popular frameworks and distributions. That is helpful, but there are two significant limitations: firstly, they only cover end products — not their own dependencies. A framework itself depends on hundreds of libraries not in the catalogue. Secondly, the catalogue is limited — the majority of your SBOM remains uncovered. OTTRIA covers your entire SBOM, including all transitive dependencies. Additionally, we work upstream: fixes flow directly back into the projects rather than disappearing into proprietary forks.

Security #

Do you need access to my system? #

No. OTTRIA works exclusively in the open source world — on public source code, in public repositories, with public tools. We do not need access to your systems, your network, or your internal data. What we need is your SBOM. This is a deliberate architectural decision: every service provider with system access increases your attack surface. OTTRIA does not.

What happens with a zero-day without a fix? #

For a zero-day where no patch yet exists, we act immediately: you receive a documented risk assessment with an exploitability evaluation, proposals for temporary mitigation measures (workarounds, configuration changes), and an estimate of when a fix is realistic. In parallel, we begin developing a patch or coordinating with the maintainers. We respond as quickly as possible and document every step. Resolution times cannot be predicted — because how quickly a fix is technically possible depends on the complexity. The documentation of the entire process is audit-ready and fulfils the reporting obligations under Art. 19 DORA, Art. 23 NIS2, and Art. 14 CRA.

What happens with a project without a maintainer? #

Abandoned projects are one of the biggest risks in the open source supply chain — and this is exactly where the difference between OTTRIA and pure scanner solutions becomes apparent. When a project no longer has an active maintainer, OTTRIA takes over maintenance directly: we create security patches, maintain forks where needed, and ensure critical fixes remain available. In many cases, we succeed in attracting new maintainers or reactivating existing ones. The alternative — a critical dependency without maintenance in your supply chain — is exactly the risk that DORA (Art. 28(8), exit strategies), NIS2 (Art. 21(2)(d)), and the CRA (Art. 13(5), due diligence for FOSS integration) address.

Audit #

What do you deliver to an auditor? #

OTTRIA delivers a complete evidence package: risk documentation per component, remediation history with timestamps, closure reports per security incident, SBOM with current maintenance status, and a supply chain vitality report. Every document contains the relevant legal references — for example, mapping to Art. 25(1) DORA for open source analyses or Art. 21(2)(d) NIS2 for supply chain security. You add: your decision per risk and the implementation status in your system. Together, this forms audit-ready documentation that an auditor can follow.

Are your documents sufficient for a NIS2 audit? #

Our documentation covers the open source part of your supply chain security — completely and audit-ready. For a NIS2 audit under Art. 21, however, you are responsible for all risk management measures, not just open source. OTTRIA delivers evidence for Art. 21(2)(d) (supply chain) and (e) (vulnerability management) related to your OSS components. The remaining areas — network security, access controls, business continuity — are with you or other service providers. We are honest: OTTRIA solves a critical part, not everything.

Liability #

Do you assume my liability? #

No. The personal responsibility of management is enshrined in law and cannot be delegated (Art. 5 DORA, Art. 20 NIS2, Section 38 NIS2UmsuCG). Product liability also requires demonstrable due diligence. No service provider in the world can relieve you of this liability — and no service provider can achieve that from a regulatory perspective. What OTTRIA does: we reduce your risk through active measures and deliver the documentation that proves you have met your duty of care. That is the difference between "did nothing" and "demonstrably acted" — and this difference decides in a liability case.

Practice #

What does your process look like in the first 30 days? #

Day 1: You submit your SBOM. Within 24 hours you receive an initial match — which projects are known, which are critical, where there are open vulnerabilities. In the first week, we create a complete risk assessment of all components and prioritise by criticality. From week 2, active work begins: patches for critical vulnerabilities, contacting maintainers, onboarding into our monitoring system. At the end of day 30, you have a fully documented initial analysis, the first resolved vulnerabilities, and ongoing monitoring of all your OSS components.

Show me a real case where you solved a problem. #

A concrete example: during the analysis of a client SBOM, we identified a critical dependency on a C project with a single maintainer who had been inactive for 8 months. The CVE scanner showed no problems — because the existing vulnerabilities had never been registered as CVEs (silent fixes in neighbouring projects hinted at the problem, though). We contacted the maintainer, verified the vulnerabilities, created patches, and submitted them upstream. The entire process is publicly traceable in the commit histories. This is not an isolated case — it is our day-to-day business.

How much work remains with me? #

Considerably less than without OTTRIA, but not zero. Your tasks: provide and keep the SBOM up to date, make decisions when action is needed (we provide decision templates with options and risk assessment), and deploy patches in your system. OTTRIA handles everything that happens in the open source world: monitoring, analysis, assessment, fixes, documentation. The decision and deployment remain with you — this is also not possible any other way from a regulatory perspective, as the responsibility for your system lies with you (Art. 5(2) DORA, Section 38 NIS2UmsuCG).

Costs #

What does it cost to solve this internally? #

The following cost model is deliberately conservative — actual costs in practice tend to be significantly higher. 800 projects in the SBOM mean 15 or more programming languages, hundreds of different build systems, communities, and release cycles. For serious internal coverage, you need at least 5 to 7 full-time positions — security analysts who understand these languages and ecosystems, plus processes for monitoring, triage, upstream communication, and documentation. Such people are hardly available on the market and cost at least EUR 80,000 to 120,000 per person per year. Even if you find them: the expertise across all ecosystems simultaneously cannot be built internally. OTTRIA solves this through the community effect — projects are managed collectively, and you benefit from the work we do for all clients.

Termination #

What happens if I terminate you? #

You keep all documentation, reports, and evidence packages created during the collaboration — those are your data. All patches and fixes that OTTRIA contributed to open source projects remain permanently available — they are open source and belong to the community. What ceases: ongoing monitoring, active remediation of new vulnerabilities, and early warnings. You then stand where you were before — responsible for the entire OSS supply chain, without a structured partner. There are no lock-in effects and no data hostage situations.

Insurance #

Do you replace a cyber insurance? #

No. OTTRIA is not an insurance and does not replace one. But OTTRIA significantly improves your insurance profile. Cyber insurers increasingly assess how well a company manages its software supply chain — documented governance, demonstrable patch times, and active vulnerability remediation lower your risk profile. D&O insurance policies typically exclude wilful legal violations (the personal obligation under Art. 5 DORA and Section 38 NIS2UmsuCG makes inaction a legal violation). OTTRIA documents that you have acted — that is the decisive evidence in an emergency.

Open source #

What is an Open Source Steward? #

The Cyber Resilience Act (CRA) defines a new role in Art. 3 No. 14: the "open source software steward". This is a legal person that systematically and sustainably supports the development of open source products — without being a manufacturer itself. Stewards have reduced obligations (Art. 24 CRA): document a cybersecurity strategy, manage vulnerabilities, cooperate with authorities. In return, they are exempt from fines (Art. 64(10) CRA). OTTRIA voluntarily registers as a steward — this legally commits us to promoting open source security and gives us early access to security reports in supported projects.

Why should my project accept OTTRIA as a steward? #

Because we strengthen, not co-opt. OTTRIA as steward means for your project: additional resources for security reviews and patches, bug bounty programmes, CI/CD infrastructure, hardware, and holiday cover for maintainers. We do not fork and we do not take control. Your governance remains your governance. What changes: you have a structured partner that takes over security work you cannot perform alone — and one that is legally obligated to do so (Art. 24 CRA). Everything OTTRIA does is open source and publicly verifiable. Check our commit history, our issues, our patches.

Have a question not answered here? Contact us directly — we answer honestly, even when the answer is uncomfortable.