Was tun, wenn CodeQL-Scans durch Xcode 27 blockiert werden? Reparaturleitfaden 2026

Symptom: CodeQL startet nicht oder liefert weniger Ergebnisse als erwartet

Fix: Fixieren Sie Swift-Scans zunächst auf eine von GitHub unterstützte Kombination aus macOS 26 oder älter und Xcode 26 oder älter; verschieben Sie Swift 6.4, bis die Kompatibilität geklärt ist. Für C/C++, C# und Java können Sie build mode: none untersuchen, müssen die Abdeckung aber gegen Ihren bisherigen Scan prüfen.

Diese Anleitung ist für Sie relevant, wenn Sie GitHub Actions und CodeQL betreiben, Swift- oder iOS-Projekte absichern oder Mac-CI-Knoten planen. Sie hilft Ihnen, eine Toolchain-Änderung von einem unvollständigen Scan zu unterscheiden.

Zuletzt aktualisiert am 24.10.2026; geprüft anhand der CodeQL-Kompatibilitätsmeldung von GitHub vom 19.10.2026 und der aktuellen GitHub-Dokumentation zu kompilierten Sprachen.

Ein erfolgreicher Workflow-Lauf beweist nicht, dass CodeQL den relevanten Quellcode vollständig erfasst hat. Kompilierung, Datenbankerstellung, Analyse und Upload sind getrennte Prüfpunkte: Sie müssen jeden davon kontrollieren, bevor Sie die Änderung als behoben einstufen.

Welche Arbeitslast ist betroffen?

Die Kompatibilitätsmeldung betrifft mehrere voneinander abzugrenzende Situationen. Entscheidend ist nicht nur, ob auf einem Mac gebaut wird, sondern welche Sprache untersucht wird, welche Xcode-Version installiert ist und ob CodeQL den Build verfolgen muss.

Die Angaben zu den betroffenen Sprachen, Toolchains und dem geplanten Ende der Intel-Mac-Unterstützung stammen aus der offiziellen GitHub-Meldung. Die allgemeine Beschreibung von Build-Modi und Sprachunterstützung finden Sie in der CodeQL-Dokumentation für kompilierte Sprachen.

Diese Unterschiede sind für Ihre Fehlerdiagnose wesentlich: Swift 6.4 ist eine Sprachversionsgrenze; Xcode 27 betrifft die Trace-basierte Erfassung in den genannten Sprachen; macOS 27 ist eine weitere, davon zu unterscheidende Umgebungseinschränkung. Ein Runner kann den Build erfolgreich ausführen und dennoch keine vollständige CodeQL-Datenbank liefern.

Szenario Swift: Warum wird Swift 6.4 nicht analysiert?

GitHub hat bestätigt, dass CodeQL Swift 6.4 nicht unterstützt. Das gilt nicht nur für einen bestimmten Mac-Knoten. Ein Wechsel des Rechners oder ein erneuter Workflow-Lauf beseitigt die Sprachversionsgrenze daher nicht automatisch. Prüfen Sie zuerst, ob der Build tatsächlich Swift 6.4 verwendet, statt aus einem erfolgreichen Kompilierungsschritt auf einen erfolgreichen Sicherheits-Scan zu schließen.

Für Swift-Scans empfiehlt GitHub eine Umgebung mit macOS 26 oder älter und Xcode 26 oder älter. Halten Sie für den Scan die Toolchain fest und verschieben Sie das Swift-Upgrade, bis GitHub die Unterstützung bestätigt oder Sie eine andere, belastbar geprüfte Vorgehensweise haben. Vermeiden Sie, in derselben Diagnose mehrere Variablen zu ändern: Wenn Sie gleichzeitig Runner-Image, Xcode-Auswahl und Swift-Version wechseln, wird die Ursache schwerer nachzuvollziehen.

Prüfen Sie vor dem Rollback, wie die Version in Ihrem Workflow festgelegt wird. Ein Runner-Label allein belegt nicht zwingend, welche Xcode-Version der Job auswählt. Kontrollieren Sie daher die Image-Angabe, den tatsächlich ausgewählten Xcode-Pfad und die Toolchain-Ausgabe im Job-Protokoll. Die Veröffentlichung eines Runner-Images mit Xcode 27 ist in den GitHub-Hinweisen zur allgemeinen Verfügbarkeit des Xcode-27-Runner-Images dokumentiert; daraus folgt aber nicht, dass dieses Image für jede CodeQL-Arbeitslast geeignet ist.

