Häufige Schwachstellen und Risiken

Das Common Vulnerabilities and Exposures ( CVE )-System, ursprünglich Common Vulnerability Enumeration ^{[ 1 ]} , bietet eine Referenzmethode für öffentlich bekannte Schwachstellen und Sicherheitslücken in der Informationssicherheit . ^{[ 2 ]} Das System wird vom Homeland Security Systems Engineering and Development Institute (FFRDC) der Vereinigten Staaten, betrieben von der MITRE Corporation , mit Mitteln der National Cyber ​​Security Division des US-Heimatschutzministeriums gepflegt . ^{[ 3 ]} Das System wurde im September 1999 offiziell für die Öffentlichkeit freigegeben. ^{[ 4 ]}

Das Security Content Automation Protocol verwendet CVE, und CVE-IDs sind sowohl im System von MITRE als auch in der US National Vulnerability Database aufgeführt . ^{[ 5 ]}

Die Dokumentation der MITRE Corporation definiert CVE-Kennungen (auch „CVE-Namen“, „CVE-Nummern“, „CVE-IDs“ oder „CVEs“ genannt) als eindeutige, allgemein anerkannte Kennungen für öffentlich bekannte Sicherheitslücken in öffentlich freigegebenen Softwarepaketen. Ursprünglich hatten CVE-Kennungen den Status „Kandidat“ („CAN-“) und konnten später zu Einträgen („CVE-“) hochgestuft werden. Dieses Verfahren wurde jedoch 2005 eingestellt ^{[ 6 ] [ 7 ]} , und alle Kennungen werden nun als CVEs vergeben. Die Vergabe einer CVE-Nummer garantiert nicht, dass daraus ein offizieller CVE-Eintrag wird (z. B. kann eine CVE fälschlicherweise einem Problem zugeordnet werden, das keine Sicherheitslücke darstellt oder einen bereits vorhandenen Eintrag dupliziert). Erfüllt ein Eintrag die Kriterien nicht, kann MITRE oder eine CVE Numbering Authority (CNA) ihn umgehend auf den Status „Abgelehnt“ setzen.

CVEs werden von einer CVE-Nummerierungsstelle (CNA) vergeben. ^{[ 8 ]} Obwohl einige Anbieter zuvor als CNA fungierten, wurden Name und Bezeichnung erst am 1. Februar 2005 eingeführt. ^{[ 9 ]} Es gibt vier Hauptarten der CVE-Nummernvergabe:

1. Die MITRE Corporation fungiert als Herausgeber und primärer CNA.
2. Verschiedene Zertifizierungsstellen (CNAs) vergeben CVE-Nummern für ihre eigenen Produkte (z. B. Microsoft, Oracle, HP, Red Hat).
3. Ein externer Koordinator wie beispielsweise das CERT Coordination Center kann CVE-Nummern für Produkte vergeben, die nicht von anderen CNAs abgedeckt werden.
4. Forschern wurde in einem Fall die Rolle des CNA übertragen. ^{[ 10 ]}

Bei der Untersuchung einer Schwachstelle oder potenziellen Schwachstelle ist es hilfreich, frühzeitig eine CVE-Nummer zu erhalten. CVE-Nummern erscheinen möglicherweise erst nach einiger Zeit (Tagen, Wochen, Monaten oder unter Umständen Jahren) in den Datenbanken von MITRE oder NVD. Dies kann daran liegen, dass manche Probleme unter Embargo stehen (die CVE-Nummer wurde zwar vergeben, das Problem aber noch nicht öffentlich gemacht) oder dass MITRE aufgrund von Ressourcenmangel den Eintrag nicht recherchiert und dokumentiert hat. Der Vorteil einer frühzeitigen CVE-Kandidatur besteht darin, dass sich die gesamte weitere Korrespondenz und Koordination auf die CVE-Nummer beziehen kann, um sicherzustellen, dass alle Beteiligten dieselbe Schwachstelle meinen. Informationen zum Erhalt von CVE-Kennungen für Probleme in Open-Source-Projekten finden Sie bei Red Hat ^{[ 11 ]} und GitHub ^{[ 12 ]} .

