KRIs for application security and the SDLC

Infrastructure risk is mostly static between changes. Application security risk is not. Every sprint produces new code. Every dependency bump pulls in supply-chain exposure you did not write. Every API endpoint is attack surface that did not exist six months ago. The risk compounds with every deployment, which means a snapshot taken last quarter tells you almost nothing about what is exploitable today.

The indicators in this guide measure whether the software development lifecycle is producing secure software. Not whether security tools sit in the pipeline, but whether those tools cover the right scope, catch the right issues, and (the part that gets skipped) whether the findings they produce actually get fixed before they reach production. If you are standing up these signals from scratch, start with how to build a KRI program, then map what follows onto your AppSec stack.

These eight indicators sit alongside the other domain guides in the series, including product security, security architecture, and AI security. The full set of thresholds, mapped to CIS Controls, lives in the KRI reference library.

Why AppSec KRIs are different

Most application security metrics measure activity: scans run, findings found, tools deployed. A KRI measures risk state instead. How much exploitable exposure exists in production right now, how fast is it growing, and is the security gate stopping issues or just documenting them?

That distinction is the whole game. A team can run SAST on every commit and still carry a high-risk portfolio if findings are suppressed, pipelines are bypassed, or the tool coverage does not match the actual code footprint. Counting scans rewards the activity. Counting unfixed exploitable exposure rewards the outcome. When you start watching velocity on these signals, the difference between a backlog that is shrinking and one that is quietly growing is the early warning you actually want; reading a drifting KRI covers how to spot that movement before it becomes an incident.

KRI inventory

1. SAST pipeline coverage rate

What to measure. The percentage of production application repositories with static application security testing (SAST) wired into the CI/CD pipeline and running on every pull request or merge.

Why it matters. SAST that runs on-demand or on a schedule misses everything introduced between scans. SAST in the PR gate catches vulnerabilities before they merge, which is the one point where fixing them is cheap.

Derivation sources:

• Source code management (GitHub, GitLab, Bitbucket, Azure DevOps): list of active repositories, cross-referenced with pipeline config files (.github/workflows, .gitlab-ci.yml, Jenkinsfile). GitHub Advanced Security surfaces this directly.
• SAST tools (Semgrep, Checkmarx, Veracode, SonarQube, Snyk Code): list of repositories currently being scanned.
• CI/CD orchestration (Jenkins, GitHub Actions, CircleCI, Azure Pipelines): pipeline config audit for SAST step presence.
• AppSec team records: in-scope production applications versus repositories with active scanning.

How to calculate. (repos with SAST on every PR/merge) ÷ (total production application repos) × 100.

Status	Criteria
Green	>95% of production repos with SAST on every PR; pipeline break-on-critical enforced for new critical findings.
Amber	80–94% coverage, or SAST present but running on schedule rather than on every commit.
Red	<80% coverage, or SAST findings not gated (advisory only).

2. DAST coverage rate

What to measure. The percentage of internet-facing and internally-critical web applications covered by dynamic application security testing (DAST) run against the deployed application, measured over the trailing 90 days.

Why it matters. SAST finds code-level issues. DAST finds runtime vulnerabilities that only show up when the application is processing requests. Authentication flaws, session management issues, and injection in API endpoints are frequently caught only by DAST.

Derivation sources:

• DAST tools (Burp Suite Enterprise, OWASP ZAP, Invicti, Detectify): application scan inventory and last-scan dates.
• Application inventory or CMDB: internet-facing applications and internal critical applications.
• WAF logs: application endpoints actively receiving traffic, which helps surface undocumented applications.
• DevSecOps pipeline: DAST scan trigger configuration.

How to calculate. (apps with DAST scan completed in last 90 days) ÷ (total in-scope apps) × 100.

Status	Criteria
Green	>90% of internet-facing applications scanned in the last 90 days; authenticated scans covering post-login functionality.
Amber	70–89%, or unauthenticated scans only (misses significant attack surface).
Red	<70%, or no DAST program for internet-facing applications.

3. Open-source vulnerability rate (SCA)

What to measure. The percentage of production applications with unresolved high or critical CVEs in direct or transitive open-source dependencies, as identified by software composition analysis (SCA).

Why it matters. Modern applications are 70–90% open-source code by volume. Log4Shell, Spring4Shell, and the Struts vulnerabilities were all in dependencies, not in code the organization wrote. Unmanaged open-source risk is one of the largest sources of exploitable production vulnerability, and it is often the least visible.

Derivation sources:

• SCA tools (Snyk Open Source, OWASP Dependency-Check, Black Duck, JFrog Xray, GitHub Dependabot): per-repository and per-application vulnerability reports. Qualys VMDR and Tenable.io add deployed-host context to the same CVEs.
• Package managers (npm, pip, Maven, Gradle, NuGet, Cargo): dependency manifests for direct dependency analysis.
• CI/CD pipeline: SCA scan results per build.
• SBOM: if generated, a comprehensive dependency inventory to cross-reference against CVE databases.