Kompilieren Sie nach der Fixierung erneut und prüfen Sie separat, ob CodeQL die Datenbank erstellt und analysiert hat. Wenn Ihr Team Swift 6.4 für andere CI-Aufgaben benötigt, können Sie diese Builds getrennt von der CodeQL-Prüfung ausführen. Dokumentieren Sie dann klar, welche Toolchain den Scan erzeugt, damit ein grüner Build auf der neuen Version nicht fälschlich als Sicherheitsfreigabe für den Scan gilt.

Szenario Xcode 27: Was ändert sich bei Trace-basierten Scans?

Bei installiertem Xcode 27 ist die Trace-basierte Extraktion laut GitHub für C/C++, C#, Go, Java, Kotlin und Swift nicht verfügbar. Das bedeutet nicht automatisch, dass jedes Projekt dieser Sprachen in jeder Konfiguration scheitert. Es bedeutet, dass Sie feststellen müssen, ob Ihr konkreter Scan auf die Trace-basierte Erfassung angewiesen ist und ob diese im aktuellen Runner tatsächlich funktioniert.

Erfassen Sie in einem Fehlerfall zunächst die reale Job-Konfiguration: Runner-Image, installierte Xcode-Version, ausgewählte Xcode-Version und CodeQL-Build-Modus. Prüfen Sie außerdem, ob die Sprache durch den betroffenen Build erzeugt wird oder ob mehrere Sprachscans in einem Workflow zusammenlaufen. Bei einem Multi-Language-Repository kann ein einzelner erfolgreicher Job-Schritt die fehlende Extraktion einer anderen Sprache verdecken.

macOS 27 ist gesondert zu betrachten. GitHub beschreibt die Extraktion dort als möglicherweise nicht verfügbar; diese Formulierung ist keine Bestätigung, dass jeder Scan auf macOS 27 fehlschlägt. Behandeln Sie die Betriebssystemversion deshalb als zu prüfende Variable und nicht als pauschale Fehlerdiagnose. Führen Sie einen Vergleich mit einem festgelegten Runner-Image und einer passenden Xcode-Version durch, damit Sie sehen, ob sich Datenbankinhalt und Analyseergebnisse tatsächlich ändern.

Die Versionswahl sollte außerdem in Ihren Workflow-Regeln sichtbar sein. Wenn Xcode durch ein Image-Label oder eine spätere Runner-Aktualisierung wechseln kann, reicht eine einmalige manuelle Prüfung nicht aus. Legen Sie die erwartete Umgebung fest, geben Sie die tatsächlich verwendete Version im Protokoll aus und stoppen Sie den Scan oder markieren Sie ihn als nicht freigabefähig, wenn die erforderliche Kombination abweicht.

Szenario ohne Trace-Build: Ist build mode: none ein Ersatz?

Für C/C++, C# und Java kann build mode: none eine mögliche Ausweichoption sein. Es handelt sich jedoch nicht um einen allgemeinen Ersatz für die Trace-basierte Extraktion. Der Modus erfasst den Build nicht auf dieselbe Weise; ob die resultierende Datenbank für Ihr Projekt genügt, hängt unter anderem davon ab, wie Quellcode, Abhängigkeiten und generierte Dateien in den Scan gelangen. Die zulässigen Optionen und ihre Grenzen beschreibt GitHub in den Build-Optionen für kompilierte Sprachen.

Bevor Sie none produktiv einsetzen, vergleichen Sie die Ergebnisse mit einem Scan aus der bisherigen, unterstützten Umgebung. Prüfen Sie, ob relevante Quellverzeichnisse in der Datenbank auftauchen, ob Abhängigkeiten angemessen berücksichtigt werden und ob generierter Code unerwartet fehlt oder anders behandelt wird. GitHub weist gesondert darauf hin, dass Warnungen in generiertem Code anders zu bewerten sind; lesen Sie dazu die Dokumentation zu Warnungen in generiertem Code.

