GitHub senkt eine konkrete Einstiegshürde für KI-gestützte Sicherheitsprüfungen in Pull Requests: AI Scan kann nun auch in geeigneten Repositorys laufen, in denen CodeQL Default Setup nicht aktiviert ist. Für Unternehmen bedeutet das jedoch nicht, dass Sicherheitsprüfungen automatisch überall aktiv werden. Code Scanning und AI Scan müssen weiterhin auf der passenden Verwaltungsstufe eingeschaltet sein.
Die operative Chance liegt in einer breiteren Abdeckung ohne zusätzlichen Einrichtungsschritt pro Repository. Der sinnvolle nächste Schritt ist deshalb kein pauschales Einschalten, sondern ein kontrollierter Rollout: Repositorys segmentieren, Berechtigungen prüfen, Befunde in bestehende Review-Prozesse einordnen und erst danach die Reichweite erhöhen.
Was GitHub bestätigt hat
Bestätigt ist, dass AI Scan Pull Requests nun auch dann auf Sicherheitslücken untersuchen kann, wenn CodeQL Default Setup im jeweiligen Repository fehlt. Zuvor war dieser Einsatz an das konfigurierte Default Setup gebunden. Wer AI Scan bereits auf Organisationsebene aktiviert hat, erhält dadurch eine breitere Abdeckung über geeignete Repositorys hinweg.
Ebenso bestätigt sind die Grenzen: Code Scanning und AI Scan müssen weiterhin auf Repository-, Organisations- oder Enterprise-Ebene aktiviert sein; die bestehende Berechtigungshierarchie bleibt bestehen. Die Funktion befindet sich in einer Public Preview für persönliche und organisationsverwaltete Repositorys auf GitHub.com und setzt GitHub Advanced Security voraus. GitHub Enterprise Server ist für diese Veröffentlichung nicht unterstützt.
Was sich im Betriebsmodell ändert
Aus den bestätigten Fakten lässt sich ableiten, dass Unternehmen ihre bisherige Auswahl der prüfbaren Repositorys neu bewerten sollten. Besonders relevant sind Projekte, die aus technischen oder organisatorischen Gründen kein CodeQL Default Setup nutzen, aber dennoch Pull Requests mit zusätzlicher Sicherheitsanalyse absichern sollen. Die neue Reichweite kann Lücken im Prüfpfad schließen, erhöht zugleich aber die Zahl potenzieller Befunde.
Damit verschiebt sich Arbeit vom einmaligen Setup in den laufenden Betrieb. Teams brauchen klare Zuständigkeiten für Triage, Nachprüfung und Eskalation. Ohne diese Regeln kann eine größere Scan-Abdeckung zu mehr Rückfragen, längeren Pull-Request-Zeiten oder ignorierten Warnungen führen. Der wirtschaftliche Nutzen entsteht erst, wenn relevante Befunde früh erkannt werden, ohne den Entwicklungsfluss unnötig zu blockieren.
Entscheidungsrahmen für die Repository-Auswahl
Vor dem Pilot sollten Sicherheits- und Entwicklungsteams die Repositorys nicht nur nach Kritikalität, sondern auch nach Betriebsfähigkeit auswählen. Eine kleine, gemischte Stichprobe liefert bessere Erkenntnisse als ein Start ausschließlich mit einem Vorzeigeprojekt.
- Schutzbedarf: Enthält das Repository geschäftskritische Logik, sensible Schnittstellen oder öffentlich erreichbaren Code?
- Änderungsfrequenz: Entstehen genügend Pull Requests, um Nutzen, Fehlalarme und Durchlaufzeiten realistisch zu bewerten?
- Verantwortung: Gibt es benannte Personen für Triage, Rückfragen und die abschließende Risikofreigabe?
- Berechtigungen: Ist nachvollziehbar, auf welcher Ebene Code Scanning und AI Scan aktiviert wurden und wer diese Einstellung ändern darf?
- Prozessanschluss: Können Befunde in vorhandene Pull-Request-, Ticket- und Eskalationswege übernommen werden?
Rollout in vier kontrollierten Phasen
- Inventarisieren: Repositorys mit und ohne CodeQL Default Setup erfassen, Verantwortliche zuordnen und die tatsächliche AI-Scan-Aktivierung dokumentieren.
- Pilotieren: Wenige geeignete Repositorys auswählen und zunächst beobachten, welche Befundarten, Bearbeitungszeiten und Rückfragen entstehen.
- Kalibrieren: Regeln für Triage, Schweregrade, Ausnahmen und menschliche Freigaben festlegen; unbegründete Blockaden vermeiden.
- Erweitern: Nur bei stabilen Abläufen weitere Repository-Gruppen aufnehmen und Änderungen an Aktivierung oder Berechtigungen revisionsfähig festhalten.
Für die Freigabe reichen reine Fundzahlen nicht aus. Aussagekräftiger sind der Anteil bestätigter Befunde, die Zeit bis zur Triage, Auswirkungen auf Pull-Request-Durchlaufzeiten und die Zahl wiederkehrender Befundmuster. Diese Größen sind keine von GitHub vorgegebenen Benchmarks, sondern ein sinnvoller interner Bewertungsrahmen.
Kosten und Risiken realistisch bewerten
Der entfallene Setup-Schritt kann Einführungsaufwand reduzieren, beseitigt aber weder Lizenz- noch Betriebskosten. GitHub nennt GitHub Advanced Security als Voraussetzung. Zusätzlich fallen intern Kapazitäten für Richtlinien, Triage und Schulung an. Vor einer Ausweitung sollte daher geklärt sein, welche Repositorys geschäftlich relevant sind und welche Teams die laufende Bearbeitung übernehmen.
Das größte Risiko ist eine Aktivierung ohne Prozessverantwortung. Weitere Risiken sind unklare Enterprise- und Organisationsgrenzen, eine zu frühe Nutzung als harte Merge-Schranke und die Annahme, AI Scan ersetze andere Sicherheitskontrollen. Da es sich um eine Public Preview handelt, sollte der Betrieb zudem Änderungen am Funktionsumfang einkalkulieren und einen Rückfallweg vorsehen.
Wann der Pilot bereit für die Ausweitung ist
- Aktivierung und Berechtigungsweg sind für jedes Pilot-Repository dokumentiert.
- Jeder Befund hat einen verantwortlichen Triage-Pfad und eine nachvollziehbare Entscheidung.
- Entwicklungsteams verstehen, dass AI Scan eine zusätzliche Kontrolle und keine vollständige Sicherheitsgarantie ist.
- Auswirkungen auf Durchlaufzeit und Arbeitslast werden regelmäßig bewertet.
- Für Änderungen der Public Preview existiert ein klarer Rückfall- oder Anpassungsprozess.
Für DACH-Unternehmen ist die Änderung vor allem eine Gelegenheit, bestehende Lücken zwischen Repository-Governance und Pull-Request-Sicherheit zu schließen. Wer die neue Reichweite mit klarer Verantwortung, begrenztem Pilotumfang und messbaren Kriterien verbindet, kann schneller lernen, ohne eine Preview-Funktion vorschnell zum unkontrollierten Standard zu machen.