Wir laden Sie ein, uns hart zu prüfen. Jeder Anbieter klingt im Pitch gut. Die richtigen Fragen trennen Substanz von Slides. Hier sind die Fragen, die Sie jedem Anbieter stellen sollten - und unsere Antworten darauf.
Wie eine Zusammenarbeit mit OTTRIA konkret startet, erfahren Sie unter Wie eine Zusammenarbeit startet.
Die Frage: Deckt ihr meine gesamte SBOM ab - oder nur einen festen Katalog? Was passiert mit Projekten, die nicht in eurem Katalog sind? Gibt es versteckte Einschränkungen nach Sprache, Lizenz oder Projektgrösse?
OTTRIAs Antwort: Wir arbeiten mit Ihrer konkreten SBOM, nicht mit einem festen Katalog. Es gibt keine Einschränkung nach Programmiersprache, Lizenztyp oder Projektgrösse. Wenn eine Komponente in Ihrer SBOM steht, wird sie von uns betreut. Das schliesst transitive Abhängigkeiten ein. Die gesetzliche Pflicht zur Lieferkettensicherheit (Art. 28 DORA, Art. 21 Abs. 2 lit. d NIS2) unterscheidet nicht zwischen populären und weniger bekannten Projekten - und wir tun das auch nicht.
Was passiert mit Projekten ausserhalb eines Katalogs? Wir haben keinen Katalog. Jede Komponente in Ihrer SBOM wird individuell betrachtet, unabhängig von Sprache, Lizenz oder Grösse. Versteckte Einschränkungen gibt es nicht: Alles, was in Ihrer SBOM steht, wird von uns abgedeckt.
Die Frage: Nach welchem Modell bewertet ihr Risiken? Gibt es ein formales, dokumentiertes Risikomodell? Wie entscheidet ihr, was zuerst bearbeitet wird?
OTTRIAs Antwort: Jede Schwachstelle wird nach einem dokumentierten Risikomodell bewertet, das Ausnutzbarkeit, Verbreitung, Kritikalität der betroffenen Komponente und den Kontext Ihrer Nutzung berücksichtigt. Die Priorisierung folgt einer klaren Rangfolge: aktiv ausgenutzte Schwachstellen zuerst, dann Schwachstellen mit bekanntem Exploit, dann Schwachstellen mit hoher Ausnutzbarkeitswahrscheinlichkeit. Das Modell ist dokumentiert, nachvollziehbar und wird in jedem Report offengelegt. Das erfüllt die Risikomanagement-Pflichten aus Art. 6 DORA und die Anforderungen an ein formales Risiko-Scoring nach ISO 18974 (4.3.2 Nr. 2).
Ganz im Sinne von Open Source planen wir, unser Risikomodell offen zu legen, damit es nachvollziehbar und überprüfbar ist.
Die Frage: Was passiert konkret, wenn ihr eine Schwachstelle findet? Erstellt ihr selbst Patches? Nur für bestimmte Sprachen? Was passiert, wenn der Upstream nicht reagiert?
OTTRIAs Antwort: Unser Massnahmenkatalog umfasst: Upstream-Koordination mit Maintainern, eigene Patch-Entwicklung und Einreichung, Backports für ältere Versionen, Workarounds und Mitigationsempfehlungen als Sofortmassnahme, und bei verwaisten Projekten die Übernahme der Wartung. Wir arbeiten sprachunabhängig - unser Netzwerk von über 650+ Spezialisten deckt alle relevanten Ökosysteme ab. Wenn der Upstream nicht reagiert, warten wir nicht - wir erstellen den Fix selbst und stellen ihn als Patch oder Fork bereit. Die technischen Massnahmen werden vollständig dokumentiert, inklusive Begründung, Zeitverlauf und Ergebnis.
Die Frage: Wie schnell reagiert ihr bei einem kritischen Problem? Gibt es definierte Reaktionszeiten? Was ist der Unterschied zwischen Reaktionszeit und Lösungszeit?
OTTRIAs Antwort: Wir unterscheiden klar zwischen Reaktionszeit und Lösungszeit. Reaktionszeit ist die Zeit vom Fund bis zur dokumentierten Erstbewertung und Einleitung von Massnahmen. Lösungszeiten garantieren wir bewusst nicht, denn wie lange ein Fix technisch dauert, ist nicht vorhersagbar: ein einzeiliger Patch kann in Stunden fertig sein, ein tiefgreifendes Architekturproblem braucht Wochen.
Darüber hinaus liegt es nicht in unserer Hoheit, ob ein Patch vom Upstream-Projekt akzeptiert wird oder ob es zeitnah ein Release gibt. Welche Probleme im Alltag des Patch-Managements auftreten können, beschreiben wir in unserem Wissensartikel Alltagsprobleme im Patch-Management von Open-Source-Projekten.
Was wir bieten: Frühwarnungen bei Steward-Projekten vor der öffentlichen CVE-Veröffentlichung und sofortige Workaround-Empfehlungen als Zwischenlösung. Die Meldepflichten kennen wir: 4 Stunden Erstmeldung bei schwerwiegenden Vorfällen (Art. 19 Abs. 4a DORA), 24 Stunden Frühwarnung (Art. 23 Abs. 4a NIS2, Art. 14 Abs. 2a CRA).
Die Frage: Habt ihr echte Beziehungen zu Maintainern? Könnt ihr Commits vorzeigen? Oder seid ihr nur ein weiterer Consumer, der Issues aufmacht?
OTTRIAs Antwort: Unser Gründer ist selbst aktiver Open-Source-Committer mit über 1.000 Commits, unter anderem bei FreeBSD. Das ist keine Marketing-Behauptung - es ist öffentlich nachprüfbar. OTTRIA registriert sich als Open Source Steward nach Art. 24 CRA. Das bedeutet: aktive Beteiligung an der Entwicklung, nicht passiver Konsum. Sehr viele Personen aus unserem Netzwerk haben selbst Open-Source-Beiträge geleistet und bringen entsprechende Erfahrung und Beziehungen in die Zusammenarbeit mit Upstream-Projekten ein. Wir reichen Patches upstream ein und beteiligen uns an Security-Reviews. Fragen Sie nach konkreten Commit-Links und Issue-Referenzen - wir zeigen sie Ihnen gerne.
Die Frage: Funktioniert euer Modell auch bei 2.000 Projekten? Bei 50 Kunden gleichzeitig? Bricht das Modell bei Wachstum?
OTTRIAs Antwort: Unser Modell skaliert über den Community-Effekt: Projekte, die in den SBOMs mehrerer Kunden auftauchen, werden gemeinsam betreut. Je mehr Kunden, desto besser die Abdeckung für alle. Die operative Arbeit wird über ein Netzwerk von über 650+ Spezialisten abgewickelt, das nach Bedarf wächst. Engpässe entstehen nicht beim Monitoring - das ist weitgehend automatisiert - sondern bei der Patch-Entwicklung für exotische Projekte. Dort steuern wir über Priorisierung und das Spezialisten-Netzwerk gegen.
Zusätzlich bringen wir jahrzehntelange Erfahrung in Automatisierung und Verarbeitung grosser Datenmengen mit. Das stützt unseren Umgang mit Skalierung und macht es erheblich leichter, auch umfangreiche SBOMs effizient zu betreuen.
Wir sind transparent: Wenn wir an Kapazitätsgrenzen stossen, kommunizieren wir das, statt Qualität stillschweigend zu reduzieren.
Die Frage: Was passiert bei einem verwaisten Projekt? Bei einem plötzlichen Lizenzwechsel? Bei einem Projekt, das gelöscht wird? Bei einem Supply-Chain-Angriff?
OTTRIAs Antwort: Genau diese Fälle unterscheiden uns von Scanner-Lösungen, die nur registrierte CVEs kennen.
Ausstiegsstrategie: Die Ausstiegsstrategie für IKT-Drittdienstleister ist eine explizite DORA-Pflicht (Art. 28 Abs. 8). Falls OTTRIA nicht mehr fortgesetzt wird, sind alle unsere Arbeiten in Open-Source-Projekten weiterhin verfügbar und gehen nicht verloren. Patches, Forks und Dokumentation bleiben öffentlich zugänglich. Für Open-Source-Abhängigkeiten ist das ein struktureller Vorteil gegenüber proprietären Lösungen.
Die Frage: Was steht wirklich im Vertrag? Was ist eine Reaktionszeit, was eine Lösungszeit? Was passiert bei Nicht-Erfüllung? Gibt es versteckte Ausschlüsse?
OTTRIAs Antwort: Wir sind hier ehrlich: Ein standardisiertes Vertragstemplate haben wir noch nicht. Wir befinden uns im Aufbau und erarbeiten die vertraglichen Rahmenbedingungen. Was wir bereits klar benennen können:
Feste Lösungszeiten garantieren wir bewusst nicht - warum, erklären wir in Abschnitt 4 (Reaktionsfähigkeit). Wenn Sie konkrete Fragen zu vertraglichen Details haben, sprechen Sie uns an.
Die Frage: Liefert ihr NIS2-relevante Nachweise? Kann ein Auditor eure Dokumentation direkt verwenden? Wie sieht ein konkreter Report aus?
OTTRIAs Antwort: Jeder OTTRIA-Report ist so aufgebaut, dass ein Auditor ihn direkt verwenden kann. Die Struktur folgt den gesetzlichen Anforderungen: Risikodokumentation pro Komponente (Art. 6 DORA), Massnahmenhistorie mit Zeitstempeln, Zuordnung zu den relevanten Gesetzesartikeln (Art. 25 Abs. 1 DORA für Open-Source-Analysen, Art. 21 Abs. 2 lit. d und e NIS2), SBOM im maschinenlesbaren Format (Art. 13 Abs. 24 CRA). Sie erhalten keine Prosa, sondern strukturierte Evidenz. Ein Muster-Report steht auf unserer Downloads-Seite bereit, damit Sie vor einer Entscheidung sehen, was Sie bekommen.
Die Frage: Wie viel muss ich selbst tun? Wie lange dauert das Onboarding? Brauche ich dediziertes Personal?
OTTRIAs Antwort: Für den Start benötigen wir von Ihnen:
Damit beginnt die Überwachung direkt. Sind neue Projekte in der SBOM enthalten, starten wir umgehend mit dem Onboarding in unser System. Die Dauer hängt von der Grösse und Historie des jeweiligen Projektes ab - in der Regel sind es nur wenige Stunden.
Im Bestfall binden Sie die Übermittlung der aktuellen SBOM via API in Ihr System ein. Das ist optional, aber empfohlen, damit wir immer die aktuelle und tatsächliche Lieferkette überwachen.
Sie brauchen kein dediziertes Personal für OTTRIA - aber Sie brauchen jemanden, der Entscheidungen trifft (bei Handlungsbedarf liefern wir Entscheidungsvorlagen) und Patches in Ihrem System deployed. OTTRIA erfordert keinen Systemzugriff, keine Agenten-Installation, keine Firewall-Änderungen.
Mehr zum Ablauf erfahren Sie unter Wie eine Zusammenarbeit startet.
Stellen Sie jedem Anbieter diese drei Fragen. Die Antworten sagen mehr als jede Hochglanzpräsentation.
OTTRIAs Antwort: Gerne. Wir zeigen Ihnen konkrete Commit-Links, Pull Requests und Issue-Referenzen. Alles öffentlich, alles nachprüfbar. Ein Anbieter, der keine Upstream-Arbeit vorweisen kann, ist ein Scanner mit Support-Vertrag.
OTTRIAs Antwort: Wir übernehmen die Wartung. Wir haben das bereits getan - bei Projekten, deren einziger Maintainer aufgehört hat. Wir erstellen Sicherheitspatches, pflegen einen Fork und suchen aktiv nach neuen Maintainern.
OTTRIAs Antwort: Wir zeigen Ihnen einen Muster-Report. Jetzt, vor Vertragsschluss. Mit Gesetzesreferenzen, Massnahmenhistorie und Risikoklassifikation.
Achten Sie auf diese Warnsignale, wenn Sie Anbieter evaluieren:
Sie wollen uns testen? Vereinbaren Sie einen Termin. Bringen Sie diese Checkliste mit. Wir freuen uns auf harte Fragen.
Noch offene Punkte? Die häufigsten Fragen beantworten wir in unseren FAQ.