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. Der Scanner arbeitet nur lesend. Rook (Autofix) nutzt eine separate, optionale GitHub App namens Kromse Fix und öffnet, nur wenn Sie es einschalten, Pull Requests als Entwurf, die Sie prüfen und zusammenführen.
- 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.
- Die GitHub App für die Scans hat nur Lesezugriff. Autofix ist eine separate, optionale GitHub App, Kromse Fix: Wo sie aktiviert ist, öffnet sie einen Pull Request als Entwurf erst, nachdem eine Person die Korrektur freigegeben hat.
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?
Nicht von selbst. KROMSE erklärt jeden Befund, gibt Upgrade-Empfehlungen aus den Daten der Sicherheitshinweise und kann Reaktionsmaßnahmen vorschlagen, die eine Person freigibt oder ablehnt. Der Scanner arbeitet nur lesend. Rook (Autofix) nutzt eine separate, optionale GitHub App namens Kromse Fix und öffnet, nur wenn Sie es einschalten, Pull Requests als Entwurf, die Sie prüfen und zusammenführen.