Due Diligence — How to evaluate us

We invite you to scrutinise us rigorously. Every provider sounds good in a pitch. The right questions separate substance from slides. Here are the questions you should ask every provider — and our answers.

How a collaboration with OTTRIA concretely starts is described under How a collaboration starts.

1. Coverage and completeness #

The question: Do you cover my entire SBOM — or just a fixed catalogue? What happens with projects not in your catalogue? Are there hidden restrictions by language, licence, or project size?

OTTRIA's answer: We work with your specific SBOM, not a fixed catalogue. There are no restrictions by programming language, licence type, or project size. If a component is in your SBOM, we cover it. This includes transitive dependencies. The legal obligation for supply chain security (Art. 28 DORA, Art. 21(2)(d) NIS2) does not distinguish between popular and less well-known projects — and neither do we.

What happens with projects outside a catalogue? We have no catalogue. Every component in your SBOM is assessed individually, regardless of language, licence, or size. There are no hidden restrictions: everything in your SBOM is covered by us.

2. Triage and prioritisation #

The question: What model do you use to assess risks? Is there a formal, documented risk model? How do you decide what gets addressed first?

OTTRIA's answer: Every vulnerability is assessed using a documented risk model that considers exploitability, prevalence, criticality of the affected component, and the context of your usage. Prioritisation follows a clear hierarchy: actively exploited vulnerabilities first, then vulnerabilities with a known exploit, then vulnerabilities with high exploitability probability. The model is documented, traceable, and disclosed in every report. This fulfils the risk management obligations under Art. 6 DORA and the requirements for formal risk scoring under ISO 18974 (4.3.2 No. 2).

In the spirit of open source, we plan to publish our risk model openly so it can be verified and reviewed.

3. Measures (technical) #

The question: What concretely happens when you find a vulnerability? Do you create patches yourselves? Only for certain languages? What happens when upstream does not respond?

OTTRIA's answer: Our measures catalogue includes: upstream coordination with maintainers, own patch development and submission, backports for older versions, workarounds and mitigation recommendations as immediate measures, and for abandoned projects, taking over maintenance. We work language-independently — our network of over 650+ specialists covers all relevant ecosystems. When upstream does not respond, we do not wait — we create the fix ourselves and provide it as a patch or fork. Technical measures are fully documented, including rationale, timeline, and outcome.

4. Responsiveness #

The question: How quickly do you respond to a critical problem? Are there defined response times? What is the difference between response time and resolution time?

OTTRIA's answer: We clearly distinguish between response time and resolution time. Response time is the time from discovery to documented initial assessment and initiation of measures. We deliberately do not guarantee resolution times, because how long a fix takes technically is unpredictable: a one-line patch may be done in hours, a deep architectural problem takes weeks.

Moreover, it is not within our control whether a patch is accepted by the upstream project or whether there is a timely release. What problems can arise in everyday patch management is described in our knowledge article Everyday problems in open source patch management.

What we offer: early warnings for steward projects before the public CVE disclosure and immediate workaround recommendations as interim solutions. We know the reporting deadlines: 4-hour initial report for severe incidents (Art. 19(4a) DORA), 24-hour early warning (Art. 23(4a) NIS2, Art. 14(2a) CRA).

5. Upstream access #

The question: Do you have real relationships with maintainers? Can you show commits? Or are you just another consumer opening issues?

OTTRIA's answer: Our founder is himself an active open source committer with over 1,000 commits, including at FreeBSD. This is not a marketing claim — it is publicly verifiable. OTTRIA registers as an Open Source Steward under Art. 24 CRA. This means: active participation in development, not passive consumption. Many people in our network have themselves made open source contributions and bring corresponding experience and relationships with upstream projects. We submit patches upstream and participate in security reviews. Ask us for specific commit links and issue references — we are happy to show them.

6. Scaling #

The question: Does your model work with 2,000 projects? With 50 clients simultaneously? Does the model break with growth?

OTTRIA's answer: Our model scales through the community effect: projects that appear in the SBOMs of multiple clients are managed collectively. The more clients, the better the coverage for everyone. Operational work is handled through a network of over 650+ specialists that grows as needed. Bottlenecks do not arise in monitoring — that is largely automated — but in patch development for exotic projects. We counter that through prioritisation and the specialist network.

Additionally, we bring decades of experience in automation and processing large data volumes. This supports our approach to scaling and makes it considerably easier to manage even extensive SBOMs efficiently.

We are transparent: if we hit capacity limits, we communicate that rather than silently reducing quality.

7. Edge cases #

The question: What happens with an abandoned project? With a sudden licence change? With a project that is deleted? With a supply chain attack?

OTTRIA's answer: These are precisely the cases that distinguish us from scanner solutions that only know registered CVEs.

