Alphabetisch sortierte Übersicht aller Abkürzungen, Fachbegriffe und Gesetzesverweise, die auf dieser Website verwendet werden.
Bundesanstalt für Finanzdienstleistungsaufsicht. Die deutsche Aufsichtsbehörde für den Finanzsektor. Im Kontext von DORA ist die BaFin die zuständige Behörde, die die Einhaltung der Verordnung durch Finanzunternehmen in Deutschland überwacht und Sanktionen verhängen kann.
Das dreistufige Modell, das OTTRIA verwendet, um die Absicherung der Open-Source-Lieferkette zu strukturieren. Layer 1 ist Sichtbarkeit (z.B. durch SCA-Tools und SBOM-Erstellung). Layer 2 ist Eingriff (Schwachstellen beheben, Patches erstellen, Upstream-Arbeit). Layer 3 ist Governance (auditfähige Dokumentation, Risikobewertung, Compliance-Nachweise). OTTRIA deckt Layer 2 und 3 ab, komplementär zu bestehenden Scanner-Lösungen.
Bundesamt für Sicherheit in der Informationstechnik. Die zuständige Behörde in Deutschland für die Umsetzung und Durchsetzung der NIS2-Richtlinie. Betroffene Unternehmen müssen sich beim BSI registrieren (Paragraph 33 Abs. 1 NIS2UmsuCG).
Ein Programm, bei dem Sicherheitsforscher eine finanzielle Belohnung erhalten, wenn sie Schwachstellen in Software verantwortungsvoll melden. OTTRIA finanziert Bug-Bounty-Programme für Open-Source-Projekte, die in den SBOMs der Kunden enthalten sind, und erhält als Sponsor die Meldungen direkt.
Konformitätskennzeichnung, die bestätigt, dass ein Produkt die grundlegenden Anforderungen der einschlägigen EU-Rechtsvorschriften erfüllt. Der CRA verlangt erstmals eine CE-Kennzeichnung für Software (Art. 29, 30 CRA). Open Source Stewards dürfen keine CE-Kennzeichnung anbringen (EWG 19 CRA).
Das Skalierungsprinzip von OTTRIA: Projekte, die in den SBOMs mehrerer Kunden auftauchen, werden gemeinsam betreut. Je mehr Kunden OTTRIA hat, desto besser die Abdeckung für alle, weil sich der Betreuungsaufwand auf mehrere Auftraggeber verteilt.
Cyber Resilience Act. Verordnung (EU) 2024/2847. Führt verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen ein, die in der EU auf den Markt gebracht werden. Zentrale Elemente: CE-Kennzeichnung für Software, SBOM-Pflicht, mindestens fünf Jahre Security-Support, 24-Stunden-Meldefristen bei Schwachstellen. Enthält die Definition des Verwalters quelloffener Software (Open Source Steward) in Art. 3 Nr. 14. Gilt direkt in allen EU-Mitgliedstaaten. Meldepflichten gelten ab 11. September 2026, vollständige Geltung ab 11. Dezember 2027.
Computer Security Incident Response Team. Im Kontext von NIS2 fungiert ein national benanntes CSIRT als Koordinator für die koordinierte Offenlegung von Schwachstellen (Art. 12 Abs. 1 NIS2). Das CSIRT vermittelt zwischen Schwachstellenmeldern und Herstellern und koordiniert die Offenlegung.
Common Vulnerabilities and Exposures. Ein standardisiertes System zur Identifizierung und Benennung öffentlich bekannter Sicherheitsschwachstellen in Software. Jede registrierte Schwachstelle erhält eine eindeutige CVE-Nummer. SCA-Tools prüfen Softwarekomponenten gegen CVE-Datenbanken. Auf jede registrierte CVE kommen durchschnittlich 4 bis 11 Silent Fixes, die in keiner Datenbank erfasst sind.
Directors and Officers. Bezeichnet die Haftpflichtversicherung für Geschäftsführer und Vorstände. D&O-Versicherungen schließen vorsätzliche Gesetzesverstoße typischerweise aus. Da DORA und NIS2 persönliche Pflichten der Geschäftsleitung verankern, kann Untätigkeit als Gesetzesverstoß gewertet werden, der nicht von der D&O-Police gedeckt ist.
Aufgeschobene Architektur- und Designentscheidungen in Software-Projekten, die zu einem wachsenden Sicherheitsrisiko führen. Beispiele: veraltete Kryptografie-Bibliotheken, unsichere Build-Systeme, nie umgesetzte API-Redesigns. Decision Debt ist gefährlicher als registrierte CVEs, weil es in keiner Datenbank erfasst ist und von keinem Scanner erkannt wird.
Datenschutz-Grundverordnung, Verordnung (EU) 2016/679. Seit dem 25. Mai 2018 unmittelbar geltendes Recht in allen Mitgliedstaaten. Für Open-Source-Governance besonders relevant sind die Grundsätze nach Art. 5 (Integrität und Vertraulichkeit, Rechenschaftspflicht), der Datenschutz durch Technikgestaltung nach Art. 25, die Sicherheit der Verarbeitung nach Art. 32 (Stand der Technik, Belastbarkeit "auf Dauer", regelmäßige Überprüfung), die 72-Stunden-Meldefrist nach Art. 33 und die Bußgeldbemessung nach Art. 83, die dokumentierte TOM nach Art. 25 und 32 ausdrücklich als mildernden Faktor berücksichtigt.
Digital Operational Resilience Act. Verordnung (EU) 2022/2554. Gilt seit Januar 2025 für 21 Kategorien von Finanzunternehmen und deren IKT-Drittdienstleister. Zentrale Anforderungen: IKT-Risikomanagement unter Vorstandsverantwortung, vollständiges IKT-Asset-Inventar, Open-Source-Analysen als ausdrückliche Pflicht-Testmethode (Art. 25 Abs. 1), persönliche Haftung des Leitungsorgans (Art. 5 Abs. 2a). Gilt direkt in allen EU-Mitgliedstaaten.
European Union Agency for Cybersecurity (Agentur der Europäischen Union für Cybersicherheit). Entwickelt und pflegt unter anderem die europäische Schwachstellendatenbank (Art. 12 Abs. 2 NIS2) und veröffentlicht Umsetzungsleitlinien zu NIS2, einschließlich konkreter Leitlinien zur Behandlung von Open-Source-Software.
Erwägungsgründe sind die einleitenden Abschnitte einer EU-Verordnung oder -Richtlinie, die die Ziele und den Kontext der einzelnen Regelungen erläutern. Sie sind nicht unmittelbar rechtsverbindlich, dienen aber der Auslegung der Gesetzesartikel. Auf dieser Website referenziert als "EWG" gefolgt von der Nummer, z.B. EWG 18-20 CRA zur Abgrenzung des Open-Source-Anwendungsbereichs.
Free and Open Source Software (freie und quelloffene Software). Der CRA definiert FOSS als Software, deren Quellcode offen geteilt wird und die unter einer kostenlosen Open-Source-Lizenz zur Verfügung steht (Art. 3 Nr. 48 CRA). Hersteller müssen bei der Integration von FOSS-Komponenten die gebotene Sorgfalt walten lassen (Art. 13 Abs. 5 CRA).
Informations- und Kommunikationstechnologie. Der zentrale Oberbegriff in DORA für alle IT-bezogenen Systeme, Dienste und Prozesse. DORA fordert unter anderem einen umfassenden IKT-Risikomanagementrahmen (Art. 6), die Inventarisierung aller IKT-Assets (Art. 8) und das Management von IKT-Drittparteienrisiken (Art. 28).
Internationaler Standard für Open-Source-Security-Assurance (ISO/IEC 18974:2023). Definiert 16 Kernanforderungen für ein Open-Source-Sicherheitsprogramm in den Bereichen Governance, Erkennung, Schwachstellenmanagement und SBOM-Pflege. Gilt als Referenz für den "Stand der Technik", auf den DORA (Art. 6 Abs. 2), NIS2 (Art. 21 Abs. 1) und der CRA (EWG 34) verweisen. Die Zertifizierung erfolgt über das OpenChain-Programm.
Netz- und Informationssicherheitsrichtlinie. Richtlinie (EU) 2022/2555. Betrifft Unternehmen in 18 Sektoren kritischer und wichtiger Infrastruktur. Zentrale Anforderung für die Open-Source-Lieferkette: Sicherheit der Lieferkette als Pflichtmaßnahme (Art. 21 Abs. 2 lit. d), einschließlich Bewertung der Schwachstellen und Entwicklungsprozesse unmittelbarer Anbieter (Art. 21 Abs. 3). Persönliche Haftung der Leitungsorgane (Art. 20 Abs. 1). Bußgeldrahmen: bis 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes für wesentliche Einrichtungen.
NIS-2-Umsetzungs- und Cybersicherheitsstaerkungsgesetz. Die deutsche nationale Umsetzung der NIS2-Richtlinie. Enthält unter anderem die persönliche Schadenshaftung der Geschäftsleitung (Paragraph 38 Abs. 2), eine dreistufige Kategorisierung (besonders wichtige Einrichtungen, wichtige Einrichtungen, Betreiber kritischer Anlagen) und die Registrierungspflicht beim BSI (Paragraph 33 Abs. 1).
Eine durch den CRA geschaffene neue Rechtskategorie. Definiert in Art. 3 Nr. 14 CRA als juristische Person, die kein Hersteller ist und die Entwicklung spezifischer Open-Source-Produkte, die für kommerzielle Tätigkeiten bestimmt sind, systematisch und nachhaltig unterstützt. Pflichten nach Art. 24 CRA: dokumentierte Cybersicherheitsstrategie, Schwachstellenmanagement, Zusammenarbeit mit Behörden, Meldepflichten. Stewards sind ausdrücklich von Bußgeldern ausgenommen (Art. 64 Abs. 10b CRA). OTTRIA registriert sich freiwillig als Open Source Steward.
Open Source Trust, Threat and Risk Intelligence Alliance. Ein europäischer Dienstleister für die Absicherung von Open-Source-Lieferketten. OTTRIA erstellt keine SBOMs, sondern wertet bestehende Software-Stücklisten aus und identifiziert darin Risiken, veraltete Komponenten und kritische Abhängigkeiten. OTTRIA registriert sich als Open Source Steward nach dem CRA und arbeitet aktiv in Open-Source-Projekten mit.
Richtlinie (EU) 2024/2853. Die neue EU-Produkthaftungsrichtlinie, die Software erstmals als Produkt im Sinne des Haftungsrechts definiert (Art. 4 Nr. 1). Zentrale Änderungen gegenüber der Vorgängerrichtlinie von 1985: Datenverlust als Haftungsgrund (Art. 6 Abs. 1 lit. c), Cybersicherheit als Fehlerkriterium (Art. 7 Abs. 2 lit. f), keine Obergrenze für die Gesamthaftung mehr (Art. 12), Beweislasterleichterung bei technischer Komplexität (Art. 10), Offenlegungspflicht für Beweismittel (Art. 9). Muss national umgesetzt werden.
Koordinierte Offenlegung von Schwachstellen. Ein Prozess, bei dem ein Sicherheitsforscher eine entdeckte Schwachstelle vertraulich an die Maintainer oder den Hersteller meldet und eine vereinbarte Frist abwartet, bevor die Schwachstelle öffentlich bekannt gemacht wird. Übliche Fristen sind 28, 30 oder 90 Tage. DORA fordert in Art. 14 Abs. 1 Kommunikationspläne für die verantwortungsbewusste Offenlegung. NIS2 regelt in Art. 12 die koordinierte Offenlegung auf EU-Ebene. Der CRA verlangt in Anhang I Teil II Nr. 5 eine koordinierte Schwachstellenoffenlegung.
Software Bill of Materials (Software-Stückliste). Ein maschinenlesbares Verzeichnis aller Komponenten, die in einem Softwareprodukt enthalten sind. Der CRA definiert die SBOM als "formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten" (Art. 3 Nr. 39). Die SBOM-Erstellung ist gesetzlich vorgeschrieben (CRA Anhang I Teil II Nr. 1, Art. 13 Abs. 24). Eine SBOM allein ist kein Sicherheitsinstrument, sondern ein Inventar, das kontinuierliche Bewertung und Pflege erfordert.
Software Composition Analysis. Werkzeuge, die Softwarekomponenten gegen Schwachstellendatenbanken (CVE, NVD, GitHub Security Advisories) prüfen. SCA- Tools finden nur registrierte, gemeldete Schwachstellen. Sie erkennen keine Silent Fixes, keine Decision Debt und keinen Projektverfall. SCA-Tools bilden Layer 1 (Sichtbarkeit) in der Betreuungspyramide.
Eine Sicherheitskorrektur, die in den Quellcode eines Open-Source-Projekts eingepflegt wird, ohne dass eine öffentliche Schwachstellenmeldung (CVE) erfolgt. Studien zeigen, dass auf jede registrierte CVE durchschnittlich 4 bis 11 Silent Fixes kommen. Silent Fixes sind für SCA-Tools unsichtbar, da sie in keiner Schwachstellendatenbank erfasst sind.
Threat-Led Penetration Testing (bedrohungsorientierte Penetrationstests). Von DORA vorgeschriebene Tests, die alle drei Jahre durchzuführen sind und auch IKT-Drittdienstleister einbeziehen müssen (Art. 26 DORA). TLPT simulieren realistische Angriffsszenarien auf Basis aktueller Bedrohungsinformationen.
Ein Regulierungsansatz, bei dem die Pflichten zur Risikokontrolle nicht nur die eigene Software umfassen, sondern den gesamten IT-Stack einschließlich aller Open-Source-Komponenten, transitiver Abhängigkeiten und der Dienste von IKT-Drittdienstleistern. DORA und NIS2 verfolgen diesen Ansatz (DORA Art. 28, NIS2 Art. 21 Abs. 2 lit. d, CRA Art. 13 Abs. 5).