Seit dem 2026-09-21 lehnt CircleCI Konfigurationen der Version 2.0, Branch-Filter wie /^(?!main).*/ und Parameter ab, die verwendet, aber nie deklariert werden, sodass die Pipeline fehlschlägt, bevor überhaupt ein Job startet. Ein unter environment: eingefügtes Sentry-Token kann jeder mit Zugriff auf das Projekt lesen, und ein Deploy-Job mit einem aws-production-Kontext, der auf jedem Branch läuft, übergibt diese Zugangsdaten jedem, der einen Branch pushen kann. Dieser Skill findet diese und die weiteren unten aufgeführten CircleCI-Fehler und zeigt Ihnen, wie Sie jeden davon beheben.

Ihr Agent führt einen Scanner über jede YAML-Datei unter .circleci/ aus (config.yml, Continuation-Konfigurationen für Setup-Workflows und Dynamic Config, gepackte Konfigurationsfragmente) oder über eine Konfigurationsdatei, die Sie angeben. Er versteht Orbs (aus der Registry, per URL und inline), Executors, Jobs, Commands, Workflows, Kontexte, Approval-Jobs, Filter, Pipeline-Parameter und << >>-Werte, YAML-Anker und ordnet run: |-Blöcke ihren echten Zeilennummern zu. Er kennt $NAME-Referenzen, env_var_name-Orb-Parameter, Passwörter von Testdatenbanken in Service-Containern (auch wenn ein Befehl sie wiederverwendet) und Einstellungen wie OIDC_TOKEN_AUDIENCE: sts.amazonaws.com, sodass diese nicht als Lecks gemeldet werden. Regeln mit einer CircleCI-Frist werden mit dem heutigen Datum verglichen. Er führt nie einen Job oder die CircleCI CLI aus und nutzt nie das Netzwerk. Er liefert BLOCK, REVIEW oder NOT FLAGGED mit Datei, Zeile, Begründung und einem sichereren Ansatz und verlinkt die CircleCI-Seite zu jeder Regel, für die es eine gibt. Secrets werden nie ausgegeben.

Was geprüft wird

BLOCK (vor dem Ausliefern beheben)

• C01: Passwörter, Tokens und Schlüssel, die in der Konfiguration stehen (environment-Werte, docker auth, Orb- und Job-Parameter, Parameter-Standardwerte, curl -u, Authorization-Header, docker login -p, ein per echo an docker login --password-stdin übergebenes Literal, npm _authToken, Passwörter in URLs, Token-Formate von GitHub, AWS, CircleCI, npm, Slack und anderen, private Schlüssel)
• C02: Skripte oder Binärdateien, die über http:// oder mit deaktivierter TLS-Prüfung heruntergeladen und dann ohne Prüfsumme ausgeführt werden
• C03: Orbs, die als @volatile oder mit einer dev:-Version referenziert werden (außer dem Orb, den ein Orb-Repository in seiner eigenen Test-Pipeline veröffentlicht)
• C04: Konfiguration, die CircleCI nicht mehr kompiliert: eine andere Version als 2.1, Regex-Filter mit negativen Lookarounds, possessiven Quantoren oder Rückverweisen, nicht deklarierte Parameter, Pipeline-Parameter in Inline-Orbs, Job-Namen mit Doppelpunkten oder Klammern, branches an einem Job, resource_class innerhalb von machine, eine leere config.yml und ab dem 2026-12-14 die Validator-Warnungen aus C19
• C05: entfernte Executors: Ubuntu 14.04/16.04 und entfernte datierte Machine-Images 20.04/22.04, entfernte Xcode-Versionen (16.2.0 und 26.2.0 ab dem 2026-12-07), Intel-macOS- und M1/M2-Resource-Classes

REVIEW (vor dem Release prüfen)

