Risiken, Ursachen und Lösungen für ungepatchte Sicherheitslücken

Wichtigste Erkenntnisse

• Für eine noch nicht behobene Sicherheitslücke gibt es bereits einen Patch, der jedoch noch nicht installiert wurde.
• Mandiant M-Trends 2026 gibt die durchschnittliche Zeit bis zur Ausnutzung mit minus sieben Tagen an, sodass Angreifer im Durchschnitt schneller sind als die Patch-Veröffentlichung.
• Der Verizon DBIR 2026 ergab, dass nur 26 % der erkannten KEV-Schwachstellen vollständig behoben wurden, wobei die Medianzeit bis zur Behebung bei 43 Tagen lag.

Die meisten Sicherheitsteams haben denselben Rückstand. Darin befinden sich die CVEs, die geprüft, erfasst, eingeplant und dann stillschweigend zurückgestellt wurden, weil das Wartungsfenster mit dem Quartalsabschluss kollidierte. Das sind ungepatchte Schwachstellen, und deren Ausnutzung ist mittlerweile die bekannteste Methode, mit der Angreifer sich einen ersten Zugriff verschaffen.

Die entscheidende Lücke besteht zwischen der Verfügbarkeit eines Patches und dessen tatsächlicher Ausführung in der Produktion. Im weiteren Verlauf dieses Beitrags wird untersucht, warum diese Lücke bestehen bleibt und wie man sie schließen kann.

Was gilt als nicht gepatchte Sicherheitslücke?

Eine ungepatchte Sicherheitslücke ist ein bekannter Fehler, für den ein Patch verfügbar ist, der jedoch auf einem System noch nicht installiert wurde. Drei Komponenten sind hierfür erforderlich: ein bekannter Fehler, ein verfügbarer Patch und ein System, auf dem dieser Patch noch nicht installiert ist.

Genau dieser mittlere Teil, die verfügbare Lösung, unterscheidet ihn von seinen beiden Nachbarn.

Ein Zero-Day-Exploit wird ausgenutzt, bevor die Verteidiger eine faire Chance hatten, darauf zu reagieren – in der Regel noch vor der Offenlegung oder bevor ein Patch verfügbar ist. Bis ein Patch veröffentlicht wird, sind Abhilfemaßnahmen das Einzige, was Ihnen bleibt. Unsere Analyse, wie Zero-Day-Exploits funktionieren, behandelt genau diesen Fall.

Software, deren Lebenszyklus abgelaufen ist ist der andere Nachbar. Fehlerbehebungen sind zwar möglich, aber der ursprüngliche Anbieter stellt deren Bereitstellung nicht mehr bereit. CentOS 7, PostgreSQL 13sowie ein PHP-Zweig am Ende der Lebensdauer – echte CVEs, echte Sicherheitslücken, kein Upstream-Support.

Auf dem Papier ist die ungepatchte Sicherheitslücke die am leichtesten zu vermeidende der drei, da der Patch bereits existiert und in der Regel kostenlos ist. In der Praxis kostet ein kostenloser Patch dennoch Testzeit und ein Wartungsfenster – und genau darum geht es zur Hälfte in diesem Beitrag.

Der Zeitrahmen zwischen der Bekanntgabe einer Sicherheitslücke und deren Ausnutzung ist enger, als bei den meisten Patch-Zyklen angenommen wird, und verläuft nicht immer in chronologischer Reihenfolge.

Bühne	Wenn es passiert	Was passiert gerade?
CVE veröffentlicht, Patch bereitgestellt	Am selben Tag oder im Abstand von mehreren Wochen	Wird häufig für kritische RCE-Angriffe genutzt
Öffentlich zugänglicher PoC oder Exploit-Code	Von der Zeit vor der Bekanntgabe bis zu Wochen danach	GitHub, Exploit-Frameworks, Forschungsberichte
Massives Scannen des Internets	Einige Stunden nach einem funktionierenden PoC	Angreifer identifizieren exponierte Instanzen in großem Umfang
Aktive Verwertung, KEV-Listung	Kann bereits vor der Bekanntgabe beginnen, und die KEV-Notierung erfolgt, nachdem die CISA dies bestätigt hat	Nun ein bestätigter, tatsächlich genutzter Angriffsvektor

