DriveLock Blog | IT Sicherheit und Cyber Security

Wie melde ich eine Schwachstelle? Der vertrauensvolle Umgang mit kritischen Informationen.

Geschrieben von DriveLock | Nov 20, 2025 10:03:13 AM

Als Hersteller von Security-Software haben wir einen sehr hohen Anspruch an die Qualität unserer Lösung, um unseren Kunden die bestmögliche Sicherheit ihrer Systeme, Daten und digitalen Arbeitsplätze zu ermöglichen. Wie alle Software-Hersteller wissen aber auch wir, dass nur eines wirklich sicher ist: Software ohne Fehler und Schwachstellen gibt es nicht.

INHALT
  1. ÜBERBLICK ÜBER DIE GÄNGIGEN DISCLOSURE-MODELLE
  2. UNSERE ENTSCHEIDUNG: PRIVATE DISCLOSURE
  3. ABSCHLUSSGEDANKEN


Um so wichtiger ist es, dass Hersteller mit Schwachstellen verantwortungsbewusst und transparent umgehen. So haben sich verschiedene Modelle bzw. Vorgehensweisen zum Umgang mit Schwachstellen etabliert, die alle eine Gemeinsamkeit aufweisen: Sie berücksichtigen möglichst alle unterschiedlichen Auffassungen und Wünsche der beteiligten Parteien für eine maximal gemeinschaftliche Zusammenarbeit bei der Veröffentlichung von Schwachstellen.

Wir werden in diesen Blog-Artikel die gängigsten Modelle und deren Unterschiede genauer betrachten. Und wir klären, warum  DriveLock sich für ein ganz bestimmtes Modell entschieden hat. 

A. Überblick über die gängigen Disclosure-Modelle


Schwachstellen in Software können auf unterschiedliche Weisen entdeckt werden. Eine Möglichkeit, ist die Prüfung des Source-Codes schon während des Entwicklungsprozesses. Dies kann auf vielfältige Weise und zu unterschiedlichen Zeitpunkten erfolgen. Die Einhaltung entsprechender Verfahren zur sicheren Softwareentwicklung wird auch in gängigen Zertifizierungsprozessen, beispielsweise einem ISO 27001 Audit (Annex A, A.8.25-A.8.31) oder bei einer Common Criteria EAL3+ Zertifizierung, geprüft.

Eine weitere Quelle für das Auffinden von Schwachstellen sind Penetrationstests. Diese können sowohl durch den Hersteller (interne Quelle) als auch durch ein anderes Unternehmen (externe Quelle), welches das zu prüfendes Produkt einsetzt, beauftragt werden. In die Kategorie “externe Quelle” fallen auch Personen, die ohne expliziten Auftrag und mit unterschiedlicher Motivation nach Schwachstellen suchen, z. B. White Hacker.

Wenn eine Schwachstelle durch eine externe Quelle entdeckt wird, stellt sich die Frage, wie mit dieser Information umgegangen werden soll. Folgende drei Disclosure Modelle haben sich etabliert:

  • Full Disclosure Model: Hier veröffentlicht die Person/Organisation, die die Schwachstelle entdeckt hat, die genauen Details so bald wie möglich. 

  • Responsible Disclosure (oder Coordinated Disclosure) Model: Hier erfolgt die Meldung zunächst an den Hersteller. Nach der Verfügbarkeit eines Patches, spätestens aber nach Ablauf einer Frist werden alle Details zur Schwachstelle veröffentlicht – ggf. durch die Person/Organisation, die ursprünglich die Schwachstelle gefunden hat. 

  • Private Disclosure Model: Die Meldung der Schwachstelle erfolgt ausschließlich an den Hersteller. Dieser entscheidet sowohl über den Inhalt als auch den Zeitpunkt der Veröffentlichung – im besten Fall unter Berücksichtigung der Wünsche und Ziele der meldenden Person/Organisation. 

Immer wieder wird über den Sinn und die Verwendung dieser Modelle diskutiert und dabei auch emotional argumentiert. Jedes Modell hat seine Berechtigung und für die beteiligten Parteien positive wie negative Implikationen. Zu den Parteien, deren Bedürfnisse es bei der Veröffentlichung von Schwachstellen zu berücksichtigen gilt, gehören im Wesentlichen die Entdecker/Melder, das herstellende Unternehmen und die betroffenen Kunden.

