KRIs for DevSecOps and security engineering

The KRIs in this domain are different from application security KRIs (which measure the security of what gets built) and security operations KRIs (which measure how well you detect and respond). DevSecOps KRIs measure the integration quality between security and engineering, the shift-left metrics, the pipeline reliability, the security tool health, and the organizational friction (or lack of it) that determines whether developers treat security as a colleague or an obstacle.

If you are standing this up from scratch, start with how to build a KRI program and the consolidated KRI reference library, which maps every domain to one CIS-aligned catalog.

KRI inventory

1. Security pipeline gate coverage and enforcement rate

What to measure. Percentage of production application pipelines with security gates that break the build on new critical findings, covering SAST, SCA, secrets scanning, and IaC security scanning, where the gate is enforced (blocking) rather than advisory (reporting only).

Why it matters. A security scan that reports findings but doesn't gate the deployment is a reporting tool, not a control. Enforcement rate measures whether security gates are actually preventing vulnerable code from reaching production, or just documenting vulnerabilities that ship anyway. High coverage with low enforcement is worse than low coverage, it creates the illusion of control.

• CI/CD platform (GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure DevOps): pipeline configuration files, presence of security steps and whether failures block deployment (continue-on-error: false vs. true)
• SAST/SCA platforms: policy configuration, which severity levels are set to blocking vs. warning
• Secrets scanner: configuration for mandatory vs. advisory mode
• Deployment frequency vs. security finding counts: high deployment frequency with declining security findings signals effective gating

How to calculate. (Production pipelines with ≥1 security gate in blocking mode) ÷ (total production pipelines) × 100 Enforcement quality: (Pipelines with blocking gates for critical severity) ÷ (total pipelines with any security gate) × 100

Status	Criteria
Green	>95% of production pipelines with at least SAST + secrets in blocking mode; SCA gating on critical CVEs; IaC scanning for infrastructure pipelines
Amber	80–94%; or gates present but in advisory mode for all findings; or critical findings allowed to bypass gate
Red	<80%; or security steps present but universally non-blocking; or pipelines routinely bypassing security step

2. Security tool reliability rate

What to measure. Uptime and reliability of security tools that serve engineering teams, SAST, DAST, secrets scanning, vulnerability management, and WAF, specifically measuring the rate of tool failures, false positives causing build failures, and scan timeouts that result in security steps being skipped.

Why it matters. Security tools that are slow, unreliable, or produce excessive false positives get turned off by engineering teams or bypassed. A SAST tool that adds 20 minutes to a CI pipeline and fails half the time due to timeouts will be disabled by an engineering team under delivery pressure. Tool reliability is the prerequisite for developer adoption and sustained enforcement.

• CI/CD platform: pipeline run logs, security step exit codes, execution time, timeout events, skip events
• Security tool vendor dashboards: uptime SLAs and incident history
• Engineering team feedback: developer satisfaction with security tooling (developer NPS or survey)
• False positive rate per tool: findings triaged as false positive ÷ total findings, high rates indicate tuning debt

How to calculate.

• Reliability: (Security pipeline runs completing without tool failure or timeout) ÷ (total pipeline runs with security step) × 100
• False positive rate per tool: (Findings marked false positive in trailing 90 days) ÷ (total findings in trailing 90 days) × 100
• Mean scan time: average seconds for each security step, track for latency increase trends

Status	Criteria
Green	>99% tool reliability; false positive rate <15%; mean scan time stable or declining; no patterns of skip/bypass due to tool failure
Amber	95–98% reliability; or false positive rate 15–30%; or scan time increasing quarter-over-quarter
Red	<95% reliability; or >30% false positive rate; or regular skip events due to timeout; or engineering teams actively working around security steps

3. Developer security training and champion coverage

