Skip to main content

Informationen über Autofix für CodeQL Codeüberprüfung

Erfahren Sie, wie GitHub KI verwendet, um potenzielle Fixes für code scanning Warnungen vorzuschlagen, die von CodeQL in Ihrer Pull Request gefunden wurden.

Wer kann dieses Feature verwenden?

Die automatische Korrektur für code scanning ist nur für GitHub Enterprise Cloud-Benutzer mit GitHub Advanced Security verfügbar. Weitere Informationen findest du unter Informationen zu GitHub Advanced Security.

Informationen über Autofix für CodeQL code scanning

Autofix ist eine KI-gesteuerte Erweiterung von code scanning, die Benutzern gezielte Empfehlungen bietet, um ihnen bei der Behebung von code scanning-Warnungen in Pull Requests zu helfen, damit sie neue Sicherheitsrisiken vermeiden können. Die potenziellen Fixes werden automatisch von großen Sprachmodellen (LLMs) mithilfe von Daten aus der Codebasis, Pull Request und aus CodeQL-Analyse generiert.

Code scanning Autofix generiert potenzielle Fixes, die für den vorhandenen Quellcode relevant sind, und übersetzt die Beschreibung und den Standort einer Warnung in Codeänderungen, die die Warnung beheben können. Das Autofix-System verwendet das OpenAI GPT-4 große Sprachmodell, das über ausreichende generative Funktionen verfügt, um sowohl vorgeschlagene Fixes im Code als auch erläuternden Text für diese Fixes zu erzeugen.

Entwicklungsumgebung

GitHub Advanced Security-Benutzer können bereits Sicherheitswarnungen sehen, die von code scanning mithilfe von CodeQL erkannt wurden, um ihre Pull Requests zu analysieren. Entwickler haben jedoch häufig wenig Schulungen zur Codesicherheit, sodass das Beheben dieser Warnungen erheblichen Aufwand erfordert. Sie müssen zuerst den Standort der Warnung und die Beschreibung lesen und verstehen und dann dieses Verständnis verwenden, um den Quellcode zu bearbeiten, um das Sicherheitsrisiko zu beheben.

Code scanning Autofix senkt die Barriere des Einstiegs für Entwickler, indem Informationen zu bewährten Methoden mit Details der Codebasis und Warnung kombiniert werden, um dem Entwickler einen potenziellen Fix vorzuschlagen. Anstatt mit einer Suche nach Informationen über das Sicherheitsrisiko zu beginnen, beginnt der Entwickler mit einem Codevorschlag, der eine mögliche Lösung für ihre Codebasis veranschaulicht. Der Entwickler wertet den potenziellen Fix aus, um festzustellen, ob es die beste Lösung für ihre Codebasis ist, und um sicherzustellen, dass das beabsichtigte Verhalten beibehalten wird.

Nachdem ein Commit für einen vorgeschlagenen Fix oder eine Änderung vorgenommen wurde, sollte der Entwickler immer überprüfen, ob Continuous Integration-Tests (CI) für die Codebasis weiterhin bestehen und dass die Warnung vor dem Zusammenführen ihrer Pull Request als aufgelöst angezeigt wird.

Autofix-Generierungsprozess

Wenn Autofix aktiviert ist für ein Repository, senden code scanning Warnungen, die in einem Pull Request durch unterstützte CodeQL Abfragen bezeichnet sind, Eingaben an LLM. Wenn die LLM einen potenziellen Fix generieren kann, wird der Fix in dem Pull Request als Vorschlagskommentar angezeigt.

GitHub sendet det LLM eine Vielzahl von Daten aus dem Pull Request und aus CodeQL-Analyse.

  • CodeQL Warnungsdaten im SARIF-Format. Weitere Informationen finden Sie unter „SARIF-Unterstützung für die Codeüberprüfung“.
  • Code aus der aktuellen Version der Pull Request-Verzweigung.
    • Kurze Code-Ausschnitte um jeden Quellstandort, Empfänger-Standort und jeden Standort, auf den in der Warnmeldung verwiesen wird oder im Flusspfad enthalten ist.
    • Erste ~10 Zeilen aus jeder Datei, die an einem dieser Standorte beteiligt ist.
  • Hilfetext für die CodeQL-Abfrage, die das Problem identifiziert hat. Beispiele finden Sie unter „CodeQL Abfrage-Hilfe.“

Alle Autofix-Vorschläge werden im code scanning-Back-End generiert und gespeichert. Sie werden als Vorschlagskommentare in Pull Request angezeigt. Es ist keine Benutzer-Interaktion erforderlich, außer code scanning auf der Codebasis zu aktivieren und Pull Request zu erstellen.

Qualität der Autofix-Vorschläge

GitHub verwendet eine automatisierte Testumgebung, um die Qualität der Autofix-Vorschläge kontinuierlich zu überwachen. Auf diese Weise können wir verstehen, wie sich die von der LLM generierten Autofix-Vorschläge während der Entwicklung des Modells ändern.

