Cybersicherheitsrichtlinie für Open-Source-Software einrichten und dokumentieren
- Gilt für
- Open-source steward
- Quellenangaben
- Art. 24(1)
- Produktklassen
- DefaultImportant — Class IImportant — Class IICritical
Einfache Sprache
Als OSS-Betreiber ist eine schriftliche Cybersicherheitsrichtlinie erforderlich, die beschreibt, wie das Projekt sichere Software entwickelt und wie Sicherheits- schwachstellen bei ihrer Entdeckung behandelt werden. Diese muss kein unternehmenstypisches Compliance-Dokument sein – eine SECURITY.md-Datei, eine Projekt-Sicherheitsrichtlinie oder Ähnliches genügt –, muss jedoch existieren und dokumentiert sein. Die Richtlinie muss sowohl sichere Entwicklungspraktiken als auch die Schwachstellenbehandlung abdecken.
Rechtstext
Artikel 24(1) der Verordnung (EU) 2024/2847 bestimmt, dass Betreiber von Open-Source-Software eine Cybersicherheitsrichtlinie einrichten und dokumentieren müssen, die die Entwicklung eines sicheren Produkts mit digitalen Elementen – einschließlich der von ihnen bereitgestellten Open-Source-Software-Komponenten – fördert und eine effektive Behandlung von Schwachstellen gemäß dem auf sie anwendbaren Artikel 13(6) ermöglicht.
Die Cybersicherheitsrichtlinie muss mindestens Folgendes abdecken:
- die auf die Open-Source-Software angewendeten sicheren Entwicklungspraktiken;
- den Prozess der Schwachstellenbehandlung einschließlich koordinierter Offenlegung.
Wesentliche Anforderungen
- Schriftliche Richtlinie – muss dokumentiert sein (nicht nur als informelle Praxis vorhanden)
- Sichere Entwicklung – Richtlinie beschreibt, wie Sicherheit bei der Entwicklung der OSS-Komponente berücksichtigt wird
- Schwachstellenbehandlung – Richtlinie beschreibt, wie Schwachstellen entgegengenommen, triagiert, behoben und offengelegt werden
- Koordinierter Offenlegungsprozess – klar verständlicher Prozess für Sicherheitsforschende und Nutzer zur Meldung von Schwachstellen (z. B. SECURITY.md, Richtlinie zur Schwachstellenoffenlegung)
- Aktuell gehalten – die Richtlinie soll mit dem Projekt und der Bedrohungslandschaft weiterentwickelt werden
Nachweise, die Sie möglicherweise benötigen
- Veröffentlichtes Sicherheitsrichtliniendokument (z. B. SECURITY.md im Quell-Repository)
- Richtlinie zur Schwachstellenoffenlegung oder Prozess zur koordinierten Offenlegung
- Referenzierte oder angewendete sichere Entwicklungsrichtlinien des Projekts
- Nachweis, dass die Richtlinie aktiv befolgt wird (z. B. behobene CVEs über den Offenlegungsprozess)