Security Metrics Dashboard

What Your Security Dashboard Actually Tells You

Most security dashboards are collections of numbers that nobody acts on. A good dashboard answers two questions simultaneously. For engineering teams: what should I fix, and how urgently? For leadership: is our security posture getting better or worse, and are our investments working?

Start with five core metrics. You can expand later, but these five cover the vulnerability lifecycle from detection through remediation, and each one tells you something specific about where your program is strong or breaking down.

Vulnerability Remediation SLAs

Severity-based timelines create accountability, but only if the SLAs are realistic and backed by tooling.

• Critical: 24 hours to remediate or mitigate. This means actively exploited, public exploit available, or internet-facing with no compensating controls. 24 hours sounds aggressive, but a critical vulnerability with a public exploit on your payment API genuinely cannot wait until Monday.
• High: 7 days. Exploitable but requires specific conditions, or internal-facing with some defense-in-depth.
• Medium: 30 days. Theoretical risk with multiple defensive layers providing interim protection.
• Low: 90 days. Minimal risk, fix during normal maintenance cycles.

Track SLA compliance rate per severity tier. If critical SLA compliance drops below 90%, that means 1 in 10 critical vulnerabilities sits exposed past the 24-hour window. Escalate immediately. For high severity, target 85%.

The metric that matters here isn't just the compliance percentage. It's the trend. Declining compliance rates tell you something is wrong before a breach does. Common causes: growing infrastructure without proportional security headcount, alert fatigue from noisy scanners, or unclear ownership of shared dependencies.

Mean Time to Remediate

MTTR by severity class is the clearest signal of whether your AppSec program is working. Plot it monthly. Compare it quarter over quarter.

Common benchmarks from industry surveys (Veracode's State of Software Security, Snyk's annual report): critical under 3 days median, high under 14 days, medium under 45 days. If your numbers are significantly worse, the bottleneck usually falls into one of three buckets. Detection: teams don't know the vulnerability exists because scanning coverage is incomplete. Prioritization: the vulnerability sits in a backlog because the team has no context on exploitability. Execution: the fix is complex, touches shared code, or has no clear owner.

Each bottleneck requires a different intervention. Detection problems need better pipeline coverage. Prioritization problems need risk-contextualized alerting (tools like Snyk and Wiz score vulnerabilities by reachability and exposure, not just CVSS). Execution problems need security engineering capacity embedded in the teams with the most critical remediation backlogs.

Dependency and Container Scanning

Track two rates: dependency vulnerability exposure (percentage of repositories with known vulnerable dependencies) and container image scanning pass rate (percentage of images that pass scanning before deployment).

Dependency exposure should trend downward as teams adopt automated update tools. Dependabot and Renovate can auto-create PRs for dependency updates, but the metric to watch is how quickly those PRs get merged, not just how quickly they get created. If your teams have 200 open Renovate PRs, the tooling is working but the process isn't. Consider auto-merge for patch-level updates with passing tests. GitHub and GitLab both support this natively.

Container scanning should be a hard gate. If an image fails the scan, it doesn't deploy. Track the pass rate over time. A declining pass rate signals that base images are falling behind on patches, teams are introducing new vulnerable packages, or your scanning rules have gotten stricter without corresponding engineering effort to catch up. Investigate the cause. At Shopify, base image updates are automated weekly, which keeps the pass rate above 95% without manual intervention.

AppSec Pipeline Coverage

This metric answers a simple question: what percentage of your repositories have SAST, DAST, or dependency scanning enabled and running in CI? If the answer is 60%, then 40% of your codebase ships without automated security checks.

That 40% is your biggest blind spot. Attackers don't care that your scanned repositories are clean. They care about the unscanned ones.

Track coverage by team and by repository criticality. Prioritize 100% coverage of internet-facing services and repositories handling sensitive data (PII, financial data, authentication credentials). Expand from there. The goal isn't just coverage but meaningful coverage: scans that run on every PR, with findings above a severity threshold blocking the merge. GitHub's code scanning with CodeQL, Semgrep, and Snyk all integrate natively into PR workflows.

A useful secondary metric: false-positive rate by scanner. If your SAST tool flags 50 issues per PR and 45 are false positives, engineers will start ignoring all findings. Tune your rulesets aggressively. A scanner with a 10% false-positive rate gets more attention than one with a 90% false-positive rate, even if the strict scanner catches fewer true positives.

Communicating to Leadership

Present security metrics as trends, not snapshots. A director or VP needs to see: "Critical MTTR improved from 5 days to 2 days over the past two quarters" and "AppSec pipeline coverage increased from 65% to 88%."

Pair every metric improvement with the investment that drove it. "We deployed Snyk across all production repositories and added an AppSec rotation in the platform team. Critical MTTR dropped 60%." That's how you build the case for continued security engineering investment. Raw numbers without context invite skepticism. Trends tied to specific actions invite continued funding.

One more thing: know your audience's risk tolerance. A CISO cares about MTTR and coverage gaps. A CFO cares about the financial exposure those gaps represent. A board member cares about whether you're better off than last quarter and how you compare to peers. Same data, different framing. Prepare all three versions.