Richtlinie zur koordinierten Offenlegung von Schwachstellen

Die Sicherheit unserer Produkte ist fester Bestandteil unserer Produktqualität. So sorgfältig Software und Hardware auch entwickelt werden – Schwachstellen lassen sich nie vollständig ausschließen. Rommelag SE & Co. KG begrüßt deshalb ausdrücklich Hinweise von Sicherheitsforscherinnen und Sicherheitsforschern, Kundinnen und Kunden, Partnern sowie der Allgemeinheit.

Diese Richtlinie beschreibt unseren Prozess zur koordinierten Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD): die abgestimmte Bearbeitung und Veröffentlichung von Sicherheitslücken. Sie wird gemäß den Anforderungen der Verordnung (EU) 2024/2847 (Cyber Resilience Act, CRA), Anhang I Teil II, veröffentlicht und orientiert sich an den internationalen Normen ISO/IEC 29147 (Vulnerability disclosure) und ISO/IEC 30111 (Vulnerability handling processes).

Wir verpflichten uns dazu,

• jede Meldung ernst zu nehmen, vertraulich zu behandeln und kostenfrei zu bearbeiten;
• keine rechtlichen oder geschäftlichen Schritte gegen Meldende einzuleiten, die sich an diese Richtlinie halten;
• Meldende über den Fortschritt ihrer Meldung auf dem Laufenden zu halten;
• bestätigte Schwachstellen in einem angemessenen, risikoorientierten Zeitrahmen zu beheben;
• für Schwachstellen, die Handlungsbedarf bei unseren Nutzenden auslösen, ein Security Advisory zu veröffentlichen.

Wir bitten Sie, bei Ihrer Untersuchung und Meldung die folgenden Regeln einzuhalten. Sie schützen unsere Kundschaft, deren Daten – und Sie selbst.

• Keinen Schaden anrichten. Beeinträchtigen, unterbrechen oder zerstören Sie weder die Verfügbarkeit noch die Integrität oder Vertraulichkeit unserer Systeme, Dienste und Daten.
• So wenig Zugriff wie nötig. Beenden Sie den Test, sobald die Schwachstelle bestätigt ist. Dringen Sie nicht weiter in das System vor, weiten Sie Berechtigungen nicht über das für den Nachweis Erforderliche aus, und richten Sie keine dauerhaften Zugänge ein.
• Personenbezogene Daten schützen. Greifen Sie nicht auf personenbezogene Daten oder Kundendaten zu, kopieren, verändern, speichern oder veröffentlichen Sie diese nicht. Sollten Sie versehentlich auf solche Daten stoßen, brechen Sie sofort ab, weisen Sie uns in Ihrer Meldung darauf hin und löschen Sie alle Kopien.
• Eigene Testdaten verwenden. Nutzen Sie nach Möglichkeit Konten, Geräte und Daten, die Ihnen gehören oder die wir Ihnen zu Testzwecken bereitstellen.
• Keine störenden Tests. Keine Denial-of-Service- oder Lasttests, kein Spamming, keine Brute-Force-Angriffe gegen Produktivsysteme, kein automatisiertes Massen-Scanning.
• Keine Dritten einbeziehen. Kein Social Engineering und keine physischen Zutrittsversuche gegenüber Beschäftigten, Kundschaft, Lieferanten oder Dienstleistern.
• Keine Erpressung. Meldungen, die mit einer Zahlungsforderung, einer Zahlungsfrist oder der Androhung einer Veröffentlichung als Druckmittel verbunden sind, behandeln wir als Erpressung und nicht als Sicherheitsmeldung.
• Vertraulichkeit bis zur Abstimmung. Geben Sie die Schwachstelle nicht an Dritte oder die Öffentlichkeit weiter, bevor der in Abschnitt 6 beschriebene Abstimmungsprozess abgeschlossen ist.
• Recht einhalten. Bewegen Sie sich jederzeit im Rahmen der geltenden Gesetze.

4.2 Was Ihre Meldung enthalten sollte

Je präziser Ihre Meldung ist, desto schneller können wir nachvollziehen und beheben. Hilfreich sind:

• betroffenes Produkt, genaue Version bzw. Firmware-Stand und betroffene Komponente;
• Konfiguration und Umgebung, in der Sie das Problem beobachtet haben;
• Art der Schwachstelle (z. B. CWE-Klasse) und technische Beschreibung;
• Schritt-für-Schritt-Beschreibung, mit der wir das Problem reproduzieren können;
• Proof of Concept: Request/Response-Beispiele, Logauszüge, Screenshots, Skripte oder ein kurzes Video;
• Ihre Einschätzung der Auswirkungen und – falls vorhanden – ein CVSS-v3.1- oder v4.0-Vektor;
• Voraussetzungen für die Ausnutzung (Netzwerkposition, Authentifizierung, Nutzerinteraktion);
• ob die Schwachstelle bereits öffentlich bekannt ist oder aktiv ausgenutzt wird;
• ob Sie sie bereits einer anderen Stelle gemeldet haben (z. B. einem CERT/CSIRT oder einem Koordinator);
• ein von Ihnen geplantes Veröffentlichungsdatum sowie Ihr Wunsch zur Nennung als Meldende bzw. Meldender;
• Kontaktdaten für Rückfragen.

