A security scan slows builds by an amount that depends on repository size, scan type and caching, so ask vendors for measured times on projects like yours and whether scans can be incremental. Then set a time budget, such as a few minutes on pull requests, and run your own test.
Why speed is a security feature
A gate that takes twenty minutes gets bypassed, moved to nightly, or quietly disabled. Fast feedback keeps the control in place. This is why the first question about any scanner should be about time, not features.
Different scan types have very different costs. Dependency checks against an inventory are usually quick. Static code analysis takes longer. Dynamic scans of a running application can take much longer. Our post on DAST time budgets covers the last case.
Questions to ask
| Question | What to listen for |
|---|---|
| What is the median and worst case time on a repository our size? | Numbers, not adjectives |
| Is there an incremental mode for pull requests? | Scans changed paths only |
| Does it cache between runs? | Where, and how it is invalidated |
| Can scan work run in parallel? | Across projects or checks |
| Does the scan block the build or run beside it? | Both options help |
| What happens on a timeout? | Fail open, fail closed, or configurable |
| Does time scale with findings, or only with code? | Reporting cost can matter |
Timeout behaviour is a policy decision. The article on failing open or closed gives a way to choose.
Steps to measure
- Pick three repositories: small, medium and your largest.
- Record the current build time without the scanner, over at least five runs.
- Add the scanner on a branch and record the same number of runs.
- Calculate the added time as a median and as the worst run.
- Repeat with incremental mode and cache enabled.
- Compare to a budget your developers agree is acceptable.
Do this on shared runners at a typical busy hour. A test at midnight on an idle machine flatters every product.
Ways to keep scans fast
Split checks by purpose. Run quick dependency and secret checks on every pull request. Run slower, deeper analysis on merge to the main branch or on a schedule. Report the slower results asynchronously, and gate on them only for the highest risk findings.
Also look at what you scan. Excluding generated code, vendored copies and test fixtures cuts time and noise, but write the exclusions down and review them, since they are also blind spots.
Try it yourself
Click through it at your own pace, or open it full screen.
See how monitoring after the build catches new advisories without adding time to each pipeline run.
Quick check
What is a reasonable scan time on pull requests?
That is your call. Many teams aim for a few minutes at most, so the check finishes before review does.
Should slow scans be removed from CI?
Move them, not remove them. Run them on a schedule or on merge, and keep fast checks on each pull request.
Safeguard offers policies, gates and guardrails and a CLI; try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
