Richtlinie zur koordinierten Offenlegung von Schwachstellen

Zweck

Bei Lunaris Digital Solutions ist Sicherheit ein Bestandteil davon, wie wir Software entwickeln und pflegen.

Wir begrüßen Meldungen von Sicherheitsforschenden, Nutzern, Kunden und Mitgliedern der Open-Source-Community, die potenzielle Sicherheitslücken in von Lunaris gepflegter Software erkennen.

Diese Richtlinie zur koordinierten Offenlegung von Schwachstellen beschreibt:

• welche Systeme und Projekte abgedeckt sind;
• wie eine potenzielle Schwachstelle gemeldet werden kann;
• welche Informationen uns bei der Untersuchung einer Meldung helfen;
• was Sicherheitsforschende von uns erwarten können;
• wie wir Behebung und Offenlegung koordinieren.

Unser Ziel ist es, Sicherheitslücken zu identifizieren, zu verstehen und zu beheben, dabei Nutzer zu schützen und Sicherheitsforschenden eine sichere und verantwortungsvolle Meldung ihrer Erkenntnisse zu ermöglichen.

Geltungsbereich

Diese Richtlinie gilt für Software und andere digitale Produkte, für deren Entwicklung oder Pflege die Lunaris Digital Solutions GmbH & Co. KG verantwortlich ist.

Dies umfasst insbesondere:

• von Lunaris gepflegte Open-Source-Software;
• Software-Repositorys, die unter der GitHub-Organisation Lunaris Digital Solutions GmbH & Co. KG unter https://github.com/lunarisdigitalsolutions gepflegt werden;
• offizielle Releases und unterstützte Versionen dieser Projekte;
• von Lunaris betriebene Online-Dienste, soweit diese Bestandteil eines Produkts oder Projekts von Lunaris sind.

Einzelne Repositorys können eine Datei SECURITY.mdenthalten, die unterstützte Versionen, projektspezifische Sicherheitsgrenzen oder zusätzliche Meldewege festlegt. Diese projektspezifischen Hinweise ergänzen diese Richtlinie.

Kundenprojekte

Software, Systeme oder Infrastruktur unserer Kunden fallen nicht automatisch in den Geltungsbereich dieser Richtlinie, auch wenn Lunaris an ihrer Entwicklung mitgewirkt hat.

Wenn Sie eine Schwachstelle in einem Kundensystem entdecken, führen Sie bitte keine weiteren Tests gegen dieses System durch. Kontaktieren Sie uns und stellen Sie ausreichend Informationen bereit, damit wir das betroffene System identifizieren können. Soweit angemessen, koordinieren wir uns mit der verantwortlichen Stelle.

Systeme Dritter

Von Dritten betriebene Dienste und Infrastrukturen, einschließlich GitHub selbst, liegen außerhalb unseres Autorisierungsbereichs. Schwachstellen in diesen Systemen sollten in der Regel direkt dem verantwortlichen Anbieter gemeldet werden.

Wenn eine Schwachstelle eines Drittanbieters jedoch ein von Lunaris gepflegtes Produkt betrifft, begrüßen wir Meldungen, die die möglichen Auswirkungen auf unsere Software erläutern.

Unser Reaktionsprozess

Nach Eingang einer Meldung wenden wir den folgenden Prozess an.

Eingangsbestätigung

Bei Meldungen mit einer nutzbaren Kontaktmöglichkeit bemühen wir uns um eine persönliche Eingangsbestätigung innerhalb von 5 Arbeitstagen.

Ersteinschätzung

Innerhalb von 10 Arbeitstagen bemühen wir uns, eine der folgenden Rückmeldungen zu geben:

• Bestätigung, dass wir die gemeldete Schwachstelle validiert haben;
• eine Erläuterung, dass wir das gemeldete Problem derzeit nicht als Sicherheitslücke einstufen;
• technische Rückfragen, die für die weitere Untersuchung erforderlich sind; oder
• eine Erläuterung, dass die Untersuchung mehr Zeit erfordert, und einen Termin für die nächste Rückmeldung.