• Wir veröffentlichen ein Advisory, sobald eine Korrektur oder eine wirksame Gegenmaßnahme verfügbar ist. Unser Standard-Abstimmungsfenster beträgt 90 Tage ab Bestätigung des Eingangs.
• Können wir dieses Fenster nicht einhalten, treten wir auf Sie zu und schlagen Ihnen begründet einen neuen Termin vor. Wir bitten Sie, eine angemessene Verlängerung zu erwägen, wenn die technische Komplexität dies rechtfertigt.
• Wird eine Schwachstelle bereits aktiv ausgenutzt oder von dritter Seite veröffentlicht, können wir früher veröffentlichen – auch vor Verfügbarkeit einer vollständigen Korrektur –, um unseren Nutzenden Schutzmaßnahmen zu ermöglichen.
• Nach Veröffentlichung des Advisory steht es Ihnen frei, eine eigene Veröffentlichung vorzunehmen. Gern prüfen wir vorab einen Entwurf auf sachliche Richtigkeit. Wir bitten Sie, keine Kundendaten und keine Details aufzunehmen, die Angriffe auf noch ungepatchte Installationen ermöglichen.
• Wir veröffentlichen Advisories neben der menschenlesbaren Fassung in einem maschinenlesbaren Format (CSAF 2.0) und verweisen über unsere SBOM sowie gegebenenfalls über ein VEX-Statement auf die betroffenen Komponenten.

6.1 CVE-Kennungen

Für Schwachstellen in unseren Produkten beantragen wir eine CVE-Kennung über das CVE-Programm und führen sie im Advisory auf. Sollten Sie für den Befund bereits eine CVE-ID erhalten haben, nennen Sie diese bitte in Ihrer Meldung, damit wir Doppelvergaben vermeiden.

6.2 Nennung

Wir nennen Sie im Advisory gern mit Namen, Pseudonym, Organisation und Link – genau so, wie Sie es wünschen. Teilen Sie uns Ihre Präferenz in der Meldung mit; möchten Sie anonym bleiben, nennen wir Sie nicht. Rommelag SE & Co. KG betreibt derzeit kein bezahltes Bug-Bounty-Programm; eine finanzielle Vergütung für Meldungen bieten wir nicht an.

Rommelag SE & Co. KG betrachtet Sicherheitsforschung, die in gutem Glauben und im Einklang mit dieser Richtlinie erfolgt, als autorisierten Beitrag zur Sicherheit unserer Produkte – nicht als Angriff.

Wenn Sie sich an diese Richtlinie halten, insbesondere an die Spielregeln in Abschnitt 3, dann wird Rommelag SE & Co. KG

• keine zivil- oder strafrechtlichen Schritte gegen Sie im Zusammenhang mit Ihrer Untersuchung und Ihrer Meldung einleiten oder unterstützen;
• keine Ansprüche aus Urheberrecht, Wettbewerbsrecht oder unseren Nutzungsbedingungen gegen Sie geltend machen, soweit die Handlungen für die Untersuchung erforderlich waren;
• Ihre Tätigkeit als berechtigten Zugang im Sinne der einschlägigen Vorschriften zum Ausspähen und Abfangen von Daten (§§ 202a ff. StGB) betrachten;
• gegenüber Dritten, die dennoch Verfahren gegen Sie einleiten, klarstellen, dass Ihre Tätigkeit von dieser Richtlinie gedeckt war, soweit uns dies rechtlich möglich ist.

Diese Zusage bindet ausschließlich Rommelag SE & Co. KG. Sie kann Dritte – etwa unsere Kundschaft, Hosting-Anbieter oder Behörden – nicht binden und gilt nicht für Handlungen, die über diese Richtlinie hinausgehen. Wenn Sie unsicher sind, ob ein bestimmter Test gedeckt ist, sprechen Sie uns vorab unter psirt@rommelag.com an. Wir beantworten solche Fragen kurzfristig und im Sinne der Sache.

Unsere Produkte enthalten Fremd- und Open-Source-Komponenten. Wenn Sie eine Schwachstelle in einer solchen Komponente melden,

• prüfen wir, ob und wie die Schwachstelle in unserem Produkt ausnutzbar ist, und stellen eine aktualisierte oder gepatchte Komponente bereit;
• leiten wir die Meldung an die Upstream-Maintainer bzw. den Hersteller weiter, sofern sie dort noch nicht bekannt ist, und stimmen die Veröffentlichung mit ihnen ab – Ihren Namen nennen wir gegenüber Upstream nur mit Ihrem Einverständnis;
• dokumentieren wir in unseren Advisories und VEX-Statements, welche Komponenten betroffen und welche in unserem Produkt nicht ausnutzbar sind.

Finden Sie eine Schwachstelle in einem von Rommelag SE & Co. KG gepflegten Open-Source-Projekt, gilt diese Richtlinie ebenfalls.