Schweregrad und Ausnutzungswahrscheinlichkeit sind unterschiedliche Indikatoren. Ein CVSS-Wert von 9,8 bei einem Dienst, den Sie nicht nach außen hin bereitstellen, kann weniger gefährlich sein als ein CVSS-Wert von 6,5 an Ihrer Netzwerkperipherie. Lesen Sie unsere Anleitung zu den Änderungen in CVSS v4.0.

Die tatsächlichen Kosten ungepatchter Sicherheitslücken

Beginnen Sie mit einer Zahl, die Sie nicht mehr wiederholen sollten: „Ungepatchte Sicherheitslücken verursachen 60 % der Sicherheitsvorfälle.“ Diese Angabe geht auf eine Umfrage des Ponemon Institute aus dem Jahr 2019 im Auftrag von ServiceNow zurück und sollte nicht mehr als aktueller, branchenweiter Wert zitiert werden.

Aktuelle Daten zeichnen ein noch deutlicheres Bild. Laut dem Verizon DBIR 2026 begannen 31 % der Sicherheitsvorfälle mit der Ausnutzung von Schwachstellen, gegenüber 20 % im Vorjahr. Damit war dies zum ersten Mal in der Geschichte des Berichts der häufigste bekannte Erstzugriffsvektor im Datensatz von Verizon. Auch die Kosten der Datenschutzverletzungen stiegen. Der „Cost of a Data Breach Report“ von IBM aus dem Jahr 2026 beziffert die weltweiten Durchschnitt bei 4,99 Millionen US-Dollar, was einen neuen Rekord darstellt.

Ransomware ist hier die Ausnahme. In der Sophos-Umfrage „State of Ransomware 2026“ konnten nur 18 % der Ransomware-Opfer den Angriff auf eine ausgenutzte Sicherheitslücke zurückführen, ein Rückgang gegenüber 32 % im Vorjahr, da bösartige E-Mails und Phishing nun die führenden Ursachen sind. Das Installieren von Patches ist hier nach wie vor wichtig. Es ist nur nicht mehr der einzige Einfallstor.

Die Schäden äußern sich in Form von regulatorischen Risiken, Erpressung durch Ransomware und Betriebsausfälle, Compliance-Mängel sowie einen Reputationsverlust, der all das überdauert. Unsere Aufschlüsselung der tatsächlichen Kosten, die entstehen, wenn ein kritischer CVE-Eintrag nicht gepatcht wird, geht auf jeden einzelnen Punkt näher ein.

Drei Sicherheitsvorfälle veranschaulichen, wie sich dies auswirkt – jeder auf etwas andere Weise.

Vorfall	CVE	Patch verfügbar	Ausbeutung	Fallout
Equifax	CVE-2017-5638 (Apache Struts 2)	März 7, 2017	Das Portal wurde am 10. März 2017 gescannt und als anfällig eingestuft; der Zugriff auf personenbezogene Daten erfolgte ab dem 13. Mai und wurde am 29. Juli entdeckt.	147 Millionen Menschen sowie ein Vergleich zwischen FTC, CFPB und den Bundesstaaten in Höhe von mindestens 575 Millionen Dollar
MOVEit Transfer	34362	Mai 31, 2023	Die massenhafte Ausnutzung der Cl0p-Sicherheitslücke als Zero-Day-Exploit vom 27. bis 28. Mai 2023 sowie nicht gepatchte Server wurden noch wochenlang danach immer wieder angegriffen	2.773 Organisationen, rund 95,8 Millionen Personen (Emsisoft)
Log4Shell	44228	Log4j 2.15.0, 10. Dezember 2021, mit weiteren Korrekturen wenige Tage später	Scans vom 1. Dezember 2021: Massenausnutzung innerhalb weniger Stunden nach Bekanntwerden	Fast 40 Millionen Downloads der anfälligen Log4j-Version allein im Jahr 2025, was etwa 13 % der Gesamtzahl dieses Jahres entspricht (Sonatype)

