Skip to main content

Verantwortungsvolle Verwendung von Copilot Autofix für die Codeüberprüfung

Erfahren Sie, wie GitHub mithilfe von KI potenzielle Korrekturen für code scanning-Warnungen vorschlägt, und finden Sie heraus, wie Sie Einschränkungen in den KI-Vorschlägen am besten abmildern können.

Wer kann dieses Feature verwenden?

GitHub Copilot Autofix für code scanning ist für die folgenden Repository-Typen verfügbar:

  • Öffentliche Repositorys auf GitHub.com
  • Organisationseigene Repositorys in GitHub Enterprise Cloud mit aktivierter GitHub Advanced Security

Info über Copilot Autofix für code scanning

GitHub Copilot Autofix ist eine Erweiterung von code scanning, die Benutzer*innen gezielte Empfehlungen zur Korrektur von code scanning-Warnungen gibt, damit sie neue Sicherheitsrisiken vermeiden können. Die potenziellen Korrekturen werden automatisch von großen Sprachmodellen (Large Language Models, LLMs) mithilfe von Daten aus der Codebasis und aus code scanning-Analysen generiert. GitHub Copilot Autofix ist für die CodeQL-Analyse verfügbar und unterstützt das Drittanbietertool ESLint (Die Unterstützung von Drittanbietern befindet sich in public preview und kann sich noch ändern).

Note

Sie benötigen kein Abonnement von GitHub Copilot zur Nutzung von GitHub Copilot Autofix. Copilot Autofix ist für alle öffentlichen Repositorys auf GitHub.com sowie für private Repositorys in GitHub Enterprise Cloud-Unternehmen verfügbar, die über eine Lizenz für GitHub Advanced Security verfügen.

Copilot Autofix generiert potenzielle Korrekturen, 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. Copilot Autofix nutzt die Schnittstellen interner GitHub Copilot-APIs mit dem großen Sprachmodell GPT-4o von OpenAI, das über ausreichende generative Funktionen verfügt, um sowohl vorgeschlagene Korrekturen im Code als auch erläuternden Text dazu zu erzeugen.

Copilot Autofix ist standardmäßig zulässig und für jedes Repository mit CodeQL aktiviert, aber Sie können sich dagegen entscheiden und Copilot Autofix deaktivieren. Informationen zum Deaktivieren von Copilot Autofix auf Unternehmens-, Organisations- und Repository-Ebene finden Sie unter „Deaktivieren von Copilot Autofix für die Codeüberprüfung“.

Im Sicherheitsübersichts-Dashboard einer Organisation können Sie die Gesamtzahl der Codevorschläge anzeigen, die für geöffnete und geschlossene Pull Requests in der Organisation in einem bestimmten Zeitraum generiert wurden. Weitere Informationen finden Sie unter „Einblicke in die Sicherheit anzeigen“ in der GitHub Enterprise Cloud-Dokumentation.

Entwicklerumgebung

Code scanning-Benutzer können bereits Sicherheitswarnungen sehen, 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.

Copilot Autofix senkt die Einstiegsbarriere für Entwickler*innen, indem Informationen zu bewährten Methoden mit Details der Codebasis und Warnungen kombiniert werden, um mögliche Korrekturen 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.

Unterstützte Sprachen für CodeQL code scanning

Copilot Autofix unterstützt die Generierung von Korrekturen für eine Teilmenge von Abfragen, die in den standardmäßigen und sicherheitserweiterten CodeQL-Abfragesuiten für C#, C/C++, Go, Java/Kotlin, Swift, JavaScript/TypeScript, Python und Ruby enthalten sind. Weitere Informationen zu diesen Abfragesammlungen finden Sie unter CodeQL-Abfragesammlungen.

Generierung von Vorschlägen

Wenn Copilot Autofix für ein Repository aktiviert ist, senden die identifizierten code scanning-Warnungen Input an das LLM. Wenn das LLM eine potenzielle Korrektur generieren kann, wird diese als Vorschlag angezeigt.

GitHub sendet dem LLM verschiedene Daten aus der code scanning-Analyse. Zum Beispiel:

  • CodeQL Warnungsdaten im SARIF-Format. Weitere Informationen findest du unter SARIF-Unterstützung für die Codeüberprüfung.
  • Code aus der aktuellen Version des Branches.
    • 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.“