• Abandoned project: We take over maintenance directly — security patches, maintained forks, search for new maintainers. If needed, we continue maintaining critical bugs and security issues on the last version, recommend alternatives, or take other action.
• Licence change: We actively monitor licence changes. In the event of a problematic change, you immediately receive a risk assessment and options (last compatible version, alternative components, fork strategy).
• Project deletion: We mirror critical projects. If a repository disappears, the code remains available.
• Supply chain attack: We monitor changes in source code and attempt to detect supply chain attacks as early as possible — compromised maintainer accounts, manipulated dependencies, malicious commits. Through our upstream involvement, we detect suspicious changes early.

Exit strategy: The exit strategy for ICT third-party service providers is an explicit DORA obligation (Art. 28(8)). If OTTRIA is discontinued, all our work in open source projects remains available and is not lost. Patches, forks, and documentation remain publicly accessible. For open source dependencies, this is a structural advantage over proprietary solutions.

8. Contractual clarity #

The question: What is actually in the contract? What is a response time, what is a resolution time? What happens in case of non-fulfilment? Are there hidden exclusions?

OTTRIA's answer: We are honest here: we do not yet have a standardised contract template. We are in the process of building and developing the contractual framework. What we can already clearly state:

• Coverage: Your complete SBOM
• Scope of services: Monitoring, analysis, assessment, fixes, documentation
• Exclusions: Proprietary software, system access, assumption of liability
• Documentation: You receive audit-ready reports with legal references
• Upon termination: You keep all documents and open source patches remain permanently available

We deliberately do not guarantee fixed resolution times — why is explained in Section 4 (Responsiveness). If you have specific questions about contractual details, talk to us.

9. Auditability #

The question: Do you deliver NIS2-relevant evidence? Can an auditor use your documentation directly? What does a concrete report look like?

OTTRIA's answer: Every OTTRIA report is structured so that an auditor can use it directly. The structure follows legal requirements: risk documentation per component (Art. 6 DORA), remediation history with timestamps, mapping to relevant legal articles (Art. 25(1) DORA for open source analyses, Art. 21(2)(d) and (e) NIS2), SBOM in machine-readable format (Art. 13(24) CRA). You receive not prose but structured evidence. A sample report is available on our Downloads page, so you can see what you get before making a decision.

10. Integration effort #

The question: How much do I have to do myself? How long does onboarding take? Do I need dedicated personnel?

OTTRIA's answer: To get started, we need from you:

• Your current SBOM
• A contact person, ideally tiered by criticality and communication channel

With that, monitoring begins directly. If new projects are in the SBOM, we start onboarding them into our system immediately. The duration depends on the size and history of the respective project — typically just a few hours.

Ideally, you integrate the submission of your current SBOM via API into your system. This is optional but recommended so that we always monitor the current and actual supply chain.

You do not need dedicated personnel for OTTRIA — but you need someone who makes decisions (we provide decision templates when action is needed) and deploys patches in your system. OTTRIA requires no system access, no agent installation, no firewall changes.

More about the process can be found at How a collaboration starts.

11. Reality check — three test questions for the meeting #

Ask every provider these three questions. The answers reveal more than any glossy presentation.

"Show me the last patch you submitted upstream." #

OTTRIA's answer: Gladly. We show you specific commit links, pull requests, and issue references. All public, all verifiable. A provider that cannot demonstrate upstream work is a scanner with a support contract.

"What happens when a project in my SBOM is abandoned tomorrow?" #

OTTRIA's answer: We take over maintenance. We have already done this — for projects whose sole maintainer stopped. We create security patches, maintain a fork, and actively search for new maintainers.

"What does a concrete report look like that I can give to my auditor?" #

OTTRIA's answer: We show you a sample report. Now, before signing a contract. With legal references, remediation history, and risk classification.

Red flags with other providers #

Watch for these warning signs when evaluating providers:

• "We cover everything" — but on inquiry, a fixed catalogue of 50 to 200 projects emerges
• "Guaranteed resolution time of 24 hours" — technically impossible for arbitrary open source vulnerabilities
• "No upstream work needed" — then problems are not solved at the root but hidden in proprietary forks that create long-term lock-in
• "We need access to your systems" — maintaining open source components does not require system access since the open source projects exist outside your infrastructure. Any access increases your attack surface
• "Our reports are sufficient for the auditor" — but there is no sample report to view
• "We assume your liability" — regulatorily impossible (Art. 5 DORA, Art. 20 NIS2, Product Liability)
• No public commits, issues, or patches demonstrable — anyone claiming to work in open source must be able to prove it. Open source is public by definition

Want to put us to the test? Schedule a meeting. Bring this checklist. We look forward to tough questions.

Still have open items? The most common questions are answered in our FAQ.