CVE-Behebung: vom Advisory zum behobenen, ausgelieferten Build

Der Prozess der CVE-Behebung

Die CVE-Behebung entfernt eine öffentlich offengelegte Schwachstelle aus Software, die Sie betreiben oder ausliefern. Bei Ihrem eigenen Code bedeutet das einen Patch. Bei Open-Source-Abhängigkeiten, aus denen die meisten CVEs in einem typischen Produkt stammen, bedeutet es, zu einer Version zu gelangen, in der die Schwachstelle behoben ist. In beiden Fällen sind die Schritte dieselben:

1. Finden Sie jedes Produkt, jeden Build und jedes Release, das das betroffene Paket in der betroffenen Version enthält.
2. Bewerten Sie, ob und wie stark die Schwachstelle Sie betrifft.
3. Priorisieren Sie gegenüber allem anderen, was offen ist.
4. Beheben Sie durch Upgrade, Patch, Ersatz oder, wenn es keinen Fix gibt, durch Mitigation.
5. Verifizieren Sie, dass der neue Build tatsächlich die behobene Version enthält.
6. Dokumentieren Sie, was betroffen war, was Sie entschieden haben und wann der Fix ausgeliefert wurde.

Schritt 1: jeden betroffenen Build finden

Die erste Frage nach einem Advisory ist, wo das Paket steckt. Sie anhand der Quell-Repositories zu beantworten, ist langsam und oft falsch: Die Version im Lockfile, die von einem Build aufgelöste Version und die Version in einem veröffentlichten Container-Image können sich alle unterscheiden. Transitive Abhängigkeiten und Pakete, die ein Build außerhalb des Paketmanagers herunterlädt, tauchen in Manifesten gar nicht auf.

Die verlässliche Antwort liefert eine SBOM jedes Release, die laufend mit Advisories abgeglichen wird. Wird diese SBOM während des Builds aufgezeichnet, listet sie auf, was der Build tatsächlich genutzt hat, und der Abgleich sagt Ihnen, welche ausgelieferten Builds die verwundbare Version enthalten, nicht welche Repositories sie erwähnen.

Schritt 2: nach Schweregrad und Ausnutzung priorisieren

Der Schweregrad allein stuft zu viele Schwachstellen als dringend ein. Die meisten Teams kombinieren drei Signale:

Signal	Was es Ihnen sagt	Veröffentlicht von
CVSS	Wie schwerwiegend die Schwachstelle bei Ausnutzung ist, bewertet von 0 bis 10	FIRST (der Standard); NVD und Hersteller veröffentlichen Scores
EPSS	Die geschätzte Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen	FIRST
KEV	Ob die Schwachstelle bekanntermaßen in freier Wildbahn ausgenutzt wird	Known-Exploited-Vulnerabilities-Katalog von CISA

Ergänzen Sie dann Ihren eigenen Kontext: ob das betroffene Paket an Kunden ausgeliefert wird oder nur in einem Test-Job läuft und ob die verwundbare Funktion überhaupt genutzt wird. Eine bekanntermaßen ausgenutzte Schwachstelle in einem ausgelieferten Paket kommt ganz nach oben auf die Liste. Die Priorisierung von Schwachstellen macht aus diesen Signalen eine Methode.

Fristen für die Behebung

• CISA BOD 26-04. Seit dem 10. Juni 2026 legen US-Bundesbehörden jede Frist anhand von vier Fragen fest: Ist das Asset öffentlich exponiert, steht die Schwachstelle im KEV-Katalog, lässt sich die Ausnutzung automatisieren, und verschafft sie teilweise oder vollständige Kontrolle? Die Antworten reichen von 3 Tagen, mit forensischer Triage für die schwersten Fälle, bis zur Behebung beim nächsten System-Upgrade. Die Direktive ersetzte BOD 22-01, die für die meisten KEV-Einträge zwei Wochen vorsah.
• EU Cyber Resilience Act. Hersteller müssen Schwachstellen unverzüglich behandeln und beheben, auch durch Sicherheitsupdates (Anhang I Teil II). Seit dem 11. September 2026 setzt eine aktiv ausgenutzte Schwachstelle in einem Produkt außerdem eine Meldefrist in Gang: eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und ein Abschlussbericht innerhalb von 14 Tagen, nachdem ein Fix verfügbar ist.
• Ihre eigene Richtlinie. Die meisten Sicherheitsprogramme setzen interne Ziele nach Schweregrad. Wie auch immer sie aussehen, Sie können sie nur einhalten, wenn Schritt 1 schnell geht.

Schritt 3: den Fix wählen

Option	Wann sie passt
Upgrade	Es gibt eine behobene Version. Bevorzugen Sie das kleinste Upgrade, das den Fix enthält, um Breaking Changes zu begrenzen.
Upgrade des übergeordneten Pakets	Das verwundbare Paket ist transitiv. Ein neueres Release der direkten Abhängigkeit bringt den Fix oft mit.
Override	Das übergeordnete Paket hat keinen Fix veröffentlicht. Erzwingen Sie die transitive Version mit npm overrides, Yarn resolutions oder pnpm.overrides und testen Sie sie.
Patch oder Backport	Sie können noch nicht auf die behobene Major-Version wechseln. Übernehmen Sie den Upstream-Fix in die Version, die Sie nutzen.
Ersatz	Das Paket wird nicht mehr gepflegt oder erzeugt immer wieder CVEs. Wechseln Sie zu einer Alternative.
Mitigieren und dokumentieren	Es gibt noch keinen Fix, oder Ihr Produkt ist nicht betroffen. Verringern Sie die Exposition und dokumentieren Sie die Bewertung, zum Beispiel als VEX-Aussage.

