CVD-Richtlinie – Coordinated Vulnerability Disclosure Policy

1. Präambel

1.1. Grundsätzliches

Diese Richtlinie beschreibt unseren Prozess für die Koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD). Sie legt fest, wie Schwachstellen gemeldet werden können, welche Fristen gelten und was Meldende von uns erwarten können.

Was Sie von uns erwarten können:

  • Wir behandeln jede Schwachstellenmeldung vertraulich.
  • Personenbezogene Daten geben wir nur mit Ihrer ausdrücklichen Zustimmung an Dritte weiter.
  • Wir bestätigen den Eingang Ihrer Meldung innerhalb einer festgelegten Frist und antworten innerhalb von 5 Werktagen.
  • Wir werden Ihnen als vetrauensvoller Ansprechpartner während des gesamten Prozesses zur Seite stehen.
  • Wir werden keine rechtlichen Schritte gegen Sie einleiten, solange die Bedingungen gemäß §6 der CVD-Richtlinie erfüllt sind.

Was wir von Ihnen erwarten:

  • Sie nutzen die gefundene Schwachstelle nicht missbräuchlich aus und richten keine Schäden über die Meldung hinaus an.
  • Sie führen keine Angriffe wie Social Engineering (z.B. Phishing), (Distributed) Denial-of-Service, Brute-Force-Angriffe oder physische Angriffe durch.
  • Sie manipulieren, kompromittieren oder verändern keine Systeme oder Daten Dritter.
  • Sie bieten keine Tools zur Schwachstellenausnutzung an.
  • Sie übermitteln keine Ergebnisse aus automatisierten Scans ohne erklärende Dokumentation – diese stellen keine gültigen Schwachstellenmeldungen dar.
  • Das Fehlen von Kontaktdaten verhindert die Bearbeitung nicht, kann aber die Priorisierung beeinflussen. Die Nutzung eines anonymen Meldekanals begründet für sich genommen nicht die Annahme fehlenden guten Glaubens.
  • Sie hinterlegen gültige Kontaktdaten (E-Mail-Adresse) oder nutzen einen geeigneten anonymen Meldekanal (z.B. Einmal-Mail-Adresse, verschlüsselter Kanal), damit wir bei Rückfragen mit Ihnen kommunizieren können.
  • Sie geben die Schwachstelle nicht vor der koordinierten Offenlegung an Dritte oder die Öffentlichkeit weiter.

Bei Nicht-Einhaltung dieser Erwartungen behalten wir uns vor, die weitere Bearbeitung im Rahmen des koordinierten Offenlegungsprozesses einzuschränken oder zu beenden. Unabhängig von der Einhaltung dieser Erwartungen werden eingehende Meldungen auf ihre Sicherheitsrelevanz geprüft. Auch bei formellen Verstößen erfolgt grundsätzlich innerhalb von 10 Werktagen eine erste Bewertung von Substanz und Schweregrad der gemeldeten Schwachstelle.

1.2. Definitionen

Werktage - Im Sinne dieser Richtlinie gelten als Werktage die Tage Montag bis Freitag, mit Ausnahme der gesetzlichen Feiertage im Sinne des jeweiligen Bundeslandes sowie des 24. und 31. Dezember. Maßgeblich ist der Sitz von DIAL GmbH. Fristen, die auf einen Samstag, Sonntag oder gesetzlichen Feiertag fallen, enden mit Ablauf des nächsten Werktags.

Schwachstelle - Eine Schwäche, Anfälligkeit oder Fehlfunktion eines Produkts mit digitalen Elementen, die bei einer Cyberbedrohung ausgenutzt werden kann.

Ausnutzbare Schwachstelle - Eine Schwachstelle, die von einem unbefugten Dritten unter praktischen Betriebsbedingungen wirksam genutzt werden kann.

Ausgenutzte Schwachstelle - Eine Schwachstelle, die von einem unbefugten Dritten in einem Produktivsystem ausgenutzt wird/wurde.


2. Geltungsbereich (Scope)

2.1 Abgedeckte Produkte und Dienste

Diese Richtlinie gilt für sämtliche Produkte mit digitalen Elementen, Software, Dienste und Systeme von DIAL GmbH, sofern in §2.2 nicht anders geregelt.

2.2 Nicht abgedeckte Produkte und Aktivitäten

Nicht abgedeckte Produkte und Komponenten