Equifax ist ein typisches Beispiel für eine unbehobene Sicherheitslücke. Der Patch wurde am 7. März veröffentlicht, drei Tage später versuchten Angreifer bereits, das Portal zu sondieren, und 67 Tage nach Verfügbarkeit des Patches begann der Diebstahl großer Datenmengen. MOVEit und Log4Shell begannen als Zero-Day-Angriffe, entwickelten sich dann aber fast sofort zu Fällen unbehobener Sicherheitslücken, sobald Patches verfügbar waren und zahlreiche Installationen die anfällige Version dennoch weiterliefen.

Warum Sicherheitslücken nicht behoben werden (die Gründe, die Teams selten zugeben)

Jede dieser Entscheidungen ist für sich genommen rational und lokal getroffen, führt jedoch auf Organisationsebene insgesamt zu einem irrationalen Ergebnis.

Grund	Wie es aussieht	Was beseitigt es?
Angst vor Ausfallzeiten	Kernel-CVE erfordert einen Neustart, und der Host ist zustandsbehaftet und verfügt über kein Failover	Kernel-Patching ohne Neustart
EOL-Software, kein Upstream-Patch	CentOS 7-Host, auf dem eine Anwendung läuft, die sich auf neueren Versionen nicht kompilieren lässt	Vom Anbieter unterstützter erweiterter Support oder ein festgelegter Termin für die Migration
Patches, die nie veröffentlicht werden	Die Automatisierung verzeichnet eine Erfolgsquote von 98 %. Die restlichen 2 % liegen im Grenzbereich.	Abgleich zwischen Patch-Werkzeugen und unabhängigen Scans
Unbekannte Vermögenswerte	Eine Staging-VM aus dem Jahr 2021, ein Container eines Auftragnehmers, eine vergessene Subdomain	Kontinuierliche, stets aktive Erkennung
Testaufwand	Jeder Patch wird anhand eines Monolithen auf Regressionen getestet, den niemand vollständig versteht	Risikogestützte Tests, bei denen kritische Sicherheitskorrekturen durch schrittweise Einführungen beschleunigt werden
Mehr CVEs als Zeit für die Triage	Im Jahr 2025 wurden 48.185 CVEs veröffentlicht. Das können drei Personen nicht lesen.	Auf Ausnutzbarkeit basierende Filterung

 Schon allein das Volumen ist ein Grund. Der Sicherheitsforscher Jerry Gamblins Analyse der CVE-Daten aus dem Jahr 2025 ergab 48.185 veröffentlichte Einträge, etwa 132 pro Tag, während die EPSS-Seite von FIRST deutet darauf hin, dass in einem beliebigen 30-Tage-Zeitraum nur ein geringer einstelliger Prozentsatz der veröffentlichten CVEs ausgenutzt wird. Der Großteil der Warteschlange wird diesen Monat keinen Angreifer zu Gesicht bekommen. Die Schwierigkeit besteht darin, zu wissen, welcher kleine Teil davon davon betroffen sein wird.

Dann ist da noch der Effekt der Anhäufung. Aufgeschobene Patches summieren sich zu Sicherheitsschulden, genauso wie aufgeschobene Refactorings zu technischen Schulden führen, und die Folgen zeigen sich in Form eines Vorfalls. Scanner-Falschalarme verschlimmern die Situation noch, denn Teams, die Wochen damit verbringen, einem Fehlalarm nachzugehen, verlieren die Glaubwürdigkeit, die sie benötigen, wenn ein echter Vorfall auftritt. Der „End-of-Life“-Status gehört ebenfalls in denselben kontinuierlichen Erkennungskreislauf.

Ein häufiges Muster in mittelgroßen Unternehmen ist nicht, dass sich ein Team bewusst gegen die Installation von Patches entscheidet. Vielmehr meldet ein Orchestrierungstool Erfolge auf einem Host, auf dem der Konfigurationsmanagement-Agent bereits Monate zuvor unbemerkt deaktiviert wurde. Niemand hat gelogen. Die Berichtsebene hat einfach das Falsche gemessen.

