GitHub Agentic Autofix allgemein verfügbar: Vom Sicherheitsalarm zum geprüften Fix

Ein Sicherheitsalarm sagt dir, dass etwas Aufmerksamkeit braucht. Er erklärt nicht unbedingt, wie du die Anwendung ändern kannst, ohne etwas anderes kaputtzumachen. Für Einsteiger, die eine kleine App betreuen, kann diese Lücke den Fix verhindern; Entwickler wiederum lassen dadurch oft einen wachsenden Stapel vertrauter Warnungen liegen.

GitHub hat Agentic Autofix für Code-Scanning-Alarme am 15. Oktober 2026 allgemein verfügbar gemacht. Weise einen Alarm Copilot zu, und ein Agent untersucht den Code, schlägt Änderungen vor, versucht sie zu validieren und öffnet einen Draft-Pull-Request. Der nützliche Fortschritt liegt im Startpunkt: ein prüfbarer Reparaturvorschlag statt eines leeren Editors. GitHub-Ankündigung zur allgemeinen Verfügbarkeit vom 15. Oktober 2026

Dieser Leitfaden führt dich von einem geeigneten Repository zu deinem ersten geprüften Fix und zeigt anschließend den Umgang mit verwandten Alarmen, eigenen Scannern, Kosten und gescheiterten Versuchen. Unsere Empfehlung: Behandle den Agenten als Autor eines Patches, nicht als Freigabestelle. Bevor die Änderung Teil deiner Anwendung wird, musst du sie selbst verstehen.

Die Auftaktgrafik trennt den Reparaturvorschlag des Agenten von der menschlichen Entscheidung, ihn zusammenzuführen.

Beginne mit einem Alarm statt mit dem ganzen Rückstand

Dein erster Erfolg sollte eine kleine Änderung sein, die du erklären, testen und prüfen kannst. Ein Pull Request (PR) ist ein Vorschlag, Änderungen in den Hauptzweig eines Projekts zu übernehmen; der Status Draft zeigt, dass der Vorschlag noch nicht fertig ist. CodeQL ist GitHubs Analysewerkzeug, das Alarme zu potenziell verwundbarem Code erzeugt.

Gehe zunächst so vor, bevor du eine große Bereinigung startest:

1. Wähle ein Repository, das du verwaltest. Bestätige unten die Eignung, kläre die Zugriffsfreigabe und benenne eine für die Abrechnung zuständige Person, bevor du eine Agentsitzung startest.
2. Prüfe zuerst die CodeQL-Analyse. Funktioniert die Analyse bereits, behalte diese Konfiguration bei und prüfe den letzten erfolgreichen Lauf. Für eine neue Einrichtung öffnest du in den Repository-Einstellungen Settings > Advanced Security > Code Security, suchst CodeQL analysis, wählst Set up > Default, prüfst die Konfiguration und klickst auf Enable CodeQL. Warte eine erfolgreiche Analyse ab. GitHub-Einrichtungsanleitung, geprüft am 18. Oktober 2026
3. Aktiviere Agentic Autofix über die geltenden Richtlinien. Ein Schalter im Repository kann ein Verbot auf Organisations- oder Unternehmensebene nicht übergehen.
4. Wähle einen bestehenden Alarm im Standardbranch. Öffne Security and quality > Code scanning, dann den Alarm, und wähle unter Assignees die Option Assign to Copilot. GitHub-Anleitung für Alarme, geprüft am 18. Oktober 2026
5. Prüfe den Draft-Pull-Request und das Sitzungsprotokoll. Lies den Diff, führe passende Tests aus und starte den Scan mit der Konfiguration, die das Problem gefunden hat.
6. Führe den Merge erst nach menschlicher Prüfung und den erforderlichen Checks aus. Prüfe danach den Alarmstatus, sobald der aktualisierte Standardbranch analysiert wurde.

