Behebung
KI-Codekorrekturen und automatisierte Behebung, von Menschen freigegeben
KI-Codekorrekturen sind Änderungen, die ein KI-Modell vorschlägt, um eine Schwachstelle zu beseitigen, meist ein Abhängigkeits-Upgrade oder eine kleine Codeänderung. Sie können die Zeit bis zur Behebung verkürzen, aber eine Person sollte jede einzelne freigeben, denn ein Fix kann bestehendes Verhalten brechen, neue transitive Pakete mitbringen, eine Lizenz ändern oder das Problem schlicht nicht lösen.
Free-Tarif, keine Kreditkarte erforderlich.
Was sind KI-Codekorrekturen und automatisierte Schwachstellenbehebung?
Automatisierte Schwachstellenbehebung umfasst jedes Werkzeug, das aus einem Befund eine vorgeschlagene Änderung macht. Bei einer verwundbaren Abhängigkeit ist das meist eine neue Version im Manifest und ein neu erzeugtes Lockfile. Bei einem Befund aus der Quellcodeanalyse ist es eine Codeänderung, etwa eine aus Strings zusammengesetzte Abfrage durch eine parametrisierte zu ersetzen. Bei einer Fehlkonfiguration ist es eine geänderte Einstellung in einem Dockerfile oder einer Terraform-Datei. KI-Modelle werden inzwischen sowohl eingesetzt, um diese Änderungen zu schreiben, als auch, um sie zu erklären.
Die Ansätze unterscheiden sich vor allem darin, wie viel eine Person sieht, bevor eine Änderung übernommen wird. Am einen Ende schlägt ein Tool neben einem Befund einen Fix vor, und jemand aus dem Entwicklungsteam übernimmt ihn von Hand. In der Mitte bereitet ein Tool eine Änderung vor, die jemand prüft. Am anderen Ende werden Änderungen automatisch gemergt, sobald die Tests bestehen. Je näher ein Prozess am automatischen Merge liegt, desto mehr hängt er von Tests ab, die einen fehlerhaften oder unvollständigen Fix erkennen würden.
Warum eine Person jeden Fix freigeben sollte
Ein vorgeschlagener Fix ist eine Änderung am Produktionscode, geschrieben von etwas, das Ihr Produkt nicht in den Umgebungen Ihrer Kunden ausführen kann. Das Modell kann überzeugt klingen und falschliegen, und ein sauberer Diff kann eine Verhaltensänderung verbergen. Freigabe heißt nicht, die Arbeit neu zu machen; sie heißt, dass eine namentlich benannte Person die folgenden Punkte geprüft hat und die Änderung annimmt. Dieser Eintrag ist später auch ein Nachweis, wenn Sie zeigen müssen, wie eine Schwachstelle behandelt wurde.
- Breaking Changes: Ein Major-Upgrade kann APIs entfernen oder ändern, die Ihr Code aufruft.
- Transitive Upgrades: Eine neue Version kann neue Pakete nachziehen, jedes mit eigenen Schwachstellen und eigenen Maintainern.
- Lizenzänderungen: Ein neues Release kann auf eine Lizenz wechseln, die Ihre Organisation nicht akzeptiert.
- Regressionsrisiko: Verhalten, das Ihre Tests nicht abdecken, kann sich unbemerkt ändern.
- Unvollständige Fixes: Die Änderung kann einen betroffenen Codepfad übersehen oder auf den falschen Versionsbereich zielen.
- Erfundene Details: eine vorgeschlagene Version oder ein Paket, das es nicht gibt.
Wie Sie ein vorgeschlagenes Abhängigkeits-Upgrade bewerten
Gehen Sie vom Sicherheitshinweis aus, nicht vom Vorschlag. Im OSV-Format halten die betroffenen Bereiche (affected ranges) eines Sicherheitshinweises fest, wo eine Schwachstelle eingeführt und in welcher Version sie behoben wurde. Der kleinste sichere Schritt ist meist das erste behobene Release auf der Versionslinie, die Sie bereits nutzen, weil es am wenigsten ändert. Ein Sprung auf die neueste Major-Version behebt vielleicht mehr, ist aber neben dem Sicherheitsfix auch ein Funktions-Upgrade und verdient ein eigenes Review.
Wenn Sie das verwundbare Paket nicht selbst deklarieren, kommt es über eine direkte Abhängigkeit herein. Das transitive Paket allein zu aktualisieren, kann mit dem kollidieren, was seine übergeordnete Abhängigkeit erwartet; der sauberere Fix ist daher meist, diese übergeordnete Abhängigkeit auf ein Release zu heben, das das verwundbare Paket auf eine behobene Version auflöst. Overrides im Paketmanager sind eine Notlösung, solange es ein solches Release noch nicht gibt; dokumentieren Sie sie, damit sie entfernt werden, sobald die übergeordnete Abhängigkeit nachgezogen hat.
| Prüfung | Worauf Sie achten |
|---|---|
| Behobene Version | Der Sicherheitshinweis führt die vorgeschlagene Version oder eine frühere auf derselben Linie als behoben. |
| Direkt oder transitiv | Bei einem transitiven Paket ist die direkte Abhängigkeit bekannt, die Sie anheben müssen. |
| Lockfile-Diff | Nur die erwarteten Pakete ändern sich, und es tauchen keine unerwarteten neuen Pakete auf. |
| Release Notes | Keine Breaking Changes, keine entfernten Funktionen und kein Lizenzwechsel. |
| Tests | Die Testsuite läuft durch und deckt den Code ab, der das Paket nutzt. |
| Herkunft | Die Version wurde in der offiziellen Registry von den üblichen Maintainern des Pakets veröffentlicht. |
Was der Cyber Resilience Act zur Behebung sagt
Anhang I Teil II der Cyberresilienz-Verordnung, Verordnung (EU) 2024/2847, legt die Anforderungen an die Behandlung von Schwachstellen für Hersteller fest. Nummer 2 verlangt von ihnen, im Hinblick auf die Risiken für das Produkt Schwachstellen unverzüglich zu behandeln und zu beheben, unter anderem durch Sicherheitsaktualisierungen, und neue Sicherheitsaktualisierungen, soweit technisch machbar, getrennt von Funktionsaktualisierungen bereitzustellen. Das zählt, wenn ein Fix gebündelt mit einem großen Versionssprung kommt.
Nummer 8 verlangt, dass verfügbare Sicherheitsaktualisierungen zur Bewältigung festgestellter Sicherheitsprobleme unverzüglich und, sofern mit einem gewerblichen Nutzer für ein maßgeschneidertes Produkt nichts anderes vereinbart ist, kostenlos verbreitet werden, zusammen mit Hinweisen, die den Nutzern sagen, was sie wissen müssen, einschließlich möglicher zu treffender Maßnahmen. Der CRA schreibt nicht vor, wie ein Fix geschrieben wird, ob von einer Person oder mit KI. Diese Anforderungen gelten ab dem 11. Dezember 2027.
Wann Sie nicht fixen sollten: festhalten, dass eine Schwachstelle Sie nicht betrifft
Nicht jeder Befund braucht eine Codeänderung. Eine verwundbare Funktion wird vielleicht nie aufgerufen, oder das betroffene Feature ist in Ihrem Build abgeschaltet. Dann ist eine dokumentierte Entscheidung besser als ein Upgrade, das eigene Risiken mitbringt. Ein VEX-Dokument (Vulnerability Exploitability eXchange) hält pro Schwachstelle fest, ob ein Produkt betroffen ist und warum, in maschinenlesbarer Form, die Kunden und Behörden lesen können. Bewahren Sie die Nachweise hinter jeder Aussage „nicht betroffen“ auf und prüfen Sie sie erneut, wenn sich der Code ändert.
Heute in KROMSE verfügbar
KROMSE sagt Ihnen, was zu ändern ist und warum; eine Person in Ihrem Team entscheidet und nimmt die Änderung vor.
- Upgrade-Empfehlungen aus den Daten der Sicherheitshinweise: die behobene Version des verwundbaren Pakets und, bei einem transitiven Paket, die direkte Abhängigkeit, die es mitbringt, sofern das Lockfile das belegt. Für diese übergeordnete Abhängigkeit wird keine Version erfunden.
- Eine KI-Einschätzung pro Befund im Rahmen des Nutzungskontingents Ihres Tarifs, neben einer verständlichen Erklärung.
- Reaktionsmaßnahmen, die der KI-Assistent vorschlägt und die jeweils eine Person freigibt oder ablehnt.
- Schädliche Pakete werden als kritisch markiert; einzige Abhilfe ist das Entfernen.
- Für Go-Projekte eine Aufrufanalyse, die zeigen kann, ob Ihr Code die verwundbare Funktion aufruft.
- VEX-Export in CycloneDX 1.6 VEX und OpenVEX 0.2.0 sowie CRA-Reaktionsvorgänge mit Fristen und dokumentierten menschlichen Entscheidungen.
- Nichts verändert Code: Die GitHub App hat nur Lesezugriff, und KROMSE kann keine Pull Requests öffnen.
Als Nächstes geplant
Auf der Roadmap, noch nicht verfügbar. Die Termine sind Zielmarken, keine Zusagen; diese Seite wird an dem Tag aktualisiert, an dem eine Funktion live geht.
- Geplant · Q4 2026 (November)KI-Korrekturvorschläge, von Menschen freigegeben. KROMSE wird Korrekturen für Befunde vorschlagen, mit KI formuliert und erst angewendet, nachdem eine Person in Ihrem Team sie freigegeben hat.
- Geplant · Q4 2026 (November)Plug-in für Coding-Agenten. Ein Plug-in für KI-Coding-Agenten wird jedes Paket prüfen, das der Agent vorschlägt, bevor es in den Code gelangt – auch Pakete, die es gar nicht gibt oder die erst vor wenigen Tagen veröffentlicht wurden.
- Geplant · Q4 2026 (Dezember)Überwachung nach Ihrem Zeitplan, mit KI-Agenten. Erneute Scans werden nach einem Zeitplan laufen, den Sie festlegen, mit KI-Agenten, die neue Sicherheitshinweise verfolgen, einordnen, was davon zutrifft, Korrekturen vorschlagen und den Bericht zu Ihrer Prüfung entwerfen.
Häufige Fragen
Lassen sich KI-Codekorrekturen gefahrlos automatisch mergen?
Nur dort, wo Tests und Review einen fehlerhaften Fix erkennen würden, und selbst dann mit Vorsicht. Eine von KI vorgeschlagene Änderung kann eine API brechen, neue transitive Pakete nachziehen, eine Lizenz ändern oder einen Teil der Schwachstelle übersehen. Eine namentlich benannte Person, die jeden Fix mit dem Lockfile-Diff und den Release Notes vor Augen freigibt, ist für Produktionscode die sicherere Voreinstellung.
Was ist die minimale sichere Version für ein Abhängigkeits-Upgrade?
Meist das erste Release, das der Sicherheitshinweis auf der Versionslinie, die Sie bereits nutzen, als behoben führt. Es beseitigt die Schwachstelle mit der kleinsten Verhaltensänderung. Ein größerer Sprung, besonders über eine Major-Version hinweg, kann sich lohnen, ist aber auch ein Funktions-Upgrade, das ein eigenes Review und eigene Tests braucht.
Wie behebe ich eine Schwachstelle in einer transitiven Abhängigkeit?
Suchen Sie die direkte Abhängigkeit, die das verwundbare Paket nachzieht, und heben Sie sie auf ein Release, das das Paket auf eine behobene Version auflöst. Gibt es kein solches Release, kann ein Override im Paketmanager die behobene Version erzwingen; dokumentieren Sie es aber und entfernen Sie es, sobald die übergeordnete Abhängigkeit nachgezogen hat, denn ein Override kann das übergeordnete Paket beschädigen.
Verlangt der Cyber Resilience Act eine automatisierte Behebung?
Nein. Anhang I Teil II verlangt von Herstellern, Schwachstellen im Hinblick auf die Risiken unverzüglich zu behandeln und zu beheben, unter anderem durch Sicherheitsaktualisierungen, und verfügbare Sicherheitsaktualisierungen unverzüglich und in der Regel kostenlos zu verbreiten. Wie Fixes entstehen, sagt er nicht. Automatisierung hilft beim Tempo, dokumentierte Entscheidungen helfen bei den Nachweisen.
Wendet KROMSE Fixes auf meinen Code an?
Nein. KROMSE erklärt jeden Befund, gibt Upgrade-Empfehlungen aus den Daten der Sicherheitshinweise und kann Reaktionsmaßnahmen vorschlagen, die eine Person freigibt oder ablehnt. Es bearbeitet keinen Code und öffnet keine Pull Requests. KI-Korrekturvorschläge, die erst nach der Freigabe durch eine Person angewendet werden, stehen auf der Roadmap.