Wie Angreifer ungepatchte Sicherheitslücken ausnutzen

Betrachten Sie es einmal aus der Perspektive des Angreifers. Ein Zero-Day kostet Forschungszeit oder auf einem Broker-Markt einen sechsstelligen Betrag und mehr. Ein N-Day – also ein Fehler, für den es bereits einen öffentlichen Fix gibt – kostet kaum mehr als eine Shodan-Abfrage, vorausgesetzt, es gibt einen funktionierenden Proof-of-Concept und genügend exponierte Ziele, auf die man ihn richten kann. Angreifer greifen auf Zero-Days zurück, wenn sie müssen, und auf N-Days, wann immer sie können, und der Offenlegungsprozess füllt den N-Day-Bestand jeden Tag wieder auf.

Der „M-Trends 2026“-Bericht von Mandiant Bericht beziffert konkret, wie stark sich diese Lücke verengt hat. Die durchschnittliche Zeit bis zur Ausnutzung wird nun auf minus sieben Tage geschätzt, was bedeutet, dass die Ausnutzung im Durchschnitt bereits vor der Veröffentlichung des Patches beginnt. Exploits stehen seit sechs Jahren in Folge an erster Stelle der häufigsten anfänglichen Infektionsvektoren und machen mittlerweile 32 % der Angriffe aus, bei denen Mandiant den Einstiegspunkt identifizieren konnte.

Der Katalog „Known Exploited Vulnerabilities“ der CISA ist die öffentliche Übersicht über Schwachstellen, die den Sprung von der Theorie in die aktive Nutzung geschafft haben, und sie wächst jede Woche. Die darin festgelegten Fristen für zivile Bundesbehörden der USA haben sich im Jahr 2026 geändert. Die Richtlinie BOD 22-01, die den Behörden seit 2021 zwei Wochen Zeit für die Behebung von KEV-Einträgen (sechs Monate für ältere CVEs) eingeräumt hatte, wurde zusammen mit der älteren Richtlinie BOD 19-02 durch BOD 26-04, „Priorisierung von Sicherheitsupdates auf der Grundlage des Risikos“, ersetzt, das am 10. Juni 2026 veröffentlicht wurde.

Anstelle einer pauschalen Frist bewertet die neue Richtlinie jede Schwachstelle anhand von vier Faktoren. Ist die Ressource öffentlich zugänglich? Befindet sich die Schwachstelle in KEV? Lässt sich die Ausnutzung automatisieren? Verschafft sie einem Angreifer die vollständige oder nur teilweise Kontrolle über das System? Die Antworten legen die Frist fest. Die risikoreichsten Kombinationen erhalten drei Tage, und die KEV-Fälle mit dem höchsten Risiko und vollständiger Kontrolle erfordern zudem eine forensische Überprüfung, um festzustellen, ob das System bereits kompromittiert wurde. Alle anderen Fälle erhalten 14 oder 60 Tage, und Schwachstellen, die keinen der vier Faktoren erfüllen, können bis zum nächsten planmäßigen Update der Ressource warten.

Viele stark ausgenutzte Sicherheitslücken sind Fehler, die die Ausführung von Code aus der Ferne in mit dem Internet verbundenen Diensten und Edge-Geräten ermöglichen, und manchmal gehört das anfällige System nicht einmal Ihnen, sodass Sie es nicht selbst patchen können. MOVEit ist das deutlichste Beispiel aus jüngster Zeit. Eine Sicherheitslücke in einem weit verbreiteten Dateiübertragungsprogramm führte zu Tausenden von Opfern in nachgelagerten Systemen.

Für zivile Bundesbehörden beträgt die Obergrenze für die schlimmste Stufe nun drei Tage, und ein wöchentlich tagender Beratungsausschuss darf diese nicht überschreiten. Wenn Ihre schnellstmögliche Reaktion auf eine aktiv ausgenutzte, mit dem Internet verbundene RCE länger als drei Tage dauert, ist das eine Prozesslücke, die es zu schließen gilt, bevor die nächste Schwachstelle auftaucht.

