Eine .pre-commit-config.yaml mit rev: stable wirkt fixiert, doch pre-commit aktualisiert eine Branch-Revision nie, und jeder neue Klon erhält, was dieser Branch an diesem Tag gerade enthält. Ein lokaler Hook mit dem entry bash -c 'curl ... | sh' führt bei jedem Commit auf jedem Entwickler-Laptop ein heruntergeladenes Skript aus. Ein gitleaks-Hook, der unter ci: skip steht, scannt nie die Commits, die ihn lokal übersprungen haben. Dieser Skill findet diese und die weiteren unten aufgeführten Fehler bei Git-Hooks und sagt Ihnen, wie Sie jeden davon beheben.

Ihr Agent führt einen Scanner auf .pre-commit-config.yaml (mit dem Abschnitt ci: für pre-commit.ci) und .pre-commit-hooks.yaml aus, auf lefthook-Konfigurationen in YAML, JSON oder TOML (einschließlich lefthook-local-Dateien und Remotes) und den Skripten in .lefthook/, auf husky-Hook-Skripten in .husky/, Hook-Skripten in .githooks/ und ähnlichen Ordnern, auf simple-git-hooks und alter husky-Konfiguration in package.json sowie auf Shell-Skripten, Makefiles und package.json-Skripten, die Hooks installieren oder umgehen. Er überspringt Kommentare, fügt fortgesetzte Zeilen zusammen, nutzt den eigenen Test von pre-commit für Branch-Revisionen und behandelt $VAR und ${{ secrets.X }} als Werte, die außerhalb der Datei liegen. Er führt nie einen Hook, git oder ein anderes Tool aus und nutzt nie das Netzwerk. Das Ergebnis lautet BLOCK, REVIEW oder NOT FLAGGED, mit Datei, Zeile, Begründung und einem sichereren Ansatz. Secrets werden nie ausgegeben.

Was geprüft wird

BLOCK (vor der Auslieferung beheben)

• G01: Hook-Repositorys, die über http:// oder git:// abgerufen werden (pre-commit repo:, lefthook remote git_url)
• G02: pre-commit-Revisionen, die einen Branch, HEAD, ein verschiebbares Tag oder gar nichts angeben (rev: main, rev: stable, rev: '')
• G03: Hooks, die Code herunterladen und ausführen (curl oder wget, gepipt in eine Shell oder einen Interpreter, der den Download als Programm liest, sh -c "$(curl ...)", bash <(wget ...), iex (irm ...), oder eine heruntergeladene Datei, die ohne Prüfsummenkontrolle ausgeführt wird); Installationshinweise, die ein Hook nur ausgibt, zählen nicht
• G04: Tokens, Passwörter und Schlüssel in Hook-Konfigurationen und -Skripten (env-Werte, Argumente --token und --password, Authorization-Header, ein Passwort in einer Repository-URL, bekannte Token-Formate); Dateinamen, Pfade und Einstellungswörter wie enabled werden nicht gemeldet

REVIEW (vor dem Release prüfen)

• G11: pre-commit-Revisionen, die auf Tags statt auf Commit-SHAs fixiert sind
• G12: lefthook-Remotes ohne ref oder mit einem Branch als ref
• G13: Hook-Tools, die ohne Version abgerufen werden (additional_dependencies, Docker-Images ohne Tag oder mit :latest, npx --yes, bunx, pnpm und yarn dlx, uvx, pipx run, go run @latest)
• G14: Projekte mit Git-Hooks, aber ohne Hook zum Scannen nach Secrets
• G15: Secret-Scanner, die in pre-commit.ci übersprungen, auf die Stage manual beschränkt, von allen Dateien ausgeschlossen oder in lefthook auf skip gesetzt sind
• G16: Umgehungen von Hooks in Skripten und Hook-Meldungen (--no-verify, git commit -n, HUSKY=0, LEFTHOOK=0, SKIP= mit einem Secret-Scanner, core.hooksPath auf /dev/null gesetzt)
• G17: Projektskripte, die core.hooksPath mit --global oder --system setzen
• G18: in Hooks deaktivierte TLS- oder Host-Key-Prüfungen (curl -k, http.sslVerify false, NODE_TLS_REJECT_UNAUTHORIZED=0, --trusted-host und weitere)
• G19: Hook-Konfigurationen, die das Tool nie lädt (husky-v4-Konfiguration mit husky 5 oder neuer, .pre-commit-config.yml, zwei lefthook-Konfigurationen in einem Ordner)

Was enthalten ist

• Der Scanner (Python 3.9+, nur Standardbibliothek)
• Ein Regelleitfaden mit Begründung, sichererem Ansatz und offizieller Quelle für jede Regel
• Ein riskantes und ein sicheres Beispiel (eine API mit pre-commit, eine Web-App mit lefthook, eine mobile App mit husky) sowie der echte Bericht, den der Scanner für das riskante Beispiel erzeugt

Grenzen

Jede Datei wird so gelesen, wie sie geschrieben ist. Entfernte Hook-Repositorys und entfernte lefthook-Konfigurationen werden benannt, aber nicht abgerufen, daher wird der Code, den sie mitbringen, nicht geprüft. Bereits in .git/hooks installierte Hooks, in Ihrer git-Konfiguration gesetztes core.hooksPath, Skripte, die ein Hook aufruft, und CI-Workflows, die pre-commit ausführen, werden nicht gelesen. G11 (auf Tags fixierte Revisionen) und G14 (kein Hook zum Scannen nach Secrets) schlagen bei den meisten Konfigurationen an, einschließlich des Schnellstart-Beispiels von pre-commit und standardmäßiger husky-Projekte; der Agent stellt sie als Hinweise zur Härtung dar, nicht als Probleme. G14 kann serverseitiges Scannen wie GitHub Push Protection nicht erkennen. NOT FLAGGED ist keine Garantie.

Inhalt

Eine ZIP-Datei mit 22 Dateien: SKILL.md, der Scanner in scripts/ (10 Python-Dateien), references/rules.md (jede Regel mit Begründung und sichererem Ansatz) und examples/ (11 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 Ihren Agenten dann, 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.