Keep security checks that run on every commit within a few minutes, in line with DORA's guidance that CI tests give feedback in a few minutes. Anything slower should move to a scheduled or pre-release job, so developers keep getting fast answers and do not learn to ignore the check.
What DORA says about CI speed
DORA's continuous integration page says each commit should trigger a build and a series of automated tests that provide feedback in a few minutes. It says unit tests must run in a few minutes or less, because if they take longer developers will not run them often, and failures then come from many changes at once, which makes debugging harder. It also lists an agreement that fixing a broken build takes priority over other work.
Security checks live in the same pipeline, so the same reasoning applies.
A practical budget
DORA does not set a number for security checks, so choose one with your team. A workable approach:
| Stage | Target | Contents |
|---|---|---|
| On every push or pull request | A few minutes total, shared with tests | Dependency advisory check, policy and license check, incremental static analysis |
| On merge to trunk | A few minutes | Same as above plus build artifact checks |
| Nightly or scheduled | Longer is fine | Full static analysis, container image scan, rescan of all dependencies against new advisories |
| Pre-release | Within release window | Dynamic testing, deeper review of high-risk changes |
How to find out where the time goes
- Record the duration of each pipeline step for two weeks.
- Calculate the median and the slowest 10 percent for each security step.
- Mark any step that is slower than the unit tests combined.
- Check what share of that time is setup, such as downloading databases, versus analysis.
- Cache what you can, and scope analysis to changed files where the tool supports it.
What to move out of the main path
Move a check out if it is slow and its findings are rarely about the current change. Whole-repository analysis is a typical example, since most findings predate the pull request. Keep the diff-scoped result in the path and show the rest as backlog.
Do not hide the cost
A check moved to a schedule must have an owner and a report. Otherwise slow checks become silent checks. Show the age of the last full scan per service, and alert if it goes stale.
Signs the budget is broken
- Developers rerun failed security jobs until they pass.
- Branches get longer, since people avoid triggering the pipeline.
- Overrides rise on busy days.
Each one points to slow or noisy checks, and each undermines the small-batch habit DORA recommends.
Quick check
Is a ten minute security scan acceptable?
It depends on your tests and team. If it is the slowest step and developers avoid it, split it into a fast diff-scoped part and a scheduled full part.
Can a scheduled scan replace the per-commit one?
No. The per-commit check gives feedback while the change is fresh. The scheduled one catches new advisories on old code. You want both.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how little a developer has to wait to see a gate result.
How Safeguard fits
Safeguard offers dependency scanning with policies and gates for pull requests and continuous monitoring for scheduled rescans, matching the two paths above. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, Continuous integration: https://dora.dev/capabilities/continuous-integration/
Last reviewed: 19 October 2026.
