Not by itself. DORA's research frames throughput and stability as moving together for top performers, and its pervasive security page says integrating security into daily work improves delivery performance. Speed becomes risky when checks are skipped, batches are large, or nobody owns fixes. Those are process problems, not speed problems.
Myth 1: you have to choose between fast and safe
DORA's guide says top performers do well across all five delivery metrics and low performers do poorly. It does not describe a trade-off between throughput and instability for top performers. The pervasive security page goes further, stating that teams achieve higher software delivery performance by better integrating security objectives into daily work.
Fact: the research points to practices, not speed, as the deciding factor.
Myth 2: security review at the end is the safe way
The DORA page describes the traditional model, where security testing happens after development, as one where teams discover significant problems that are expensive to fix, with unpredictable time to repair that can push delivery dates out.
Fact: late review tends to be slower and riskier. Earlier, smaller checks find problems while they are cheap.
Myth 3: more gates always mean more security
Gates help only if people respect them and they return fast. DORA's continuous integration guidance says feedback should arrive in minutes. A slow or noisy gate gets bypassed, or leads to bigger batches.
Fact: a quick, accurate gate beats a thorough, slow one that gets skipped.
Where the tension is real
| Situation | Why speed hurts |
|---|---|
| Emergency deployment without review | Skips the normal check |
| Large batches shipped less often | Harder to review, riskier to deploy |
| Pressure to hit a deployment count | Invites gaming |
| AI generated large changes | DORA links AI adoption to higher instability |
Each is manageable. None requires slowing the whole pipeline.
What lets teams have both
- Small batches, merged daily.
- Automated security checks in the pipeline, returning in minutes.
- A clear rule for what blocks a release, and a logged way to override.
- Rollback that works, so a bad change is cheap to undo.
- Continuous monitoring for advisories on what you already shipped.
How to check your own team
Track speed and safety measures in the same view for one service. If lead time and deployment frequency improve while change fail rate, rework rate and time to remediate hold steady or improve, you have evidence for your own case. If safety measures worsen, the data tells you where to look. For pairings, see which delivery and security metrics to pair.
Quick check
Does DORA prove that security investment speeds delivery?
Its pages state that integrating security into daily work is associated with higher delivery performance. That is research on associations in surveyed teams, so test it on your own data.
What is the first practice to adopt?
Automated dependency checks on every pull request, with a narrow blocking rule. It is quick to add and cheap to run.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how a check at pull request time gives an answer before anything ships.
How Safeguard fits
Safeguard offers dependency scanning, policies and gates, and continuous monitoring, so checks run in the pipeline and after release. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, DORA's software delivery performance metrics: https://dora.dev/guides/dora-metrics/
- DORA, Pervasive security: https://dora.dev/capabilities/pervasive-security/
- DORA, Continuous integration: https://dora.dev/capabilities/continuous-integration/
Last reviewed: 19 October 2026.
