Part I · Day One · Your first guardrail · p. 18–19

One file, six lines

This is the point where SecureGit stops being a thing you remember to run and starts being a thing that protects you when you forget.

Prefer the installer — securegit hook install --pre-commit (or --all) — so the fail-on bar and paths stay consistent with the CLI. If you are teaching the mechanism by hand:

.git/hooks/pre-commit

#!/bin/bash
securegit scan --staged --fail-on high || {
  echo "SecureGit: staged changes contain high-severity findings. Commit blocked."
  echo "Review with: securegit scan --staged"
  echo "Override once with: git commit --no-verify"
  exit 1
}

It scans only staged changes. Staged-only keeps it fast — typically well under a second — which is the difference between a hook you keep and a hook you delete in week two.
It fails at high, not medium. Start permissive. Tightening a working gate is easy. Loosening a gate that everyone has learned to bypass is nearly impossible.
It tells you how to override. A gate with no visible escape hatch gets removed. Print the override.

A gate with no visible escape hatch does not get respected. It gets removed. Print the override.

Distributing hooks to a team

.git/hooks is not version controlled. Three options, in increasing order of robustness: a setup script people forget to run; git config core.hooksPath .githooks with the hook committed; managed workstation configuration. Do not rely on a setup script alone past about five engineers. The failure is silent: someone joins, never runs the script, and is unprotected while believing they are protected.