CVEs werden für öffentlich verfügbare Software vergeben; dies schließt Betaversionen und andere Vorabversionen ein, sofern diese weit verbreitet sind. Kommerzielle Software fällt in die Kategorie „öffentlich verfügbar“, während individuell entwickelte, nicht vertriebene Software in der Vergangenheit keine CVE erhielt. In den ersten zwei Jahrzehnten des Programms wurden Diensten (z. B. webbasierten E-Mail-Anbietern) keine CVEs für im Dienst gefundene Schwachstellen (z. B. eine XSS-Schwachstelle) zugewiesen, es sei denn, das Problem bestand in einem zugrunde liegenden, öffentlich vertriebenen Softwareprodukt. Offizielle Regeln zu dieser Änderung wurden nicht veröffentlicht, aber einige Zertifizierungsstellen, darunter MITRE, begannen bereits im Jahr 2000 damit, CVEs für dienstbasierte Schwachstellen zu vergeben. ^{[ 13 ]}

Die CVE-Datenbank enthält mehrere Felder:

Dies ist eine standardisierte Textbeschreibung des/der Problems/Probleme. Ein gängiger Eintrag lautet:

** RESERVIERT ** Dieser Kandidat wurde von einer Organisation oder Einzelperson reserviert, die ihn bei der Veröffentlichung eines neuen Sicherheitsproblems verwenden wird. Sobald der Kandidat veröffentlicht wurde, werden die Details dazu bereitgestellt.

Dies bedeutet, dass die Eintragsnummer von Mitre für ein Problem reserviert wurde oder dass eine CNA die Nummer reserviert hat. Wenn eine CNA also im Voraus einen Block von CVE-Nummern anfordert (z. B. fordert Red Hat derzeit CVEs in Blöcken von 500 an), wird die CVE-Nummer als reserviert markiert, auch wenn die CVE selbst möglicherweise erst später von der CNA zugewiesen wird. Bis die CVE zugewiesen ist, Mitre darüber informiert wurde (d. h. das Embargo abgelaufen ist und das Problem öffentlich gemacht wurde) und Mitre das Problem untersucht und eine Beschreibung dazu verfasst hat, werden die Einträge als „**RESERVIERT**“ angezeigt.

Dies ist das Erstellungsdatum des Eintrags. Bei CVEs, die direkt von Mitre vergeben wurden, ist dies das Datum, an dem Mitre den CVE-Eintrag erstellt hat. Bei CVEs, die von zertifizierten Sicherheitsorganisationen (CNAs) (z. B. Microsoft, Oracle, HP, Red Hat) vergeben wurden, ist dies ebenfalls das von Mitre erstellte Datum, nicht das der CNA. Wenn eine CNA im Voraus einen Block von CVE-Nummern anfordert, ist das Eintragsdatum das Datum, an dem der Block der CNA zugewiesen wurde.

Die folgenden Felder wurden früher in CVE-Datensätzen verwendet, werden aber nicht mehr verwendet.

• Phase: Die Phase, in der sich das CVE befindet (z. B. CAN, CVE).
• Abstimmungen: Bisher stimmten die Vorstandsmitglieder mit Ja oder Nein darüber ab, ob der CAN akzeptiert und in einen CVE umgewandelt werden sollte.
• Kommentare: Anmerkungen zu diesem Thema.
• Vorgeschlagen: Als der Vorschlag erstmals eingebracht wurde.

Um CVE-IDs jenseits von CVE-YEAR-9999 zu unterstützen (ein Problem, das als „CVE10k-Problem“ ^{[ 14 ]} bekannt ist ), wurde 2014 eine Änderung an der CVE-Syntax vorgenommen, die am 13. Januar 2015 in Kraft trat. ^{[ 15 ]}

Die neue CVE-ID-Syntax ist von variabler Länge und umfasst Folgendes:

CVE-Präfix + Jahr + Beliebige Ziffern

Die beliebig langen Ziffern beginnen mit vier festen Ziffern und werden nur bei Bedarf innerhalb eines Kalenderjahres um weitere Ziffern erweitert; beispielsweise CVE-YYYY-NNNN und gegebenenfalls CVE-YYYY-NNNNN, CVE-YYYY-NNNNNN usw. Das Schema ist kompatibel mit bereits vergebenen CVE-IDs, die alle mindestens vier Ziffern enthalten.