Die Testumgebung umfasst eine Reihe von über 700 JavaScript/TypeScript-Warnungen aus einer Vielzahl öffentlicher Repositorys, in denen der hervorgehobene Code Test-Abdeckung hat. Autofix-Vorschläge für diese Warnungen werden getestet, um zu sehen, wie gut sie sind, d. h., wie viel ein Entwickler sie bearbeiten muss, bevor sie auf die Codebasis festgelegt werden. Für viele der Testwarnungen können Autofixes, die von der LLM generiert werden, übernommen werden, um die Warnung zu beheben, während alle vorhandenen CI-Tests erfolgreich bestanden werden.

Darüber hinaus wird das System einem Belastungstest unterzogen, um auf potenzielle Schäden (häufig als rotes Team bezeichnet) zu prüfen, und ein Filtersystem auf dem LLM hilft, potenziell schädliche Vorschläge für Benutzer anzuzeigen.

So testet GitHub Autofix-Vorschläge

Wir testen die Effektivität von Autofix-Vorschlägen, indem alle vorgeschlagenen Änderungen zusammengeführt werden, unbearbeitet, bevor code scanning und die Komponententests des Repositorys für den Ergebniscode ausgeführt werden.

  1. Wurde die code scanning-Warnung durch den Vorschlag behoben?
  2. Hat der Fix neue code scanning Warnungen eingeführt?
  3. Hat die Lösung Syntaxfehler eingeführt, die von CodeQL erkannt werden können?
  4. Hat der Fix die Ausgabe einen der Repository-Tests geändert?

Darüber hinaus überprüfen wir viele der erfolgreichen Vorschläge und stellen sicher, dass sie die Warnung beheben, ohne neue Probleme einzuführen. Wenn eine oder mehrere dieser Überprüfungen fehlgeschlagen sind, hat unsere manuelle Überprüfung gezeigt, dass die vorgeschlagene Korrektur in vielen Fällen nahezu korrekt war, aber einige kleinere Änderungen benötigten, die ein Benutzer identifizieren und manuell ausführen konnte.

Effektivität für andere JavaScript/TypeScript-Projekte

Der Testsatz enthält eine breite Spanne verschiedener Arten von Projekten und Warnungen. Unsere Vorhersage ist, dass Autofixes für andere JavaScript/TypeScript-Projekte einem ähnlichen Muster folgen sollten.

  • Autofix fügt wahrscheinlich einen Codevorschlag zu den meisten Warnungen für JavaScript/TypeScript-Projekte hinzu.
  • Wenn Entwickler die Autofix-Vorschläge auswerten, erwarten wir, dass die Mehrheit der Fixes ohne Bearbeitung oder mit kleineren Updates übernommen werden können, um den breiteren Kontext des Codes widerzuspiegeln.
  • Ein kleiner Prozentsatz der vorgeschlagenen Fixes spiegelt ein erhebliches Missverständnis der Codebasis oder des Sicherheitsrisikos wider.

Jedes Projekt und jede Codebasis ist jedoch eindeutig, sodass Entwickler möglicherweise einen größeren Prozentsatz der vorgeschlagenen Fixes bearbeiten müssen, bevor sie diese festlegen. Autofix bietet wertvolle Informationen, mit denen Sie code scanning Warnungen auflösen können, aber letztendlich ist es Ihre Verantwortung, die vorgeschlagene Änderung auszuwerten und die Sicherheit und Genauigkeit Ihres Codes sicherzustellen.

Hinweis: Das System schlägt keine Fixes für alle Arten von code scanning Warnungen vor, die von CodeQL identifiziert wurden. Autofix wird für eine Teilmenge die standardmäßigen CodeQL JavaScript/TypeScript-Abfragen unterstützt, und die LLM ist in ihrer operativen Kapazität begrenzt. Darüber hinaus wird jeder vorgeschlagene Fix getestet, bevor er einem Pull Request hinzugefügt wird. Wenn kein Vorschlag verfügbar ist oder wenn der vorgeschlagene Fix interne Tests fehlschlägt, wird kein Autofix-Vorschlag angezeigt.

Einschränkungen von Autofix-Vorschlägen

Wenn Sie einen Autofix-Vorschlag überprüfen, müssen Sie immer die Einschränkungen von KI berücksichtigen und die Änderungen nach Bedarf bearbeiten, bevor Sie die Änderungen akzeptieren. Sie sollten auch die CI-Test- und Abhängigkeitsverwaltung für ein Repository aktualisieren, bevor Sie Autofix für code scanning aktivieren. Weitere Informationen finden Sie unter „Ausgleich der Einschränkungen von Autofix-Vorschlägen“.

