Die Behebung von Sicherheitslücken ist der Prozess der Beseitigung von Sicherheitsmängeln, unabhängig davon, ob diese im von Ihrem Team geschriebenen Code, in den von Ihnen genutzten Open-Source-Paketen, in den von Ihnen bereitgestellten Containern oder in den von Ihnen betriebenen Cloud-Konten liegen. Sicherheitslücken sind mittlerweile der häufigste Einfallstor für Angreifer. Der „Verizon Data Breach Investigations Report 2026“ ergab, dass die Ausnutzung von Sicherheitslücken zum ersten Mal gestohlene Anmeldedaten als häufigsten Erstzugangsvektor überholte und 31 % der Sicherheitsvorfälle ausmachte – ein Anstieg gegenüber 20 % im Vorjahr.
Die meisten Teams wissen bereits von mehr Sicherheitslücken in ihrem Code, als sie beheben können. Derselbe Bericht ergab, dass im Jahr 2025 nur 26 % der Sicherheitslücken im „Known Exploited Vuln“ (KEV) -Katalog der CISA vollständig behoben waren und sich die mittlere Zeit bis zur Behebung einer Sicherheitslücke auf 43 Tage verlängerte.
Dieser Leitfaden beschreibt Schritt für Schritt den Prozess zur Behebung von Sicherheitslücken, wie Sie Prioritäten setzen, welche Probleme zuerst behoben werden sollten, und wie Sie die einzelnen Arten von Sicherheitslücken beheben können – einschließlich der Vorgehensweise für den Fall, dass ein Upgrade einer Abhängigkeit nicht möglich ist. Wenn Sie nach Tools suchen, die diese Aufgabe übernehmen, sehen Sie sich unsere Übersicht über Tools zur Behebung von Sicherheitslücken an.
{{cta}}
Wo die Schwachstellen liegen
Ihr eigener Code
Sicherheitslücken im von Ihrem Team geschriebenen Code lassen sich in zwei Gruppen einteilen, die zwei verschiedene Bereiche des Sicherheitsstacks erfordern. Musterbasierte Fehler sind diejenigen, die von „ SAST “ bei jedem Commit deterministisch erkannt werden.
SAST ist eine regelbasierte, deterministische Engine, die auf Musterabgleich basiert. Sie eignet sich gut für Fehler mit einer erkennbaren Struktur, wie zum Beispiel: „Wenn Benutzereingaben in diese Funktion gelangen, ohne zuvor durch einen Sanitizer geleitet worden zu sein, kennzeichne dies als SQL-Injection.“ Logische Fehler weisen keine solche Struktur auf. Es gibt kein Muster für einen Endpunkt, der prüfen sollte, ob der Benutzer Eigentümer einer Ressource ist, dies aber nicht tut. Um solche Fehler zu erkennen, muss man daher darüber nachdenken, was der Code eigentlich tun soll. Das ist die Aufgabe der KI-Codeüberprüfung, die den Code mit dieser Absicht im Hinterkopf liest, sowie von „ KI-Penetrationstests “, das die laufende App untersucht, um nachzuweisen, ob ein Fehler tatsächlich ausgenutzt werden kann.
Beide Arten der Behebung von Sicherheitslücken erfordern Codeänderungen durch denjenigen, der für den Code verantwortlich ist. Musterbasierte Korrekturen folgen bewährten Vorgehensweisen wie der Parametrisierung einer Abfrage oder der Kodierung der Ausgabe. Logikfehler hängen davon ab, was der Code eigentlich leisten sollte; daher erfordert deren Behebung dasselbe Verständnis der Anwendung, das auch für deren Aufdeckung erforderlich war. Wenn ein KI-Tool bereits aufgezeigt hat, wie eine fehlende Autorisierungsprüfung ausgenutzt werden kann, kann es auf der Grundlage dieser Analyse eine Korrektur vorschlagen, und der Prüfer erhält zusammen mit der Änderung eine Erläuterung.
Open-Source-Abhängigkeiten
Der Großteil des Codes in einer modernen Anwendung stammt aus Open-Source-Paketen, und bei den meisten davon handelt es sich um transitive Abhängigkeiten, die von den von Ihnen ausgewählten Paketen mit einbezogen werden. Daher befinden sich die meisten Sicherheitslücken hier in Code, den niemand aus Ihrem Team geschrieben oder gar ausgewählt hat.
Software-Kompositionsanalyse (SCA) liest Ihre Lockfiles aus, um den vollständigen Abhängigkeitsbaum zu erstellen, und gleicht anschließend die Version jedes Pakets mit einer Quelle für Schwachstellendaten ab. Diese Quelle entscheidet, welche Schwachstellen erkannt werden. Tools, die sich ausschließlich auf öffentliche CVE-Datenbanken stützen, übersehen Open-Source-Schwachstellen, die in einer Version behoben werden, ohne dass jemals eine CVE-Kennung vergeben wurde. Aus diesem Grund greifen einige SCA -Tools, darunter auch Aikido, auf Bedrohungsaufklärung -Feeds wie Aikido Intel zurück.
Eine Sicherheitslücke allein sagt noch nichts darüber aus, ob sie für Sie von Bedeutung ist. Eine CVE in einer Funktion, die Ihr Code niemals aufruft, ist nicht erreichbar und stellt kaum ein echtes Risiko dar, während dieselbe CVE in einer Funktion, die Sie überall verwenden, es wert ist, andere Arbeiten dafür zurückzustellen. Ein CVSS-Wert kann hier keinen Unterschied machen, da er die Schwachstelle abstrakt bewertet und nicht berücksichtigt, wie anfällig Ihre App tatsächlich ist.
SCA Die Prüfungen müssen auch nach dem Merge weiterlaufen. Die Paketversionen in Ihrer Lockfile-Datei bleiben fest vorgegeben, während immer wieder neue Sicherheitslücken in diesen Versionen bekannt werden. Daher kann ein Abhängigkeitsbaum, der letzten Monat noch erfolgreich war, heute fehlschlagen, ohne dass jemand daran etwas geändert hat. Wenn eine Sicherheitslücke bekannt wird, besteht die Standardlösung darin, auf eine Version zu aktualisieren, die diese behebt. Im nächsten Abschnitt wird erläutert, warum dieses Upgrade oft zu einem größeren Aufwand wird, als es zunächst den Anschein hat.
Container-Images
Der Großteil der Sicherheitslücken in einem „ container “-Image stammt aus dem Basis-Image, auf dem es aufbaut. Ein typisches Basis-Image enthält Dutzende von Systembibliotheken und Tools, wie beispielsweise eine Shell und einen Paketmanager, und beim „ container “-Image-Scan werden genau diese Pakete auf Betriebssystemebene überprüft. Außerdem unterliegen Images einer Entwicklung, die leicht zu übersehen ist. Ein laufendes „ container “ behält die Pakete bei, mit denen es erstellt wurde, bis jemand es neu erstellt und bereitstellt. Daher kann ein in der Produktion laufendes „ container “ monatelang keinen Fix erhalten, der bereits im Upstream vorhanden ist.
Die Behebung eines Sicherheitsproblems hängt davon ab, inwieweit Sie bereit sind, diese Grundlage zu ändern. Das Entfernen von Paketen, die Ihre Laufzeitumgebung nie nutzt, schränkt das Problem ein. Für alles, was verbleibt, bedeuten sowohl ein Upgrade auf ein neueres Basis-Tag als auch die Migration auf eine gehärtete Distribution eines anderen Anbieters, dass Sie Ihre Anwendung auf einer anderen Grundlage testen müssen, während ein gepatchter Build derselben Basisversion die CVEs schließt und alles andere unverändert lässt.
Infrastructure as Code (IaC)
Mit IaC werden Cloud-Konfigurationen in Dateien wie Terraform- und CloudFormation-Vorlagen, Helm-Charts und Kubernetes-Manifeste übertragen, sodass der Großteil Ihrer Cloud-Konfiguration wie jeder andere Code überprüft werden kann. Zu den typischen Schwachstellen zählen:
- Ein für das Internet zugänglicher Speicher-Bucket
- Eine Sicherheitsgruppe, die Datenverkehr von überall akzeptiert
- Ein „ container “, der als Root ausgeführt wird
- Eine EC2-Instanz, die noch IMDSv1 verwendet, die ältere Version des Metadatendienstes von AWS, auf die sich SSRF-Angriffe stützen, um Anmeldedaten zu stehlen
Mit IaC lassen sich Fehlkonfigurationen in der Cloud am einfachsten beheben, da noch keine Änderungen übernommen wurden. IaC-Prüfungen werden in Ihrer CI/CD-Pipeline ausgeführt und im Pull-Request markiert. Die Korrektur erfolgt durch eine angepasste Vorlage – oft eine Änderung von nur einer Zeile –, die niemals in eine Produktionsumgebung gelangt. Der Haken dabei ist, dass IaC-Prüfungen nur das erkennen, was in Ihren Vorlagen steht.
Cloud Konfiguration
In einer ausgereiften IT-Organisation wird der Großteil der Cloud-Infrastruktur über IaC definiert, sodass viele Cloud-Befunde eigentlich IaC-Befunde sind, die es bis zur Umsetzung geschafft haben. Der Rest stammt aus Änderungen, die niemand dokumentiert hat. Jemand klickt sich durch die Konsole, um einen Port zu öffnen oder eine Rolle zu erweitern, und es gibt weder eine Vorlage noch einen Pull-Request, der dies festhält.
Cloud Sicherheitsstatus-Management (CSPM) liest direkt aus dem Live-Konto aus und erfasst so diese Änderungen sowie alles, was bei der Überprüfung übersehen wurde. Die Korrektur erfolgt durch eine Konfigurationsänderung oder eine verschärfte Richtlinie und muss wieder in die IaC übernommen werden. Wird die Ressource bereits über eine Vorlage verwaltet, wird eine ausschließlich über die Konsole vorgenommene Korrektur beim nächsten Deployment rückgängig gemacht. Wurde sie manuell erstellt, bedeutet die Einbindung in die IaC, dass die nächste Änderung an ihr einer Überprüfung unterzogen wird.
Einige der schwerwiegendsten Befunde erstrecken sich über mehrere Ebenen hinweg, und die MLflow-SSRF-Sicherheitslücke (CVE-2026-64849) veranschaulicht dies. Bereits wenige Stunden, nachdem ihr im August 2026 eine CVE-Nummer zugewiesen worden war, nutzten Angreifer sie aus, um MLflow-Server dazu zu bringen, den Metadatendienst des Cloud-Anbieters nach deren eigenen Anmeldedaten abzufragen. Bei AWS gibt IMDSv1 diese als Antwort auf eine einfache Anfrage weiter. IMDSv2 erfordert zunächst ein Sitzungstoken – ein zusätzlicher Schritt, den die meisten SSRF-Fehler nicht ausführen können; daher hätte die Durchsetzung dieser Anforderung den Diebstahl wahrscheinlich verhindert.
Welche Anmeldedaten Angreifer auch immer erlangen konnten, ihre Zugriffsrechte waren nur so weitreichend wie die dem Server zugewiesene IAM-Rolle, und da diese Rollen in der Regel ebenfalls in Terraform oder CloudFormation hinterlegt sind, können IaC-Prüfungen eine zu weit gefasste Richtlinie bereits vor der Bereitstellung erkennen. Beide Sicherheitsvorkehrungen befinden sich in denselben Vorlagen, die von den IaC-Prüfungen ohnehin bereits ausgewertet werden, was IaC zum kostengünstigsten Ansatzpunkt macht, um einen solchen Angriff zu verhindern.
Secrets
Secrets landen oft versehentlich im Code. Ein API-Schlüssel wird in einem Test fest codiert, oder ein Datenbankpasswort gelangt versehentlich in eine Konfigurationsdatei, die zusammen mit allem anderen committet wird. Insbesondere von KI geschriebener Code neigt zu diesem Problem. Die Erkennung unter Secrets überprüft neue Commits und den gesamten Git-Verlauf darauf, und ein Pre-Commit-Hook kann solche Einträge blockieren, bevor sie überhaupt committet werden. Container -Images benötigen dieselbe Überprüfung, da ein in eine Schicht kopiertes Geheimnis im Image verbleibt, selbst wenn es in einer späteren Schicht gelöscht wird.
Das Löschen des Geheimnisses aus dem Code behebt das Problem nicht, da es sich weiterhin in der Git-Historie befindet. Die Lösung besteht darin, die Anmeldedaten zu ändern und anschließend die Zugriffsprotokolle zu überprüfen, um festzustellen, ob jemand die alten Daten vor der Änderung verwendet hat. Wenn die Protokolle zeigen, dass jemand anderes darauf zugegriffen hat, müssen Sie herausfinden, auf welche Daten der Angreifer zugegriffen hat und ob die betroffenen Daten Meldepflichten im Falle einer Datenschutzverletzung auslösen. Sobald die alten Anmeldedaten ungültig sind, ist das Löschen aus der Historie zwar eine gute Praxis, aber nicht mehr dringend erforderlich. Um zu verhindern, dass sich so etwas wiederholt, sollten Sie das Geheimnis in einen „ secrets -Manager“ oder in eine Umgebungsvariable verschieben, die der Code zur Laufzeit ausliest.
Wenn ein Upgrade einer Abhängigkeit nicht in Frage kommt
Die meisten „ SCA “-Tools und Sicherheitshinweise geben bei einem anfälligen Paket denselben Rat: ein Upgrade auf die Version mit dem Fix. Bei einer Erhöhung der Patch-Nummer reicht das in der Regel schon aus. Probleme treten erst auf, wenn der Fix nicht so nahtlos bereitgestellt wird – was in der Praxis oft der Fall ist.
Probleme entstehen, wenn die Korrektur erst in einer neuen Hauptversion mit kompatibilitätsbrechenden API-Änderungen verfügbar ist oder wenn das anfällige Paket transitiv ist und Ihr Upgrade von einem Betreuer abhängt, der drei Ebenen höher in der Struktur steht. Für aufgegebene Pakete und Versionen, deren Lebenszyklus abgelaufen ist, gibt es überhaupt keine gepatchten Releases, und gerade durch reflexartiges Upgraden gelangten die manipulierten Versionen von „chalk“ und „debug“ innerhalb weniger Minuten in die Pipelines. Daher verschieben Teams das Upgrade, und die CVE landet auf einer Ignorierliste, die immer länger wird.
CVE-2026-48937 in Node.js zeigt, wie sich dies auswirkt. Der Fix wurde zusammen mit einem Semver-Major-Update für nghttp2 ausgeliefert, bei dem die HTTP/2-Prioritätssignalisierung vollständig entfernt wurde, da das anfällige Verhalten und die entfernte Funktion auf demselben zugrunde liegenden Code beruhten. Für ein Team, das einen HTTP/2-Dienst betreibt, wurde aus einer einzeiligen Versionserhöhung eine Suche nach jedem Aufruf von `setPriority` und `.priority()` – sowohl im eigenen Code als auch in allen Abhängigkeiten, die auf denselben APIs basierten –, während die CVE weiterhin offen blieb.
Backporting ist der direkteste Weg: Dabei wird der Fix auf die Version angewendet, die Sie bereits nutzen. Sie können das Paket forken und dies selbst vornehmen – allerdings sind Sie dann für diesen Fork verantwortlich – oder einen gepatchten Build eines Anbieters verwenden, der Backports bereitstellt, wie beispielsweise Aikido Security für Open-Source-Pakete und container für Images. Sie können den CVE schließen und das Upgrade durchführen, sobald Ihr Team Zeit hat, es ordnungsgemäß zu testen.
Bewährte Verfahren zur Behebung von Sicherheitslücken
SLAs nach Risiko festlegen
Sobald Sie die Ergebnisse nach Ausnutzbarkeit und Risiko eingestuft haben, legen Sie für jede Risikostufe eine Frist fest, die Ihr Team einhalten kann. Ein Service Level Agreement (SLA), das für eine in der KEV-Liste aufgeführte Schwachstelle in einem internetgestützten Dienst in Tagen und für eine erreichbare Schwachstelle in einem internen Tool in Wochen gemessen wird, sorgt für eine geordnete Reihenfolge in der Warteschlange. Verfolgen Sie auch Verstöße gegen diese SLAs, da ein Muster von Verstößen in einem Team oder auf einer Ebene in der Regel auf ein Prozessproblem hindeutet, das behoben werden sollte.
Integrieren Sie Korrekturen dort, wo die Entwickler bereits arbeiten
Ein Befund, der in einem Sicherheits-Dashboard verbleibt, konkurriert mit all den anderen Aufgaben, die ein Entwickler zu bewältigen hat – und unterliegt dabei meist. Wird der Fehler bereits während des Schreibens des Codes in der IDE oder im Pull-Request vor dem Merge angezeigt, sieht der Entwickler ihn, solange die Änderung noch frisch im Gedächtnis ist. Zu diesem Zeitpunkt hat er den besten Überblick darüber, was der Code bewirken soll, und die Behebung kostet am wenigsten – noch bevor der Code veröffentlicht wird. Außerdem klärt sich dadurch die Frage nach der Zuständigkeit, denn wer den Pull-Request erstellt hat, ist offensichtlich auch derjenige, der den Fehler beheben sollte.
Korrekturen automatisieren, die das Verhalten nicht verändern
Backportierte Patches und Patch-Level-Erhöhungen, die Ihre Tests bestehen, können nach einer kurzen Überprüfung zusammengeführt werden, da sie eine CVE schließen, ohne das Verhalten Ihres Codes zu verändern. Korrekturen für Logikfehler wie einen IDOR oder eine fehlende Autorisierungsprüfung verändern das Verhalten; daher sind sie am nützlichsten, wenn sie mit einer Begründung eingereicht werden, aus der hervorgeht, wie der Fehler ausgenutzt werden könnte und was die Korrektur bewirkt – das beschleunigt die Überprüfung. Bei Upgrades, die eine Hauptversionsgrenze überschreiten, hilft die Automatisierung am wenigsten; der obige Abschnitt zur „Upgrade-Falle“ behandelt bessere Optionen für solche Fälle.
Vor dem Schließen erneut prüfen
Führen Sie den Test, der die Schwachstelle aufgedeckt hat, erneut mit der korrigierten Version durch und schließen Sie den Befund erst dann, wenn er nicht mehr auftritt. Bei Befunden in einer laufenden Anwendung bedeutet dies, dass die produktive Umgebung erneut getestet werden muss, da eine Korrektur, die in einem Zweig erfolgreich ist, hinter einem falsch konfigurierten Proxy oder einem alten Build, der nie erneut bereitgestellt wurde, immer noch fehlschlagen kann.
Wie „ Aikido Security“ die Behebung von Sicherheitslücken handhabt
Aikido Der Sicherheitsbereich umfasst die Behebung von Schwachstellen vom ersten Anzeichen bis hin zum Pull-Request, mit dem die Schwachstelle behoben wird. Den Anfang macht „Aikido Intel“, das Schwachstellen in Open-Source-Paketen nachverfolgt, noch bevor ihnen eine CVE-Kennung zugewiesen wird – darunter auch viele, die niemals eine erhalten werden –, sodass mit der Behebung bereits vor der Veröffentlichung in den öffentlichen Datenbanken begonnen werden kann.
Jeder Befund durchläuft anschließend zwei Phasen der „ triage “. „ Erreichbarkeitsanalyse “ ermittelt, ob Ihr Code einen Ausführungsweg zu der anfälligen Funktion enthält, wodurch CVEs in Paketen entfernt werden, die Sie zwar einbinden, aber nie nutzen. Was übrig bleibt, wird an CVE Ausnutzbarkeitsanalyse weitergeleitet – einen Agenten, der analysiert, wie Ihr Code das Paket tatsächlich nutzt, und dann auf jeden Befund reagiert: Er erhöht den Schweregrad, wenn eine CVE in Ihrer Umgebung gefährlicher ist, als es die Basisbewertung vermuten lässt; senkt ihn, wenn sie weniger gefährlich ist; verschiebt Befunde zur späteren Überprüfung oder ignoriert diejenigen, die überhaupt nicht ausnutzbar sind. Zusammen reduzieren sie den „Lärm“ um bis zu 95 %.
Korrekturen werden als AutoFix-Pull-Requests bereitgestellt. Bei Code- und IaC-Befunden schreibt AutoFix die Änderung selbst. Bei Abhängigkeiten und Containern erfolgt die Korrektur durch einen Backport. „Aikido -Bibliotheken“ stellen gepatchte Builds der Paketversionen bereit, die Sie bereits über npm, PyPI, Maven und Go ausführen, sodass die CVE ohne Versionssprung oder API-Änderung geschlossen wird – selbst wenn im Upstream noch keine gepatchte Version vorliegt. Aikido Images tut dasselbe auf der Ebene „ container “ mit über 2.000 direkt einsetzbaren Ersatz-Images, die hohe und kritische CVEs gemäß einem definierten SLA für die von Ihnen bereits verwendete Betriebssystemversion und Distribution beseitigen.
Beide werden als tägliche AutoFix-Pull-Anfragen in den Workflow integriert, den Ihr Team bereits nutzt. Eine Pull-Anfrage muss noch getestet und bereitgestellt werden, bevor die Sicherheitslücke tatsächlich behoben ist – und genau diesen Schritt übernimmt AutoShip. Fügen Sie einer AutoFix-Pull-Anfrage ein Label hinzu, und AutoShip leitet sie von der CI über die Staging-Umgebung bis in die Produktion weiter, führt dabei Smoke-Tests durch und achtet auf Regressionen, sodass die Korrektur in die Produktion gelangt, ohne dass ein Entwickler von seiner eigentlichen Arbeit abgezogen werden muss.
Aikido Außerdem stellt das Unternehmen der Open-Source-Community kostenlos zurückportierte Korrekturen für in der KEV-Liste aufgeführte Sicherheitslücken zur Verfügung, sodass die Schwachstellen, die Angreifer aktiv ausnutzen, für alle behoben werden – unabhängig davon, ob es sich um Kunden handelt oder nicht. Und da jede Korrektur über dieselbe Plattform läuft, wird jede einzelne als Nachweis für „ compliance “ im Rahmen von SOC 2 und den von „ Aikido “ unterstützten ISO-Normen erfasst, darunter ISO 27001 und ISO 42001.
{{walkthrough}}
