Kurz vor dem Pull Request fällt Ihnen auf, dass ein neuer API-Endpunkt Eingaben direkt an eine Datenbank weitergibt. Die Tests sind grün, der Diff wirkt überschaubar, und trotzdem bleibt die Frage: Haben Sie gerade nur funktionalen Code geschrieben oder auch eine Sicherheitslücke eingebaut? Genau an dieser Stelle kann die Frage „Wie lässt sich GitHub Copilot App /security-review verwenden?“ relevant werden – allerdings nur, wenn Sie den Befehl richtig einordnen und die Ergebnisse nicht mit einem vollständigen Sicherheitstest verwechseln.
Seit dem 14.07.2026 ist /security-review in GitHub Copilot App als öffentliche Vorschau verfügbar. Der Befehl untersucht laufende Änderungen in einer aktiven Agent-Sitzung, priorisiert sicherheitsrelevante Befunde und liefert Vorschläge für mögliche Korrekturen. (GitHub Changelog)
GitHub Copilot App /security-review verwenden
GitHub Copilot App /security-review ist eine bedarfsabhängige Sicherheitsprüfung für den aktuellen Arbeitsstand. Sie starten sie nicht als dauerhaft laufenden Scanner für das gesamte Repository, sondern gezielt innerhalb einer aktiven Agent-Sitzung mit noch nicht abgeschlossenen Änderungen.
Das ist besonders nützlich in drei Situationen:
- nach einer größeren Änderung an Authentifizierung, Eingabevalidierung oder Dateizugriffen,
- unmittelbar vor dem Commit oder dem Erstellen eines Pull Request,
- nach einer Reparatur, wenn Sie prüfen möchten, ob der konkrete Befund noch reproduzierbar ist.
Nach Angaben von GitHub liefert der Befehl priorisierte Ergebnisse mit Schweregrad und Konfidenz sowie anwendbaren Reparaturvorschlägen. Genannt werden unter anderem Injection-Probleme, Cross-Site-Scripting, unsichere Datenverarbeitung, Pfad-Traversal und schwache Kryptografie. (GitHub Changelog)
Für die Praxis bedeutet das: Die Prüfung eignet sich als schneller Sicherheitsfilter innerhalb Ihres Entwicklungsflusses. Sie beantwortet jedoch nicht automatisch die umfassendere Frage, ob Ihre gesamte Anwendung, Infrastruktur, Abhängigkeiten und Laufzeitkonfiguration sicher sind.
Grenzen vor dem ersten Lauf
Bevor Sie GitHub Copilot App /security-review verwenden, sollten Sie mehrere Einschränkungen berücksichtigen. Viele scheinbar technische Probleme sind in Wirklichkeit Fragen des Kontexts, der Berechtigungen oder des Prüfbereichs.
Begrenzter Änderungsumfang
Der Befehl bewertet den aktuellen Arbeitsstand beziehungsweise die laufenden Änderungen der Sitzung. Wenn eine Sicherheitslücke bereits vorher im Repository vorhanden war und Ihre aktuelle Änderung sie nur indirekt beeinflusst, kann sie außerhalb des sichtbaren Prüfkontexts liegen.
Ein sauberer Diff ist deshalb entscheidend. Prüfen Sie vor dem Start:
git status
git diff --stat
git diff
Ein zu großer Diff erschwert die Bewertung. Ein zu kleiner Diff kann relevante Hilfsfunktionen, Middleware oder Konfigurationsdateien aus dem Zusammenhang reißen.
Fehlender Anwendungskontext
Ein Sprachmodell kann Datenflüsse aus dem Quelltext ableiten, kennt aber nicht automatisch Ihre internen Annahmen. Ob ein Token tatsächlich öffentlich ist, ob ein Reverse Proxy bereits eine Schutzschicht bereitstellt oder ob eine Eingabe nur aus einer vertrauenswürdigen internen Quelle stammt, muss oft ein Mensch beurteilen.
Vorschau- und Richtlinienstatus
/security-review befindet sich in der öffentlichen Vorschau und kann sich daher hinsichtlich Verhalten, Ausgabe oder Verfügbarkeit ändern. GitHub dokumentiert, dass der Befehl in einer aktiven Agent-Sitzung mit laufenden Änderungen verwendet wird. (Dokumentation zu Agent-Sitzungen)
Bei Copilot Business und Enterprise kann zusätzlich eine Administratorrichtlinie für Copilot CLI beziehungsweise die App relevant sein. Die Dokumentation nennt eine aktivierte Copilot-CLI-Richtlinie als Voraussetzung für bestimmte Business- und Enterprise-Szenarien. (Dokumentation zu GitHub Copilot App)
Datenschutz und sensible Inhalte
Bevor Sie Quellcode prüfen lassen, klären Sie, ob der betreffende Arbeitsstand sensible Informationen enthält. Entfernen Sie echte Zugangsdaten, private Schlüssel, Kundendaten und produktive Konfigurationswerte. Für Teams sollten Sie außerdem festlegen, welche Agent-Sitzungen geteilt werden dürfen und welche Informationen in Sitzungsverläufen auftauchen können.
Lesen Sie dazu Ihre internen Vorgaben und die Datenschutzhinweise für die Nutzung der Umgebung, bevor Sie vertrauliche Projekte in einer neuen Arbeitsumgebung testen.
Voraussetzungen für die Sicherheitsprüfung
Für einen sinnvollen Lauf benötigen Sie vier Dinge:
- ein geöffnetes Projekt in GitHub Copilot App,
- eine aktive Agent-Sitzung,
- lokale beziehungsweise laufende Codeänderungen,
- eine Berechtigung und App-Konfiguration, mit der die Funktion verfügbar ist.
GitHub Copilot App unterstützt Sitzungen mit eigenen isolierten Arbeitsbereichen. Die Dokumentation beschreibt, dass jede Sitzung in einem separaten Workspace und auf einem eigenen Branch laufen kann. Dadurch lassen sich Sicherheitsprüfungen durchführen, ohne parallel bearbeitete Aufgaben unmittelbar zu vermischen. (Dokumentation zu Agent-Sitzungen)
Verwenden Sie möglichst einen kontrollierten Branch. Gerade bei sicherheitsrelevanten Änderungen sollten Sie nicht direkt auf dem Hauptbranch experimentieren. Ein rücksetzbarer Testbranch erleichtert die Wiederholung, die manuelle Prüfung und den Vergleich zwischen ursprünglichem und korrigiertem Zustand.
Ablauf der Prüfung
Die folgende Reihenfolge eignet sich für das tägliche Arbeiten und verhindert, dass Sie einen unklaren oder veralteten Diff prüfen.
1. Projekt und Branch öffnen
Öffnen Sie das Repository in GitHub Copilot App und wechseln Sie auf den Branch, in dem die Änderung tatsächlich entstanden ist. Prüfen Sie anschließend den Status und stellen Sie sicher, dass keine unbeteiligten temporären Dateien enthalten sind.
Bei mehreren parallelen Agent-Sitzungen kontrollieren Sie besonders den Sitzungsnamen und den zugehörigen Branch. Eine Sicherheitsprüfung im falschen Workspace kann formal erfolgreich sein und trotzdem die falsche Änderung untersuchen.
2. Aktive Agent-Sitzung starten
Öffnen Sie eine aktive Agent-Sitzung mit dem Projektkontext. Eine reine Unterhaltung ohne dedizierten Arbeitsbereich ist für diese Aufgabe nicht die richtige Ausgangslage, weil /security-review in einer aktiven Agent-Sitzung mit laufenden Änderungen ausgeführt wird.
Wenn die Sitzung noch keine Änderung enthält, bitten Sie den Agenten zunächst um eine klar abgegrenzte Aufgabe oder nehmen Sie selbst eine kontrollierte Änderung vor. Formulieren Sie den Sicherheitskontext möglichst konkret:
Prüfen Sie nur die Änderungen an der Eingabevalidierung und am Datenbankzugriff. Berücksichtigen Sie den Datenfluss vom HTTP-Parameter bis zur Abfrage und nennen Sie Annahmen, die manuell bestätigt werden müssen.
3. Prüfbereich eingrenzen
Ein begrenzter Auftrag erzeugt meist besser verwertbare Ergebnisse als die pauschale Aufforderung, „alles auf Sicherheit zu prüfen“. Nennen Sie betroffene Dateien, Endpunkte oder Datenflüsse. Besonders hilfreich sind Hinweise auf:
- externe Eingaben,
- Authentifizierungs- und Autorisierungsentscheidungen,
- Dateisystemzugriffe,
- Datenbankabfragen,
- Ausgaben in HTML, Logs oder Fehlermeldungen,
- Netzwerkaufrufe und Dateiuploads.
Damit wird aus einer allgemeinen Analyse eine gezielte Prüfung der lokalen Codeänderung.
4. Befehl ausführen
Geben Sie im Eingabefeld der aktiven Sitzung ein:
/security-review
Drücken Sie die Eingabetaste und warten Sie, bis die Analyse abgeschlossen ist. Der vorgesehene Ablauf besteht darin, eine aktive Sitzung mit Änderungen zu öffnen, /security-review einzugeben, die Befunde zu prüfen und anschließend die Codeänderungen anzupassen.
Das Erfolgssignal ist nicht zwingend eine gefundene Sicherheitslücke. Auch eine Ausgabe ohne Befund kann ein gültiges Ergebnis sein. Entscheidend ist, dass die Sitzung den aktuellen Änderungsstand verarbeitet und eine nachvollziehbare Antwort mit Prüfbereich oder Ergebnis liefert.
5. Ergebnisse dokumentieren
Übernehmen Sie nicht sofort jede vorgeschlagene Änderung. Speichern Sie zunächst:
- betroffene Datei und Zeilennummer,
- beschriebene Angriffskette,
- Schweregrad,
- Konfidenz,
- vorgeschlagene Reparatur,
- offene Annahmen oder Rückfragen.
Diese Informationen sind später wichtig, wenn Sie einen Befund als Fehlalarm einstufen, eine Sicherheitsentscheidung im Pull Request begründen oder die Reparatur erneut prüfen müssen.
Schweregrad und Konfidenz
Die zwei wichtigsten Bewertungsachsen sind Schweregrad und Konfidenz. Sie beantworten unterschiedliche Fragen.
Der Schweregrad beschreibt, wie gravierend ein Problem wäre, wenn es tatsächlich ausnutzbar ist. Ein möglicher Zugriff auf beliebige Dateien oder eine Umgehung der Autorisierung verdient normalerweise mehr Aufmerksamkeit als eine geringfügige Offenlegung technischer Fehlermeldungen.
Die Konfidenz beschreibt dagegen, wie sicher die Analyse ist, dass der beschriebene Befund im konkreten Code zutrifft. Ein Befund mit hohem Schweregrad, aber niedriger Konfidenz ist kein Grund für eine unkontrollierte Komplettänderung. Er ist ein Prüfauftrag.
Praktisch können Sie die Ergebnisse so sortieren:
- hoher Schweregrad und hohe Konfidenz: sofort reproduzieren und vor dem Merge beheben,
- hoher Schweregrad und mittlere oder niedrige Konfidenz: Datenfluss und Schutzmechanismen manuell überprüfen,
- niedriger Schweregrad und hohe Konfidenz: in den normalen Hardening-Backlog aufnehmen,
- niedriger Schweregrad und niedrige Konfidenz: dokumentieren, aber nicht ohne Beleg den Code umbauen.
Was bedeutet ein hoher Befund ohne Exploit-Test?
Er ist ein priorisierter Hinweis, kein Beweis für eine ausnutzbare Schwachstelle. Prüfen Sie Eingabequelle, Bereinigung, Berechtigungsprüfung und tatsächliche Ausführung. Wenn ein Schutz außerhalb des gezeigten Diffs liegt, muss dieser Schutz im Review nachvollziehbar dokumentiert werden.
Sollten Sie die vorgeschlagene Reparatur direkt übernehmen?
Nur nach Prüfung der Nebenwirkungen. Ein Agent kann eine Eingabe stärker validieren, eine Funktion ersetzen oder die Fehlerbehandlung verändern. Dadurch kann zwar der gemeldete Pfad geschlossen werden, aber ein anderer Ablauf brechen. Führen Sie deshalb Tests, Linter und gegebenenfalls einen manuellen Negativtest aus.
Reparatur und erneute Verifikation
Die GitHub Copilot App Sicherheitsprüfung ist dann besonders wertvoll, wenn sie in einen geschlossenen Arbeitsablauf eingebettet wird. Ein einzelner Befund ohne Nachprüfung ist noch keine belastbare Sicherheitsentscheidung.
1. Angriffspfad nachvollziehen
Lesen Sie zuerst, wie die Eingabe in den gefährlichen Vorgang gelangt. Bei einer möglichen SQL-Injection verfolgen Sie den Weg vom HTTP-Parameter über Hilfsfunktionen bis zur Datenbankabfrage. Bei einem möglichen Pfad-Traversal prüfen Sie zusätzlich Normalisierung, symbolische Links und Berechtigungen des Zielprozesses.
2. Kleinste sinnvolle Reparatur planen
Vermeiden Sie eine großflächige Umstrukturierung, wenn eine begrenzte Änderung die Ursache beseitigt. Verwenden Sie etablierte Schutzmechanismen des jeweiligen Frameworks, etwa parametrisierte Abfragen, sichere Ausgabekodierung oder eine zentrale Autorisierungsprüfung.
3. Änderung anwenden
Sie können den Reparaturvorschlag des Agenten als Ausgangspunkt verwenden. Prüfen Sie anschließend den Diff selbst. Achten Sie darauf, ob neue Abhängigkeiten, gelockerte Prüfungen, geänderte Fehlermeldungen oder unbeabsichtigte Datenfreigaben entstanden sind.
4. Tests und Negativfälle ausführen
Ein Sicherheitstest sollte nicht nur den normalen Erfolgsfall abdecken. Ergänzen Sie, soweit sinnvoll, Tests mit zu langen Eingaben, ungültigen Zeichen, fehlenden Rollen, manipulierten Dateinamen oder abgelaufenen Sitzungen. Der konkrete Testumfang hängt von Sprache, Framework und Anwendungstyp ab.
5. /security-review erneut starten
Führen Sie nach der Reparatur erneut aus:
/security-review
Vergleichen Sie die neue Ausgabe mit dem ursprünglichen Befund. Eine gute Verifikation erklärt entweder, warum der ursprüngliche Pfad nicht mehr funktioniert, oder weist auf einen verbleibenden Teilpfad hin.
6. Pull Request erst danach erstellen
Erstellen Sie den Pull Request erst, wenn der Diff, die Tests und die Sicherheitsbewertung zusammenpassen. Dokumentieren Sie im Pull Request kurz, welcher Befund untersucht wurde, welche Änderung ihn beheben soll und welche Punkte weiterhin manuell überwacht werden müssen.
Abgrenzung zu CodeQL, Dependabot und secret scanning
Die Frage „Was ist der Unterschied zwischen Copilot Sicherheitsprüfung und CodeQL?“ lässt sich am besten über den jeweiligen Zweck beantworten.
GitHub Copilot App /security-review
- prüft gezielt den aktuellen Änderungsstand in einer aktiven Agent-Sitzung,
- eignet sich für unmittelbares Feedback während der Entwicklung,
- erklärt Befunde in natürlicher Sprache und kann Reparaturvorschläge machen,
- ist keine vollständige Analyse des gesamten Repositorys.
CodeQL
- analysiert Quellcode mit einer regel- und abfragebasierten Sicherheitslogik,
- eignet sich für wiederholbare Prüfungen in Pull Requests und CI/CD,
- kann Datenflüsse über mehrere Dateien und größere Repository-Bereiche verfolgen,
- sollte in einem Teamprozess nicht durch eine einzelne interaktive Agent-Antwort ersetzt werden.
Dependabot
- konzentriert sich auf bekannte Schwachstellen in Abhängigkeiten,
- unterstützt Aktualisierungsvorschläge und Warnungen für betroffene Pakete,
- erkennt nicht automatisch jede individuell geschriebene Logikschwachstelle.
secret scanning
- sucht nach versehentlich veröffentlichten Zugangsdaten, Token oder Schlüsseln,
- ist für Geheimnislecks zuständig,
- ersetzt weder eine Quellcodeanalyse noch eine Prüfung von Autorisierung und Eingabevalidierung.
Damit lautet die praktische Antwort auf „Wie kann ich vor dem Commit Sicherheitslücken prüfen?“ nicht „Verwenden Sie nur ein Werkzeug“. Nutzen Sie /security-review für die unmittelbare Prüfung Ihrer Änderung, CodeQL für wiederholbare Codeanalysen, Dependabot für Abhängigkeiten und secret scanning für offengelegte Geheimnisse.
Fehlalarme und fehlende Befunde
Die Frage „Wie lässt sich mit Fehlalarmen bei /security-review umgehen?“ sollte nicht mit blindem Ignorieren beantwortet werden. Ein Fehlalarm ist erst dann plausibel, wenn Sie den behaupteten Datenfluss geprüft und den Gegenbeleg dokumentiert haben.
Gehen Sie in dieser Reihenfolge vor:
- Prüfen Sie, ob die genannte Datei und Zeile noch zum aktuellen Diff gehören.
- Verfolgen Sie Eingabequelle, Verarbeitung und Ausgabe beziehungsweise Ausführung.
- Suchen Sie nach Schutzmechanismen außerhalb des markierten Codeabschnitts.
- Führen Sie einen kleinen reproduzierbaren Test aus.
- Dokumentieren Sie, warum der Befund nicht ausnutzbar ist.
- Starten Sie die Prüfung mit einem enger formulierten Auftrag erneut.
Keine Ergebnisse bedeuten ebenfalls nicht, dass der Code sicher ist. Häufige Ursachen sind ein zu kleiner Änderungsumfang, fehlender Kontext, nicht erreichbare Dateien, unklare Abhängigkeiten oder eine Schwachstelle, die eher die Laufzeitkonfiguration als den Quelltext betrifft.
Auch die lokale Code-Schwachstellensuche mit Copilot kann Sicherheitslücken übersehen. Besonders schwierig sind Logikfehler in komplexen Berechtigungssystemen, falsch konfigurierte Infrastruktur, Abhängigkeiten mit unbekanntem Verhalten und Schwachstellen, deren Ausnutzung mehrere Dienste voraussetzt.
Kontrolliertes Kvmzen-Testprotokoll
Für ein reproduzierbares Kvmzen-Testprotokoll empfiehlt sich ein separates Testrepository oder ein rücksetzbarer Branch. Das Ziel ist nicht, eine bestimmte Fundzahl vorzugeben, sondern den vollständigen Ablauf nachvollziehbar zu machen.
1. Kontrollierte Schwachstelle einführen
Fügen Sie beispielsweise eine klar erkennbare, nicht produktive Teständerung ein, bei der eine externe Eingabe ohne ausreichende Prüfung an eine Datenbankabfrage oder einen Dateipfad weitergegeben wird. Verwenden Sie keine echten Kundendaten und keine produktiven Zugangsdaten.
2. Diff begrenzen
Lassen Sie nur die Testdateien und die zugehörigen Tests im Branch. Prüfen Sie mit git diff --stat, ob keine unabhängigen Änderungen enthalten sind.
3. Agent-Sitzung öffnen
Starten Sie eine neue Agent-Sitzung im Testbranch und beschreiben Sie die erwartete Datenflussrichtung, ohne die konkrete Schwachstelle unnötig vorwegzunehmen.
4. Prüfung ausführen
Führen Sie /security-review aus und dokumentieren Sie Zeitpunkt, Sitzungszweck, betroffene Dateien und die erhaltene Ausgabe. Da sich eine Vorschaufunktion ändern kann, sollte das Protokoll auch den damaligen Funktionsstatus festhalten.
5. Manuell bewerten
Vergleichen Sie den Befund mit dem tatsächlichen Testcode. Prüfen Sie, ob Schweregrad und Konfidenz zur realen Angriffsmöglichkeit passen. Ersetzen Sie das Ergebnis nicht durch eine pauschale Kennzahl.
6. Reparatur und Gegenprobe
Wenden Sie eine begrenzte Reparatur an, führen Sie Positiv- und Negativtests aus und starten Sie /security-review erneut. Halten Sie fest, ob der ursprüngliche Befund verschwunden, verändert oder weiterhin vorhanden ist.
Dieses Vorgehen liefert Kvmzen verwertbare Erfahrungsdaten, ohne ein angeblich exaktes Ergebnis zu erfinden. Gerade bei einer öffentlichen Vorschaufunktion ist die Dokumentation des konkreten Commit-Zustands wichtiger als eine isolierte Aussage wie „der Scanner findet immer alle Probleme“.
Dauerhafte Testumgebung für Sicherheitsprüfungen
Wenn Sie regelmäßig Agent-Sitzungen, Pull Requests und reproduzierbare Testzweige betreiben, wird die Arbeitsumgebung selbst zu einem Betriebsfaktor. Lokale Geräte können durch begrenzten Arbeitsspeicher, wechselnde Entwicklungsstände, fehlende Fernzugriffsmöglichkeiten oder manuelle Einrichtungsarbeit ausgebremst werden.
Eine gemietete Mac-Umgebung kann sinnvoll sein, wenn Sie für Tests eine stabile, getrennte macOS-Instanz benötigen und nicht dauerhaft zusätzliche Hardware verwalten möchten. Prüfen Sie dabei insbesondere Zugriffsrechte, Datenlöschung, Standort der Verarbeitung, Netzwerkbandbreite und die Möglichkeit, Testdaten nach jeder Sitzung zurückzusetzen. Informationen zu verfügbaren Umgebungen finden Sie in der Übersicht der Mac-Mietoptionen.
Für Teams mit wiederkehrenden Builds, Agent-Sitzungen und Sicherheitsprüfungen ist eine feste Umgebung oft leichter zu standardisieren als wechselnde Entwicklergeräte. Die Mietlösung ersetzt jedoch weder CodeQL, Dependabot, secret scanning noch die manuelle Freigabe eines sicherheitskritischen Pull Request.
Wenn Sie für einen laufenden macOS-Testprozess eine getrennte Instanz benötigen, können Sie eine Mac-mini-Mietumgebung für Entwicklung und Tests prüfen. Entscheidend ist, dass Sie die Umgebung als kontrollierte Arbeitsfläche verstehen: keine produktiven Geheimnisse, klar getrennte Branches, nachvollziehbare Sitzungen und ein definierter Löschprozess.
Die Alternative – Sicherheitsprüfungen ausschließlich auf wechselnden lokalen Geräten durchzuführen – hat im Alltag mehrere Nachteile: uneinheitliche Tool-Versionen, schwer reproduzierbare Fehler, manuelle Einrichtung und eine höhere Gefahr, dass Testdaten im falschen Arbeitsbereich verbleiben. Eine gemietete Mac-Umgebung kann deshalb für wiederkehrende Prüfungen die stabilere Betriebsentscheidung sein, sofern Datenschutz, Zugriffsmodell und Rücksetzung vorab geklärt sind.