Blog

CTEM vs. Schwachstellenmanagement: Was sich wirklich ändert

Von Dan Swihart · Veröffentlicht 5. September 2026 · Aktualisiert 29. September 2026

Die meisten Organisationen, die angeben, CTEM (kontinuierliches Threat-Exposure-Management) eingeführt zu haben, haben eines von zwei Dingen getan: ein neues Dashboard für den vorhandenen Scanner gekauft oder das Wort „Exposure“ in den Namen des Schwachstellenmanagement-Teams aufgenommen. Beides ist nicht falsch, aber beides ist nicht die Veränderung, die Gartners CTEM-Modell beschreibt.

Die kurze Antwort

Schwachstellenmanagement findet und behebt bekannte Softwarefehler auf Assets, die Sie bereits erfassen. CTEM ist ein breiterer, wiederkehrender Zyklus: Er legt den Scope nach geschäftlicher Auswirkung fest, findet Exposures, die keine CVEs sind, ordnet sie nach Wahrscheinlichkeit und Folgen, beweist, dass die wichtigen ausnutzbar sind, und sorgt dafür, dass jemand sie behebt. Schwachstellenmanagement wird zu einem Input von CTEM, nicht zu einem Rivalen.

Was jeder Ansatz misst

Schwachstellenmanagement misst den Zustand der Software auf Hosts, die der Scanner erreicht: wie viele Schwachstellen, wie schwerwiegend, wie alt. CTEM misst Exposure: auf wie vielen Wegen ein Angreifer etwas erreichen könnte, das dem Unternehmen wichtig ist, wie viele dieser Wege bewiesen sind und wie schnell sie geschlossen werden. Das eine zählt Befunde. Das andere zählt Ergebnisse.

Schwachstellenmanagement zählt CVEs. Das CVE-Programm existiert, um „identify, define, catalog publicly disclosed cybersecurity vulnerabilities“ (öffentlich bekannt gewordene Cybersicherheitslücken zu identifizieren, zu definieren und zu katalogisieren). Alles, was keine öffentlich bekannt gewordene Schwachstelle ist, taucht in der Zählung daher nie auf. Ein überprivilegiertes Servicekonto, eine vergessene Subdomain, eine SaaS-Integration mit Schreibrechten und ein falsch konfigurierter Storage-Bucket sind alle Exposures. Die meisten erhalten nie eine CVE, weil es sich um Konfigurations- und Identitätsprobleme handelt und nicht um Softwarefehler.

CTEM zählt sie alle, und es bleibt nicht beim Zählen. Entscheidend sind die noch offenen validierten Exposures und die Zeit, die bis zu ihrer Behebung vergeht. Deshalb sehen die Kennzahlen, die die Führung tatsächlich liest, so anders aus als ein Scanner-Bericht.

Scope: Assets versus Angriffspfade

Der Scope im Schwachstellenmanagement ist meist eine Asset-Liste: jeder Server, jeder Endpoint und jeder Container, auf den der Scanner gerichtet ist. Der Scope bei CTEM ist ein Ausschnitt des Geschäfts, etwa ein umsatzrelevanter Prozess oder die externe Angriffsfläche, abgestimmt mit der Person, die dafür verantwortlich ist. Das Scoping ist eine eigene Phase, für die der Scanner kein Gegenstück hat.

Ein Asset-basierter Scope behandelt die Test-VM eines Entwicklers und eine Zahlungsdatenbank als gleichrangige Einträge in einem Inventar. Ein geschäftsbasierter Scope beginnt mit der Frage „Was würde schaden, wenn es ausfiele oder abfließen würde?“ und arbeitet sich rückwärts zu den Systemen, Identitäten und Dritten auf dem Weg dorthin vor.

Er bestimmt auch, was gefunden wird. Ein Scanner sieht, was er erreichen kann. Ein Zyklus mit festgelegtem Scope fragt, welche Quellen den Scope überhaupt sehen (Cloud-Inventar, Identitätssysteme, DNS, Zertifikatsprotokolle, die CMDB), und geht den Lücken nach.