Eine offizielle Benutzeroberflächen-Demo findest du in GitHubs Ankündigung zur allgemeinen Verfügbarkeit. Nutze sie neben deinem Repository als Orientierung, statt anzunehmen, dass eine schematische Abbildung jeden aktuellen Bildschirm exakt wiedergibt.

Können öffentliche oder private Repositories die Funktion verwenden?

Die Ankündigung hebt Unternehmenskunden hervor. GitHubs aktuelle Zugriffsdokumentation ist breiter gefasst: Sie nennt öffentliche Repositories auf GitHub.com und organisationsverwaltete Repositories mit GitHub Code Security oder GitHub Advanced Security. Eine Copilot-Lizenz ist nicht erforderlich. GitHub-Dokumentation zum Zugriff, geprüft am 18. Oktober 2026

Öffentlicher Zugriff bedeutet nicht, dass Agentsitzungen kostenlos sind. Trenne die Eignung des Repositorys von den Nutzungskosten, bevor du andere zum Ausprobieren einlädst.

Gewähre Zugriff von der höchsten geltenden Richtlinie abwärts

Bei einer unternehmenseigenen Organisation müssen zunächst ein Enterprise Owner oder Security Manager die Funktion unter Policies > Advanced Security > Agentic Autofix erlauben. Diese Berechtigung allein aktiviert sie noch nicht. Anschließend aktiviert ein Organization Owner oder Security Manager sie unter Settings > Advanced Security > Global settings; geeignete Repositories übernehmen die Aktivierung. Repository-Administratoren können sich abmelden oder die Funktion erneut aktivieren, aber nur, sofern übergeordnete Richtlinien es zulassen. Eigenständige Organisationen überspringen den Unternehmensschritt; geeignete öffentliche persönliche Repositories verwenden direkt ihre Repository-Einstellung. Nutzer der Vorschau müssen die Funktion erneut aktivieren. GitHub-Verfahren für Richtlinien, geprüft am 18. Oktober 2026

Zugriffsgrafik: Berechtigung, Aktivierung und Auswahl des Repositorys sind getrennte Entscheidungen. Quelle: GitHubs Zugriffsdokumentation, geprüft am 18. Oktober 2026.

Lege vor einem organisationsweiten Rollout fest, welche Repositories abgemeldet bleiben sollen, und vereinbare, wer erzeugte Patches prüft. Für einen Pilotversuch bietet sich ein Tandem aus Repository-Maintainer und Security-Reviewer an. Halte Alarm, erwartetes Verhalten, Reviewer und Budgetverantwortung fest, damit ein unbearbeiteter Draft nicht zur unerklärten Verantwortung anderer wird.

Stelle sicher, dass CodeQL den Code tatsächlich analysiert hat

Die Standardeinrichtung erfordert GitHub Actions und entweder ein öffentliches Repository oder Code Security. Prüfe die gewählten Sprachen und die Query-Suite, nicht nur den aktivierten Schalter. Läuft eine vorhandene erweiterte Einrichtung zuverlässig, wechsle nicht leichtfertig: Die Standardeinrichtung überschreibt bestehende Konfigurationen, deaktiviert den bisherigen Workflow und blockiert CodeQL-Analyse-Uploads über die API. GitHub-Dokumentation zur Standardeinrichtung, geprüft am 18. Oktober 2026

Prüfe das neueste Analyseergebnis, bevor du einen Alarm auswählst. War der betroffene Dienst eingeschlossen, und haben Build oder Abhängigkeiten einen Analysefehler verursacht? Ein aktivierter Schalter belegt nicht, dass die relevanten Dateien erfolgreich analysiert wurden. Behebe dieses Einrichtungsproblem, bevor du einen Agenten mit Befunden auf einer unzuverlässigen Grundlage beauftragst.

