DORA's pervasive security capability suggests measuring five things: the share of features with an early security review, the time reviews add, how widely security is involved across the lifecycle, how much of security is covered by automated tests, and use of preapproved libraries and tools. Each can be collected without special software.
The idea behind it
The page frames security as everyone's responsibility and ties it to shifting left, meaning security concerns are addressed earlier in the lifecycle. It says research shows teams get better outcomes by making security part of daily work instead of testing at the end, and that much of this can be automated in the deployment pipeline. It also notes that automation can generate evidence on demand that controls are operating, which is useful to auditors and assessors.
It cites the 2016 State of DevOps Report as showing that high-performing teams spend 50 percent less time remediating security issues than low-performing teams. That figure is from the page as written, and is dated, so treat it as background rather than a benchmark.
The measures, translated
| DORA's factor | What to measure | Direction | How to collect it |
|---|---|---|---|
| Features get security review early | Percentage of features reviewed during design | Up | Tag design tickets with a review flag |
| Review does not slow development | Time added by security review | Down to an agreed minimum | Timestamps on the review step |
| Security integrated across the lifecycle | Reviews captured at design, develop, test and release | Up until fully integrated | Count by stage |
| Automated tests cover security requirements | Share of security requirements in automated testing | Up | Map requirements to tests |
| Preapproved libraries and tools | Number or share in use | Up until all in use | Compare dependency lists to an approved list |
Notes on each
Early review percentage. The denominator is the problem. Define what counts as a feature that needs review, or the percentage drifts. Review the definition each quarter.
Review time. Track the median and the slowest cases. A review that is fast on average but occasionally takes weeks still blocks releases.
Lifecycle coverage. Counting reviews per stage shows where security joins late. If most reviews sit at release, you are still testing at the end.
Security in automated tests. Start with a short list of requirements, such as authentication and input handling, and write tests for them first.
Preapproved libraries. DORA suggests the InfoSec team can provide preapproved libraries and tools, which makes standard code easier to review and lets automated testing check that approved libraries are used. Compare each service's dependency list to the approved list, and treat the gap as a worklist.
Why these are good measures
All five describe the process, not the outcome count. Counts of vulnerabilities depend on how hard you look. Process measures show whether security is built in. Pair them with an outcome measure such as time to remediate so you can check that process changes lead somewhere.
Quick check
Which one should a small team start with?
Start with the preapproved libraries measure. It needs only a dependency list and an agreed approved list.
Are these required by any standard?
No. They are suggestions from DORA's research, not a regulatory requirement.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a dependency inventory is produced. It is the input to the preapproved libraries measure.
How Safeguard fits
Safeguard provides SBOM and dependency scanning, policies and gates, and compliance evidence automation, which supports the library and evidence measures above. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, Pervasive security: https://dora.dev/capabilities/pervasive-security/
Last reviewed: 19 October 2026.
