Add a small set of security measures beside the five DORA metrics, using the same service and time window: time to remediate by severity, scan coverage, open exploitable findings, and gate outcomes. Keep it to four or five extra tiles, and define each one in writing before charting it.
Start from the existing dashboard
If you already show lead time, deployment frequency, recovery time, change fail rate and rework rate, you have the delivery half. DORA's guide says to apply them per application or service, so keep that grain. Adding security as a second row, not a separate dashboard, makes it harder to read speed without safety.
The four additions
| Tile | Definition | Why it earns space |
|---|---|---|
| Time to remediate | Days from a finding being identified to fix deployed, by severity, median and worst case | The core outcome measure |
| Scan coverage | Share of services and repos with a scan that ran in the window | Shows blind spots |
| Open exploitable findings | Count of findings with a known exploit or reachable code path, not raw total | Cuts noise |
| Gate outcomes | Pull requests passed, blocked, and overridden | Shows whether controls work and are respected |
Optionally add exception count and age, to show risk that was accepted rather than fixed.
Define before you chart
Write a one-paragraph definition for each tile covering the start event, stop event, unit, and what is excluded. Without it two people will compute different numbers and distrust both. A short card per metric works, and we have a definition card template you can copy.
Steps to build it
- Choose one service as a pilot.
- Export findings from your scanner with identified and fixed dates, severity and service.
- Export deployment events from your delivery tooling.
- Join them on service and date in a spreadsheet or a small script.
- Chart the delivery row and the security row over the same weeks.
- Review monthly with both engineering and security present.
How to read it
Look for combinations, not single tiles.
- Lead time falling and gate overrides rising: speed may be coming from bypassing controls.
- Deployment frequency steady and time to remediate rising: findings are being deprioritized.
- Rework rate rising and open exploitable findings rising: unplanned fixes are going to security incidents.
- Coverage low: every other security tile is understating risk.
What to leave off
Skip raw vulnerability totals as a headline, number of scans run, and any ranking of teams. DORA warns against competition between teams and against relying on a single metric. Those tiles invite both.
Quick check
Do I need a new tool for this?
Not to begin. A spreadsheet joining two exports is enough for a pilot. Automate once the definitions are stable.
How often should the dashboard refresh?
Weekly is enough for trends. Daily refresh helps only for gate outcomes and open critical findings.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings change over time without a new build. That ongoing signal feeds the open findings tile.
How Safeguard fits
Safeguard offers dependency scanning, reachability analysis, policy gates and continuous monitoring, which produce the findings, exploitability and gate data these tiles need. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, DORA's software delivery performance metrics: https://dora.dev/guides/dora-metrics/
Last reviewed: 19 October 2026.
