How fast must a SAST scan be to fit your CI pipeline?

Decide your budget first: pull request scans should finish in roughly the time your tests do, so developers do not wait on them, while full scans can run nightly and take much longer. Measure each candidate tool on your largest repository, cold and warm, and record the numbers.

Two different clocks

A tool has at least two speeds, and vendors tend to quote the better one.

Pull request scan. Runs on every push. It competes with unit tests for developer patience. If it is much slower than your test suite, people stop waiting and merge on faith.

Full scan. Runs on a schedule against the whole codebase. It can take an hour without hurting anyone, as long as results are ready by morning.

Ask which clock a quoted number refers to. A claim about scanning speed on a small sample project says very little about your monorepo.

What to measure

For each candidate, on your largest and your most typical repository, write down:

• Time to first result on a cold run, with no cache and no prior scan.
• Time on a warm run with a small change.
• Time for the build step, if the tool needs a compile. OWASP notes that many static tools need buildable code, so build time is part of scan time.
• Peak memory and CPU on the runner. A tool that needs a large machine changes your CI cost.
• Variation across five runs. Averages hide the slow outlier that breaks a deadline.

Do it three times at different times of day if your runners are shared.

Incremental scanning, honestly

Many tools claim to scan only what changed. That is good when it works, but static analysis often needs to follow data across files, so a change in one file can affect results in another. Ask how the tool handles this. Acceptable answers include scanning changed files plus their callers, or running a quick check on the pull request and a complete scan after merge.

Test it. Change a helper function that many files use, introduce a flaw that depends on it, and see whether the pull request scan catches it. If it only looks at the diff, it may miss flows that cross the changed line.

Budgets by team type

There is no universal number, but you can reason about it.

• If your tests take five minutes, aim for a pull request scan in a similar range.
• If your pipeline already takes forty minutes, a ten minute scan runs in parallel and costs developers nothing, provided it is not on the critical path.
• If a scan cannot meet a pull request budget, run it after merge and alert on new findings. That is less protective but better than a check everyone bypasses.

Parallel runs and caching

Check whether the tool can run as a parallel job, whether results can be cached between runs, and whether it splits a large repository by directory. These features matter more on big codebases than raw engine speed.

Also ask about timeouts. What happens when the scan exceeds a limit: does it report partial results, fail loudly, or silently pass?

When slow is fine

Some tools take longer because they do deeper data flow analysis. If a slower engine finds real issues the quick one misses, a nightly scan with the deeper tool plus a fast pull request check can be a sensible pairing. Judge that by your pilot data, not by the marketing page.

Quick check

Safeguard's CLI can run in CI pipelines, and the free scan at gold.safeguard.sh/scan lets you try the dependency side without setup.

Sources

• OWASP, Source Code Analysis Tools

Last reviewed: 19 October 2026.