Sie müssen nicht den gesamten Bestand in den Scope nehmen. Ein eingegrenzter Ausschnitt mit einem benannten Fachverantwortlichen genügt für einen ersten Zyklus, und der 90-Tage-Plan baut genau darauf auf.

Priorisierung: Schweregrad versus Wahrscheinlichkeit und Auswirkung

Schwachstellenmanagement priorisiert typischerweise nach CVSS. CTEM priorisiert danach, ob eine Exposure in Ihrer Umgebung ausnutzbar ist, ob sie gerade aktiv ausgenutzt wird und was ein Angreifer erreicht, wenn er sie nutzt. CVSS wird zu einem Input unter mehreren. Es beantwortet „wie schlimm könnte das grundsätzlich sein“, nicht „wie schlimm ist es hier“.

FIRST, das CVSS pflegt, sagt das ausdrücklich. Im Benutzerhandbuch heißt es, CVSS-Basiswerte „are designed to measure the severity of a vulnerability and should not be used alone to assess risk“ (sind dafür gedacht, den Schweregrad einer Schwachstelle zu messen, und sollten nicht allein zur Risikobewertung verwendet werden). Der Basiswert ignoriert Bedrohungslage und Umgebung. Eine CVSS 9.8 auf einer isolierten Testmaschine rangiert unter einer CVSS 6 auf dem Pfad zu einem Domänencontroller.

Zwei öffentliche Quellen helfen bei der Frage „wird es ausgenutzt“:

• Der Known-Exploited-Vulnerabilities-Katalog der CISA. Die CISA beschreibt ihn als „the authoritative source of vulnerabilities that have been exploited in the wild“ (die maßgebliche Quelle für Schwachstellen, die in freier Wildbahn ausgenutzt wurden) und empfiehlt, ihn als Input für das Priorisierungs-Framework im Schwachstellenmanagement zu verwenden. Steht etwas darin, hat es bereits jemand ausgenutzt.
• EPSS. Das Exploit Prediction Scoring System von FIRST schätzt die Wahrscheinlichkeit, dass eine veröffentlichte CVE in den nächsten 30 Tagen in freier Wildbahn ausgenutzt wird, und soll helfen, begrenzten Behebungsaufwand dorthin zu lenken, wo Angriffe am wahrscheinlichsten sind. Es ordnet die Wahrscheinlichkeit über CVEs hinweg ein. Wie Ihr Netzwerk aussieht, weiß es nicht.

Keines von beiden kennt Ihr Geschäft. Erreichbarkeit und geschäftliche Auswirkung stammen aus Ihrer eigenen Scoping- und Discovery-Arbeit: Kann ein Angreifer das System erreichen, und was liegt dahinter? Belege für Ausnutzung sagen Ihnen, was in der Welt dringend ist. Ihr Kontext sagt Ihnen, was für Sie dringend ist. Die Priorisierung braucht beides, und eine Tabellenkalkulation ist ein guter Anfang.

Der Data Breach Investigations Report 2025 von Verizon stellte fest, dass die Ausnutzung von Schwachstellen in 20 % der Sicherheitsvorfälle mit bekanntem Vektor der Erstzugriffsweg war (ohne Fehler und Missbrauch) und dass nur etwa 54 % der untersuchten Edge-Device-Schwachstellen vollständig behoben wurden, mit einem Median von 32 Tagen (Verizon, 2025 DBIR).

Validierung: der Beweis

Schwachstellenmanagement endet bei „der Scanner sagt es“. CTEM validiert: Es prüft, ob eine konkrete Exposure aus der Position eines realistischen Angreifers tatsächlich ausnutzbar ist und was sie erreicht, bevor jemand Behebungsaufwand investiert. Das Ergebnis ist entweder ein bewiesener Pfad oder eine dokumentierte Herabstufung, und beides ist nützlich.