Definieren Sie für den Vergleich nicht nur „Workflow erfolgreich“ als Kriterium. Legen Sie fest, welche Module, Quellpfade und Arten von Ergebnissen für Ihr Sicherheitsmodell relevant sind. Wenn der Scan mit none keine hinreichend nachvollziehbare Datenbank liefert, ist das ein Grund, zur unterstützten Trace-Umgebung zurückzukehren, nicht die Ergebnisse als gleichwertig zu behandeln.

Ein Wechsel des Build-Modus sollte außerdem in der Repository-Dokumentation und im Freigabeprozess auftauchen. Andernfalls können Entwickler und Sicherheitsverantwortliche Ergebnisse aus zwei unterschiedlichen Erfassungsverfahren miteinander vergleichen, ohne zu wissen, dass sich die Grundlage geändert hat. Halten Sie den Modus pro Sprache fest, besonders wenn dieselbe Pipeline mehrere kompilierte Sprachen prüft.

Szenario macOS- und Xcode-Fixierung: So führen Sie die Diagnose aus

Gehen Sie schrittweise vor. Die Reihenfolge hilft, die Ursache einzugrenzen, ohne die Umgebungsvariablen gleichzeitig zu verändern.

1. Betroffene Jobs erfassen. Notieren Sie Repository, gescannte Sprache, Runner-Image, ausgewählte Xcode-Version und CodeQL-Build-Modus. Unterscheiden Sie Swift-Scans von den Trace-basierten Scans der weiteren betroffenen Sprachen.

2. Die reale Toolchain feststellen. Prüfen Sie im Job-Protokoll, welche macOS- und Xcode-Version tatsächlich verwendet wird. Verlassen Sie sich nicht allein auf den Workflow-Namen oder einen zuvor freigegebenen Runner.

3. Die passende unterstützte Umgebung festlegen. Für Swift-Scans und Aufgaben, die die betroffene Trace-basierte Erfassung benötigen, folgen Sie der GitHub-Empfehlung zu macOS 26 oder älter und Xcode 26 oder älter. Verschieben Sie Swift 6.4 für den CodeQL-Scan.

4. Den Scan sauber neu ausführen. Verwenden Sie die fixierte Konfiguration und verändern Sie während dieses Vergleichs nicht zusätzlich Abhängigkeiten oder Quellpfade. So können Sie Unterschiede eher der Toolchain als einer weiteren Änderung zuordnen.

5. Die Datenbank kontrollieren. Prüfen Sie, ob der erwartete Erfassungsschritt ausgeführt wurde und ob die Datenbank die für das Repository relevanten Quellbereiche enthält. Ein Prozess, der ohne Fehler beendet wurde, reicht als Nachweis nicht aus.

6. Analyse und Upload getrennt bestätigen. Kontrollieren Sie, ob die Analyse abgeschlossen ist und ob der Ergebnis-Upload erfolgt ist. GitHub beschreibt den SARIF-Upload in der Anleitung zum Hochladen einer SARIF-Datei. Fehlt ein erwarteter Bericht, behandeln Sie den Lauf nicht als vollständigen Scan.

7. Ergebnis und Konfiguration dokumentieren. Halten Sie fest, welche Kombination freigegeben wurde, welcher Build-Modus eingesetzt wird und welche Abdeckung geprüft wurde. So können Sie spätere Runner- oder Toolchain-Änderungen gegen einen nachvollziehbaren Referenzstand prüfen.

Wenn Sie Ihre macOS- und Xcode-Versionen als kontrollierte Baseline verwalten, hilft Ihnen ergänzend der Leitfaden zur Wiederherstellung eines Mac-Packservers, um Wiederanlauf- und Rückfallbedingungen für Mac-CI einzuordnen. Das ist keine CodeQL-Kompatibilitätslösung, sondern eine Betriebsmaßnahme für den Fall, dass ein benötigter Mac-Knoten nicht verfügbar ist.

Wichtig: Eine erfolgreiche Kompilierung, ein erfolgreiches Ende des CodeQL-Schritts und ein sichtbarer Analysebericht sind unterschiedliche Beobachtungen. Geben Sie die Änderung erst frei, wenn Datenbank, Analyse und Upload jeweils geprüft sind.

Szenario Intel Mac: getrennte Migration statt vermeintlicher Reparatur