Wähle für den ersten Versuch ein klar umrissenes Problem mit erwartbarem Verhalten, etwa eine Datenbanksuche oder einen bestimmten Ausgabepfad. Beginne nicht mit einer umfassenden Neugestaltung der Autorisierung. Gibt es keinen passenden Alarm, führe nicht absichtlich eine Schwachstelle in ein aktives Repository ein, nur um eine Demo zu erzeugen.

Was geschieht zwischen der Zuweisung und dem Draft-Pull-Request?

GitHub beschreibt einen Agenten, der relevante Dateien untersucht, einen Fix generiert, CodeQL erneut ausführt und iteriert, bevor er einen Draft-Pull-Request öffnet. Der Vorschlag enthält eine Reparaturzusammenfassung und Validierungsdetails. Das ist der Agentic-Autofix-Ablauf, kein automatischer Merge in den Standardbranch. GitHub-Workflow zur allgemeinen Verfügbarkeit, 15. Oktober 2026

Gehe nach dem Zuweisen des Alarms bei der Prüfung so vor:

1. Lies den ursprünglichen Befund noch einmal. Bestimme die nicht vertrauenswürdige Eingabe, die sensible Operation und den erwarteten Schutz. Notiere Alarmkennung und meldende Konfiguration.
2. Prüfe jede geänderte Datei. Achte auf nicht zugehörige Änderungen, entfernte Prüfungen, deaktivierte Tests, neue Abhängigkeiten und verändertes Fehlerverhalten.
3. Prüfe die Sitzungsbelege. Unterscheide einen abgeschlossenen Scan von einem fehlgeschlagenen Befehl oder dem Hinweis, dass Validierung nicht möglich war. Du kannst über die Sitzung oder durch eine Copilot-Erwähnung in einem PR-Kommentar um eine weitere Iteration bitten. GitHub-Hinweise zu Sitzungen, geprüft am 18. Oktober 2026
4. Führe Anwendungstests und den relevanten Scanner aus. Nutze die dokumentierten Testbefehle des Projekts in einer geeigneten Entwicklungsumgebung. Prüfe Einrichtungsskripte und Workflow-Änderungen, bevor du unbekannten Code ausführst.
5. Fordere eine menschliche Freigabe an. Lass den Draft blockiert, solange Verhalten, Scan-Abdeckung oder Zuständigkeit ungeklärt sind. Markiere ihn erst dann als bereit, wenn die Belege überprüfbar sind.

Prüfschleife: Ein vom Agenten erstellter Draft ist ein Zwischenstand, kein Sicherheitsnachweis. Quelle: GitHub-Ankündigung und Dokumentation zur Alarmbehebung.

GitHub-Pull-Requests zeigen den Diff unter Files changed und automatisierte Ergebnisse unter Checks. Nutze beides: Eine grüne Zusammenfassung erklärt nicht, ob eine geänderte Berechtigungsprüfung weiterhin die Regeln deiner Anwendung durchsetzt. GitHub-Konzepte zu Pull Requests, geprüft am 18. Oktober 2026

Arbeitsablauf 1: Eine kleine Datenbanksuche reparieren, ohne ihre Bedeutung zu ändern

Stell dir einen fiktiven Python-Dienst vor, der einen Lagerartikel anhand seiner Bezeichnung sucht. Die bestehende Implementierung fügt die übergebene Bezeichnung per Stringformatierung in SQL ein; ein Code-Scanning-Alarm beanstandet den Aufbau der Abfrage. Ein sinnvoller Fix trennt SQL-Anweisung und Wert, statt einzelne Satzzeichen entfernen zu wollen.

Eine sichere, beispielhafte Implementierung mit Pythons sqlite3-Schnittstelle sieht so aus:

def find_item(connection, label):
    return connection.execute(
        "SELECT id, label FROM inventory WHERE label = ?",
        (label,),
    ).fetchone()