How to calculate. (apps with zero unresolved high/critical dependency CVEs) ÷ (total production apps scanned) × 100. Also track the total count of critical dependency CVEs by age (>7 days, >30 days, >90 days).

Status	Criteria
Green	>95% of applications clear of critical/high dependency CVEs; SCA integrated in CI/CD with a merge gate.
Amber	80–94% clear, or critical CVEs present with active remediation within SLA.
Red	<80% clear, or critical dependency CVEs >30 days old unresolved, or no SCA program.

4. Secrets exposure rate

What to measure. The number of active secrets (API keys, database credentials, tokens, private keys, passwords) exposed in source code repositories, container images, or CI/CD configuration, detected by automated secrets scanning.

Why it matters. A committed secret is a direct path to breach. Hardcoded API keys, cloud credentials, and database passwords found in source code have driven some of the most significant data exposures of the last decade. This vector needs no exploitation. The credential is the access.

Derivation sources:

• Secrets scanning tools (GitGuardian, Gitleaks, TruffleHog, GitHub Advanced Security secret scanning): repository-wide and commit-history scans.
• Source code management: repositories with secrets scanning enabled versus total repository count.
• CI/CD pipeline logs: secrets in environment variables or build logs.
• Container registries (ECR, GCR, Docker Hub): image scanning for embedded credentials.
• Infrastructure as code (Terraform, CloudFormation): IaC scanning for hardcoded credentials.

How to calculate. Track three numbers: coverage as (repos with active secrets scanning) ÷ (total repos) × 100, the count of valid unrevoked secrets detected (the most critical figure), and mean time to revoke in hours from detection to credential revocation.

Status	Criteria
Green	100% repository coverage; zero valid unrevoked secrets; MTTD for secrets <1 hour with an auto-revocation workflow.
Amber	>90% coverage; valid secrets detected with revocation in progress within 24 hours.
Red	<90% coverage, any valid secret unrevoked >24 hours, or no secrets scanning program.

5. Critical vulnerability finding age (SAST/DAST)

What to measure. The percentage of critical and high findings from SAST and DAST tools that stay unresolved in production beyond the defined remediation SLA, typically 30 days for critical and 60 days for high.

Why it matters. Finding age measures whether the security program produces remediation, not just reports. High finding ages paired with high finding counts signal either a resource gap or organizational friction in the remediation process. This is the indicator that separates a program from a dashboard.

Derivation sources:

• SAST/DAST platforms: export open findings with creation date, severity, application, and assignee.
• Issue tracking (Jira, Linear, GitHub Issues, Azure DevOps): security finding tickets with created and resolved dates.
• AppSec management platforms (ThreadFix, PlexTrac): centralized finding tracking with age and SLA metrics.
• Security Champion program records: finding handoff dates between AppSec and development teams.

How to calculate. (critical findings open >30 days + high findings open >60 days) ÷ (total open critical and high findings) × 100. Report it as the share of the finding pool that is past SLA.

Status	Criteria
Green	<5% of critical/high findings past SLA; SLA documented and agreed with engineering.
Amber	5–15% past SLA; remediation backlog with engineering prioritization.
Red	>15% past SLA, no defined remediation SLA, or findings routinely marked accepted without a documented risk decision.

6. Secure SDLC gate compliance rate

What to measure. The percentage of production application releases that passed defined security gates in the development process, including threat modeling for new features, security review at design, and pre-release security sign-off.

Why it matters. Security gates are the organizational intervention that makes secure development systematic rather than ad hoc. Teams that bypass gates consistently are shipping code with unknown security properties. The compliance rate tells you how often security is integrated into development versus bolted on after deployment.

Derivation sources:

• Release management records (Jira, Confluence, ServiceNow change management): completed security review checklist items per release.
• CI/CD pipeline: required security approval steps in the deployment pipeline configuration.
• Security Champions and AppSec team: sign-off records for security reviews.
• Threat modeling records (IriusRisk, ThreatModeler, or documentation in Confluence/Notion): threat model completion per new feature or architectural change.

How to calculate. (releases with all required security gates passed) ÷ (total production releases) × 100.

Status	Criteria
Green	>95% of releases passing all defined security gates; exceptions documented with risk acceptance.
Amber	80–94%, or security gates present but inconsistently applied across teams.
Red	<80%, or no formal security gates in the release process.

7. API security coverage rate

What to measure. The percentage of production APIs (internal and external) inventoried, documented with security ownership, and included in security testing scope.

Why it matters. APIs are the dominant attack surface for modern applications. The OWASP API Security Top 10 describes attack patterns that scanners and WAFs miss unless APIs are explicitly in scope. APIs built by separate teams, third-party integrations, and shadow APIs with no documentation make up the largest unscanned surface area in most portfolios.