Folgende Produkte und Komponenten fallen nicht in den Geltungsbereich dieser Richtlinie:

  • End-of-Life-Versionen der Produkte

Nicht abgedeckte Aktivitäten

Folgende Aktivitäten sind nicht Gegenstand dieser Richtlinie und dürfen nicht durchgeführt werden:

  • Social Engineering (z. B. Phishing)
  • Physische Angriffe
  • (Distributed) Denial-of-Service (DoS/DDoS)
  • Brute-Force-Angriffe
  • Automatisierte Scans ohne erklärende Dokumentation

3. Meldung von Schwachstellen

3.1 Kontakt

Schwachstellenmeldungen senden Sie bitte an:

KanalDetails
PSIRT (Produktschwachstellen)psirt@dial.de
CSIRT (Infrastrukturschwachstellen)csirt@dial.de
OpenPGP-PSIRTURI: https://security.dial.de/psirt-pgp-key.asc Fingerprint: 8C29 895A 9F6B 1A11 7703 BDAD 7AC5 2306 FD2F FCF3
OpenPGP-CSIRTURI: https://security.dial.de/csirt-pgp-key.asc Fingerprint: 9B4E DB67 FAAD 0FF8 3D22 3566 67BE ECFF 8B4A 10EE
OpenPGP-security.txtURI: https://security.dial.de/.well-known/security-signature-pgp-key.asc Fingerprint: 1DED E1D8 A62D EF7D 771A B361 BE78 0C0B 1FA2 F791
security.txt (RFC 9116)https://security.dial.de/.well-known/security.txt – PGP-signiert, crawler-zugänglich

Wir empfehlen, Meldungen nach Möglichkeit PGP-verschlüsselt zu übermitteln. Alternativ kann unser Webformular unter /de/vulnerability-report-form.html genutzt werden.

Die Kommunikation erfolgt über die oben genannten Funktionsmailboxen. Die Bearbeitung erfolgt in deutscher oder englischer Sprache. Rückfragen zum Bearbeitungsstand Ihrer Meldung sind jederzeit willkommen – senden Sie hierzu eine E-Mail an die Funktionsmailbox mit Ihrer Incident-ID. Status-Updates erfolgen planmäßig mindestens alle 10 Werktage (§4). Kontaktoptionen (E-Mail-Adressen, PGP-Schlüssel, Webformular) werden regelmäßig auf Aktualität geprüft und vor Ablauf erneuert. Das Ablaufdatum ist in der security.txt (RFC 9116) ersichtlich.

3.2 Erwartete Informationen

Um eine effiziente Bearbeitung zu ermöglichen, bitten wir um folgende Angaben. Je ausführlicher Ihre Meldung ist, desto schneller können wir die Schwachstelle nachvollziehen und beheben:

  • Bezeichnung der Schwachstelle – ggf. mit Verweis auf die CWE (Schwachstellentyp) und/oder einen konkreten Identifier wie CVE, OSV oder GHSA, falls die Schwachstelle bereits bekannt ist.
  • Betroffenes Produkt / Komponente mit genauer Versionsnummer
  • Umfassende Beschreibung der Schwachstelle inkl. technischer Details
  • Schritt-für-Schritt-Anleitung zur Reproduktion
  • Proof-of-Concept (PoC) (Code, Screenshots, Netzwerk-Traces)
  • Einschätzung des Schweregrads (niedrig / mittel / hoch / kritisch) – optional; die finale Bewertung erfolgt durch unser Sicherheitsteam
  • Einschätzung der möglichen Auswirkungen
  • Kontaktdaten für Rückfragen (optional; anonyme Meldung möglich – anonyme Meldungen werden nach denselben Kriterien geprüft wie nicht-anonyme Meldungen; eine Rückkopplung ist jedoch nur möglich, wenn ein geeigneter anonymer Kommunikationsweg angegeben wird)

3.3 Vertraulichkeit

Wir behandeln jede Meldung im rechtlich zulässigen Umfang vertraulich. Personenbezogene Daten werden nur mit ausdrücklicher Zustimmung an Dritte weitergegeben, sofern nicht gesetzliche Meldepflichten (z. B. CRA Art. 14, DSGVO Art. 33) dem entgegenstehen. Insbesondere sind wir bei aktiv ausgenutzten Schwachstellen gesetzlich verpflichtet, diese unverzüglich an das zuständige CSIRT und die ENISA zu melden (CRA Art. 14). Dies kann im Einzelfall die Weitergabe von Informationen zur Schwachstelle, nicht aber von personenbezogenen Daten über das erforderliche Maß hinaus, umfassen. Die Meldung an das zuständige nationale CSIRT (CERT-Bund) bleibt hiervon unberührt.