Der Platzhalter bindet den Wert getrennt vom SQL-Text, wie in Pythons offizieller Anleitung zur Parameterbindung, geprüft am 18. Oktober 2026, beschrieben. Dieses Beispiel zeigt ein fiktives Reparaturmuster, keinen Agentic-Autofix-Patch und keinen berichteten Test. Abfrage, Schema und Autorisierungsregeln eines realen Dienstes müssen gesondert geprüft werden.

Lass für dieses Beispiel Tests für eine gewöhnliche Bezeichnung, eine mit Apostroph wie Maker's Kit und einen unbekannten Artikel schreiben. Prüfe, dass die Funktion weiterhin erwartungsgemäß eine Zeile oder None zurückgibt. Teste danach die bestehenden Zugriffsregeln des aufrufenden Endpunkts: Eine parametrisierte Abfrage entscheidet nicht, wer Lagerdaten lesen darf.

Ein hilfreicher Review-Kommentar wäre: „Behalte das bisherige Suchverhalten bei, binde die Bezeichnung als Wert und ergänze Regressionstests für Apostrophe und unbekannte Artikel.“ Er beschreibt den Vertrag, statt den Agenten bloß zum Verschwinden der Warnung aufzufordern. Führe vor der Annahme erneut einen Scan des konkreten Patches aus.

Arbeitsablauf 2: Verwandte Alarme bündeln, nicht beliebige Warnungen

Angenommen, in einem fiktiven Webdienst beziehen sich drei Alarme auf dieselbe Hilfsfunktion zur Antwortdarstellung. Prüfe gemeinsam, ob eine gemeinsame Korrektur sinnvoll ist. GitHub erlaubt, bis zu 25 Rückstandsalarme aus der Alarmliste oder einer Sicherheitskampagne auszuwählen; eine Zuweisung erzeugt eine Sitzung und einen Pull-Request. GitHub-Anleitung zur Mehrfachzuweisung, geprüft am 18. Oktober 2026

Das Limit ist eine Obergrenze, keine empfohlene Batchgröße. Drei zusammenhängende Befunde mit einem Verantwortlichen sind möglicherweise leichter zu prüfen als zwanzig unabhängige Befunde zu Authentifizierung, Dateiverarbeitung und Datenbankzugriff. Liste vor der Zuweisung jeden betroffenen Endpunkt und das dort zu erhaltende normale Verhalten auf.

In diesem Beispiel prüfst du die gemeinsame Hilfsfunktion und testest jeden Aufrufer. Ändert der vorgeschlagene Fix die Ausgabemaskierung, kontrolliere den jeweiligen Ausgabekontext, statt die Änderung abzunicken, weil ein Beispiel nun richtig aussieht. Teile die Arbeit auf, wenn Befunde unterschiedliche Reviewer oder Veröffentlichungstermine erfordern. Lass einen ungeklärten Alarm nicht verdecken, für welche Reparaturen es tatsächlich Belege gibt.

Arbeitsablauf 3: Ein eigener Scanner muss separat bestätigt werden

Agentic Autofix bearbeitet nur Rückstandsalarme im Standardbranch. Alarme, die nur in einem Pull-Request oder einem anderen Branch auftauchen, gehören nicht zu diesem Zuweisungsablauf. Führt ein neuer Pull-Request einen Befund ein, behebe ihn dort, statt verwundbaren Code nur deshalb zu mergen, damit er zugewiesen werden kann. GitHub-Aussage zum Umfang, 15. Oktober 2026

Es gibt noch eine weitere Grenze: GitHub weist darauf hin, dass die Agentenvalidierung Fixes für eigene CodeQL-Abfragen, die CodeQL-Query-Suite security-extended oder Code-Scanning-Alarme von Drittanbietern nicht bestätigen kann. Die eingebaute Validierung startet die Code-Scanning-Query-Suite bestmöglich erneut. Grenzen der GitHub-Validierung, geprüft am 18. Oktober 2026