What to measure. Percentage of engineers building production software who have completed secure coding training within the last 18 months, and the percentage of engineering teams with an active Security Champion (a developer who serves as the security team's embedded partner in the engineering organization).

Why it matters. Security champions reduce the friction between security and engineering by creating embedded advocates who understand both domains. Trained developers write fewer vulnerabilities in the first place, reducing the burden on SAST tools and code review. The combination of training and champions is more effective than either alone, champions reinforce training through practical application.

• LMS: secure coding training completion records cross-referenced with engineering org chart
• Security Champion program records: active champions per team, meeting participation, issues raised
• Training platform (SANS, Secure Code Warrior, Veracode Security Labs, HackTheBox): completion records and skill scores per developer
• Engineering org chart: total developer headcount for coverage denominator

How to calculate.

• Training coverage: (Engineers with current secure coding training) ÷ (total engineers) × 100
• Champion coverage: (Engineering teams with active Security Champion) ÷ (total engineering teams) × 100

Status	Criteria
Green	>85% training coverage; >70% of engineering teams with active champion; champions meeting monthly with security team
Amber	60–84% training; or champion program exists but participation declining; or training not specific to secure coding (generic security awareness only)
Red	<60% training coverage; or no security champion program; or security training limited to annual compliance training

4. Mean time to resolve developer security issues

What to measure. Average days from security finding identification in CI/CD pipeline to confirmed resolution, segmented by finding severity and by whether the finding was identified pre-merge (in PR) or post-merge (in branch scanning or DAST on deployed application).

Why it matters. Developer response time to security findings is the operational metric of DevSecOps adoption. A finding that lives in a ticket for 60 days before anyone looks at it is a finding that will never be fixed until it becomes a breach. Pre-merge findings are cheaper and faster to fix than post-merge findings, the ratio of pre-merge to post-merge detections measures how far left the security program has actually shifted.

• SAST/SCA platform: finding creation date (merged to main) and resolution date
• Engineering ticketing system (Jira, Linear, GitHub Issues): security finding tickets, time from creation to resolution
• CI/CD pipeline: PR check failure date (pre-merge) vs. branch scan finding date (post-merge)

How to calculate.

• MTTR by severity: average days from finding creation to resolution, by critical/high/medium
• Pre-merge ratio: (Security findings caught in PR check before merge) ÷ (total new security findings in period) × 100, higher is better (shift-left effectiveness)

Status	Criteria
Green	Critical MTTR <15 days; High MTTR <30 days; pre-merge detection ratio >70%
Amber	Critical 15–30 days; or pre-merge ratio 40–69%; or no measurement distinguishing pre-merge from post-merge detection
Red	Critical MTTR >30 days; or pre-merge ratio <40%; or security findings not tracked with resolution dates

5. Security-as-Code coverage rate

What to measure. Percentage of security controls (WAF rules, network security group policies, cloud security configurations, security monitoring rules) managed as code, in version control, reviewed, tested, and deployed through automated pipelines, versus manually configured.

Why it matters. Security controls managed as code are reproducible, reviewable, testable, and auditable. Controls configured manually through console UIs drift, aren't reviewed, have no audit trail, and can't be reliably reproduced. Security-as-code is the foundation of consistent, scalable security control delivery, and the mechanism that prevents the configuration drift that most CSPM findings represent.

• Version control (GitHub, GitLab): security-related repositories, WAF rule sets, Terraform security modules, SIEM detection rules, firewall policy code
• Deployment pipeline: security controls with automated deployment pipeline vs. manual deployment
• CSPM: manually configured cloud resources (without Terraform tags) vs. IaC-managed, a proxy for security control automation
• SIEM: detection rules managed in Sigma format or Sentinel YAML vs. rules created through UI

How to calculate. (Security controls in version control with automated deployment) ÷ (total security controls of the same type) × 100 Track by control category: WAF rules, network policies, detection rules, cloud security configurations

Status	Criteria
Green	>80% of security controls managed as code; all new controls deployed through pipelines; control changes go through code review
Amber	50–79%; or code managed but deployment manual; or new controls consistently going to UI before being codified
Red	<50%; or security controls primarily managed through console UIs; or no version control for security configurations

6. Security technical debt index (DevSecOps layer)

What to measure. The accumulated security-specific technical debt in the engineering organization, measured through the count and age of security findings that have been deferred, the number of security exceptions granted to development teams, and the age of security tooling components that are end-of-life.

Why it matters. Security technical debt compounds. A SAST exception granted for "this sprint" that becomes permanent, a known vulnerable dependency deferred until the next major release, a WAF rule that was temporarily disabled and never re-enabled, these accumulate into a security debt that is more expensive to remediate than it would have been to address at the time. Tracking it makes it visible before it becomes a breach.

• SAST/SCA platform: findings marked as "accepted" or "wont-fix", count by severity and age
• Security exception registry: exceptions granted to engineering teams, count, duration, and renewal rate
• Security tooling inventory: components of the security engineering stack approaching or past vendor end-of-support
• CI/CD: disabled security steps with no documented review date

How to calculate.

• Accepted finding debt: count of accepted/wont-fix findings by severity and age bracket
• Exception accumulation rate: new exceptions granted per month vs. exceptions closed
• Tooling EOL rate: (Security tooling components past end-of-support) ÷ (total security tooling components) × 100

Status	Criteria
Green	Accepted finding count stable or declining; exceptions have defined expiry and are reviewed at renewal; no EOL security tooling in critical pipeline
Amber	Accepted findings growing quarter-over-quarter; or exceptions without expiry accumulating; or known EOL tooling with remediation plan
Red	Large backlog of accepted critical/high findings; or permanent exceptions without review; or EOL security tooling with no remediation plan

7. Developer friction score

What to measure. A composite measure of the friction security tools and processes introduce into engineering workflows, measured through pipeline latency from security steps, developer escalation rate for security finding questions, and optional developer sentiment survey on security tooling.

Why it matters. Security friction that slows engineering teams creates pressure to disable security controls, bypass security gates, and treat security as an obstacle rather than a partner. Low-friction security, fast scans, high-fidelity findings, clear remediation guidance, responsive security team, produces better adoption and better outcomes than high-friction security that engineers work around.

• CI/CD pipeline timing: security step execution time as a percentage of total pipeline time, should be <10–15%
• Security team ticket queue: developer questions and escalations to security team about findings, volume and response time
• Security exception request volume: rate of requests to bypass or suppress security findings, high rates signal friction
• Optional: developer experience survey on security tooling, similar to DevEx surveys but security-specific

How to calculate. Composite of:

• 1. Security step latency: average seconds for security steps in pipeline (lower = better)
• 2. Developer escalation rate: security questions per 100 developers per month
• 3. Exception/suppression request rate: requests per 100 developers per month

Status	Criteria
Green	Security step <5 minutes average; developer escalations handled within 24 hours; exception request rate stable or declining
Amber	Security step 5–15 minutes; or escalation response >48 hours; or exception requests growing (friction signal)
Red	Security step >15 minutes (significant pipeline bottleneck); or escalation queue unmanaged; or engineering teams actively working around security requirements

Deriving these KRIs by source type

From CI/CD Platforms (GitHub Actions, GitLab CI, Jenkins)

• Pipeline configuration audit: gh api repos/{org}/{repo}/contents/.github/workflows/{file}, parse YAML for security steps; check continue-on-error and if: always() flags that would bypass failures
• Step execution logs: gh api repos/{owner}/{repo}/actions/runs filtered to runs with security steps; calculate success rate, execution time, timeout rate
• Security bypass detection: git log --grep="skip ci" --all, commits deliberately bypassing CI (and therefore security gates)

From SAST/SCA Platforms

• Semgrep: semgrep scan --json output includes findings with severity, path, rule_id; exit_code=1 on findings in CI = blocking gate active
• Snyk: snyk test --json, ok: false with exitCode: 1 confirms blocking behavior; snyk monitor for accepted findings tracking
• Dependabot/GitHub Security Alerts: gh api repos/{org}/{repo}/vulnerability-alerts, open alerts with created_at for age calculation; dismissed_at for accepted finding tracking

From Developer Experience Data

• GitHub Pull Request analytics: PR review time, security review required status checks, measure delay introduced by security gates
• Jira/Linear velocity data: Sprint velocity before and after security gate introduction, measure impact on delivery cadence
• Security Champion meeting records: Attendance rate, issues raised, findings raised by champions vs. found by tools, champion program health signal

From Security Tool Vendor Dashboards

• SLA and uptime records: Most security tool vendors (Snyk, Semgrep, Veracode) provide status pages and uptime SLAs, track against vendor commitments
• API error rates: Security tool API failures in CI/CD → skip events; monitor via CI/CD log aggregation
• Scan time trends: Track P50 and P95 scan time per tool per month, latency increases signal scaling issues or configuration problems