CodeQL stellt das Gesamtpaket ein: zuerst OS- und CPU-Installationspfade prüfen
Die Version eines Sicherheitsscanners kann aktuell sein, obwohl der Dateiname des Installers seit Jahren unverändert bleibt. Wer CodeQL über eigene CI oder interne Spiegel lädt, sollte Version und Downloadziel zusammen prüfen.
GitHub kündigte am 22. September 2026 die Einstellung des plattformübergreifenden CodeQL-Pakets an. Dieser Beitrag ordnet die Ankündigung ein und schlägt einen nachvollziehbaren Wechsel zu plattformspezifischen Dateien vor.
Ankündigung ist nicht gleich Ausfall
Seit CodeQL CLI 2.27.0 gelten codeql-bundle.tar.gz und codeql-bundle.tar.zst als veraltet; die Entfernung ist für Mitte März 2027 geplant. Empfohlen wird das Paket für das unterstützte Betriebssystem und die passende Architektur.
Linux-ARM64-Binärdateien sind nur in plattformspezifischen Downloads enthalten. Das bedeutet nicht, dass heute alle bestehenden Workflows scheitern. Prüfen Sie zuerst, ob Ihre Installation die betroffenen Dateien direkt verwendet.
Direkte Installationswege finden
Eine Suche allein im Workflow-YAML übersieht Container-Images, Bootstrap-Skripte oder interne Artefaktspeicher. Verbinden Sie die Erzeugung der Download-URL mit der Umgebung, die die Analyse ausführt.
Notieren Sie Umgebung, Betriebssystem, CPU, Datei, Cache und Verantwortliche. Das ist eine betriebliche Empfehlung, keine offizielle Vorgabe. Geheime Tokens und interne Adressen gehören nicht in öffentliche Issues.
Der Betriebssystemname reicht nicht
Linux auf x86-64 und ARM64 sind unterschiedliche Ziele. Unterscheiden Sie Host und Container und übernehmen Sie exakte Dateinamen aus den Release-Assets. Unbekannte Kombinationen sollten sichtbar scheitern statt still auf einen Standard zurückzufallen.
Release 2.27.0 nennt CLI und Bundle für Linux ARM64. Ein verfügbarer Download garantiert jedoch nicht jede Sprach- und Build-Konfiguration. Die aktuellen Systemanforderungen kennzeichnen Linux ARM64 als Beta; prüfen Sie die jeweiligen Bedingungen.
Ein alter Cache kann den Wechsel verdecken
Ein neuer Downloadname beweist wenig, wenn der Cache weiterhin die alte ausführbare Datei liefert. Bilden Sie Plattform und Version in Cache-Schlüsseln und Spiegelpfaden ab und protokollieren Sie die tatsächlich verwendete Datei und CLI-Version.
Nutzen Sie offizielle Dateien und bereitgestellte Integritätsinformationen. Bewahren Sie bei intern gespeicherten, geprüften Artefakten auch Originalversion und Plattform auf. Ein gemeinsamer Cache-Name für verschiedene Architekturen verdient besondere Aufmerksamkeit.
Vom Start zur vollständigen Analyse
Ein startendes CLI belegt noch keine gleichwertige Analyse. Prüfen Sie am gleichen Commit eines repräsentativen Repositories Datenbankerstellung, Abfragen und Ergebnis-Upload sowie enthaltene Sprachen und Build-Modi.
Vermischen Sie den Wechsel nicht mit Refactoring oder neuen Abfrageregeln. Prüfen Sie die Installation separat und grenzen Sie unerwartete Unterschiede anhand von Tool-Version, Pack-Versionen und Build-Logs ein.
Ein reproduzierbarer Weg als Anfang
Kleine Teams können mit ihrem wichtigsten eigenen CI-Pfad beginnen. Dokumentieren Sie Erfolgskriterien und Rücknahme-Einstellungen und geben Sie denselben Maßstab an Verantwortliche für Spiegel und alte Images weiter.
Öffentliche Releases und Issues helfen bei Kompatibilitätsfragen, ersetzen aber nicht die Ergebnisse der eigenen Umgebung. Hier werden weder ein Community-Konsens noch Erfolgsquoten behauptet.
Der heutige Änderungsnachweis
Ergänzen Sie den PR um bisherigen Dateinamen, neue Plattformzuordnung, reale Ausführungsumgebung und Analyseergebnisse. Benennen Sie auch noch ungeprüfte Umgebungen, damit der Umfang klar bleibt.
Vor der Entfernung müssen Sie den Installationspfad ändern und prüfen, nicht nur eine Warnung ausblenden. Bestimmen Sie auch, wer offizielle Änderungen und einen möglicherweise präzisierten Termin erneut kontrolliert.