GitHub plant, die CodeQL-Unterstützung für Intel Mac Mitte Dezember 2026 einzustellen. Dieser Termin ist ein eigener Planungspunkt und keine Lösung für die Inkompatibilität von Xcode 27 oder Swift 6.4. Wenn Sie einen Intel-Mac-Runner ersetzen, können Sie dadurch die CodeQL-Kompatibilitätsgrenzen der neuen Toolchain nicht automatisch umgehen.

Ermitteln Sie, welche Workflows tatsächlich auf Intel-Macs laufen und welche davon CodeQL ausführen. Erfassen Sie für jeden betroffenen Job den Verantwortlichen, die benötigte Sprache, den Build-Modus und die vorgesehene Zielumgebung. Planen Sie die Umstellung getrennt von der Wiederherstellung eines derzeit blockierten Scans, damit eine bevorstehende Runner-Migration nicht die unmittelbare Fehlerbehebung verzögert.

Für den Mac-Betrieb sollten Sie außerdem Datenzugriff, Zugangskontrolle und Protokollierung gemeinsam mit der technischen Toolchain prüfen. Eine interne Prüfung Ihrer Datenschutzanforderungen, einschließlich der DSGVO-Vorgaben, sollte klären, welche Quellcode- und Build-Daten die jeweilige Umgebung verlassen dürfen. Für die Bewertung von Aufbewahrung und Zugriff können Sie die Datenschutzhinweise als einen Prüfpunkt heranziehen; sie ersetzen keine Prüfung Ihrer eigenen Compliance-Anforderungen.

Checkliste für die Freigabe

Nutzen Sie diese Prüfpunkte, bevor Sie den Scan wieder als verbindliche Sicherheitskontrolle behandeln:

• [ ] Sprache und tatsächliche Compiler- beziehungsweise Swift-Version sind dokumentiert.
• [ ] Runner-Image, macOS-Version und ausgewählte Xcode-Version wurden im Job bestätigt.
• [ ] Für Swift wird Swift 6.4 nicht als unterstützte CodeQL-Analyse vorausgesetzt.
• [ ] Bei Xcode 27 wurde geprüft, ob die betreffende Sprache auf Trace-basierte Extraktion angewiesen ist.
• [ ] Eine mögliche Einschränkung unter macOS 27 wird als prüfbare Grenze behandelt, nicht als pauschales Scheitern aller Scans.
• [ ] build mode: none wurde nur für C/C++, C# oder Java erwogen und anhand der benötigten Abdeckung bewertet.
• [ ] Datenbankinhalt, Analyseabschluss und Ergebnis-Upload wurden separat kontrolliert.
• [ ] Der Intel-Mac-Migrationsplan ist von der aktuellen Xcode- oder Swift-Fehlerbehebung getrennt.
• [ ] Abweichungen und freigegebene Toolchain-Kombinationen sind für Plattform- und Sicherheitsteams nachvollziehbar dokumentiert.

Wenn CodeQL einen Mac braucht

Prüfen Sie zuerst, ob Ihr konkreter CodeQL-Job tatsächlich eine Mac-Umgebung benötigt und ob sich das Problem durch eine unterstützte Toolchain beheben lässt. Wenn eine Mac-Ausführung erforderlich bleibt, vergleichen Sie den eigenen Knoten mit einem gemieteten Mac anhand Ihrer Beschaffungs- und Betriebsbedingungen. Ein eigener Rechner bindet Kapital und verlangt interne Verantwortung für Bereitstellung, Wartung und Ausfallbehandlung; eine gemietete Umgebung vermeidet die eigene Hardwarebeschaffung, ersetzt aber nicht die Prüfung von Zugriff, Datenschutz, Verfügbarkeit und Toolchain-Kompatibilität.

Für einen kurzfristigen oder klar abgegrenzten Bedarf kann ein entfernter Mac von KVMFLUX den Einstieg erleichtern, wenn Sie keine eigene Hardware beschaffen möchten. Prüfen Sie vor einer Entscheidung die konkreten Angebotsbedingungen und verifizieren Sie Ihre CodeQL-, macOS- und Xcode-Kombination selbst; hier liegen keine belastbaren KVMFLUX-Messdaten für genau diese Scans vor. Die verfügbaren Optionen können Sie in der Preisübersicht prüfen. Wenn Ihre Organisation bereits dauerhaft hohe Mac-Last oder besondere physische Schnittstellen benötigt, kann ein eigener Knoten die passendere Wahl bleiben.