Wie man verhindert, dass sich ungepatchte Sicherheitslücken häufen

Hier handelt es sich um ein Prozessproblem mit fünf beweglichen Teilen, und wenn man direkt zur Priorisierung übergeht, bevor man eine Bestandsaufnahme erstellt hat, bedeutet das lediglich, dass man eine Teilmenge priorisiert, die man nicht vollständig benennen kann.

Finde zuerst alle noch nicht behobenen Sicherheitslücken

In diesem Fall ist Abdeckung wichtiger als Raffinesse. Ein perfektes Priorisierungsmodell, das 70 % Ihres Nachlasses abdeckt, nützt Ihnen weniger als eine grobe Einstufung, die den gesamten Nachlass abdeckt.

Erstellen Sie Ihre Bestandsaufnahme aus mehreren Blickwinkeln, da jede Quelle andere Aspekte außer Acht lässt. Bei der Konfigurationsverwaltung und der Agenten-Bestandsaufnahme werden alle Elemente übersehen, die nicht mehr vom Agenten erfasst werden. APIs von Cloud-Anbietern lassen On-Premise-Systeme und Schattenkonten außer Acht. Bei authentifizierten Netzwerkscans werden Hosts übersehen, die während des Scan-Zeitfensters ausgeschaltet waren. Durch DNS- und externe Angriffsflächenerkennung werden Subdomains aufgedeckt, an deren Besitz sich niemand mehr erinnert.

Führen Sie anschließend einen Abgleich durch. Der nützliche Teil liegt genau dort, wo diese Listen voneinander abweichen. Ein Host, der in Ihrem Cloud-Bestandsverzeichnis aufgeführt ist, aber nicht in Ihren Scanner-Ergebnissen erscheint, ist genau die Art von Lücke, durch die Sie angegriffen werden können. Sobald die Bestandsliste stimmt, gleichen Sie die installierten Pakete und Versionen jedes Hosts mit den für sie geltenden Sicherheitshinweisen ab, damit Sie wissen, welche dieser Hosts tatsächlich anfällig sind.

Überprüfen Sie außerdem, ob die gemeldeten Patches auch tatsächlich installiert wurden. Dass ein neueres Kernel-Paket auf der Festplatte vorhanden ist, bedeutet noch nicht, dass der aktuell ausgeführte Kernel geschützt ist. Sofern der Host nicht damit neu gestartet wurde oder einen Live-Patch für diese CVE erhalten hat, handelt es sich um eine Sicherheitslücke, die lediglich als „behoben“ gekennzeichnet ist.

Nach tatsächlicher Ausnutzbarkeit priorisieren

Die reine Anzahl der CVEs gibt Aufschluss über den Arbeitsaufwand. Um das tatsächliche Risiko zu ermitteln, sind drei weitere Faktoren erforderlich.

Beginnen Sie mit KEV. Ein Eintrag bedeutet, dass eine Ausnutzung in freier Wildbahn bestätigt wurde. Wenn Ihre Systeme davon betroffen sind, installieren Sie sofort einen Patch – unabhängig vom CVSS-Wert. Überprüfen Sie anschließend den EPSS-Wert, eine täglich aktualisierte Wahrscheinlichkeit zwischen 0 und 1, mit der eine veröffentlichte CVE in den nächsten 30 Tagen in freier Wildbahn ausgenutzt wird. Dieser Wert ist kostenlos, maschinenlesbar und genau für diese Entscheidung konzipiert. Zuletzt sollten Sie das Risiko und die geschäftliche Bedeutung getrennt voneinander abwägen. Ist das System mit dem Internet verbunden oder von Systemen aus erreichbar, auf denen sich ein Angreifer möglicherweise bereits befindet? Befinden sich darauf sensible oder regulierte Daten?

