FAQ - Häufig gestellte Fragen

Sie haben Fragen. Wir haben Antworten - ehrlich, konkret und mit Gesetzesreferenz, wo es darauf ankommt.

Geltungsbereich

Ich habe hunderte Projekte in der SBOM - könnt ihr die alle abdecken?

Ja. OTTRIA arbeitet nicht mit einem festen Katalog, sondern mit Ihrer konkreten SBOM. Ob 80 oder 800 Projekte - wir decken alle ab, inklusive transitiver Abhängigkeiten. Das unterscheidet uns grundlegend von Katalog-Anbietern, die nur ausgewählte Projekte betreuen. Der Aufwand skaliert über unser Netzwerk von mehr als 650 Spezialisten und den Community-Effekt: Projekte, die für mehrere Kunden relevant sind, werden gemeinsam betreut. Die gesetzliche Pflicht zur Lieferkettensicherheit (Art. 28 DORA, Art. 21 Abs. 2 lit. d NIS2) kennt keine Ausnahme für weniger bekannte Abhängigkeiten.

Gibt es Komponenten, die ihr nicht übernehmt?

Unser Fokus liegt ausschließlich auf Open-Source-Komponenten, die öffentlich zugänglich sind. Proprietäre Software, Eigenentwicklungen oder geschlossene Drittanbieter-Systeme fallen nicht in unseren Leistungsbereich. Das gilt auch für interne "Open Source"-Projekte: Wenn der Quellcode nicht öffentlich einsehbar ist, können wir ihn weder überwachen noch betreuen. Ebenso übernehmen wir keine Arbeit an Ihren internen Systemen - wir arbeiten in der Open-Source-Welt, nicht in Ihrer Infrastruktur. Das ist eine bewusste Sicherheitsentscheidung: OTTRIA soll kein zusätzliches Einfallstor sein. Für alles außerhalb von Open Source empfehlen wir Partner aus unserem Netzwerk.

Was passiert bei neuen Dependencies automatisch?

Wenn sich Ihre SBOM ändert - durch neue Abhängigkeiten, Updates oder Entfernungen - erfassen wir das im Rahmen der laufenden SBOM-Pflege. Neue Komponenten werden automatisch in die Überwachung aufgenommen, risikobewertet und dokumentiert. Sie müssen keine gesonderte Meldung machen. Die kontinuierliche Inventar-Aktualisierung ist eine gesetzliche Pflicht (Art. 8 Abs. 6 DORA, Art. 21 Abs. 2 lit. d NIS2, Anhang I Teil II Nr. 1 CRA) und ein zentraler Bestandteil unserer Leistung.

Abgrenzung

Wie unterscheidet ihr euch von SCA-Tools wie Black Duck oder FOSSA?

SCA-Tools sind ein guter erster Schritt - sie scannen Ihre SBOM und zeigen registrierte CVEs. Aber sie zeigen nur bekannte, registrierte Schwachstellen. Die Gesetze fordern mehr: Der CRA verlangt Freiheit von bekannten ausnutzbaren Schwachstellen (Anhang I Teil I Nr. 2a), und bei FOSS-Integration sogar die Prüfung gegen alle bekannten Schwachstellen (Art. 13 Abs. 5 CRA). OTTRIA erkennt auch Silent Fixes - durchschnittlich 4 bis 11 pro registriertem CVE - und behebt Probleme aktiv, statt sie nur aufzulisten. Scanner sind Layer 1 (Sichtbarkeit). OTTRIA ist Layer 2 (Eingriff) und Layer 3 (Governance).

Wie unterscheidet ihr euch von HeroDevs oder TuxCare?

HeroDevs und TuxCare sind Katalog-Anbieter: Sie bieten Extended Lifecycle Support für eine feste Auswahl populärer Frameworks und Distributionen. Das ist hilfreich, aber es gibt zwei wesentliche Einschränkungen: Erstens decken sie nur Endprodukte ab — nicht deren eigene Abhängigkeiten. Ein Framework hängt selbst von hunderten Bibliotheken ab, die nicht im Katalog stehen. Zweitens ist der Katalog begrenzt — die Mehrheit Ihrer SBOM bleibt unabgedeckt. OTTRIA betreut Ihre gesamte SBOM, einschließlich aller transitiven Abhängigkeiten. Außerdem arbeiten wir Upstream: Fixes fließen direkt in die Projekte zurück, statt in proprietären Forks zu verschwinden.

Sicherheit

Braucht ihr Zugriff auf mein System?

Nein. OTTRIA arbeitet ausschließlich in der Open-Source-Welt - an öffentlichem Quellcode, in öffentlichen Repositories, mit öffentlichen Tools. Wir brauchen keinen Zugriff auf Ihre Systeme, Ihr Netzwerk oder Ihre internen Daten. Was wir brauchen, ist Ihre SBOM. Das ist eine bewusste Architekturentscheidung: Jeder Dienstleister mit Systemzugriff vergrößert Ihre Angriffsfläche. OTTRIA tut das nicht.

