Start with the pull request. A pull request scan runs for everyone, cannot be skipped by one person's local setup, and fits the moment when code is already under review. For a team of about five, add IDE feedback second, and treat pre-commit hooks and nightly jobs as later upgrades.
Why the pull request comes first
Four places can host a scan: the editor, the commit, the pull request, and the scheduled job. Each one catches problems at a different cost. The editor is fastest but depends on every person installing and configuring it. A commit hook is personal too. Git's own documentation notes that client-side hooks are not copied when you clone a repository, so they cannot enforce policy on their own.
A pull request check is shared. It lives in the repository, runs the same way for every author, and shows up next to the review. With five people you probably do not have a platform team, so one shared check beats five local setups.
The order we suggest
| Order | Stage | Why at this size |
|---|---|---|
| 1 | Pull request scan | Shared, enforceable, one config file |
| 2 | IDE extension | Faster feedback, optional per person |
| 3 | Scheduled rescan | Catches new advisories on old code |
| 4 | Pre-commit hook | Useful once the team agrees on fast checks |
The scheduled rescan sits third because a clean pull request does not stay clean. New advisories are published against packages you already use. If nobody merges for two weeks, a pull request scan says nothing about them.
Keep the first gate small
A new scanner on a five person team can stall the whole group if it blocks on every finding. Start by blocking only issues that the pull request itself introduces, and only at the severity your team agrees is urgent. Everything else becomes a comment or a ticket. Tighten the rule after a month of real results.
Decide who owns a failure before it happens. On a small team the author of the pull request fixes it, and the reviewer checks that the fix is real and not a suppression.
Steps to set it up
- Pick one scanner that covers your dependencies and your code.
- Run it on every pull request through your CI service.
- Mark the job as a required status check so a merge needs it to pass. GitHub's branch protection documentation says required status checks must have a successful, skipped, or neutral status before changes reach a protected branch.
- Block only on new findings above your agreed severity.
- Write down the exception process in one paragraph.
- Revisit the rule after 30 days.
Where Safeguard fits
If you want to see what a first scan returns before wiring anything, the free scan at https://gold.safeguard.sh/scan needs no setup. Safeguard also offers policies and gates for pull requests, plus IDE extensions for VS Code and JetBrains, so you can move through the same order without changing tools.
Quick check
Should a small team scan in the IDE instead?
Not as the only stage. An IDE extension is helpful, but it depends on each person installing it and keeping it current. Use it as a second layer after the shared pull request check.
Do we need all four stages?
No. Most small teams are well served by a pull request scan plus a scheduled rescan. Add the others when you see a specific gap.
Sources
Last reviewed: 19 October 2026.
