There is no universal right number. Set your own limit, time the demo on your largest repository, and measure the first scan and a rescan separately. A pull request check that developers wait on should finish in minutes. A full baseline scan can run longer if it runs off the critical path.
Two different clocks
People say "scan time" and mean different things. Separate them:
- First scan. The initial analysis of a whole repository. It builds the inventory and matches it against advisories. It can be slow and is done once.
- Incremental scan. The check on a change, such as a pull request. This is the one developers feel every day.
- Scheduled rescan. A periodic check of the existing inventory against new advisories. It usually needs no code to be re-read.
A tool can be slow on the first and fast on the others, or the reverse. Ask for all three in the demo.
How to time it fairly
- Start your own stopwatch when the scan is triggered, not when the vendor says it started.
- Record when results are visible in the interface, not when the job is "finished" in a log.
- Repeat the scan once. Caches change timing, so note both runs.
- Use the largest repository you actually maintain, and one typical one for contrast.
- Note what else was running. Time of day and shared infrastructure can matter.
Setting your limit
Ask the developers who will wait on it. A short survey of one question works: "How long would you wait for a security check on a pull request before you start doing something else?" Many teams find the answer is a few minutes. Use your team's answer, not mine.
| Scan type | Typical expectation | Where it runs |
|---|---|---|
| Pull request check | Short, in line with other CI jobs | In the pipeline |
| First scan | Can be longer | Off the critical path |
| Rescan for new advisories | Short, no code re-read | Scheduled |
The middle column is a prompt for your own thinking, not a benchmark. Your pipeline, your codebase and your tolerance decide.
What slows a scan down
- Very large monorepos with many lockfiles.
- Container image analysis with many layers.
- Code analysis that builds a call graph for reachability.
- Network calls to fetch advisory data or private packages.
Ask the vendor which of these apply to your repo and what settings control them. Some tools let you run the heavy analysis on merge to the main branch rather than on every pull request.
What to do if it is too slow
Do not decide on the spot. Ask whether scope can be narrowed, whether results can be cached, and whether the heavy parts can run asynchronously. Then retest. A slow first result with a fixable cause is different from a slow design.
Where Safeguard fits
You can try a scan on one of your repositories for free at gold.safeguard.sh/scan and time it yourself. Safeguard offers dependency scanning, SBOM generation and reachability analysis.
Quick check
Is a faster scan always better?
No. Speed matters, but a fast scan that skips files is worse than a slower accurate one. Check coverage as well.
Should I test on my smallest repo?
Include it for contrast, but the largest repo is where problems show up first.
Last reviewed: 19 October 2026.