Die Validierung ist die Phase, die am häufigsten übersprungen wird, weil sie echten technischen Aufwand erfordert. Sie kann ein Pentest mit begrenztem Umfang für die zehn wichtigsten Einträge sein, ein sicherer Ausnutzungsversuch, eine Angriffspfad-Analyse oder eine Simulation, die prüft, ob die Detektion anschlägt. Sie ist nicht dasselbe wie ein Programm für Breach-and-Attack-Simulation, das Sicherheitsmaßnahmen gegen bekannte Techniken testet; BAS versus CTEM-Validierung zeigt, wo sich beide überschneiden und wo nicht.

Wer die Validierung überspringt, lässt die Behebungsprioritäten auf einem Wert statt auf einem Beweis ruhen. Teams patchen Einträge, die nie erreichbar waren, und verbrauchen Wohlwollen mit Tickets, die bestritten werden, während eine niedrig bewertete Exposure, die sich zu etwas Wertvollem verketten lässt, am Ende der Warteschlange liegt.

Mobilisierung: wer behebt

Schwachstellenmanagement endet meist mit einem Bericht oder einer Ticket-Warteschlange und der stillen Hoffnung, dass das richtige Team sie aufgreift. Die letzte Phase von CTEM, die Mobilisierung, macht den Abschluss zur benannten Aufgabe einer Person: ein Verantwortlicher je Exposure-Klasse, ein vereinbartes Datum, ein Weg für Ausnahmen und ein Verifizierungsschritt, nachdem die Behebung eingespielt wurde.

Die Lücke ist hier eher organisatorisch als technisch. Die Sicherheit findet die Exposure, aber Infrastruktur-, Plattform-, Anwendungs- und Identitätsteams beheben sie, und diese haben eigene Prioritäten. Eine Liste von zehn validierten, geschäftsrelevanten Einträgen mit einem abgezeichneten Scope dahinter ist schwerer zu ignorieren als eine rohe Befundliste.

Praktische Elemente der Mobilisierung:

• Verantwortliche für die Behebung, benannt beim Scoping, nicht erst beim Ticket entdeckt.
• Service-Level je Exposure-Klasse, nicht eine Zahl für alles. Eine exponierte Admin-Oberfläche und ein veraltetes Testzertifikat sind nicht gleich dringend.
• Ein Entscheidungsweg für Risikoakzeptanz, damit „wir beheben das nicht“ eine dokumentierte Entscheidung von jemandem mit der nötigen Befugnis ist.
• Erneuter Test. Ein geschlossenes Ticket ist keine geschlossene Exposure. Verifizieren Sie.

CTEM und Schwachstellenmanagement im Vergleich

Die beiden stehen nicht im Gegensatz. CTEM umfasst das Schwachstellenmanagement und ergänzt Phasen darum herum. Die folgende Tabelle vergleicht sie in acht Dimensionen, von der Arbeitseinheit bis zu dem, was Sie nach oben berichten, damit Sie sehen, welche Unterschiede Ihr eigenes Programm bereits abdeckt.

Was Sie aus Ihrem Schwachstellenmanagement behalten

Fast alles. Gepatcht werden muss weiterhin. Das Asset-Inventar muss weiterhin gepflegt werden. Der Scanner läuft weiter, und seine Ausgabe ist Ihre größte einzelne Discovery-Quelle. CTEM setzt darauf auf und entscheidet, wohin der Aufwand fließt. Wenn Ihre Behebungskapazität zweihundert Fixes im Monat beträgt, ist CTEM der Prozess, der die richtigen zweihundert auswählt.

Behalten Sie auch die Menschen. Wer heute das Schwachstellenmanagement betreibt, kennt den Bestand und weiß, welche Teams auf Tickets antworten, und ist damit die naheliegende Programmverantwortung für einen ersten Zyklus.

Was sich ändern muss, ist kleiner, als die meisten Anbieter suggerieren: ein Scoping-Gespräch, mehr Quellen als der Scanner, Priorisierung nach Belegen für Ausnutzung und nach Erreichbarkeit, Validierung der obersten Einträge der Liste und benannte Verantwortliche für die Behebung. Das ist zuerst eine Prozessänderung und erst danach eine Tool-Frage.

