AppSec Coverage Metrics: You Can't Secure What You Don't Analyze

Every AppSec dashboard counts findings. Very few tell you what the findings were counted over. That is a problem, because a repository with zero findings looks exactly the same as a repository nobody scanned.

Coverage is the number underneath every other number. If you report "critical vulnerabilities down 30%" without knowing how much of the estate was analyzed, you are reporting a ratio with no denominator. AppSec coverage metrics fix that. They tell you what is in scope, how deeply it is analyzed, and whether analysis is keeping pace with how fast your teams ship.

This post lays out the coverage metrics worth tracking, the traps that make coverage look better than it is, and how to report it to leadership.

Why findings metrics mislead without coverage

Findings go down for three reasons, and only one of them is good.

• You fixed things. The outcome you want.
• You stopped looking. A connection token expired, a repository moved organizations, a new language was never configured, a scanner started failing on a large monorepo and nobody noticed.
• The estate changed shape. A service was split, a repository was archived, a team moved to a new SCM, and its findings dropped out of the count.

Without coverage you cannot tell these apart. The second one is the dangerous one, because it produces a chart that looks like progress.

The same applies to AI-generated code. Agents create repositories, services and dependencies faster than onboarding checklists run. If new code is not picked up automatically, the gap grows every week while the findings chart stays flat.

The four dimensions of AppSec coverage

"Are we covered?" is really four questions. Track each one separately.

1. Scope: what is being analyzed

The inventory. Which repositories, dependencies, lines of code, container images, services and AI agent files are under analysis right now. Scope should be measured against an independent source of truth, not against the scanner's own list.

2. Depth: how much analysis is applied

Two repositories can both be "scanned" while one gets dependency analysis only and the other gets SAST, secrets, reachability and exposure context. Depth asks which analyses actually ran and how complete their inputs were.

3. Currency: whether analysis keeps pace

How much of this week's engineering activity was analyzed: commits, pull requests, deployments. A program that scans every repository once a month has full scope and poor currency.

4. Threat currency: whether intelligence is current

How quickly new CVEs and newly identified malicious packages become matchable against your inventory. A perfect inventory checked against stale intelligence still misses the thing that was published this morning.

AppSec coverage metrics worth tracking

These are the metrics that answer the four questions. None of them needs a benchmark to be useful. The trend and the gaps matter more than any industry number.

Scope metrics

• Repositories analyzed vs repositories in your SCM. Use the SCM's own count, including every organization, group and project. Report the gap as a list alongside the percentage.
• Time from repository creation to first analysis. If it is measured in days, agent-created repositories are running unanalyzed.
• Dependencies resolved vs declared. A module with a manifest and no lockfile, or a build that could not be resolved, has partial dependency coverage even if it shows as "scanned".
• Production services mapped to source. For each running service, do you know which repository and commit it came from? Unmapped services are coverage gaps for exposure and ownership.
• Agent files analyzed. Instruction files, skills and MCP configurations are code that runs with implicit trust. Count them like code.

Depth metrics

• Analyses applied per repository. Which of SCA, SAST, secrets, IaC and reachability ran on each repository. A matrix of repository by analysis type exposes gaps fast.
• Languages and frameworks without static analysis support. Every tool has gaps. Know yours by name.
• Reachability computed, yes or no. "No reachable findings" and "reachability never computed" are different states. Report them separately.
• Coverage by business tier. Full depth on Tier 1 services matters more than full depth on internal tools. Break depth down by tier.

Currency metrics

• Scan rate of engineering activity. The share of this week's commits and pull requests that were analyzed.
• Pull requests evaluated by guardrails, and how many were blocked. This is where prevention coverage shows up.
• Time since last successful analysis, per repository. Sort by oldest. The top of that list is where coverage quietly broke.
• Connections healthy. SCM, registry and cloud connections that are failing mean everything behind them is going stale.

Threat currency metrics

• New CVEs and compromised packages ingested this week. Evidence that intelligence is flowing.
• Time from disclosure to "are we affected?" Measure it on the next high-profile advisory. The answer should take minutes of querying, not a day of grepping.

