DevSecOps in Practice

Measuring DevSecOps Success

DevSecOps isn't just about preventing incidents—it's about increasing velocity without increasing risk. To measure this, you need to track the right metrics. There are many metrics you can use, but you should focus on those that provide actionable insights and align with your business goals. Ask yourself: What do I want to achieve? and How can I measure progress?

Next, we’ll explore some of the most commonly used metrics in DevSecOps.

Mean Time to Remediation (MTTR)

This metric captures the average time it takes to detect and remediate security vulnerabilities once they’re introduced. A low MTTR indicates your teams can respond quickly and efficiently, reducing the window of exposure and potential exploitation.

Example: If a vulnerability is detected on Monday and remediated by Friday, the MTTR is 5 days.

Pre-Production vs. Production Vulnerabilities

Track the number of vulnerabilities found in production versus those caught earlier in the development lifecycle. A shift toward catching more issues pre-production demonstrates effective DevSecOps adoption.

Example: If 80% of vulnerabilities are caught pre-production, it indicates a strong security posture.

Commit Signature Ratio

Measure the ratio of signed to unsigned commits. A higher proportion of signed commits indicates better accountability, traceability, and trust within your development workflows.

Example: If 90% of commits are signed, it suggests a mature security culture. If not, consider implementing mandatory signing policies.

Security Test Pass Rate per Pipeline Stage

This metric reflects the percentage of security tests that pass at each stage of your CI/CD pipeline. It highlights areas where security controls may be weaker and where investment is needed.

Example: If 50% of tests fail in the build stage but only 2% in the deployment stage, focus on improving security in the build phase. Your shift-left strategy is not working.

Secrets Detection Efficiency

Compare the number of secrets that leaked into source control versus those detected pre-merge. High detection before merge indicates effective preventive controls and secret scanning integrations.

Example: If 95% of secrets are detected before merge, it suggests a strong preventive posture, but there's still room for improvement.

Software Security Coverage (SSC)

This refers to the total number of software assets that are monitored and protected under DevSecOps practices. Broader coverage ensures fewer blind spots and a more robust security posture.

Example: If 10% of your software assets are monitored, it indicates limited security coverage. Aim for 80% or more.

Security Technical Debt (STD)

Track the total number of unresolved vulnerabilities in production. This represents the accumulation of security debt over time and indicates how much risk has been deferred.

Example: If you have 100 unresolved vulnerabilities, it suggests a significant amount of technical debt. Aim to reduce this number over time.

Security Test Coverage (STC)

STC measures the percentage of infrastructure-as-code (IaC) files that undergo static analysis. This helps ensure configuration issues are caught early before they manifest as production misconfigurations.

Example