Die Mitre CVE-Datenbank kann über die CVE-Listensuche durchsucht werden , und die NVD CVE-Datenbank kann über die CVE- und CCE-Schwachstellendatenbank durchsucht werden .

CVE-Kennungen dienen der Identifizierung von Sicherheitslücken:

Common Vulnerabilities and Exposures (CVE) ist ein Verzeichnis gebräuchlicher Bezeichnungen (CVE-Kennungen) für öffentlich bekannte Sicherheitslücken. Die CVE-Kennungen erleichtern den Datenaustausch zwischen verschiedenen Netzwerksicherheitsdatenbanken und -tools und bieten eine Grundlage für die Bewertung der Abdeckung durch die Sicherheitstools einer Organisation. Enthält ein Bericht eines Ihrer Sicherheitstools CVE-Kennungen, können Sie schnell und präzise auf Informationen zur Behebung des Problems in einer oder mehreren separaten CVE-kompatiblen Datenbanken zugreifen. ^{[ 16 ]}

Benutzer, denen eine CVE-Kennung für eine Sicherheitslücke zugewiesen wurde, werden dazu angehalten, die Kennung in allen zugehörigen Sicherheitsberichten, Webseiten, E-Mails usw. anzugeben.

Gemäß Abschnitt 7 der CNA-Regeln hat ein Anbieter, der einen Bericht über eine Sicherheitslücke erhalten hat , hinsichtlich dieser die volle Entscheidungsfreiheit. ^{[ 17 ]} Dies kann zu einem Interessenkonflikt führen , da ein Anbieter versuchen könnte, Schwachstellen ungepatcht zu lassen, indem er die Zuweisung einer CVE-Nummer von vornherein ablehnt – eine Entscheidung, die Mitre nicht rückgängig machen kann. Das 2023 angekündigte Projekt „!CVE“ (nicht CVE) hat zum Ziel, Schwachstellen zu sammeln, deren Anerkennung von Anbietern abgelehnt wird, sofern sie von einem Expertengremium des Projekts als gültig eingestuft werden. ^{[ 18 ]}

CVE-Kennungen wurden auch für Scheinprobleme und Probleme ohne Sicherheitsfolgen vergeben. ^{[ 19 ]} Als Reaktion darauf haben sich mehrere Open-Source-Projekte selbst darum beworben, die CVE-Nummerierungsstelle (CNA) ihres jeweiligen Projekts zu werden. ^{[ 20 ]}

Am 15. April 2025 wurde berichtet, dass der Vertrag zwischen MITRE und der US-Regierung, der am darauffolgenden Tag auslaufen sollte, ^{[ 21 ]} auslaufen würde. Berichten zufolge würde das Auslaufen des Vertrags das Ende des operativen Teils des CVE-Programms, einschließlich der Zuweisung neuer CVEs, bedeuten, während die Datenbank weiterhin über GitHub zugänglich bliebe . ^{[ 22 ]}

Kurz vor Ablauf des Vertrags wurde dieser um elf Monate verlängert, wodurch die Einstellung des Programms abgewendet werden konnte. ^{[ 23 ]}

Nachdem die Gefahr bestanden hatte, dass die Finanzierung am 16. März 2026 auslaufen würde, erklärte der amtierende Direktor von CISA, Nick Andersen, dass das Programm nun vollständig finanziert sei. Pete Allor, Mitbegründer der CVE Foundation, berichtete, dass die Finanzierung der CVE-Programme von einem Ermessensposten zu einem der Kernprogramme umstrukturiert worden sei. ^{[ 24 ]}

• Gemeinsames Schwachstellenbewertungssystem (CVSS)
• Common Weakness Enumeration (CWE)
• Computersicherheit
• Europäische Union Schwachstellendatenbank
• Software-Kompositionsanalyse
• Statische Anwendungssicherheitstests

• Official website
• National Vulnerability Database (NVD)
• Common Configuration Enumeration (CCE) at NVD
• vFeed the Correlated and Aggregated Vulnerability Database - SQLite Database and Python API
• Cyberwatch Vulnerabilities DatabaseArchived 22 August 2018 at the Wayback Machine, third party
• What Enterprises need to know about IT Security Audit Services?