Die von FIRST selbst durchgeführten Vergleiche belegen die Effizienz dieses Ansatzes eindrucksvoll. Eine pauschale Regel für CVSS-Werte ab 7 führt dazu, dass ein großer Teil der Warteschlange in die Behebung aufgenommen wird, während ein EPSS-Schwellenwert einen großen Anteil der tatsächlich ausgenutzten Schwachstellen mit nur einem Bruchteil des Aufwands abdeckt. Es gibt jedoch keinen allgemeingültigen Grenzwert, den man einfach übernehmen kann. Der richtige Schwellenwert hängt von Ihrer eigenen Warteschlange ab.

Wenn Ihr Team nicht über ausreichende Ressourcen verfügt, beginnen Sie mit KEV und Exposure und fügen Sie EPSS später hinzu. Wenn Sie KEV bereits zuverlässig patchen, ist EPSS die nächste Stufe der Risikominderung.

Führe Patches zügig durch und beseitige die Ursachen, die dich daran hindern.

Geschwindigkeit entsteht dadurch, dass Reibungsverluste im Prozess beseitigt werden. Automatisieren Sie die Bereitstellung, damit das Aufspielen von Patches als Pipeline statt als einmaliges Projekt abläuft, denn ein Patch, dessen Einplanung von einem Menschen vorgenommen werden muss, wird oft erst spät eingeplant.

Dann sollten Sie sich direkt mit der Abhängigkeit vom Neustart befassen. Neustarts sind einer der häufigsten Gründe dafür, dass Kernel-Patches nicht angewendet werden. Sie erfordern ein Wartungsfenster, ein Änderungs-Ticket und jemanden, der um 2 Uhr morgens wach ist, um zu bestätigen, dass der Host wieder online ist. Das Patchen ohne Neustart, manchmal auch als Live-Patching, wendet die Korrektur auf den laufenden Kernel im Arbeitsspeicher an, sodass bei unterstützten Sicherheitslücken die Lücke ohne Ausfall geschlossen wird.

KernelCare funktioniert dies bei allen gängigen Linux-Distributionen für Unternehmen, sodass in einer gemischten Infrastruktur nicht für jedes Betriebssystem ein separates Tool erforderlich ist und 24/7-Workloads keine Kompromisse mehr zwischen Verfügbarkeit und CVE-Sicherheitslücken eingehen müssen.

Abdeckung von EOL-Software, für die es keine Hersteller-Patches gibt

All dies setzt voraus, dass der Hersteller weiterhin einen Patch bereitstellt. Bei Komponenten, deren Lebenszyklus beendet ist (EOL), ist dies beim Originalhersteller nicht der Fall, und der übliche Ratschlag, einfach ein Upgrade durchzuführen, geht nicht auf die Frage ein, warum das System überhaupt noch in Betrieb ist.

Meistens liegt es an Hardware, die einen neueren Kernel nicht unterstützt, an einer Anwendung, deren Hersteller nur eine Betriebssystemversion zertifiziert hat, an behördlichen Zulassungsverfahren, die von Grund auf neu durchgeführt werden müssten, oder an technischen Kapazitäten, die bereits für die nächsten drei Quartale ausgebucht sind. Eine strenge E-Mail bezüglich der EOL-Termine löst keines dieser Probleme.

Damit bleiben drei praktikable Optionen.

Option	Am besten, wenn	Achten Sie auf
Jetzt migrieren	Die App ist portabel, und Sie haben in diesem Quartal Kapazitäten zur Verfügung.	Verrutschungen sind normal, und die Exposition hält während des Verrutschens an
Nur Ausgleichssteuerungen	Vollständig isoliert, keine nicht vertrauenswürdigen Eingabepfade	Die Isolierung wird unbemerkt untergraben. Eine einzige Änderung an der Firewall öffnet sie wieder.
Vom Hersteller angebotener erweiterter Support	Sie benötigen die Schließung von CVEs, während Sie die Migration nach Ihrem eigenen Zeitplan durchführen	Stellen Sie genau fest, welche Betriebssystem-Pakete, Laufzeitumgebungen und Bibliotheken abgedeckt sind