Copilot Autofix-Vorschläge werden im code scanning-Back-End generiert und gespeichert. Sie werden als Vorschläge angezeigt. Bis auf die Aktivierung von code scanning für die Codebasis und die Erstellung eines Pull Request ist keine Benutzerinteraktion erforderlich.

Bei der Generierung von Korrekturen werden keine Kundendaten gesammelt oder verwendet, die über den oben beschriebenen Umfang hinausgehen. Daher unterliegt die Verwendung dieses Features den bestehenden Geschäftsbedingungen, die GitHub Advanced Security zugeordnet sind. Darüber hinaus werden Daten, die von Copilot Autofix verarbeitet werden, grundsätzlich nicht für LLM-Trainingszwecke verwendet. Weitere Informationen zu den GitHub Advanced Security-Geschäftsbedingungen finden Sie unter "GitHub-Nutzungsbedingungen für zusätzliche Produkte und Funktionen."

Qualität der Vorschläge

GitHub nutzt eine automatisierte Testumgebung, um die Qualität der Copilot Autofix-Vorschläge kontinuierlich zu überwachen. So lässt sich nachvollziehen, wie sich die vom LLM generierten Vorschläge während der Entwicklung des Modells ändern.

Die Testumgebung umfasst eine Reihe von über 2.300 Warnungen aus einer Vielzahl öffentlicher Repositorys, in denen der hervorgehobene Code Testabdeckung hat. Die Vorschläge für diese Warnungen werden getestet, um deren Qualität zu ermitteln, d. h., in welchem Umfang sie von Entwickler*innen bearbeitet werden müssen, bevor sie in der Codebasis festgeschrieben werden. Bei vielen Testwarnungen können die vom LLM generierten Vorschläge unverändert zur Behebung der jeweiligen Warnung festgeschrieben werden, während alle vorhandenen CI-Tests weiter 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 Vorschläge

Wir testen die Effektivität von Vorschlägen, indem alle vorgeschlagenen Änderungen unbearbeitet zusammengeführt werden, bevor code scanning und die Komponententests des Repositorys für den resultierenden Code 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 code scanning 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 bei anderen Projekten

Der Testsatz enthält eine breite Spanne verschiedener Arten von Projekten und Warnungen. Wir gehen davon aus, dass Vorschläge für andere Projekte, die von Copilot Autofix unterstützte Sprachen nutzen, einem ähnlichen Muster folgen sollten.

  • Copilot Autofix fügt wahrscheinlich dem Großteil der Warnungen einen Codevorschlag hinzu.
  • Wenn Entwickler*innen die Vorschläge auswerten, erwarten wir, dass die Mehrheit der Korrekturen ohne Bearbeitung oder mit kleineren Aktualisierungen festgeschrieben 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. Copilot Autofix bietet wertvolle Informationen, mit denen Sie code scanning-Warnungen auflösen können. Letztendlich liegt es aber in Ihrer Verantwortung, die vorgeschlagene Änderung auszuwerten und die Sicherheit und Genauigkeit des Codes sicherzustellen.

Note

Die Generierung von Korrekturen für unterstützte Sprachen hängt von der LLM-Betriebskapazität ab. Darüber hinaus wird jeder vorgeschlagene Fix getestet, bevor er einem Pull Request hinzugefügt wird. Wenn kein Vorschlag verfügbar ist oder die vorgeschlagene Korrektur bei internen Tests durchfällt, wird kein Vorschlag angezeigt.

Einschränkungen bei Vorschlägen

Beim Überprüfen von Copilot Autofix-Vorschlägen müssen Sie stets die Einschränkungen der KI berücksichtigen und die Änderungen nach Bedarf bearbeiten, bevor Sie sie annehmen. Außerdem sollten Sie die CI-Test- und Abhängigkeitsverwaltung für ein Repository aktualisieren, bevor Sie Copilot Autofix für code scanning aktivieren. Weitere Informationen finden Sie unter „Ausgleichen der Einschränkungen bei Vorschlägen“.

Einschränkungen bei Codevorschlägen

  • 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 bei 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.

Ausgleichen der Einschränkungen bei Vorschlägen

Die beste Möglichkeit, die Einschränkungen bei Copilot Autofix-Vorschlägen auszugleichen, 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