Einschränkungen von Autofix-Code-Vorschlägen

  • Programmiersprachen: Eine Teilmenge der Programmiersprachen wird unterstützt, zunächst nur JavaScript und TypeScript. Support für zusätzliche Sprachen wird hinzugefügt, aber es ist nicht beabsichtigt, Support für alle CodeQL Sprachen bereitzustellen.
  • Menschliche Sprachen: Das System verwendet in erster Linie englische Daten, einschließlich der Eingabeaufforderungen, die an das System gesendet werden, den Code, der von den LLMs in ihren Datasets gesehen wurde, und die Testfälle, die für die interne Auswertung verwendet werden. Vorschläge, die von LLM generiert werden, weisen möglicherweise eine niedrigere Erfolgsquote für Quellcode und Kommentare auf, die in anderen Sprachen geschrieben wurden und andere Zeichensätze verwenden.
  • Syntaxfehler: Das System schlägt möglicherweise Korrekturen vor, die keine syntaktisch korrekten Codeänderungen sind, daher ist es wichtig, Syntaxprüfungen für Pull Requests auszuführen.
  • Standortfehler: Das System schlägt möglicherweise Korrekturen vor, die syntaktisch korrekter Code sind, aber an der falschen Position vorgeschlagen werden. Dies bedeutet, dass ein Benutzer, wenn ein Benutzer eine Korrektur akzeptiert, ohne den Standort zu bearbeiten, einen Syntaxfehler verursacht.
  • Semantische Fehler: Das System kann Fixes vorschlagen, die syntaktisch gültig sind, aber die Semantik des Programms ändern. Das System hat kein Verständnis für die Absicht des Programmierers oder der Codebasis, wie sich der Code verhalten soll. Wenn Sie eine gute Testabdeckung haben, können Entwickler überprüfen, ob ein Fix das Verhalten der Codebasis nicht ändert.
  • Sicherheitsrisiken und irreführende Fixes: Das System kann Korrekturen vorschlagen, die das zugrunde liegende Sicherheitsrisiko nicht beheben und/oder neue Sicherheitsrisiken einführen.
  • Teilausführung der Fixes: Das System kann Fixes vorschlagen, die nur teilweise das Sicherheitsrisiko beheben oder nur teilweise die beabsichtigte Codefunktionalität beibehalten. Das System sieht nur eine kleine Teilmenge des Codes in der Codebasis und erzeugt nicht immer global optimale oder korrekte Lösungen.

Einschränkungen von Autofix-Abhängigkeitsvorschlägen

Manchmal enthält ein vorgeschlagener Fix eine Änderung der Abhängigkeiten der Codebasis. Wenn Sie ein Abhängigkeitsverwaltungssystem verwenden, werden alle Änderungen automatisch hervorgehoben, damit der Entwickler dies überprüfen kann. Stellen Sie vor dem Zusammenführen eines Pull Request immer sicher, dass Abhängigkeitsänderungen sicher sind und das beabsichtigte Verhalten der Codebasis beibehalten.

  • Neue oder aktualisierte Abhängigkeiten: Das System kann das Hinzufügen oder Aktualisieren von Softwareabhängigkeiten als Teil eines vorgeschlagenen Fixes vorschlagen. Wenn Sie beispielsweise vorschlagen, die package.json Datei für JavaScript-Projekte zu ändern, um Abhängigkeiten von npm hinzuzufügen.
  • Nicht unterstützte oder unsichere Abhängigkeiten: Das System weiß nicht, welche Versionen einer vorhandenen Abhängigkeit unterstützt oder sicher sind.
  • Erzeugte Abhängigkeiten: Das System verfügt über unvollständige Kenntnisse der im breiteren Ökosystem veröffentlichten Abhängigkeiten. Dies kann zu Vorschlägen führen, die eine neue Abhängigkeit von Malware hinzufügen, die Angreifer unter einem statistisch wahrscheinlichen Abhängigkeitsnamen veröffentlicht haben.

Ausgleich der Einschränkungen von Autofix-Vorschlägen

Die beste Möglichkeit, die Einschränkungen von Autofix-Vorschlägen zu mindern, besteht darin, bewährte Methoden zu befolgen. Beispielsweise sind die Verwendung von CI-Tests von Pull Requests zur Überprüfung der funktionalen Anforderungen nicht betroffen und verwenden Abhängigkeitsverwaltungslösungen, z. B. die Abhängigkeitsüberprüfungs-API und -Aktion. Weitere Informationen findest du unter Informationen zur Abhängigkeitsüberprüfung.

Es ist wichtig zu beachten, dass der Autor eines Pull Requests die Verantwortung dafür behält, wie er auf die Kommentare der Reviewer und die vorgeschlagenen Code-Änderungen reagiert, unabhängig davon, ob sie von Kollegen oder automatischen Tools vorgeschlagen wurden. Entwickler sollten immer Vorschläge für Codeänderungen kritisch betrachten. Bei Bedarf sollten sie die vorgeschlagenen Änderungen bearbeiten, um sicherzustellen, dass der Ergebniscode und die Anwendung korrekt, sicher sind, Leistungskriterien erfüllen und alle anderen funktionalen und nicht funktionalen Anforderungen für die Anwendung erfüllen.

Nächste Schritte