Derivation sources:

• API gateway (Kong, AWS API Gateway, Apigee, Azure API Management): complete list of deployed API endpoints.
• OpenAPI/Swagger spec inventory: documented APIs in specification files.
• Network traffic analysis (WAF logs, service mesh telemetry, Noname Security, Salt Security): APIs discovered from traffic patterns, which frequently exceed the documented inventory by 20–40%.
• Developer documentation and internal wikis: API documentation completeness.
• DAST with API scanning capability: the share of API endpoints inside DAST scope.

How to calculate. (APIs in security testing scope with documented owner) ÷ (total APIs discovered from traffic analysis) × 100.

Status	Criteria
Green	>95% of discovered APIs documented and in security testing scope; shadow API discovery running.
Amber	80–94%, or documented APIs in scope but shadow/undocumented APIs not inventoried.
Red	<80%, no API inventory, or API security testing not covering authenticated endpoints.

8. Dependency license and supply chain risk score

What to measure. The percentage of critical production applications with a current software bill of materials (SBOM) and dependency provenance analysis, including identification of dependencies from high-risk supply chain sources (unverified maintainers, recently transferred packages, single-maintainer critical packages).

Why it matters. Software supply chain attacks (XZ Utils, event-stream, SolarWinds) exploit the trust organizations place in dependencies. An SBOM is the foundation for rapid response when a dependency is compromised. Without one, discovering exposure is a slow manual process exactly when speed matters most.

Derivation sources:

• SBOM generation tools (Syft, CycloneDX, SPDX generators): SBOM creation per application build.
• Package managers: dependency provenance, including verified maintainer status, publish date, and download count trends.
• SCA tools with supply chain risk features (Snyk, Socket.dev, Phylum): analysis of new or changed packages for injection risk.
• CI/CD pipeline: SBOM generation step in the build process.

Status	Criteria
Green	>90% of critical applications with a current SBOM; supply chain risk scanning in the CI/CD pipeline.
Amber	60–89% SBOM coverage, or SBOMs generated but not used for incident response.
Red	<60% SBOM coverage, or no supply chain risk analysis on dependencies.

Deriving these KRIs by source type

Each indicator above is only as good as the source it draws from. The same signal usually shows up in more than one system, and reconciling them is where the real picture appears. The breakdown below maps the eight KRIs onto the platforms that produce their inputs.

From source code management (GitHub, GitLab, Bitbucket)

Start with a repository inventory, filtered to active or production repos by last commit date or branch protection rules. Check SAST integration by querying CI/CD config files for a scan job (for example grep -r "semgrep\|checkmarx\|sonar" .github/workflows/). Pull secrets scanning state from the GitHub Advanced Security secret scanning alerts API or the GitLab Security Dashboard. Track Dependabot or dependency-review activity by open PR count and age. Repos with required status checks that include security scans are your branch-protection signal for gate compliance.

From CI/CD platforms (GitHub Actions, Jenkins, CircleCI, Azure DevOps)

Export pipeline configurations and parse for the presence of each security step (SAST, SCA, secrets scan, DAST trigger). Analyze build failures filtered by security-gate cause, since a high failure rate may point to tool quality rather than genuine findings. Watch the security-step bypass rate: pipelines run with --no-verify flags or skip conditions on the security step. High deployment frequency paired with low gate compliance is a strong signal of process bypass.

From SAST/DAST/SCA platforms

For Semgrep, Checkmarx, and Veracode, export the findings API and filter by severity, age, application, and status, then feed it into the finding-age calculation. For Snyk, use snyk test --json per repository plus the projects list API for coverage, and the priority score for risk-based triage. For OWASP ZAP, take scan results per target URL and check the authentication configuration for post-login coverage. For Burp Suite Enterprise, pull the scan queue and coverage report, and treat false positive rate as a tool-quality signal.

From application runtime (WAF, API gateway, APM)

From the WAF (Cloudflare, AWS WAF, ModSecurity), pull attack-pattern hits by rule category, the blocked-versus-logged ratio, and application-specific attack volumes. From the API gateway, export the endpoint inventory for the API coverage calculation and track authentication failure rates as an application security signal. From APM (Datadog, New Relic, Dynatrace), watch error rates that may indicate exploitation attempts, such as SQL errors, auth errors, and stack traces leaking in responses.

From container and IaC platforms

From container registries (ECR, GCR), pull Trivy or Clair scan results, image vulnerability counts by severity, and base image age. From IaC scanning (Checkov, tfsec, Terraform Sentinel), pull security policy violations in infrastructure code and findings by severity in the pipeline. From Kubernetes tooling (kube-bench, Polaris), pull cluster security configuration posture and pod security policy compliance.