Stell dir eine fiktive Organisation vor, deren eigene Abfrage eine interne Regel zur Datenverarbeitung durchsetzt. Selbst wenn der Agent einen plausiblen Patch vorlegt, muss ein Reviewer diese Analyse separat ausführen und das Ergebnis prüfen. Halte Abfrageversion, Konfiguration, analysierte Revision und Resultat fest. Ein erfolgreicher Lauf der Standardsuite ersetzt nicht die Abfrage, die das Problem gemeldet hat.

Lass den strengeren Scanner aktiviert. Die Abdeckung zu verringern, um einen grünen Status zu erhalten, ändert die Messung, nicht die Sicherheit der Anwendung. Kannst du die erforderliche Analyse nicht reproduzieren, lass den Vorschlag bis zur Validierung offen und benenne, wer sie ausführen kann.

Keine Copilot-Lizenz heißt nicht: keine Rechnung

Agentic Autofix verbraucht Code-Security-KI-Credits und GitHub-Actions-Minuten. GitHubs Abrechnungsdokumentation stellt ausdrücklich fest, dass auch öffentliche Repositories ohne erforderliche Lizenzen für aktive Mitwirkende KI-Credits verbrauchen. Enthaltene KI-Credits werden zuerst verwendet, sofern das zahlende Konto darauf Anspruch hat; weiterer Verbrauch wird nutzungsbasiert berechnet. Konten ohne enthaltene Credits zahlen von Anfang an nach Verbrauch. GitHub-Abrechnung für KI-Credits, geprüft am 18. Oktober 2026

Bei Organisations-Repositories werden Gebühren dem zahlenden Organisations- oder Unternehmenskonto zugeordnet. Prüfe vor einer breiten Aktivierung dessen Kontingent und Budget für Code-Security-KI-Credits. Die Ankündigung verlangt außerdem eine eingerichtete Copilot-Abrechnung; das ist etwas anderes, als für jeden Nutzer eine Copilot-Lizenz vorauszusetzen. Abrechnungsbedingungen der GitHub-Ankündigung, 15. Oktober 2026

Notiere bei einem Pilotversuch Sitzungsverbrauch, Actions-Verbrauch, Prüfzeit und ob der Patch angenommen wurde. Versprich keinen festen Preis pro behobenem Alarm: Auch ein Batch, eine Iteration oder ein erfolgloser Vorschlag muss in die Kostenprüfung einfließen. Vergleiche die Kosten angenommener Reparaturen mit deinem bisherigen Ablauf, statt erzeugte Pull-Requests als abgeschlossene Behebung zu zählen.

Das klassische Copilot Autofix ist etwas anderes: Es schlägt in einem Schritt eine Änderung vor, statt den agentengestützten Untersuchungs- und Draft-Ablauf zu verwenden; seine Vorschläge verbrauchen keine KI-Credits. Wo es unterstützt wird, bleibt es eine Option, wenn Agentic Autofix nicht aktiviert ist. GitHub-Vergleich, geprüft am 18. Oktober 2026

Beantworte vor dem Merge diese sieben Fragen

Unsere Prüfliste soll nicht nur die gemeldete Schwachstelle beseitigen, sondern auch das Verhalten bewahren:

• Ursache: Behebt der Patch die unsichere Operation, statt die Warnung zu unterdrücken?
• Umfang: Sind nicht zusammenhängende Refactorings, neue Abhängigkeiten und Konfigurationsänderungen begründet?
• Verhalten: Funktionieren gültige und ungültige Eingaben, Fehlerfälle und Berechtigungen weiterhin richtig?
• Tests: Gibt es einen Regressionstest, der das ursprüngliche Problem erkennen würde?
• Analyse: Hat der meldende Scanner die vorgeschlagene Revision mit der erforderlichen Konfiguration analysiert?
• Freigabe: Hat ein verantwortlicher Mensch den Diff und offene Hinweise des Agenten geprüft?
• Nach dem Merge: Hat die Analyse des Standardbranchs den erwarteten Alarmstatus bestätigt, ohne neue Befunde zu erzeugen?