Diese Zeiträume beschreiben unsere Kommunikationsziele. Sie sind keine Fristen für die Behebung.

Analyse und Priorisierung

Wir bewerten bestätigte Schwachstellen unter anderem anhand folgender Faktoren:

• technischer Schweregrad;
• Ausnutzbarkeit;
• betroffene Versionen und Nutzer;
• erforderliche Berechtigungen oder Zugriffe;
• Beeinträchtigung von Vertraulichkeit, Integrität oder Verfügbarkeit;
• Verfügbarkeit von Gegenmaßnahmen;
• Hinweise auf eine Ausnutzung;
• Auswirkungen auf nachgelagerte Projekte oder Nutzer.

Soweit hilfreich, können wir CVSS oder andere etablierte Bewertungsmethoden in diese Analyse einbeziehen. Ein numerischer Wert ersetzt nicht unsere Bewertung des tatsächlichen Produktkontexts.

Statusmeldungen

Bei einer noch nicht behobenen bestätigten Schwachstelle bemühen wir uns mindestens alle 30 Tage um eine Aktualisierung, sofern mit der meldenden Person kein anderer Kommunikationsrhythmus vereinbart wurde.

Behebung

Wir bemühen uns, bestätigte Schwachstellen ohne unangemessene Verzögerung und entsprechend dem von ihnen ausgehenden Risiko zu behandeln.

Je nach Schwachstelle kann die Behebung Folgendes umfassen:

• ein Softwareupdate;
• ein neues Release;
• eine Konfigurationsänderung;
• eine Umgehungslösung oder Gegenmaßnahme;
• aktualisierte Dokumentation;
• die Deaktivierung oder Entfernung einer betroffenen Funktion;
• Änderungen an einer vorgelagerten Abhängigkeit.

Wir versprechen nicht, dass jede Schwachstelle innerhalb einer festen Anzahl von Tagen vollständig behoben werden kann. Die Dauer hängt von Schweregrad, technischer Komplexität, Kompatibilitätsanforderungen, vorgelagerten Abhängigkeiten und dem durch die Behebung selbst entstehenden Risiko ab.

Bei kritischen oder bekanntermaßen aktiv ausgenutzten Schwachstellen können wir Behebung, Benachrichtigung und Offenlegung beschleunigen.

Koordinierte Offenlegung

Wir bevorzugen die Offenlegung einer bestätigten Schwachstelle zusammen mit einem Sicherheitsupdate, einer Gegenmaßnahme oder anderen Informationen, mit denen Nutzer sich schützen können.

Als allgemeines Ziel streben wir an, die öffentliche Offenlegung einer bestätigten Schwachstelle innerhalb von 90 Tagen zu koordinieren.

Der Zeitraum kann kürzer sein, wenn eine sofortige Offenlegung zum Schutz der Nutzer erforderlich ist, insbesondere bei Hinweisen auf eine aktive Ausnutzung.

Ein längerer Koordinationszeitraum kann angemessen sein, wenn:

• die Behebung erhebliche Architekturänderungen erfordert;
• ein vorgelagertes Projekt oder mehrere nachgelagerte Projekte betroffen sind;
• die Veröffentlichung von Details das Risiko für Nutzer vor Verfügbarkeit einer Gegenmaßnahme wesentlich erhöhen würde;
• eine koordinierte Offenlegung mit einem anderen Maintainer, Anbieter, CERT oder einer Behörde erforderlich ist.

Soweit möglich, besprechen wir wesentliche Änderungen des Offenlegungszeitplans mit der meldenden Person.

Das Fehlen einer vollständigen Korrektur bedeutet nicht automatisch, dass die Offenlegung unbegrenzt aufgeschoben wird. Soweit angemessen, können wir einen Sicherheitshinweis veröffentlichen, der Schwachstelle, betroffene Versionen, Risiken und verfügbare Gegenmaßnahmen beschreibt, auch wenn noch keine vollständige Behebung verfügbar ist.