Für den Fall, dass Sie personenbezogene Daten angegeben haben, beachten Sie bitte die Hinweise zum Datenschutz: /de/cvd-privacy-information.html


4. Prozessablauf

Nach Eingang einer Meldung durchläuft diese folgenden Prozess:

SchrittBeschreibung
1. Einfache AntwortAutomatisierte Bestätigung bei Eingang (PGP-signierte Quittung auf Wunsch) – innerhalb von 24 Stunden. Detaillierte Antwort innerhalb von 5 Werktagen.
2. Detaillierte RückmeldungInnerhalb von 10 Werktagen erfolgt eine detaillierte Rückmeldung mit Bestätigung oder Ablehnung, Rückfragen oder einer Verzögerungserklärung.
3. AnalyseUnser Sicherheitsteam analysiert die Schwachstelle und erarbeitet eine Lösung.
4. Fix-EntwicklungWir entwickeln, testen und bereiten ein Sicherheitsupdate oder eine Mitigationsmaßnahme vor.
5. Koordinierte OffenlegungNach Bereitstellung des Fixes erfolgt die koordinierte Veröffentlichung. Der Melder wird vorab informiert.

4.1 Status-Updates

Wir informieren den Melder während des gesamten Prozesses mindestens alle 10 Werktage über den aktuellen Bearbeitungsstand. Sofern kein Kontakt gewünscht oder möglich ist (anonyme Meldung), erfolgen keine Updates.

4.2 Kein Single-Analyst-Close

Meldungen können nicht von einer Einzelperson geschlossen werden. Jede Schließung erfordert die Freigabe durch eine zweite berechtigte Person, um das Übersehen gültiger Schwachstellen zu vermeiden.


5. Fristen

5.1 Behebungsfristen nach Schweregrad

Die angestrebten Behebungszeiten richten sich nach dem Schweregrad der Schwachstelle. Die finale Einstufung erfolgt durch unser Sicherheitsteam:

SchweregradKriteriumZiel-Behebungszeit
KritischRemote Code Execution, Authentifizierungsumgehung, vollständiger Datenverlust ohne Benutzerinteraktion≤ 30 Tage – vollständiger Patch; bei aktiv ausgenutzten Schwachstellen erfolgt die Behebung unverzüglich (Art. 14 CRA)
HochZugriff auf sensitive Daten, eingeschränkte Code-Ausführung, laterale Bewegung möglich60 Tage
MittelDatenleckage, Sicherheitsumgehung mit Benutzerinteraktion, eingeschränkter Zugriff90 Tage
NiedrigInformationsoffenlegung ohne sensitiven Bezug, theoretische RisikenNächstes reguläres Release, maximal 180 Tage

5.2 Offenlegungsfrist

Validierte und verifizierte Schwachstellen werden innerhalb von 90 Tagen öffentlich bekannt gegeben. Der Melder wird vor der Veröffentlichung informiert. Advisories werden mindestens auf unserer Security-Seite veröffentlicht: /de/security-advisories.html . Die Veröffentlichung erfolgt ggf. zusätzlich in der Europäischen Schwachstellendatenbank (EUVD).

5.3 Verlängerung

Fristverlängerungen sind in beidseitigem Einvernehmen möglich, insbesondere bei komplexen Schwachstellen oder produktspezifischen Besonderheiten. Die Kommunikation hierzu erfolgt direkt mit dem Melder.

5.4 Ende des CVD-Prozesses

Der CVD-Prozess gilt als abgeschlossen, wenn einer der folgenden Fälle eintritt:

  • Die Schwachstelle wurde behoben und koordiniert veröffentlicht (Security Advisory, ggf. EUVD/CVE-Eintrag).
  • Die Meldung wurde nach Prüfung als ungültig eingestuft (z. B. kein sicherheitsrelevantes Produktverhalten, kein reproduzierbarer Proof-of-Concept).
  • Der Melder reagiert 30 Kalendertage nicht auf sachlich notwendige Rückfragen zur Reproduktion oder Validierung der Schwachstelle (z. B. fehlende Versionsangabe, unvollständiger PoC) – die Meldung gilt dann als gegenstandslos. Die Frist beginnt mit Zugang der letzten sachlich notwendigen Rückfrage beim Melder.
  • Die Schwachstelle wurde öffentlich bekannt gemacht und – in Abstimmung mit dem zuständigen nationalen CSIRT – nicht mehr davon ausgegangen werden kann, dass die Schwachstelle entschärft oder behoben wird.

