GitHub hat CodeQL 2.27.0 veröffentlicht. Das Release lässt die CodeQL CLI nativ auf Linux ARM64 laufen, ergänzt eine Rust-Abfrage gegen unkontrollierte Kommandozeilen und erweitert die Modellierung mehrerer Sprachen und Frameworks. Für Unternehmen ist das nicht nur ein Versionssprung: ARM64-Runner werden einfacher nutzbar, während präzisere Modelle zugleich neue oder veränderte Sicherheitsalarme erzeugen können. Ein guter Rollout prüft deshalb Infrastruktur, Analyseergebnisse und Betriebsprozesse gemeinsam.
Was CodeQL 2.27.0 bestätigt verändert
Nach dem GitHub Changelog stehen CodeQL CLI und Bundle als Linux-ARM64-Artefakte bereit. Teams können die Analyse damit nativ auf entsprechenden Hosts ausführen, statt eine andere Architektur oder zusätzliche Übersetzungsschichten einzuplanen. Für GitHub Code Scanning auf github.com wird jede neue CodeQL-Version automatisch ausgerollt. Eine künftige GitHub-Enterprise-Server-Version soll die Funktionen ebenfalls enthalten; bei älteren GHES-Versionen ist ein manuelles CodeQL-Upgrade möglich.
In Rust kommt die Abfrage „rust/command-line-injection“ hinzu. Sie sucht nach unkontrollierten Kommandozeilen. Zugleich reduziert GitHub bei der Abfrage zu fest codierten kryptografischen Werten ähnliche Doppelfunde. Für Java und Kotlin wird Micronaut unter anderem bei HTTP-Controllern, WebSockets, Konfigurationsinjektion, Datenzugriff und Security-Annotationen modelliert. In C# verbessert GitHub die Erkennung von ASP.NET-Core-MVC-Controllern und -Actions sowie das Taint Tracking für OData-Action-Parameter.
Auch C und C++ erhalten zusätzliche Abdeckung: Funktionen der PostgreSQL-Bibliothek libpq für Abfragen und vorbereitete Statements gelten nun als SQL-Injection-Sinks. Bei GitHub Actions bewertet CodeQL Prüfungen von Author-Association-Feldern nur noch dann als Schutz, wenn das Ereignis-Payload das relevante Feld tatsächlich liefert. GitHub weist ausdrücklich darauf hin, dass dadurch zusätzliche Alarme für Workflows entstehen können, die sich bisher auf unwirksame Prüfungen verlassen haben.
Der geschäftliche Nutzen von nativem ARM64
Die bestätigte Neuerung ist die native Verfügbarkeit. Daraus lässt sich für Unternehmen ableiten, dass Code-Scanning-Jobs näher an bereits genutzter ARM64-Infrastruktur betrieben werden können. Ob dadurch Laufzeit oder Kosten sinken, belegt das Changelog jedoch nicht. Diese Effekte hängen von Runner-Größe, Build, Sprache, Datenbankerstellung und Abrechnungsmodell ab und sollten mit identischen Repositories auf der bisherigen und der neuen Plattform gemessen werden.
Ein Architekturwechsel nur wegen des neuen Downloads wäre daher voreilig. Relevanter ist die Frage, ob ARM64 bereits strategisch genutzt wird, etwa für Build-Farmen oder selbst gehostete Runner. In diesem Fall entfällt eine technische Lücke im Analysepfad. Bleibt die übrige Toolchain jedoch x86-zentriert oder enthält sie nicht kompatible Abhängigkeiten, kann ein gemischter Betrieb zunächst robuster sein.
Auswirkungsmatrix für den Release-Wechsel
- Linux ARM64: Native CLI- und Bundle-Artefakte sind verfügbar; Runner-Images, Caches und Downloadprüfungen müssen angepasst werden.
- Rust: Die neue Command-Line-Injection-Abfrage kann bisher nicht gemeldete Datenflüsse sichtbar machen; Zuständigkeit und Behebungsweg vorab festlegen.
- Java/Kotlin und C#: Erweiterte Framework-Modelle können Abdeckung und Alarmprofil ändern; Micronaut-, ASP.NET-Core- und OData-Projekte gezielt in den Pilot nehmen.
- C/C++: Anwendungen mit PostgreSQL libpq auf neue SQL-Injection-Funde prüfen, insbesondere bei PQexec- und Prepared-Statement-Funktionen.
- GitHub Actions: Zusätzliche Funde als mögliches Signal für unwirksame Author-Association-Prüfungen behandeln, nicht pauschal unterdrücken.
- GHES: Automatische github.com-Bereitstellung nicht mit der eigenen Serverversion gleichsetzen; enthaltene CodeQL-Version und Upgradeweg separat dokumentieren.
Rollout in fünf kontrollierten Schritten
- Bestand erfassen: CodeQL-Versionen, GitHub.com- oder GHES-Betrieb, Runner-Architekturen, Sprachen, Frameworks und eigene Query Packs dokumentieren.
- Referenz bilden: Vor dem Wechsel Laufzeiten, Fehler, Alarmzahlen und akzeptierte Baseline je Repository sichern, damit Änderungen erklärbar bleiben.
- Pilot auswählen: ARM64 zunächst mit wenigen repräsentativen Repositories testen und gezielt Rust, Micronaut, ASP.NET Core, OData, libpq sowie relevante Actions-Workflows abdecken.
- Ergebnisse trennen: Neue Alarme nach echter Schwachstelle, Modelländerung, Fehlalarm und Konfigurationsproblem klassifizieren; Unterdrückungen nur begründet übernehmen.
- Skalieren und überwachen: Runner-Images und Query Packs versionieren, Rollback ermöglichen und nach der Freigabe Laufzeit, Fehlerrate sowie Behebungsdauer beobachten.
Zusätzlich verändert CodeQL 2.27.0 den Betrieb in „build-mode: none“ für C#: Projekte und Solutions werden nun grundsätzlich über verfügbare NuGet-Feeds wiederherzustellen versucht; nicht erreichbare, explizit konfigurierte Feeds werden gemeldet. Außerdem kann das Default Setup private Registry-Konfigurationen der Organisation verwenden, wenn benutzerdefinierte Queries oder Packs aus privaten Git-Quellen beziehungsweise Docker-Registries geladen werden. Beides verbessert potenziell die Vollständigkeit, verlangt aber saubere Berechtigungen und erreichbare Paketquellen.
Abkündigungen jetzt in die Migrationsplanung aufnehmen
GitHub hat die CodeQL-Unterstützung für Java 9 und 10 abgekündigt und die Entfernung für Januar 2027 angekündigt; Java 7 und 8 sollen weiter unterstützt werden. Zusätzlich soll die generische Multi-Plattform-Distribution „codeql.zip“ künftig entfallen. GitHub empfiehlt stattdessen die plattformspezifischen ZIP-Dateien. Unternehmen sollten Installationsskripte deshalb nicht nur um ARM64 ergänzen, sondern auch prüfen, ob sie noch das generische Archiv oder veraltete Java-Versionen voraussetzen.
Welche Kennzahlen den Pilot belastbar machen
Für die Entscheidung reichen erfolgreiche Pipeline-Läufe allein nicht. Sinnvoll sind vergleichbare Werte für Analysezeit, Ressourcenverbrauch, Fehlerquote, Zahl neuer Alarme, Anteil bestätigter Schwachstellen und Zeit bis zur Triage. Bei privaten Query Packs gehören zudem Authentifizierungsfehler und nicht erreichbare Registries in die Beobachtung. Konkrete Zielwerte sollten aus der eigenen Ausgangslage entstehen; das GitHub Changelog liefert dafür keine allgemeingültigen Benchmarks.
Fazit: Plattformwechsel und Alarmänderungen gemeinsam steuern
CodeQL 2.27.0 schließt mit nativer Linux-ARM64-Unterstützung eine wichtige Plattformlücke und verbreitert gleichzeitig die Sicherheitsanalyse für Rust, etablierte Frameworks, libpq und GitHub Actions. Der sichere Weg ist ein kleiner, messbarer Pilot mit belastbarer Vorher-Nachher-Baseline. So lassen sich echte Verbesserungen von bloßen Alarmverschiebungen trennen, bevor neue Runner-Images und Query-Versionen organisationsweit ausgerollt werden.