Dependency scanning can run in four places: in the editor, on the pull request, during the build, and at a registry proxy. Each catches a different moment. The proxy acts before a package is downloaded, the IDE before it is committed, the pull request before merge, and the build before release. Most teams need more than one.
The four stages in one table
| Stage | When it fires | What it sees | Main blind spot |
|---|---|---|---|
| IDE | While the developer adds or edits a dependency | The manifest on one machine | Only runs where the plugin is installed and the developer looks |
| Pull request | When a change is proposed | The diff in manifests and lock files | Packages already on the main branch |
| Build | During CI, on the resolved tree | The full dependency set that will ship | Runs after the install, and after the code is written |
| Registry proxy | When any client requests a package | Every download, from any machine | Cannot judge how your code uses the package |
None of these is the single right answer. They answer different questions, which is why the sensible approach is to pick the order in which you add them, not to pick one.
What each stage is good at
IDE scanning is the cheapest moment to fix. A developer who sees a warning while choosing a package can pick another one in seconds. The weakness is coverage: it depends on every developer having the plugin and paying attention, so it works as guidance, not control.
Pull request scanning is where you can enforce. GitHub's dependency review, for example, shows which dependencies were added, removed or updated in a pull request, including indirect ones in lock files, along with known vulnerability data, and the related action can fail a check that blocks merging when it is required. That is a good model for what a pull request stage should do: compare before and after, and decide.
Build scanning reads the whole resolved tree. It catches things nobody changed in this pull request, such as an advisory published last night against a package that has been in the repo for a year.
Registry proxy scanning sits between your developers or CI runners and the public registry. It can refuse a package before it ever lands on a laptop or a runner, which matters because package install steps can execute code. It also covers machines that have no plugin and no pipeline.
Questions that decide the order
- Do you have enforcement anywhere today? If not, start at the pull request, because a failing check is the first real control.
- Do you worry about packages running code at install time? If yes, add a proxy or an allowlist so the decision happens before download.
- Do you ship long lived services? Then add scheduled re-scans, because a clean scan on release day says nothing about next month.
- Is developer speed your main complaint? Add the IDE stage so problems surface early and the later gates fail less often.
Try it yourself
Click through it at your own pace, or open it full screen. Watch where in the flow the decision to block is made, and what the developer sees when it fails.
Where Safeguard fits
Safeguard covers dependency scanning and SBOM generation, policies and gates that can block a pull request, and a free scan you can run at gold.safeguard.sh/scan. VS Code and JetBrains extensions and a CLI sit alongside the desktop app, so the same findings can show up at the stages described here.
Quick check
Is one stage enough?
Rarely. A single pull request check misses new advisories on old packages, and a build check alone fires late. Two stages that cover "before merge" and "after release" is a reasonable minimum.
Which stage blocks the most risk?
It depends on your threat. For known vulnerabilities, the pull request and build stages. For packages that run code on install, the proxy. Check your own incident history before deciding.
Sources
- GitHub Docs, About dependency review
Last reviewed: 19 October 2026.
