Summary

Part of John Roberts’ DevSecOps/CI-CD security series. Covers Git hooks as security touchpoints: what they are, how they work, key use cases (SAST, secret detection), and the critical limitation that client-side hooks can be bypassed with --no-verify.

John Roberts DevSecOps/CI-CD 安全系列的一部分。涵蓋 Git hooks 作為安全接觸點:它們是什麼、如何工作、主要使用案例(SAST、秘密檢測),以及客戶端 hooks 可以通過 --no-verify 繞過的關鍵限制。

Key Points

  • Git hooks: scripts in .git/hooks/ that run on development events; pre-commit (before git commit), pre-push (before git push), and others
  • Client-side hooks: run on developer machine or CI server; NOT copied on git clone; easily overridden with --no-verify
  • Server-side hooks: run on the version control server; harder to bypass; use these to enforce policies
  • Security use cases: triggering SAST and linters for security issues; running security unit tests; blocking commits containing secrets (API keys, SSH keys, TLS certs, passwords)
  • Tools: git-secrets and gitleaks — open-source, regex-based, pre-commit hooks for common secret types; GitHub proactively blocks known secret patterns server-side
  • Real power: customizing hooks to your application’s specific security needs

Insights

The --no-verify bypass is the core limitation that makes client-side hooks a “soft” control rather than a hard enforcement. The practical implication: pre-commit hooks are best for developer ergonomics (fast feedback) while server-side hooks are the actual security boundary. Running secret detection twice (client-side for speed, server-side for enforcement) is the pragmatic approach. The gitleaks/git-secrets ecosystem has matured significantly since this article; tools like detect-secrets and GitHub’s native secret scanning have largely superseded the OWASP Glue approach mentioned.

Connections

Raw Excerpt

Note that client-side hooks aren’t copied on git clone and can be easily overriden using git’s —no-verify flag, so if you’re trying to enforce security policies you want server-side hooks.