A pull request dependency scan should finish in about the time developers already wait for their other checks, and ideally in parallel with them. There is no universal number. If the scan is the slowest check, people will start merging around it, so measure your own pipeline and set the budget there.
Why speed is a security property
A slow gate does not just annoy people. It changes behaviour: developers batch changes into bigger pull requests, rerun until green, or ask for the check to be made optional. Each of those weakens the control. Speed protects adoption.
What makes a dependency scan slow
- Resolving the tree from scratch. Installing everything just to scan it.
- Fetching vulnerability data on every run. Large downloads, repeated.
- Scanning the whole repository on every pull request. Including unchanged projects in a monorepo.
- Running it serially after tests. The scan waits when it could run alongside.
- Heavy analysis on every run. Deep reachability analysis on every commit when a quick diff check would do for most.
Ways to cut the time
| Technique | Effect | Caution |
|---|---|---|
| Read the lock file, do not install | Skips the slowest step | Needs a committed lock file |
| Scan only the diff | Fast, focused result | Does not cover old packages, keep a scheduled scan |
| Run in parallel with tests | Hides the time | Needs a runner with capacity |
| Cache vulnerability data | Saves repeated downloads | Set an expiry, stale data is a risk |
| Split fast and deep | Quick check on every push, deep analysis on merge or nightly | Make sure the deep result still reaches someone |
| Skip when no dependency file changed | Zero cost for most pull requests | Keep a periodic full run |
npm's documentation on its clean install command notes that keeping the npm cache around speeds up installs in CI, which is one example of the caching idea. For the scan data, the same logic applies with a freshness limit.
A budget exercise
- Look at the median time of your existing pull request checks.
- Time the dependency scan on a typical change and on your largest one.
- If it is slower than the other checks, apply the techniques above in order: lock file input, diff only, parallel run.
- Re-measure, and decide on a target you can state in one sentence, such as "no slower than the unit test job".
What not to trade away
Do not cut speed by skipping transitive dependencies or by reading only the manifest. A fast scan that misses the tree is not a scan. And do not let caching hide new advisories for days.
Where Safeguard fits
Safeguard offers dependency scanning with gates that can block a pull request, a CLI for local runs, and reachability analysis to prioritise findings. Try the free scan at gold.safeguard.sh/scan.
Quick check
Should the scan block the pull request while it is running?
Only if the check is required. If it is too slow, fix the speed instead of making it optional.
Is it safe to cache vulnerability data?
Yes with a short expiry and a visible timestamp. Long lived caches hide new advisories.
Sources
- npm Docs, npm ci
Last reviewed: 19 October 2026.