Wenn Sie am Ende doch kaufen, erklärt der Leitfaden zu CTEM-Tools, was jede Kategorie abdeckt, und das Anbieterverzeichnis führt auf, was einzelne Produkte für sich in Anspruch nehmen.

Ein Test über einen Zyklus

Nehmen Sie die Behebungsliste des letzten Monats. Fragen Sie für jeden Eintrag: Könnten wir den Angriffspfad zu etwas zeigen, das dem Unternehmen wichtig ist? Hat jemand geprüft, ob er ausnutzbar war? War der Verantwortliche für die Behebung benannt und wurde der Abschluss nachverfolgt? Wenn die Antwort überwiegend Nein lautet, ist das Programm Schwachstellenmanagement unter neuem Namen. Das ist ein guter Ausgangspunkt. Es ist nur nicht das Ziel.

So fangen Sie an

Beginnen Sie mit einem eingegrenzten Scope, nicht mit einer Plattform. Wählen Sie einen Systemausschnitt mit einem offensichtlichen Fachverantwortlichen, gleichen Sie die Quellen ab, die ihn sehen, ordnen Sie die Exposures von Hand, validieren Sie die zehn wichtigsten und verfolgen Sie sie bis zur verifizierten Behebung. Berichten Sie, was passiert ist.

Drei praktische nächste Schritte:

• Machen Sie den Zwei-Minuten-Schnellcheck für eine erste Einschätzung Ihrer schwächsten Phase.
• Nutzen Sie die Selbstbewertung, um alle fünf Phasen zu bewerten und zu sehen, welche am weitesten von dem entfernt ist, wo sie sein müsste.
• Folgen Sie Ein CTEM-Programm in 90 Tagen starten für den Wochenplan und sehen Sie sich das Reifegradmodell an, um zu erfahren, wie „Definiert“ aussieht.

FAQ

Ist CTEM nur Schwachstellenmanagement unter neuem Namen?

Nein, obwohl es oft so umgesetzt wird. Der Unterschied ist der Prozess um den Scanner herum: geschäftsbasiertes Scoping, Quellen jenseits des Scanners, Priorisierung nach Ausnutzbarkeit und Auswirkung, Validierung und benannte Verantwortung für die Behebung. Wenn nichts davon vorhanden ist, haben Sie Schwachstellenmanagement, und das ist eine solide Basis und kein Versagen.

Muss ich meinen Schwachstellenscanner ersetzen, um CTEM zu betreiben?

Nein. Der Scanner bleibt als Discovery-Quelle und als Aufzeichnung der Softwarefehler. Was sich ändert, ist, was mit seiner Ausgabe geschieht. Die meisten ersten Zyklen laufen auf vorhandenen Tools.

Spielt CVSS unter CTEM noch eine Rolle?

Ja, als ein Input. FIRST sagt, dass Basiswerte nicht allein zur Risikobewertung verwendet werden sollten. Kombinieren Sie den Schweregrad mit Belegen für Ausnutzung wie dem CISA-KEV-Katalog und EPSS und ergänzen Sie dann Erreichbarkeit und geschäftliche Auswirkung aus Ihrem eigenen Scoping.

Wie lange dauert der Übergang vom Schwachstellenmanagement zu CTEM?

Ein Zyklus mit engem Scope lässt sich in etwa 90 Tagen durchführen, wie im 90-Tage-Plan beschrieben. Die Ausweitung auf den gesamten Bestand dauert länger und erfolgt Scope für Scope.

Weiter

Wenn der Ein-Zyklus-Test überwiegend Nein ergab, ist Ein CTEM-Programm in 90 Tagen starten der Weg vom umbenannten Scanner zu einem echten Zyklus. Die einzigen CTEM-Kennzahlen, die die Führung liest zeigt, worüber Sie berichten können, sobald Validierung und Mobilisierung Belege liefern, und die Selbstbewertung sagt Ihnen, welche der oben genannten Veränderungen am weitesten entfernt ist.