Was passiert bei einem 0-Day ohne Fix?

Bei einem Zero-Day, für den noch kein Patch existiert, handeln wir sofort: Sie erhalten eine dokumentierte Risikobewertung mit Einschätzung der Ausnutzbarkeit, Vorschläge für temporäre Mitigationsmaßnahmen (Workarounds, Konfigurationsänderungen) und eine Einschätzung, wann ein Fix realistisch ist. Parallel beginnen wir mit der Entwicklung eines Patches oder koordinieren mit den Maintainern. Wir reagieren schnellstmöglich und dokumentieren jeden Schritt. Lösungszeiten lassen sich nicht vorhersagen - denn wie schnell ein Fix technisch möglich ist, hängt von der Komplexität ab. Die Dokumentation des gesamten Vorgangs ist prüffähig und erfüllt die Meldepflichten nach Art. 19 DORA, Art. 23 NIS2 und Art. 14 CRA.

Was passiert bei einem Projekt ohne Maintainer?

Verwaiste Projekte sind eines der größten Risiken in der Open-Source-Lieferkette

Audit

Was liefert ihr einem Auditor?

OTTRIA liefert ein vollständiges Evidenzpaket: Risikodokumentation pro Komponente, Maßnahmenhistorie mit Zeitstempeln, Abschlussberichte pro Sicherheitsvorfall, SBOM mit aktuellem Pflegestatus und einen Supply-Chain-Vitalitätsbericht. Jedes Dokument enthält die relevanten Gesetzesreferenzen - zum Beispiel Zuordnung zu Art. 25 Abs. 1 DORA für Open-Source-Analysen oder zu Art. 21 Abs. 2 lit. d NIS2 für Lieferkettensicherheit. Sie ergänzen: Ihre Entscheidung pro Risiko und den Umsetzungsstatus in Ihrem System. Zusammen ergibt das eine prüffähige Dokumentation, die ein Auditor nachvollziehen kann.

Reichen eure Dokumente für eine NIS2-Prüfung?

Unsere Dokumentation deckt den Open-Source-Teil Ihrer Lieferkettensicherheit ab

Haftung

Übernehmt ihr meine Haftung?

Nein. Die persönliche Verantwortung der Geschäftsleitung ist gesetzlich verankert und nicht delegierbar (Art. 5 DORA, Art. 20 NIS2, Paragraph 38 NIS2UmsuCG). Auch die Produkthaftung setzt nachweisbare Sorgfalt voraus. Kein Dienstleister der Welt kann Ihnen diese Haftung abnehmen - und kein Dienstleister kann das regulatorisch leisten. Was OTTRIA tut: Wir reduzieren Ihr Risiko durch aktive Maßnahmen und liefern die Dokumentation, die belegt, dass Sie Ihrer Sorgfaltspflicht nachgekommen sind. Das ist der Unterschied zwischen "nichts getan" und "nachweislich gehandelt" - und dieser Unterschied entscheidet im Haftungsfall.

Praxis

Wie sieht euer Ablauf in den ersten 30 Tagen aus?

Tag 1: Sie liefern Ihre SBOM. Innerhalb von 24 Stunden erhalten Sie einen ersten Abgleich - welche Projekte sind bekannt, welche kritisch, wo gibt es offene Schwachstellen. In der ersten Woche erstellen wir eine vollständige Risikobewertung aller Komponenten und priorisieren nach Kritikalität. Ab Woche 2 beginnt die aktive Arbeit: Patches für kritische Schwachstellen, Kontaktaufnahme mit Maintainern, Aufnahme in unser Überwachungssystem. Am Ende von Tag 30 haben Sie eine vollständig dokumentierte Erstanalyse, die ersten behobenen Schwachstellen und eine laufende Überwachung aller Ihrer OSS-Komponenten.

Zeigt mir einen echten Fall, wo ihr ein Problem gelöst habt.

Ein konkretes Beispiel: Bei der Analyse einer Kunden-SBOM identifizierten wir eine kritische Abhängigkeit zu einem C-Projekt mit einem einzigen Maintainer, der seit 8 Monaten inaktiv war. Der CVE-Scanner zeigte keine Probleme - weil die vorhandenen Schwachstellen nie als CVE registriert worden waren (Silent Fixes in benachbarten Projekten deuteten aber auf das Problem hin). Wir haben den Maintainer kontaktiert, die Schwachstellen verifiziert, Patches erstellt und upstream eingereicht. Der gesamte Vorgang ist öffentlich in den Commit-Historien nachvollziehbar. Das ist kein Einzelfall - es ist unser Tagesgeschäft.

Wie viel Arbeit bleibt bei mir übrig?