Behandle „Validierung nicht möglich“ als unerledigte Arbeit, nicht als Freigabe. GitHub weist darauf hin, dass ein Agent in seinem Pull-Request melden kann, die Validierung nicht ausführen zu können oder einen Fehlalarm zu vermuten. Keine dieser Aussagen ersetzt die Beurteilung durch einen Maintainer. GitHub-Hinweise zum Best-Effort-Verhalten, geprüft am 18. Oktober 2026

Was tun, wenn die Schaltfläche fehlt oder das Ergebnis falsch ist?

Warum sehe ich einen Alarm, kann ihn aber nicht zuweisen? Prüfe, ob es sich um einen Rückstand im Standardbranch handelt, ob das Repository geeignet und die Funktion aktiviert ist und ob du die nötigen Rechte hast. Die Zuweisung erfordert Schreibzugriff. Frag bei einer gesperrten Einstellung den passenden Administrator, statt den Repository-Schalter wiederholt umzulegen. Voraussetzungen für die GitHub-Zuweisung, geprüft am 18. Oktober 2026

Beweist ein sauberer Scan, dass die App sicher ist? Nein. Er beantwortet Fragen, die von der konkreten Analyse und ihrer Konfiguration abgedeckt werden. Geschäftsregeln, Autorisierung, Laufzeitverhalten und nicht unterstützte Befunde erfordern weiterhin passende Tests und Prüfung.

Soll ich eine gescheiterte Sitzung immer wieder starten? Lies zuerst ihr Protokoll und den vorgeschlagenen Diff. Ermittle, ob Analysekonfiguration, Testausführung, Projektkontext oder Reparaturvorschlag fehlen. Gib eine präzise Korrektur vor oder behebe die zugrunde liegende Einrichtung, bevor du es erneut versuchst. Wiederholte Zuweisungen ohne neue Informationen sind keine Behebungsstrategie.

Kann ich einen mutmaßlichen Fehlalarm akzeptieren? Untersuche den Befund unabhängig und dokumentiere deine Begründung. Verwechsle das Verwerfen eines Alarms nicht mit der Behebung verwundbaren Codes, und lass nicht das Vertrauen eines Agenten über eine Risikoausnahme entscheiden.

Fazit: Ein Reparaturvorschlag ist der Anfang der Prüfung

Agentic Autofix zieht nützliche Arbeit nach vorn: Untersuchung, Kandidaten-Patch und verfügbare Validierung kommen zusammen. Der praktische Gewinn ist der kürzere Weg vom Erkennen einer Schwachstelle zur Prüfung einer konkreten Reparatur. Halte den ersten Versuch klein, lass deine Scanner aktiviert und knüpfe die Annahme an Belege statt an die Urheberschaft.

Quellen

Primärquellen, geprüft am 18. Oktober 2026.

Die Links in diesem Leitfaden führen zu GitHubs Ankündigung vom 15. Oktober zur allgemeinen Verfügbarkeit, den aktuellen Zugriffsrichtlinien, Konzepten und Grenzen von Autofix, Verfahren zur Alarmbehebung, der CodeQL-Einrichtung und der Abrechnungsdokumentation. Die Dokumentation ist eine datierte Momentaufnahme der Zugriffsmöglichkeiten, keine Garantie für die Konfiguration jedes Kontos. Die drei Arbeitsabläufe sind veranschaulichte Beispiele, keine Praxisergebnisse.

Ein Ort für deine Prüfnotizen: Bewahre Quelllinks, Alarmreferenzen, Testergebnisse und Entscheidungen gemeinsam in Telli.sh auf. Es hilft dir, Notizen zu organisieren; es scannt keine Repositories und genehmigt keine Fixes. Erstelle ein Telli.sh-Konto.