Richtlinie zur Offenlegung von Sicherheitslücken (VDP)

 

1. Zweck

Die ImagineOn GmbH („wir") entwickelt die Coldwave-Familie industrieller IoT-Produkte und -Dienste (Firmware, Hardware, Cloud-Backend, Integrationen). Sicherheitsforschung und verantwortungsvolle Meldungen externer Parteien verbessern die Sicherheit dieser Produkte wesentlich. Diese Richtlinie beschreibt, wie Sie uns eine vermutete Sicherheitslücke melden können, was Sie im Gegenzug erwarten können und welchen rechtlichen Schutz wir gutgläubig handelnden Sicherheitsforschern gewähren.

Diese Richtlinie stellt eine öffentliche Verpflichtung dar gemäß:

• ETSI EN 303 645 §5.2 — Offenlegung von Sicherheitslücken für Verbraucher-IoT

• EN 18031-1 §5.10 [GEC-1] — Aktuelle Software ohne öffentlich bekannte ausnutzbare Sicherheitslücken

• EU Cyber Resilience Act (CRA), Verordnung (EU) 2024/2847, Artikel 13 — Herstellerpflichten im Umgang mit Sicherheitslücken

• ISO/IEC 29147 / 30111 — Branchenübliche Standardprozesse für die Offenlegung und Behandlung von Sicherheitslücken

 

2. Geltungsbereich

2.1 Im Geltungsbereich

Jedes von der ImagineOn GmbH unter der Marke Coldwave angebotene Produkt oder jede solche Dienstleistung, einschließlich, aber nicht beschränkt auf:

• Coldwave YUKI Block (industrielle IoT-Gateways, alle Hardware-Varianten und Firmware-Versionen, die sich noch im Support befinden)

• coldwave-os (RTOS-Bibliothek, die von Coldwave-Produkten und lizenzierten Integratoren verwendet wird)

• Coldwave Backend (Cloud-seitige Dienste, auf die Coldwave-Geräte und kundenseitige Portale unter *.coldwave.io zugreifen)

• Coldwave Mobil- und PC-Begleitanwendungen

• Dokumentation, Websites und APIs unter coldwave.io und *.coldwave.io

2.2 Nicht im Geltungsbereich

Die folgenden Punkte fallen nicht in den Geltungsbereich dieser Richtlinie. Meldungen hierzu sind willkommen, sollten jedoch an die jeweils genannte Stelle gerichtet werden:

• Upstream-Komponenten von Drittanbietern — Mobilfunkmodems (Quectel), MCU-Chips (Silicon Labs, Nordic, ST), Open-Source-Bibliotheken (mbedTLS, MCUboot, FreeRTOS, LwIP, BACnet-Stack, nanomodbus). Bitte direkt beim jeweiligen Upstream-Anbieter melden; wir koordinieren mit, sofern das Problem ein Coldwave-Produkt betrifft.

• Coldwave-Produkte, deren Lebensdauer abgelaufen ist (nach Ablauf des veröffentlichten Defined Support Period). Wir nehmen die Meldung entgegen und stellen einen Sicherheitshinweis bereit, verpflichten uns jedoch nicht zu einer Fehlerbehebung.

• Erkenntnisse, die physische Zerstörung erfordern, die Entfernung von EMV-/Manipulationssiegeln oder andere invasive Techniken, die in einem realen Einsatz nicht durchführbar wären.

• Volumetrische Denial-of-Service-Angriffe (Flooding auf Sicherungsschicht-Ebene, Mobilfunk-Jamming, Brute-Force-Authentifizierung unbegrenzter Dauer). DoS fällt nur dann in den Geltungsbereich, wenn ein Fehler auf Protokollebene mit geringem Volumen unverhältnismäßig große Auswirkungen verursacht.

• Social Engineering gegenüber Mitarbeitern, Partnern oder Kunden.

• Erkenntnisse zu allgemeinen Branchenpraktiken (z. B. „Modbus verfügt über keine Authentifizierung"), die keine Abweichung vom dokumentierten Produktverhalten oder keinen Verstoß gegen eine Coldwave-Zusage darstellen.

 

3. Wie Sie melden

3.1 Meldekanal

• E-Mail: security@coldwave.io

• security.txt:https://coldwave.io/.well-known/security.txt

• PGP: Verschlüsseln Sie Ihre Meldung mit unserem öffentlichen Schlüssel unter https://coldwave.io/.well-known/security-pgp-key.txt (auch auf keys.openpgp.org).
  Fingerabdruck: D556 1205 F2F1 AB1A B1FB 8D38 4D4F F926 70F8 CBAC — bitte vor der Verschlüsselung überprüfen.

• Sprachen: Deutsch und Englisch.

Für die Einreichung einer Meldung ist kein Konto und keine Geheimhaltungsvereinbarung (NDA) erforderlich. Wir akzeptieren anonyme Meldungen, können anonymen Meldenden jedoch keine Statusaktualisierungen zusenden.

3.2 Was Sie angeben sollten

Eine gute Meldung enthält ausreichend Details, damit wir das Problem reproduzieren, einstufen und beheben können. Bitte geben Sie Folgendes an:

1. Produkt und Version unter Test (Firmware-Version, Hardware-Revision, App-Version, Backend-Endpunkt).

2. Schritt-für-Schritt-Anleitung zur Reproduktion, idealerweise mit einem minimalen Proof-of-Concept.

3. Beobachtete Auswirkung — was ein Angreifer tun kann, unter welchen Voraussetzungen, gegen welchen Vermögenswert (Sensordaten, Zugangsdaten, Firmware-Integrität, Verfügbarkeit usw.).

4. Betroffene Schnittstelle — Mobilfunknetz, BLE, USB, Debug-Port, Web-/API-Endpunkt, Konfigurationskanal usw.

5. Ihre Einschätzung des Schweregrads (verwenden Sie nach Möglichkeit CVSS v3.1 oder v4.0; andernfalls genügt eine Beschreibung in Textform).

6. Etwaige mildernde Faktoren — erforderliche Positionierung, Konfiguration, Kontoebene.

7. Ob Sie die Veröffentlichung des Fundes beabsichtigen, sowie Ihren bevorzugten Zeitplan für die Offenlegung.

8. Wie Sie genannt werden möchten (echter Name, Pseudonym, anonym, Organisation) — siehe §7.

Sie müssen keine vollständige Ausnutzung nachweisen. Eine glaubwürdige technische Beschreibung ist ausreichend; bitte beschränken Sie sich auf einen Proof-of-Concept und exfiltrieren Sie keine Kundendaten.

 

4. Unsere Zusagen an Sie

Wir verpflichten uns zu den folgenden Service-Levels für Meldungen von Sicherheitslücken bei Produkten und Diensten im Geltungsbereich:

Schritt	Zusage
Empfangsbestätigung	innerhalb von 5 Werktagen nach Eingang der Meldung
Triage-Entscheidung (im Geltungsbereich, Schweregrad, angenommen/abgelehnt)	innerhalb von 15 Werktagen nach Empfangsbestätigung
Häufigkeit der Statusaktualisierungen	mindestens alle 30 Kalendertage, solange der Vorgang offen ist, oder früher bei wesentlichem Fortschritt
Fehlerbehebung oder dokumentierte Abhilfemaßnahme — Kritisch (CVSS ≥ 9,0)	angestrebte Veröffentlichung innerhalb von 30 Kalendertagen nach der Triage
Fehlerbehebung oder dokumentierte Abhilfemaßnahme — Hoch (CVSS 7,0–8,9)	angestrebte Veröffentlichung innerhalb von 90 Kalendertagen nach der Triage
Fehlerbehebung oder dokumentierte Abhilfemaßnahme — Mittel (CVSS 4,0–6,9)	angestrebte Veröffentlichung innerhalb von 180 Kalendertagen nach der Triage
Fehlerbehebung oder dokumentierte Abhilfemaßnahme — Niedrig (CVSS < 4,0)	enthalten in der nächsten regulären Veröffentlichung
Öffentlicher Sicherheitshinweis	veröffentlicht unter https://coldwave.io/security/advisoriesspätestens zum in §5 festgelegten Datum der öffentlichen Offenlegung
CVE-Zuweisung	wird bei der CNA of last resort (MITRE) beantragt für jede verifizierte Sicherheitslücke mit organisationsübergreifenden Auswirkungen

Ist ein Coldwave-Produkt in ein Drittsystem eines Kunden integriert und erfordert die Behebung eine Handlung des Kunden, stimmen wir die Offenlegung mit den betroffenen Kunden ab, bevor wir an die Öffentlichkeit gehen.

Bei aktiv ausgenutzten Sicherheitslücken, die ein auf dem EU-Markt bereitgestelltes Coldwave-Produkt betreffen, benachrichtigen wir zusätzlich ENISA und das zuständige CSIRT innerhalb der in Artikel 14 CRA vorgeschriebenen Fristen (spätestens 24 Stunden für eine Frühwarnung, 72 Stunden für eine Vorfallmeldung und 14 Tage für den Abschlussbericht).

 

5. Zeitplan der koordinierten Offenlegung

Standardmäßig gilt bei uns eine koordinierte Offenlegung mit einer 90-Tage-Frist bis zur öffentlichen Offenlegung, gerechnet ab dem Datum, an dem Sie eine glaubwürdige Meldung einreichen, verlängerbar im gegenseitigen Einvernehmen, wenn eine Fehlerbehebung in Arbeit und ein Veröffentlichungstermin absehbar ist. Konkret:

1. T+0 — Sie melden. Wir bestätigen den Empfang innerhalb von 5 Werktagen.

2. T+15 Werktage — Wir führen die Triage durch und vereinbaren schriftlich mit Ihnen den Schweregrad und das angestrebte Datum der Fehlerbehebung.

3. T+30 / 90 / 180 Tage (siehe Tabelle in §4) — Fehlerbehebung veröffentlicht oder dokumentierte Abhilfemaßnahme verteilt.

4. Öffentlicher Sicherheitshinweis, veröffentlicht zum Datum der Fehlerbehebung, oder spätestens T+90 Tage, falls keine Fehlerbehebung veröffentlicht wurde, es sei denn, Sie und wir haben etwas anderes vereinbart.

Wir werden kein zeitlich unbegrenztes Embargo verlangen. Dauert eine Fehlerbehebung länger als der Standardzeitraum (z. B. bei einer Hardwareänderung), stimmen wir gemeinsam mit Ihnen ein Veröffentlichungsdatum ab, statt um unbegrenztes Stillschweigen zu bitten.

Sie behalten das Recht, zum koordinierten Termin Ihren eigenen Bericht zu veröffentlichen. Wir bitten lediglich darum, Details zur Ausnutzung, die Endnutzer erheblich gefährden, so lange zurückzuhalten, bis Kunden ein angemessenes Zeitfenster für die Installation des Patches hatten.

 

6. Safe Harbor — autorisierte Sicherheitsforschung

Wir sichern den folgenden Schutz für gutgläubig durchgeführte Sicherheitsforschung an Produkten und Diensten im Geltungsbereich zu, sofern sie in Übereinstimmung mit dieser Richtlinie erfolgt:

• Kein rechtliches Vorgehen wegen des Zugriffs auf oder des Testens unserer Produkte und Dienste zu Zwecken der Sicherheitsforschung, sofern Sie:

  • gutgläubig handeln, mit der Absicht, eine Sicherheitslücke zu identifizieren und zu melden — nicht auszunutzen;

  • Verletzungen der Privatsphäre und Störungen der Dienste für andere Nutzer vermeiden;

  • keine Kundendaten exfiltrieren oder über das für den Nachweis einer Sicherheitslücke notwendige Minimum hinaus speichern;

  • Details einer ungepatchten Sicherheitslücke nicht vor dem in §5 koordinierten Termin öffentlich offenlegen;

  • die geltenden Gesetze des Landes einhalten, in dem die Forschung durchgeführt wird.

• Wir werden keine Umgehungsverbots-Ansprüche (z. B. nach nationalem Umsetzungsrecht der EU-Richtlinie 2001/29/EG) gegen Forschung geltend machen, die sich innerhalb der oben genannten Grenzen bewegt.

• Sollte Ihre Forschung diese Richtlinie versehentlich in geringfügiger Weise verletzen, arbeiten wir mit Ihnen zusammen, um die Konformität wiederherzustellen, bevor wir andere Maßnahmen in Erwägung ziehen.

Dieser Safe Harbor gilt ausschließlich für Forschung an Systemen und Produkten, die im Eigentum oder Betrieb der ImagineOn GmbH stehen. Wir können keinen Safe Harbor für Forschung an bei Kunden eingesetzten Systemen, Diensten Dritter oder Netzwerken gewähren, die anderen Parteien gehören — Ihre Forschung muss diese Grenzen respektieren.

 

7. Anerkennung

Mit Ihrer Erlaubnis veröffentlichen wir eine öffentliche Liste anerkannter Melder unter https://coldwave.io/security/hall-of-fame, sobald der entsprechende Sicherheitshinweis veröffentlicht ist. Sie können wählen zwischen:

• Echter Name und/oder Organisation

• Pseudonym / Alias

• Anonym (keine Namensnennung)

Derzeit betreiben wir kein kostenpflichtiges Bug-Bounty-Programm. Führt eine Meldung zu einem veröffentlichten Sicherheitshinweis, können wir nach eigenem Ermessen Folgendes anbieten:

• Ein schriftliches Anerkennungsschreiben, unterzeichnet von Product Security

• Merchandise-Artikel der Marke Coldwave

• Eine Referenz für Zwecke der Personalgewinnung im Sicherheitsbereich

Wir können künftig ein kostenpflichtiges Bounty-Programm einführen; jede Änderung wird über diese VDP und die security.txt bekannt gegeben.

 

8. Pflichten der meldenden Person

Mit der Einreichung einer Meldung im Rahmen dieser Richtlinie erklären Sie sich damit einverstanden:

• das Testen unverzüglich beim ersten Hinweis auf eine Sicherheitslücke einzustellen und diese zu melden; nicht zu weiterer Ausnutzung überzugehen.

• Handlungen zu vermeiden, die die Qualität des Coldwave-Dienstes für andere Kunden beeinträchtigen würden (Denial of Service, automatisierte Scanner gegen Produktivendpunkte usw.).

• nicht auf Kundendaten zuzugreifen, sie zu kopieren, zu verändern oder zu speichern; sollten Sie während des Testens unvermeidbar auf Kundendaten stoßen, melden Sie dies und unterstützen Sie uns bei der Bestätigung der Löschung.

• die Vertraulichkeit der Sicherheitslücke bis zum koordinierten Offenlegungstermin zu wahren.

• die geltenden Gesetze einzuhalten.

Wir behalten uns das Recht vor, eine Meldung abzulehnen, die diese Bedingungen nicht erfüllt, oder den Safe-Harbor-Schutz bei eindeutiger Bösgläubigkeit zu entziehen.

 

9. Meldungen außerhalb des Geltungsbereichs und Fehlalarme

Wir beantworten jede Meldung innerhalb der in §4 genannten Frist für die Empfangsbestätigung, einschließlich Meldungen, die wir als außerhalb des Geltungsbereichs, als Duplikat oder als Fehlalarm einstufen. Wird eine Meldung abgelehnt, teilen wir den Grund schriftlich mit.

 

10. Aktualisierungen dieser Richtlinie

Diese Richtlinie wird mindestens jährlich überprüft. Wesentliche Änderungen werden versioniert und unter der URL dieser Richtlinie veröffentlicht. Das Feld „Expires:" in der security.txt wird bei jeder Überprüfung aktualisiert.

Version	Datum	Änderung
1.0	20. Mai 2026	Erstveröffentlichung.

 

11. Kontakt

• Meldung: security@coldwave.io

• Fragen zur Richtlinie: gleiche Adresse

• Post (eingetragener Sitz): ImagineOn GmbH, Neusser Straße 27–29, 50670 Köln, Deutschland