{"id":10664,"date":"2026-07-03T13:28:04","date_gmt":"2026-07-03T11:28:04","guid":{"rendered":"https:\/\/erminas.com\/?p=10664"},"modified":"2026-07-03T13:28:31","modified_gmt":"2026-07-03T11:28:31","slug":"cvd-so-gehen-sie-professionell-mit-sicherheitsluecken-um","status":"publish","type":"post","link":"https:\/\/erminas.com\/de\/blog\/cvd-so-gehen-sie-professionell-mit-sicherheitsluecken-um\/","title":{"rendered":"CVD: So gehen Sie professionell mit Sicherheitsl\u00fccken um"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Sicherheitsl\u00fccken lassen sich nie vollst\u00e4ndig vermeiden. Das gilt f\u00fcr Webanwendungen ebenso wie f\u00fcr vernetzte Ger\u00e4te, APIs, Cloud-Dienste, IoT-Plattformen oder Gateways. Entscheidend ist deshalb nicht nur, wie sicher Systeme entwickelt werden, sondern auch, wie ein Unternehmen reagiert, wenn eine Schwachstelle entdeckt wird. Genau hier setzt ein professioneller CVD-Prozess<\/strong> an.<\/p>

Unter Coordinated-Vulnerability-Disclosure (CVD) versteht man den systematischen und koordinierten Umgang mit gemeldeten Sicherheitsl\u00fccken. F\u00fcr ein Unternehmen hei\u00dft das konkret, einen transparenten Kanal bereitzustellen, \u00fcber den externe Entdecker Schwachstellen melden k\u00f6nnen. Intern folgen daraufhin vordefinierte Prozesse, um diese Meldungen zu pr\u00fcfen, zu priorisieren, zu beheben und entsprechend dar\u00fcber zu kommunizieren.<\/p>

Gerade in der IoT-Sicherheit spielt CVD eine tragende Rolle. Da Schwachstellen hier meist nicht auf eine einzelne Anwendung beschr\u00e4nkt sind, betreffen sie oft komplexe \u00d6kosysteme: Ger\u00e4te im Einsatz, Schnittstellen, Backend-Systeme, Portale sowie Integrationen von Drittanbietern. Ein verl\u00e4sslicher, strukturierter Umgang mit solchen L\u00fccken ist deshalb das Fundament einer jeden modernen Sicherheitsorganisation.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Was ein CVD Prozess leistet\n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Ein CVD-Prozess<\/strong> sorgt daf\u00fcr, dass eine gemeldete Schwachstelle nicht irgendwo im Unternehmen versandet, sondern strukturiert bearbeitet wird. Im Idealfall meldet eine entdeckende Person das Problem vertraulich an das betroffene Unternehmen, \u00fcber einen transparenten, aber sicheren Kanal. Dort wird die Meldung gepr\u00fcft, technisch eingeordnet und priorisiert. Danach folgen Bewertung, Behebung und \u2014 falls sinnvoll \u2014 eine koordinierte Ver\u00f6ffentlichung.<\/p>

Eine Vulnerability Disclosure Policy ist keine interne Prozessbeschreibung, sondern eine \u00f6ffentlich kommunizierte Richtlinie. Sie legt fest, unter welchen Rahmenbedingungen externe Personen Sicherheitsl\u00fccken melden k\u00f6nnen: \u00fcber welchen Kontakt, mit welchen Informationen, innerhalb welchen Scopes, unter welchen Verhaltensregeln und mit welcher grunds\u00e4tzlichen R\u00fcckmeldung sie rechnen k\u00f6nnen.<\/p>

Der CVD-Prozess beginnt dort, wo eine Meldung eingeht. Er umfasst die internen Abl\u00e4ufe zur Annahme, Pr\u00fcfung, Priorisierung, Behebung, Nachverfolgung und gegebenenfalls koordinierten Ver\u00f6ffentlichung einer Schwachstelle.<\/p>

Wer sich an etablierten Standards orientieren m\u00f6chte, findet in ISO\/IEC 29147<\/strong><\/a> und ISO\/IEC 30111<\/strong><\/a> einen bew\u00e4hrten Rahmen. ISO\/IEC 29147<\/strong><\/a> beschreibt, wie Schwachstellenmeldungen von au\u00dfen angenommen und kommuniziert werden sollten. ISO\/IEC 30111<\/strong><\/a> regelt die interne Seite \u2014 also Bewertung, Priorisierung, Behebung und Nachverfolgung. F\u00fcr den deutschen Markt bietet das BSI<\/strong> <\/a>zus\u00e4tzlich praxisnahe Orientierung zum professionellen Schwachstellenmanagement<\/strong>.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Warum Unternehmen einen klaren Prozess brauchen\n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Viele Organisationen investieren bereits in technische Schutzma\u00dfnahmen wie H\u00e4rtung, Monitoring, Zugriffskontrollen, Segmentierung oder Penetrationstests. Das ist sinnvoll \u2014 beantwortet aber noch nicht die organisatorische Frage: Was passiert konkret, wenn Dritte Sicherheitsl\u00fccken melden<\/strong>?<\/p>

Genau hier entstehen in der Praxis h\u00e4ufig Probleme. Eine Meldung landet im allgemeinen Support, wird als Standard-Ticket behandelt oder erreicht nie die richtigen Ansprechpersonen. Die meldende Person erh\u00e4lt keine R\u00fcckmeldung. Intern ist unklar, wer zust\u00e4ndig ist. Und wertvolle Zeit geht verloren.<\/p>

Ein funktionierender CVD-Prozess<\/strong> verhindert genau das. Er stellt sicher, dass Hinweise an der richtigen Stelle ankommen, fachlich bewertet und strukturiert bearbeitet werden. Unternehmen, die Sicherheitsl\u00fccken professionell behandeln<\/strong>, reduzieren nicht nur Risiken \u2014 sie st\u00e4rken auch Vertrauen bei Kunden, Partnern und in der Security-Community.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Warum der CVD Prozess im IoT-Bereich besonders wichtig ist<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Gerade in der IoT-Sicherheit sind Schwachstellen oft besonders kritisch. Ein Problem bleibt selten auf eine einzelne Komponente begrenzt. Wenn beispielsweise ein Ger\u00e4tezugang unzureichend abgesichert ist, eine API Schw\u00e4chen aufweist oder die Update-Funktion angreifbar ist, kann das Auswirkungen auf die gesamte Systemarchitektur haben.<\/p>

Hinzu kommt, dass viele IoT-L\u00f6sungen \u00fcber Jahre hinweg in produktiven Betriebsumgebungen laufen. Eine Schwachstelle ist dann nicht nur ein IT-Thema, sondern kann Verf\u00fcgbarkeit, Datensicherheit, Betriebsabl\u00e4ufe oder im Extremfall physische Prozesse betreffen.<\/p>

Der Standard ETSI EN 303 645<\/a> adressiert genau diesen Bereich. Er sieht f\u00fcr Hersteller vernetzter Ger\u00e4te eine Vulnerability Disclosure Policy vor. Damit ist keine interne Prozessbeschreibung gemeint, sondern eine \u00f6ffentlich kommunizierte Richtlinie, die beschreibt, wie Sicherheitsl\u00fccken gemeldet werden k\u00f6nnen, welche Informationen daf\u00fcr hilfreich sind und unter welchen Rahmenbedingungen eine Meldung bearbeitet wird.<\/p>

Dazu kommt der wachsende regulatorische Druck durch den Cyber Resilience Act. F\u00fcr Hersteller von Produkten mit digitalen Elementen wird der Umgang mit Schwachstellen k\u00fcnftig deutlich verbindlicher. Annex I, Part II<\/a> des CRA adressiert Anforderungen an das Vulnerability Handling w\u00e4hrend des Supportzeitraums. Dazu geh\u00f6rt unter anderem, Schwachstellen zu identifizieren, zu dokumentieren, zu beheben und einen Rahmen f\u00fcr Coordinated Vulnerability Disclosure vorzusehen.<\/p>

F\u00fcr IoT-Unternehmen ist ein professioneller Umgang mit Schwachstellen damit l\u00e4ngst keine rein freiwillige Best Practice mehr. Eine klare Vulnerability Disclosure Policy, definierte interne Zust\u00e4ndigkeiten und ein belastbarer CVD-Prozess werden zu wichtigen Bausteinen regulatorischer und operativer Sicherheit.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Wie ein Schwachstellen melden Prozess in der Praxis aussieht\n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Am Anfang steht ein klarer Meldeweg. Wer eine Schwachstelle entdeckt, muss ohne Umwege erkennen k\u00f6nnen, wo und wie sie gemeldet werden kann.<\/p>

Technisch bew\u00e4hrt hat sich hier die security.txt<\/strong> \u2014 eine standardisierte Datei, die Unternehmen unter \/.well-known\/security.txt\u00a0bereitstellen. RFC 9116<\/strong><\/a> definiert diesen Standard und legt fest, welche Felder eine security.txt enthalten sollte: unter anderem einen Sicherheitskontakt, eine Verkn\u00fcpfung zur Disclosure Policy und optionale Angaben zu PGP-Schl\u00fcsseln und Ablaufdatum. Wer security.txt einrichten<\/strong> m\u00f6chte, findet in RFC 9116 die ma\u00dfgebliche technische Grundlage.<\/p>

Beispiel einer security.txt:<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"security.txt\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Wenn eine Meldung eingeht, z\u00e4hlt die Reaktionsgeschwindigkeit. Eine Eingangsbest\u00e4tigung sollte innerhalb von 24 bis 48 Stunden erfolgen. Daf\u00fcr braucht es noch keine fertige Bewertung \u2014 eine kurze Best\u00e4tigung, eine Ansprechperson und ein grober Hinweis auf den weiteren Ablauf reichen in vielen F\u00e4llen aus.<\/p>

Danach beginnt die eigentliche Pr\u00fcfung: Ist die Meldung plausibel? Welche Systeme oder Produkte sind betroffen? Wie hoch ist das Risiko? F\u00fcr die Risikobewertung hat sich das Common-Vulnerability-Scoring-System (CVSS)<\/strong><\/a> etabliert, das von FIRST<\/strong> gepflegt wird und eine standardisierte Einsch\u00e4tzung des Schweregrads erm\u00f6glicht.<\/p>

Dann folgen Priorisierung und Behebung. Nicht jede Schwachstelle ist automatisch kritisch, aber jede Meldung sollte nachvollziehbar bewertet werden. Als grober Richtwert gelten h\u00e4ufig bis zu 90 Tage f\u00fcr die Behebung \u2014 bei kritischen Schwachstellen deutlich weniger.<\/p>

Ist eine Schwachstelle behoben, kann eine koordinierte Ver\u00f6ffentlichung sinnvoll sein. Daf\u00fcr steht unter anderem das CVE-Programm<\/strong><\/a> zur Verf\u00fcgung. Ein CVE-Eintrag schafft eine eindeutige, \u00f6ffentlich referenzierbare Kennung f\u00fcr eine Schwachstelle und erleichtert die Kommunikation gegen\u00fcber Kunden, Partnern und der Security-Community.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Was zu einer guten Vulnerability Disclosure Policy geh\u00f6rt\n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Ein wirksamer CVD-Prozess<\/strong> braucht nicht nur interne Abl\u00e4ufe, sondern auch eine klare externe Kommunikation. Dazu geh\u00f6rt eine Vulnerability-Disclosure-Policy<\/strong>. Wer eine Vulnerability-Disclosure-Policy erstellen<\/strong> will, sollte darin mindestens festhalten:<\/p>