Der Großteil dieses Schritts lässt sich automatisieren, von der Wahl der Version bis zum Öffnen des Pull Requests. Automatisierte Schwachstellenbehebung beschreibt, was Sie automatisieren und was Sie einem Menschen überlassen sollten.

Schritt 4: Ein gemergter Fix ist kein ausgelieferter Fix

Der Pull Request ist gemergt, also ist die CVE erledigt. Nicht unbedingt. Der Fix liegt im Repository, aber ein Build stellt einen veralteten Cache wieder her, ein Basis-Image enthält noch das alte Paket, oder ein Release-Branch hat die Änderung nie übernommen. Im Ticket steht „behoben“, während das Produkt weiterhin die verwundbare Version ausliefert.

Schließen Sie den Kreis vom anderen Ende her: Prüfen Sie die SBOM des nächsten Builds und bestätigen Sie, dass die verwundbare Version verschwunden ist. Zeichnet diese SBOM auf, was der Build tatsächlich geladen hat, einschließlich aus Caches wiederhergestellter Pakete, beantwortet die Prüfung genau die Frage, die Kunde, Auditor und Aufsichtsbehörde wirklich stellen.

Wie CRACI die CVE-Behebung unterstützt

• Finden. CRACI zeichnet die Pakete auf, die jeder GitHub-Actions-Job geladen hat, einschließlich transitiver Abhängigkeiten und aus Caches wiederhergestellter Pakete, und bewertet überwachte SBOMs laufend neu. Organisationsansichten fassen Befunde über Builds und Repositories hinweg zusammen, sodass Sie sehen, welche Builds eine neue CVE betrifft.
• Zuweisen. Sicherheitsteams sichten jeden Befund und leiten ihn an das Team weiter, das für den Fix zuständig ist. CRACI unterstützt VEX, um festzuhalten, wie sich eine Schwachstelle auf Ihr Produkt auswirkt.
• Verifizieren. Jeder neue Build erhält seine eigene SBOM mit Vollständigkeitsstatus, sodass Sie bestätigen können, dass der Build die behobene Version genutzt hat.
• Melden. Bei aktiv ausgenutzten Schwachstellen nach dem CRA übermittelt CRACI die Meldungen im Namen des Herstellers an die Behörden.

Den vollen Funktionsumfang finden Sie unter Schwachstellenverfolgung.

CVE-Behebung: häufig gestellte Fragen

Was ist CVE-Behebung?

CVE-Behebung bedeutet, eine öffentlich offengelegte Schwachstelle, identifiziert durch ihre CVE-ID, aus der Software zu entfernen, die Sie betreiben oder ausliefern. Bei einer Abhängigkeit heißt das meist ein Upgrade auf eine Version, in der die Schwachstelle behoben ist. Bei Ihrem eigenen Code heißt es, ihn zu patchen.

Wie priorisiere ich, welche CVEs ich zuerst behebe?

Kombinieren Sie den Schweregrad mit Belegen für eine Ausnutzung. CVSS beschreibt, wie schwer eine Schwachstelle wiegt, EPSS schätzt, wie wahrscheinlich ihre Ausnutzung in den nächsten 30 Tagen ist, und der Known-Exploited-Vulnerabilities-Katalog von CISA führt jene auf, die bereits ausgenutzt werden. Eine bekanntermaßen ausgenutzte Schwachstelle in einem Paket, das Sie ausliefern, kommt ganz nach oben.

Wie schnell müssen CVEs behoben werden?

Das hängt davon ab, wer fragt. Die Binding Operational Directive 26-04 von CISA gibt US-Bundesbehörden zwischen 3 Tagen und dem nächsten System-Upgrade, je nachdem, ob die Schwachstelle im KEV-Katalog steht, ob das Asset öffentlich exponiert ist, ob sich die Ausnutzung automatisieren lässt und wie viel Kontrolle sie einem Angreifer verschafft. Der EU Cyber Resilience Act verlangt von Herstellern, Schwachstellen unverzüglich zu beheben, und seit dem 11. September 2026 setzt eine aktiv ausgenutzte Schwachstelle in einem Produkt eine 24-Stunden-Meldefrist in Gang.

Was, wenn es noch keine behobene Version gibt?

Mitigieren und dokumentieren. Deaktivieren Sie die betroffene Funktion, blockieren Sie den Angriffsweg oder tauschen Sie die Komponente aus, wenn möglich, und dokumentieren Sie Ihre Bewertung, zum Beispiel als VEX-Aussage. Achten Sie dann auf das behobene Release und beheben Sie die Schwachstelle, sobald es erscheint.

Wie behebe ich eine CVE in einer transitiven Abhängigkeit?

Versuchen Sie zuerst ein Upgrade der direkten Abhängigkeit, die sie mitbringt, denn ein neueres Release enthält den Fix oft. Gibt es noch keines, lassen die meisten Paketmanager Sie die Version eines transitiven Pakets erzwingen: overrides in npm, resolutions in Yarn, pnpm.overrides in pnpm. Testen Sie das Ergebnis, denn das übergeordnete Paket wurde nicht gegen diese Version gebaut.