Die nachfolgende Übersicht zeigt die Unterschiede der Modelle aus den jeweiligen Perspektiven dieser Parteien. 

Modell Melder Hersteller Kunde
Full Disclosure

Sofortige Transparenz über die Schwachstelle und öffentliche Anerkennung der eigenen Kompetenz.

Oft keine Kooperation mit dem Hersteller.

Risiko: Es besteht die Gefahr, Gesetze zu verletzen.  

 

Massiver Handlungsdruck für die schnellstmögliche Bereitstellung eines Patches. 

Risiko: Behebung hat Vorrang vor Qualitätssicherung und Einhaltung von Compliance-Vorgaben.

Schwachstelle ist öffentlich bekannt, kann aber noch nicht gepatcht werden.

Risiko: Es besteht die Gefahr, durch Exploits/das Ausnutzen der Schwachstelle Opfer von Datenverlust oder Datenmanipulation zu werden.  

Responsible Disclosure

Vertrauliche Meldung und Zusammenarbeit mit Hersteller möglich.

Transparenz über die Schwachstelle und öffentliche Anerkennung der eigenen Kompetenz bei Ablauf der Frist.

Risiko: Es besteht die Gefahr, Gesetze zu verletzen. 

Handlungsdruck, um Patch fristgerecht bereitzustellen. 

Risiko: Mögliche Vernachlässigung von Qualitätssicherung und Compliance-Regelungen. 

Schwachstelle ist noch nicht öffentlich bekannt. Systeme können idealerweise vor öffentlichem Bekanntwerden gepatcht werden.

Risiko: Es besteht die Gefahr, durch Exploits/das Ausnutzen der Schwachstelle Opfer von Datenverlust oder Datenmanipulation zu werden. 

 

Private Disclosure 

Transparenz über die Schwachstelle und öffentliche Anerkennung der eigenen Kompetenz erfolgt durch Hersteller über Bug Bounty oder explizite namentliche Nennung. Hersteller bestimmt den Zeitpunkt der Veröffentlichung.

Die Gefahr, Gesetze zu verletzten ist gering.

Schnellstmögliche Bereitstellung eines Patches unter Einhaltung aller Vorgaben hinsichtlich Qualitätssicherung und Compliance-Regelungen möglich.

Transparente Kommunikation gegenüber Kunden und abgestimmte Veröffentlichung von Details zur Schwachstelle erfolgt koordiniert.

Schwachstelle ist noch nicht öffentlich bekannt. Systeme können idealerweise vor öffentlichem Bekanntwerden gepatcht werden.

Die Installation des Patches kann risikobasiert und an die eigene Umgebung angepasst werden.

Dem Hersteller wird vertraut, dass er transparent mit Schwachstellen umgeht und proaktiv informiert.

Konflikt zwischen den Schutzzielen Vertraulichkeit/ Integrität und Verfügbarkeit unwahrscheinlich.

 

Es ist nachvollziehbar und verständlich, dass jede der drei beteiligten Parteien unterschiedliche Meinungen zu den einzelnen Modellen hat. Dazu sind die Interessen zu verschieden und es erscheint kaum möglich, alle gleichwertig zu würdigen.

B. Unsere Entscheidung: Private Disclosure


Als Softwarehersteller müssen wir diese unterschiedlichen Interessen berücksichtigen. Wir haben uns bewusst für eine Private Disclosure Policy entschieden und diese auf unserer Webseite veröffentlicht. Sie beschreibt transparent und verständlich, wie eine Kontaktaufnahme im Idealfall erfolgen sollte, welche Daten und Informationen wir für wichtig erachten, wie der Prozess nach der Meldung aussieht und welche Erwartungshaltung wir gegenüber dem Meldenden haben.

Wir würdigen vollumfänglich die vorangegangene Leistung zum Auffinden der Schwachstelle sowie den vertraulichen Umgang und die respektvolle Einhaltung unserer Policy.