Deutlich weniger als ohne OTTRIA, aber nicht null. Ihre Aufgaben: SBOM bereitstellen und aktuell halten, Entscheidungen bei Handlungsbedarf treffen (wir liefern Entscheidungsvorlagen mit Optionen und Risikobewertung) und Patches in Ihrem System deployen. OTTRIA übernimmt alles, was in der Open-Source-Welt passiert: Überwachung, Analyse, Bewertung, Fixes, Dokumentation. Die Entscheidung und das Deployment bleiben bei Ihnen - das ist regulatorisch auch nicht anders möglich, denn die Verantwortung für Ihr System tragen Sie (Art. 5 Abs. 2 DORA, Paragraph 38 NIS2UmsuCG).

Kosten

Was kostet es, das intern zu lösen?

Die folgende Modellrechnung ist bewusst konservativ - die tatsächlichen Kosten liegen in der Praxis erfahrungsgemäß deutlich höher. 800 Projekte in der SBOM bedeuten 15 und mehr Programmiersprachen, hunderte unterschiedliche Build-Systeme, Communities und Release-Zyklen. Für eine ernsthafte interne Betreuung brauchen Sie mindestens 5 bis 7 Vollzeitstellen - Security-Analysten, die diese Sprachen und Ökosysteme verstehen, plus Prozesse für Monitoring, Triage, Upstream-Kommunikation und Dokumentation. Solche Leute sind auf dem Markt kaum verfügbar und kosten mindestens 80.000 bis 120.000 Euro pro Person und Jahr. Selbst wenn Sie sie finden: Die Expertise über alle Ökosysteme gleichzeitig ist intern nicht aufbaubar. OTTRIA löst das über den Community-Effekt - Projekte werden übergreifend betreut, und Sie profitieren von der Arbeit, die wir für alle Kunden leisten.

Kündigung

Was passiert, wenn ich euch kündigt?

Sie behalten alle Dokumentation, Reports und Evidenzpakete, die während der Zusammenarbeit erstellt wurden - das sind Ihre Daten. Alle Patches und Fixes, die OTTRIA in Open-Source-Projekten beigetragen hat, bleiben dauerhaft verfügbar

Versicherung

Ersetzt ihr eine Cyberversicherung?

Nein. OTTRIA ist keine Versicherung und ersetzt keine. Aber OTTRIA verbessert Ihr Versicherungsprofil erheblich. Cyber-Versicherer bewerten zunehmend, wie gut ein Unternehmen seine Software-Lieferkette im Griff hat - dokumentierte Governance, nachweisbare Patch-Zeiten und aktive Schwachstellenbehebung senken Ihr Risikoprofil. D&O-Versicherungen schließen vorsätzliche Gesetzesverstöße typischerweise aus (die persönliche Pflicht aus Art. 5 DORA und Paragraph 38 NIS2UmsuCG macht Untätigkeit zum Gesetzesverstoß). OTTRIA dokumentiert, dass Sie gehandelt haben - das ist im Ernstfall der entscheidende Nachweis.

Open Source

Was ist ein Open Source Steward?

Der Cyber Resilience Act (CRA) definiert in Art. 3 Nr. 14 eine neue Rolle: den "Verwalter quelloffener Software" (Open Source Steward). Das ist eine juristische Person, die die Entwicklung von Open-Source-Produkten systematisch und nachhaltig unterstützt - ohne selbst Hersteller zu sein. Stewards haben reduzierte Pflichten (Art. 24 CRA): Cybersicherheitsstrategie dokumentieren, Schwachstellen managen, mit Behörden kooperieren. Dafür sind sie von Bußgeldern ausgenommen (Art. 64 Abs. 10 CRA). OTTRIA registriert sich freiwillig als Steward - das verpflichtet uns gesetzlich zur Förderung der Open-Source-Sicherheit und gibt uns frühzeitigen Zugang zu Sicherheitsmeldungen in betreuten Projekten.

Warum sollte mein Projekt OTTRIA als Steward akzeptieren?

Weil wir stärken, nicht vereinnahmen. OTTRIA als Steward bedeutet für Ihr Projekt: zusätzliche Ressourcen für Security-Reviews und Patches, Bug-Bounty-Programme, CI/CD-Infrastruktur, Hardware und Urlaubsvertretung für Maintainer. Wir forken nicht und wir übernehmen keine Kontrolle. Ihre Governance bleibt Ihre Governance. Was sich ändert: Sie haben einen strukturierten Partner, der Sicherheitsarbeit übernimmt, die Sie allein nicht leisten können - und der dafür gesetzlich in der Pflicht steht (Art. 24 CRA). Alles was OTTRIA tut, ist Open Source und öffentlich nachprüfbar. Prüfen Sie unsere Commit-Historie, unsere Issues, unsere Patches.

Sie haben eine Frage, die hier nicht beantwortet wird? Kontaktieren Sie uns direkt - wir antworten ehrlich, auch wenn die Antwort unbequem ist.