Use a pre-commit hook for quick local checks, and use the pull request for the dependency decision you need to enforce. Hooks run on the developer's machine, so they can be skipped or never installed. They shorten the feedback loop, but only a required pull request check guarantees the scan happened.
What pre-commit is
The pre-commit project describes itself as a multi-language package manager for git hook scripts. You list hooks in a .pre-commit-config.yaml file, and it installs and runs them before every commit. Its own introduction frames hooks as a way to catch simple issues before code review, so the reviewer can focus on bigger questions.
That framing is the right way to think about dependency checks in a hook: catch the simple, fast thing early.
What fits in a hook
| Good fit | Poor fit |
|---|---|
| Is the lock file in sync with the manifest? | Full vulnerability analysis of the tree |
| Did someone add a dependency from a disallowed source? | Anything needing a slow network call each commit |
| Is a licence outside policy? | Reachability analysis |
| Is a new dependency name close to a known package name? | Decisions that must be enforced |
Commits happen often. A slow hook trains people to skip it.
Why a hook cannot be the control
- It must be installed by each developer, once per clone.
- It can be bypassed with a standard git option, and it does not run for edits made in a web editor.
- It leaves no record, so you cannot prove it ran.
That does not make hooks pointless. It makes them guidance.
Division of labour
- Pre-commit: lock file consistency, simple source and licence rules, fast local feedback.
- Pull request: the vulnerability and policy check against the diff, required before merge.
- Build: full resolved tree scan and SBOM.
- Scheduled: new advisories.
Making hooks stick
- Generate the config from the repository so it is versioned and shared.
- Add the install step to your onboarding script and the contributing guide.
- Run the same hooks in CI so a skipped hook is caught there. The pre-commit tool supports running all hooks across the repository, which makes this simple.
- Keep each hook quick. If one is slow, move it to the pull request.
For hook ideas, see pre-commit security hooks guide.
Where Safeguard fits
Safeguard offers a CLI you can call from a hook, plus dependency scanning and gates that block pull requests. You can also run a free scan at gold.safeguard.sh/scan.
Quick check
Can we make pre-commit hooks mandatory?
Not on the developer's machine. Make the same checks required in CI, which cannot be skipped locally.
Should a hook run a full vulnerability scan?
Usually not. Keep hooks fast and let the pull request carry the heavier check.
Sources
- pre-commit, Introduction
Last reviewed: 19 October 2026.