Aus folgenden Gründen haben wir uns für das Private Disclosure Model entschieden:

  • Sobald die Details einer Schwachstelle öffentlich bekannt sind, können Angreifer diese gezielt ausnutzen. Private Disclosure minimiert das Risiko für unsere Kunden während des Zeitraums, in dem eine Schwachstelle ohne Patch existiert. Eine öffentliche Bekanntgabe ohne Patch setzt sie unnötig Risiken aus und kann im schlimmsten Fall auch zu rechtlichen Problemen und Klagen führen.

  • Komplexe Systeme erfordern gründliche Tests. Ein übereilter Patch kann neue Schwachstellen einführen. Wir sind uns der Komplexität und der Rahmenbedingungen unserer Kunden bewusst und verstehen, dass eine Verteilung von Software in großen Umgebungen eine große Herausforderung darstellt und Risiken birgt. 

  • In kritischen Infrastrukturen wie Energie, Gesundheit oder Finanzwesen kann eine öffentliche Meldung katastrophale Auswirkungen haben. Selbst gehärtete Systeme sind nicht fehlerfrei. Private Disclosure reduziert das Risiko von Angriffswellen gegen KRITIS-Betreiber und Einrichtungen mit besonderer Bedeutung für unser Land. 

  • Indem wir unsere Kunden zum Release-Zeitpunkt eines Patches öffentlich über Schwachstellen informieren, sorgen wir für das notwendige Maß an Transparenz. So schaffen wir die Voraussetzung dafür, dass unsere Kunden schnell und gewissenhaft auf die Bedrohung reagieren können. 

  • Das Private-Disclosure-Modell ermöglicht uns eine offene und vertrauliche Zusammenarbeit mit den meldenden Personen – egal, ob es sich dabei um Einzelpersonen oder Unternehmen/Organisationen handelt. Dies gilt von der initialen Kontaktaufnahme bis hin zur gemeinsam abgestimmten Veröffentlichung der Schwachstelle. 

Wir reagieren umgehend auf Probleme und Schwachstellen in unserer Software und berücksichtigen dabei die Anforderungen unserer Kunden, ihnen schnellstmöglich eine entsprechende Lösung zur Verfügung stellen.

C. Abschlussgedanken


Der vertrauensvolle Umgang mit Schwachstellen in Softwareprodukten ist für Hersteller und Kunden gleichermaßen herausfordernd. Auch für diejenigen, die Schwachstellen entdecken und melden, ist es nicht immer einfach. Es erfordert einen gegenseitigen respektvollen Umgang miteinander, der gegenseitiges Vertrauen verlangt.

Für welches Disclosure-Modell sich ein Unternehmen entscheidet, hängt von verschiedenen Rahmenbedingungen wie zum Beispiel dem eigenen Risikoprofil, den Kundeninteressen oder der eigenen Strategie ab. Zum gemeinschaftlichen Umgang gehört auch, diese Entscheidung zu respektieren.

Private Disclosure ist oft die sicherste Wahl für Kunden, wenn schnelle und koordinierte Patches verfügbar sind oder nachvollziehbare Gründe vorliegen, dass diese Patches nicht umgehend oder flächendeckend eingespielt werden können.

DriveLock hat sich bewusst für dieses Modell und diese Vorgehensweise entschieden. Die Rückmeldungen unserer Kunden zeigen uns, dass sie diese Entscheidung unterstützen. Private Disclosure ist ein kontrollierter Prozess, der uns ermöglicht, unsere Kunden in KRITIS- oder sicherheitsrelevanten Bereichen bestmöglich zu schützen. Die Kommunikation mit unseren Kunden über die Schwachstelle, deren Risikoeinstufung und den Patch findet gleichzeitig statt. Einer öffentlichen Bekanntgabe weiterer Details stimmen wir erst zu, nachdem alle Kunden eine angemessene Zeit für die Installation des Patches zur Verfügung hatten. Dies kann je nach Schwachstelle, Risikoeinstufung und betroffenen Unternehmen variieren.

Durch Künstliche Intelligenz werden nicht nur die Bedrohungen immer komplexer, die Häufigkeit entdeckter Schwachstellen und womöglich auch von Zero-Day-Exploits wird sehr wahrscheinlich steigen. Die Entscheidung für und die Umsetzung dieses Disclosure-Prozesses ist eine strategische Frage. Im Sinne unserer Kunden. Gerade in diesem Umfeld ist gegenseitiges Vertrauen wichtiger denn je.