In allen Fällen wird der Abschluss dokumentiert und der meldenden Person mitgeteilt, sofern ein Kontakt besteht. Eine erneute Kontaktaufnahme durch den Melder nach Eintritt der Gegenstandslosigkeit wird als neue Meldung behandelt, sofern die Schwachstelle zu diesem Zeitpunkt noch nicht behoben wurde.

Bei Überschreitung der Behebungsfrist aus §5.1 der CVD-Richtlinie um mehr als 50 % wird der Melder hierüber informiert und es wird gemeinsam eine angemessene Verlängerung gemäß §5.3 vereinbart.


6. Safe Harbor (Rechtssicherheit)

Wir werden keine rechtlichen Schritte gegen Meldende einleiten, sofern:

  • Die Meldung im Rahmen dieser Richtlinie erfolgt.
  • Die Schwachstelle nicht missbräuchlich ausgenutzt wurde.
  • Keine Daten über das zur Validierung der Schwachstelle notwendige Maß hinaus ausgelesen, manipuliert, heruntergeladen oder gelöscht wurden – der Zugriff auf eigene Testdaten des Meldenden zur Proof-of-Concept-Erstellung bleibt hiervon unberührt.
  • Keine Schäden über die gemeldete Schwachstelle hinaus verursacht wurden.
  • Keine Angriffe gegen Dritte oder unsere Infrastruktur durchgeführt wurden.
  • Die gefundene Schwachstelle nicht vor der koordinierten Offenlegung an Dritte oder die Öffentlichkeit weitergegeben wurde.
  • Die meldende Person kein NDA (Non-Disclosure Agreement) als Bedingung für die Meldung voraussetzt.

Eine unbeabsichtigte Überschreitung der zur Validierung erforderlichen Maßnahmen führt nicht zum Verlust des Safe Harbor, sofern der Melder in gutem Glauben gehandelt hat, keine Daten über das notwendige Maß hinaus extrahiert oder an Dritte weitergegeben wurden und keine Schädigungsabsicht erkennbar ist. Dies gilt nicht bei erkennbar kriminellen Absichten oder vorsätzlicher Schädigung.


7. Inkrafttreten

Diese Richtlinie tritt mit 11.09.2026 in Kraft und gilt für unbestimmte Zeit.

Anhang 1 - Versionshistorie

Diese Richtlinie wird bei Bedarf aktualisiert und an neue gesetzliche Anforderungen (z.B. CRA, NIS-2, BSI TR-03183-3) angepasst. Sie wird mindestens jährlich auf Aktualität geprüft. Die aktuelle Version ist unter der security.txt sowie auf unserer Website einsehbar.

VersionDatumÄnderung
1.028.08.2026Erstveröffentlichung

Anhang 2 - Beispiele

Im Scope (beispielhafte Schwachstellentypen):

  • Ausnutzbare Pufferüberläufe, Injection-Schwachstellen (SQL, OS-Command, LDAP)
  • Fehler in der Authentifizierung oder Autorisierung
  • Unsichere Datenhaltung (z. B. Klartext-Passwörter in Logs)
  • Side-Channel-Angriffe
  • Sicherheitslücken in API-Endpunkten (z. B. fehlendes Rate-Limiting mit Abfluss von Transaktionsdaten)

Nicht als ausnutzbare Schwachstelle gelten:

  • Ergebnisse aus automatisierten Scans ohne validierte Analyse,
  • Konfigurationsschwächen ohne sicherheitsrelevante Auswirkungen,
  • Fehlfunktionen, die keine sicherheitsrelevante Bedrohung darstellen.
  • Self-XSS (Ausnutzung nur durch den Angreifer selbst)
  • Fehlende Security Header außerhalb kritischer APIs
  • Theoretische oder nicht reproduzierbare Risiken
  • Bestehende öffentliche Schwachstellen, die bereits vollständig und nachweislich behoben wurden

Vielen Dank, dass Sie dazu beitragen, unsere Produkte sicherer zu machen.