Coverage traps to avoid

The scanner as its own denominator

If coverage is "repositories the scanner knows about, divided by repositories the scanner knows about", it will always be 100%. The denominator has to come from the SCM, the cloud account and the registry.

"Deployed" is not "working"

A scanner configured on every repository can still be failing on a third of them. Count successful, recent analyses, not configurations.

Counting tools instead of outcomes

"We have SAST, SCA and secret scanning" says nothing about coverage. Tools are inputs. Coverage is what those tools actually analyzed last week.

One big percentage

"97% coverage" hides whether the missing 3% is test fixtures or your payments service. Always pair a percentage with the list of what is missing, sorted by business tier.

Treating coverage as a one-time project

Coverage decays. New repositories, new languages, expired tokens and reorganized SCM groups erode it every week. It needs a standing metric, not an annual audit.

How to report AppSec coverage to leadership

Lead with coverage, then show findings. The order matters, because it frames every findings number that follows.

1. Scope: "We analyze X of Y repositories and Z production services. The gaps are these, with an owner and a date."
2. Depth: "Tier 1 services receive full analysis. These languages have no static analysis today."
3. Currency: "This week we analyzed N% of pull requests and blocked M by policy."
4. Findings: only now, the risk trend, with the confidence that it covers what it claims to.

This also answers the question boards increasingly ask about AI adoption: whether code written by agents is analyzed to the same standard as code written by people. If the coverage metrics include new repositories and agent files, you can answer it with a number.

Frameworks such as the NIST Secure Software Development Framework (SP 800-218) and OWASP SAMM both expect evidence that security practices apply consistently across the codebase. Coverage metrics are that evidence.

How Heeler reports coverage

Heeler's Coverage dashboard is about the analysis behind the findings. It answers one question: are we looking at everything?

• Coverage Scope: repositories analyzed, lines of code analyzed, dependencies analyzed and AI agent skill and instruction files analyzed, each with a week-over-week change, plus a breakdown of analyzed repositories by business tier.
• Analysis Depth: the CVEs in the corpus Heeler evaluates, the SAST rules in force, the average rules applied per repository, and the critical CVEs active in scope.
• Pipeline Activity: commits, pull requests and deployments analyzed this week, the scan rate with a scanned and unscanned split, active contributors, and pull requests blocked by a guardrail.
• Threat Intelligence: new CVEs covered and new compromised packages tracked over the last seven days, with a feed showing how many of your repositories each one affects.

Coverage follows the global filter bar. Scope and depth can be reported for one team, one application or one tier. The CVE corpus, rule counts and threat feed stay global. Repository listings also report whether reachability has been computed, which separates "nothing reachable" from "never analyzed". The Coverage docs define each metric.

The inventory behind those numbers comes from the Context Engine, which connects code, cloud, runtime and ownership. For running AppSec across a large estate, see AppSec at scale.

FAQ

What is AppSec coverage?

AppSec coverage is the share of your software estate that is actually under security analysis, measured by scope, depth, currency and threat intelligence freshness. It is the denominator for every findings metric.

What is a good AppSec coverage percentage?

The percentage matters less than what is missing. Report coverage as a percentage plus a list of uncovered repositories and services, sorted by business tier, each with an owner.

How do I measure coverage accurately?

Measure it against independent sources of truth: the SCM's repository list, your cloud accounts and your registries. Count only successful, recent analyses, not configured scanners.

Why did our vulnerability count drop suddenly?

Check coverage before celebrating. A sudden drop often means an expired connection, a failing scan or a repository that moved out of scope, rather than a wave of fixes.

Does coverage include AI-generated code?

It should. Track time from repository creation to first analysis and count AI agent files as code, so code written by agents is held to the same standard as code written by people.

See your coverage as a number

Heeler shows what is being analyzed, how deeply, and whether analysis keeps pace with engineering, across every repository, dependency and running service. Get a demo.