• C11: Partner- und Community-Orbs, die nur auf eine Major- oder Minor-Version festgelegt sind, und URL-Orbs auf einem Branch statt auf einem Commit
• C12: Docker-Images ohne Tag oder mit latest, Machine-Images auf edge
• C13: Branch-Namen, Tags, Commit-Nachrichten, Pull-Request-Titel, Webhook-Bodys und String-Pipeline-Parameter, die in run-Befehle eingefügt werden (auch über einen Job-Parameter)
• C14: add_ssh_keys ohne fingerprints
• C15: veraltete circleci/-Images, Machine-Images circleci/classic und Ubuntu 20.04, Xcode 16.2.0 und 26.2.0 vor ihrer Entfernung am 2026-12-07, machine: true ohne Image
• C16: curl | bash, bash <(curl ...) und Herunterladen-dann-Ausführen über HTTPS ohne Prüfsummen- oder Signaturprüfung
• C17: Deploy-, Release-, Publish- oder Signing-Jobs mit einem Kontext, die auf jedem Branch laufen, ohne Filter, Approval-Job oder Workflow-Bedingung (Deployments für non-prod, preview, staging und dev zählen nicht)
• C18: ausgemusterte Pipeline-Werte: pipeline.trigger_parameters.circleci.*, pipeline.trigger_parameters.github_app.*, pipeline.trigger_source, $CIRCLE_COMPARE_URL
• C19: Warnungen des Konfigurationsvalidators, die ab dem 2026-12-14 Pipelines blockieren (enum-Standardwert nicht in seinem enum, run-Schritt ohne Befehl, when neben einem Schritt, Workflow mit when und unless zugleich, ungültiger Command-Name, leeres requires, nacktes docker: oder steps:, ungültige parallelism oder checkout-Methode, nicht deklarierte Job- oder Command-Argumente, per Template erzeugter Job-Typ); ab diesem Tag als C04 gemeldet

Was enthalten ist

• Der Scanner (Python 3.9+, nur Standardbibliothek)
• Ein Regelleitfaden mit Begründung, sichererem Ansatz und offizieller CircleCI-Quelle für jede Regel (C13 hat keine: Keine CircleCI-Seite behandelt das)
• Ein riskantes und ein sicheres Beispiel (ein Onlineshop mit Deploy-Jobs für Web, iOS und AWS) sowie der echte Bericht, den der Scanner für das riskante Beispiel erzeugt

Grenzen

Er liest jede Datei so, wie sie geschrieben ist. Einstellungen außerhalb des Repositorys sind nicht sichtbar: Umgebungsvariablen des Projekts, Kontext-Einschränkungen, die Weitergabe von Secrets an Pull Requests aus Forks, Orb-Allowlists, Konfigurationsrichtlinien und Branch-Schutz. Der Quellcode von Orbs wird nicht abgerufen, daher wird nicht verfolgt, was ein Orb mit seinen Parametern macht. Die Listen entfernter Images, Xcode-Versionen und Resource-Classes folgen dem Changelog von CircleCI bis November 2026. Einige Snippets aus der offiziellen Dokumentation werden absichtlich gemeldet (zum Beispiel ein echo von << pipeline.git.branch >> oder eines String-Pipeline-Parameters in einem run-Schritt); C13 beruht darauf, wie CircleCI << >>-Werte in die Konfiguration schreibt, da keine CircleCI-Seite davor warnt. Das riskante Beispiel enthält keinen C19-Befund, weil C19 am 2026-12-14 zu C04 wird. NOT FLAGGED ist keine Garantie.

Inhalt

Eine ZIP-Datei mit 11 Dateien: SKILL.md, der Scanner in scripts/ (6 Python-Dateien), references/rules.md (jede Regel mit Begründung und sichererem Ansatz) und examples/ (2 Beispieldateien plus report.md, die echte Scanner-Ausgabe für das riskante Beispiel).

Verwendung: Dies ist ein Agent-Skill: ein Ordner mit einer SKILL.md-Datei und Python-Skripten, die ein KI-Coding-Agent wie Claude Code, Cursor oder Codex CLI ausführen kann. Entpacken Sie ihn in den Skills-Ordner Ihres Agenten (für Claude Code: ~/.claude/skills/) und bitten Sie dann Ihren Agenten, Ihr Projekt zu prüfen. Die Skripte laufen auch eigenständig mit Python 3.9 oder neuer, ohne dass etwas installiert werden muss. Sie lesen nur Ihre Dateien: kein Netzwerkzugriff, und nichts wird irgendwohin gesendet.