Dieser dritte Weg ist genau das, was der „Endless Lifecycle Support“ von TuxCare abdeckt. Er stellt Sicherheitspatches für Laufzeitumgebungen, Bibliotheken, Frameworks und Anwendungen bereit, deren Support durch den Upstream-Entwickler ausgelaufen ist, sowie für die zugrunde liegenden Linux-Distributionen, deren Lebenszyklus beendet ist (EOL), und zwar über die Standard-Paketverwaltung. Die abgedeckten Systeme erhalten weiterhin Sicherheitsupdates mit entsprechender Nachverfolgbarkeit, während die Migration nach einem Zeitplan erfolgt, den das Unternehmen tatsächlich finanzieren kann.

Maßnahmen überprüfen und nachweisen

Das Installieren von Patches ohne Überprüfung ist eine Art Glaubenssystem. Zwei Dinge machen es schwierig, dem Status eines Patches zu vertrauen.

Der erste Fall ist ein stiller Fehler. Das Paket wurde zwar installiert, aber der Dienst wurde nie neu gestartet, oder der Host wurde auf einen früheren Stand zurückgesetzt, oder das Update wurde auf dem Basis-Image und nicht auf dem laufenden Container angewendet. Der zweite Fall ist ein Fehlalarm. Ein Scanner liest eine Versionszeichenfolge aus, übersieht dabei einen zurückportierten Fix und markiert eine geschlossene CVE fälschlicherweise als noch offen.

Eine gute Überprüfung liefert einige konkrete Ergebnisse. Sie erhalten direkt vom laufenden System die Bestätigung, dass der korrigierte Code tatsächlich geladen wurde, sowie einen Abgleich zwischen dem Bericht Ihres Patch-Tools und einem unabhängigen Scan. Für jeden Host und jede CVE wird ein datierter, exportierbarer Datensatz erstellt, der für einen Prüfer bereitliegt. Und in Ihren Tickets wird „behoben“ als bestätigt behandelt, während „versucht“ als eigener, separater Status erfasst wird.

Die Backport-bewusste Überprüfung ist die Schwachstelle unter Linux, da generische Scanner regelmäßig Pakete falsch interpretieren, bei denen die Distribution einen Fix zurückportiert hat, dabei aber die Versionsnummer des Upstreams beibehalten hat. Egal, welchen Scanner Sie verwenden: Vergleichen Sie dessen Ergebnisse mit den Sicherheitshinweisen der Distribution, bevor Sie einen Sprint für eine CVE verschwenden, die bereits geschlossen ist.

Wie TuxCare die Lücke schließt

In der Lücke zwischen „Patch verfügbar“ und „Patch installiert“ treten viele Sicherheitsverletzungen auf. Equifax verfügte bereits 67 Tage vor Beginn des Datendiebstahls über die Korrektur. Im Fall von Log4Shell waren Angreifer bereits aktiv, bevor der erste Patch überhaupt verfügbar war. Teams, denen es gelingt, diese Lücke zu schließen, sind in der Regel diejenigen, die die strukturellen Ursachen für Verzögerungen beseitigt haben – nämlich EOL-Sackgassen, anfällige Pakete, die immer wieder in Builds einschleichen, und Neustarts.

Der Ansatz von TuxCare entspricht genau diesen drei Punkten. Endloser Lebenszyklus-Support umfasst die Laufzeiten, Frameworks, Anwendungen und Betriebssysteme, von denen sich deren Upstream-Anbieter bereits abgewendet haben. SecureChain ersetzt öffentliche Register durch ein von TuxCare verwaltetes Register mit geprüften, kontinuierlich gepatchten Paketen für JavaScript, Python, Java, Go und PHP, wodurch sichergestellt wird, dass Versionen mit bekannten Sicherheitslücken nicht in neue Builds gelangen. KernelCare übernimmt das Patching des Kernels ohne Neustart in gemischten Linux-Umgebungen. Wählen Sie die Lösung, die Ihrem Risikoprofil entspricht.

Beginnen Sie mit einer Bestandsaufnahme, der Sie vertrauen. Entscheiden Sie dann, was Sie zuerst in Angriff nehmen möchten.

FAQs