Dein Blog zum Thema digitales Business

Was CodeQL Code Scanning prüft und was nicht

CodeQL Default Setup schaltet Code Scanning für ein Repository ein, ohne dass du eine Workflow-Datei schreibst oder pflegst. Code Scanning analysiert den Code auf Sicherheitslücken und Programmierfehler und zeigt Treffer als Alerts im Repository. CodeQL ist die Analyse-Engine, die GitHub dafür entwickelt: Sie baut aus deinem Code eine Datenbank und lässt Abfragen darüber laufen, jeder Treffer wird ein Alert.

Dieser Beitrag stützt sich auf die GitHub-Dokumentation, gelesen am 26.09.2026: Configuring default setup for code scanning, About code scanning und Code scanning with CodeQL. Ergänzend: About setup types for code scanning, CodeQL query suites, Assessing code scanning alerts und Resolving code scanning alerts. Folgerungen sind gekennzeichnet.

Die Doku nennt diese Sprachen: C/C++, C#, Go, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, Rust, Swift und GitHub-Actions-Workflows. Bei nicht unterstützten Sprachen wie PHP oder Scala kann laut Doku ein Scan ohne Alerts und mit unvollständiger Analyse herauskommen. Für eigene Abhängigkeiten ohne Modell nennt die Doku den Model Editor der CodeQL-Erweiterung für Visual Studio Code.

Folgerung, nicht in der Doku: Ein leerer Alert-Bereich heißt, dass die Abfragen nichts gemeldet haben. Er heißt nicht, dass der Code sicher ist.

CodeQL Default Setup aktivieren: was GitHub für dich wählt

Default Setup wählt laut Doku Sprachen, Query-Suite und Auslöser selbst. Gescannt wird:

• bei jedem Push auf den Default-Branch oder einen geschützten Branch,
• bei Pull Requests gegen diese Branches, ausgenommen Pull Requests aus Forks,
• nach einem wöchentlichen Zeitplan.

Als Query-Suite stehen default und „Extended“ (security-extended) zur Wahl. Die Doku nennt default hochpräzise mit wenigen False Positives. Extended enthält zusätzliche Abfragen mit etwas geringerer Präzision und Schwere und kann mehr False Positives liefern. security-and-quality steht laut Doku für Advanced Setup bereit.

Voraussetzung laut Doku: GitHub Actions ist aktiviert, und das Repository ist öffentlich oder hat GitHub Code Security aktiv. Der Weg: Repository, Settings, „Advanced Security“, bei „CodeQL analysis“ auf „Set up“ und „Default“. Ein Dialog fasst die erzeugte Konfiguration zusammen, über „Edit“ änderst du Sprachen und Suite, „Enable CodeQL“ startet einen Testlauf. Das dürfen Repository-Owner, Organisations-Owner, Security Manager und Nutzer mit Admin-Rolle. Auf einem Fork musst du zuerst GitHub Actions einschalten, und das aktiviert alle vorhandenen Workflows des Forks.

Kommt später eine unterstützte Sprache hinzu, ergänzt GitHub die Konfiguration selbst. Schlägt der Lauf damit fehl, greift die vorherige Konfiguration wieder.

Wer Code Scanning nutzen darf: öffentliche und private Repos, Lizenz

Die Doku nennt zwei Gruppen: öffentliche Repositories auf GitHub.com und organisationseigene Repositories auf GitHub Team, GitHub Enterprise Cloud oder GitHub Enterprise Server, sofern GitHub Code Security aktiviert ist. Für private Repositories steht in „About code scanning“ ausdrücklich, dass du eine GitHub-Code-Security-Lizenz brauchst. Einen Preis nennt dieser Beitrag nicht.

Dazu kommen Actions-Minuten: Code Scanning läuft über GitHub Actions, und jeder Workflow-Lauf verbraucht Minuten. Zwei Regeln aus der Doku begrenzen das:

• Ohne Push und Pull Request seit 6 Monaten schaltet GitHub den wöchentlichen Zeitplan ab, um Minuten zu sparen. Organisations-Owner können monatliche Scans inaktiver Repositories aktivieren.
• Schlägt die Analyse für alle unterstützten Sprachen fehl, bleibt Default Setup aktiviert, führt aber keine Scans aus und verbraucht keine Minuten. Das gilt, bis eine weitere Sprache dazukommt oder du neu konfigurierst und eine Analyse gelingt.

Folgerung, nicht in der Doku: Ein aktivierter Schalter belegt nicht, dass gescannt wird. Die Tool-Status-Seite zeigt laut Doku Zeitstempel je Scan und den Anteil gescannter Dateien. Schau dort nach dem ersten Lauf hinein.

Build-Modi und Grenzen: wann Default Setup nicht reicht

Default Setup nutzt für C/C++, C#, Java und Rust den Build-Modus none, der Code wird also ohne eigenen Build analysiert. Für andere kompilierte Sprachen nutzt es autobuild. Auf selbst gehosteten Runnern müssen die nötigen Befehle für C/C++, C# und Swift vorhanden sein.

Die Doku nennt Advanced Setup, wenn du eigene Workflow-Logik brauchst: kompilierte Sprachen selbst bauen, Matrix-Build, anderer Zeitplan. Auch eigene Query-Suites und zusätzliche Abfragen gehören dorthin, ebenso eine externe CI mit hochgeladenen Ergebnissen. Ein paar frühere Advanced-Gründe deckt inzwischen eine Konfigurationsdatei ab, die du per Repository-Eigenschaft an Default Setup hängst.

Wechselst du von Advanced auf Default Setup, warnt GitHub: Default Setup deaktiviert die vorhandene Workflow-Datei und blockiert CodeQL-Uploads über die API. Laufen mehrere Konfigurationen, kann derselbe Alert von mehr als einer Konfiguration gemeldet werden, und selten laufende Konfigurationen liefern veraltete Stände.

Folgerung, nicht in der Doku: Prüfe nach dem Wechsel unter „Affected branches“, welche Konfigurationen einen Alert melden. Veraltete lassen sich dort entfernen, die Resolving-Seite der Doku beschreibt den Weg.

Ergebnisse lesen: Alerts triagieren statt ignorieren

Alerts siehst du mit Schreibrechten unter „Security and quality“, „Code scanning“. Die Liste zeigt standardmäßig nur den Default-Branch. Filterbeispiele aus der Doku (nicht getestet):

is:open branch:main branch:next
-tag:style

Der Filter „Only alerts in application code“ blendet Code aus, den GitHub nicht als Anwendungscode einstuft. Bei Datenfluss-Alerts zeigt „Show paths“ den Weg von der Quelle bis zur riskanten Stelle.

Schließen kannst du einen Alert auf zwei Wegen: den Code korrigieren oder den Alert verwerfen. Beim Verwerfen wählst du einen Grund, der laut Doku beeinflussen kann, ob die Abfrage in künftigen Analysen erhalten bleibt. Das Verwerfen gilt in allen Branches, und ein Kommentar lässt sich als Begründung für Audits nutzen. Mehrere Alerts mit gleichem Grund kannst du gesammelt verwerfen, etwa nach CWE gefiltert.

Folgerung, nicht in der Doku: Ein Verwerfen ohne Kommentar hinterlässt später nur den gewählten Grund. Schreib den Kommentar, solange du den Kontext noch kennst.

Abgrenzung: CodeQL, zizmor, actionlint, SCA und Secret Scanning

CodeQL prüft Code in den oben genannten Sprachen, darunter GitHub-Actions-Workflows. Zu actionlint und zizmor, die Workflow-Dateien statisch prüfen, gibt es auf muellermh.blog den Beitrag Workflows statisch prüfen: actionlint und zizmor in der Pipeline. Abhängigkeiten sind Thema in Software Composition Analysis: Abhängigkeiten kennen, bevor es der Angreifer tut und Dependabot vs. Renovate. Tokens im Repository deckt Secret Scanning und Push Protection ab.

Ob und wie weit sich das mit zizmor und actionlint überschneidet, vergleicht dieser Beitrag nicht. Die gelesenen Doku-Seiten sagen dazu nichts.

Wo Unterstützung ansetzt

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.