Run dependency checks at the pull request for enforcement, and add a light pre-commit hook for speed. A hook can be skipped or never installed, so it cannot be your control. A pull request check runs for everyone and can block a merge.
What a pre-commit hook is
The pre-commit framework describes git hook scripts as useful for identifying simple issues before submission to code review, running on every commit. The idea is to catch trivial problems early so reviewers can focus on design. A hook that checks a changed lockfile follows the same logic.
What a pull request check is
A pull request check is a pipeline job tied to the review. It runs on a clean machine, with shared config, and reports a pass or fail status that branch protection can require.
Comparison
| Factor | Pre-commit hook | Pull request check |
|---|---|---|
| Runs for everyone | No, each clone must install it | Yes |
| Can be bypassed | Yes, with a flag or by not installing | Only with an admin override |
| Speed | Must be very fast | Can take longer |
| Needs network | Often avoided | Usually fine |
| Sees the merged result | No | Can test merge result |
| Good for | Quick hints | Decisions |
Design rules for a dependency hook
- Run when a manifest or lockfile changes. Scanning on every commit annoys people.
- Keep it under a few seconds. Slow hooks get skipped with a bypass flag, which teaches everyone to skip them.
- Use a local database or cached data. Network calls on every commit fail on trains and planes.
- Warn, do not block, unless the finding is severe. The hook is advice. The pull request check is the gate.
- Share config. The hook and the pull request check should read the same policy file.
Design rules for the pull request check
- Run on every pull request that touches dependency files, and also on a schedule.
- Comment on new findings introduced by the change. Old debt belongs on a backlog, not on a stranger's pull request.
- Make the failure message actionable: package, version, path, fix version if known.
- Require the check in branch protection.
- Allow exceptions that expire, with a named approver.
A setup that uses both
Day one, add the pull request check in report mode. When noise is low, switch it to blocking for a narrow rule. Then offer the hook as an optional install, documented in the contributing guide. Measure how many findings are caught at commit versus review. If the hook catches almost nothing, it is not earning its place.
Quick check
Should the hook block commits?
For serious, unambiguous findings. Blocking on everything leads people to bypass it.
Do I still need CI if everyone has the hook?
Yes. Hooks are local and optional, and bots and web edits never run them.
Safeguard offers a CLI, IDE plugins, and pull request gates driven by one policy set, with dependency scanning and reachability analysis behind them. You can try a free scan before choosing where to run it.
Sources
Last reviewed: 19 October 2026.
