A small team should add a pull request dependency check first, reading lock files and failing on a clear severity threshold. It is the earliest point where a check can actually block a change, it needs no developer setup, and it produces a record. Add scheduled re-scans second, and editor or proxy controls after that.
Why the pull request wins for small teams
Small teams have little time and no dedicated security staff. The first control has to be cheap to set up, hard to bypass, and easy to explain. A pull request check ticks all three.
- Cheap. One workflow file or one repository setting, shared by everyone.
- Hard to bypass. If the check is required, a merge cannot happen without it.
- Easy to explain. "A change that adds a known vulnerable package cannot merge" fits in a sentence.
An editor plugin depends on each person installing it. A registry proxy needs infrastructure to run and keep up. Both are good later, but neither is the quickest first win.
The second step: scheduled re-scans
A pull request check only looks at what changed. It will not tell you that a package already in the repository got a new advisory yesterday. A scheduled scan of the default branch, daily or weekly depending on how often you ship, fills that gap. Route the results to one place a person actually reads.
The third step: shorten the loop
Once the gate is stable, the main developer complaint will be "I found out too late". That is the moment to add editor scanning or a CLI command developers can run before pushing. The goal is fewer failed checks, not more checks.
A simple sequence
- Turn on a dependency check for pull requests and make it required on the main branch.
- Pick a failure threshold. Start with the highest severities only, so the first week is not a wall of red.
- Add a scheduled scan of the main branch and decide who owns the results.
- Write down how exceptions work: who can approve one, and for how long.
- Add editor or CLI scanning.
- Consider a registry proxy or approved package list when you have many repositories or many contributors.
For the proxy and allowlist decision specifically, see approved package allowlist or scan on install.
When to break this order
Skip ahead to a proxy or allowlist if your biggest worry is a malicious package running code during install, since a pull request check happens after a developer has probably already installed it locally. And if you ship a regulated product, scheduled scans with retained evidence may come before the editor step.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are grouped and prioritised, since that is the work a scheduled scan creates for you.
Where Safeguard fits
Safeguard covers dependency scanning and SBOM generation, with policies and gates that can block a pull request. You can try a scan for free at gold.safeguard.sh/scan to see what your repository looks like before you set anything up.
Quick check
Should the first check block merges or only warn?
Warn for a week to learn your baseline, then block on the highest severities. A check that never blocks is a report, not a control.
Do we need a security person to run this?
No, but someone must own the results and exceptions. Without an owner, the scheduled scan turns into an ignored inbox.
Last reviewed: 19 October 2026.
