GitHub adds AI Scan metrics for pull requests to security overview

On October 13, 2026, GitHub expanded security overview: admins of organizations and enterprise accounts can now track how AI Scan performs in pull requests. The dashboard shows how many findings AI Scan generated and how many of them developers resolved. The announcement in the GitHub Changelog runs only a few lines, and its list of metrics breaks off mid-sentence. So what follows covers only what is confirmed, plus an honest caveat about what is not yet visible.

What exactly is new

AI Scan for pull requests checks code changes for vulnerabilities before they are merged. It is part of code scanning. Previously, an admin could turn the feature on but had a hard time judging its payoff: findings were mixed in with results from other scanners, and any assessment had to rely on indirect signals.

Now security overview has a separate view for AI Scan. The announcement tells us the following:

• the metrics are available to admins of organizations and enterprise accounts;
• they show how many findings AI Scan generated;
• they show how many findings were resolved;
• the announcement text mentions other metrics too, but the message is cut off, so the full set cannot be reconstructed from it.

The announcement does not say when the metrics become available, whether any pricing-tier restrictions apply, or whether the data can be broken down by repository or team. It is best to check all of this in the GitHub documentation.

Why this matters to those who pay for the tool

Like classic static analysis, an AI scanner can easily turn into a source of noise. If it produces many findings and only a small share gets resolved, developers start scrolling past pull request comments without reading them. The pair of numbers, "generated" and "resolved," gives a first rough answer to whether the feature is useful. A high share of resolved findings suggests the signals are hitting the mark. A low share points to false positives, poorly chosen coverage, or teams that simply ignore the check.

There is a management angle as well. Security teams usually win budget with arguments like "we found and fixed this many issues before production." Until now, such figures for the AI part had to be collected by hand. Now they sit in the same dashboard that already shows alerts from the other scanners. For enterprise customers with dozens or hundreds of repositories, that saves reporting time.

What to do about it in practice

The announcement offers little data, so it makes sense to proceed step by step:

1. Open security overview and look for the new AI Scan view. If it is not there, check your permissions: the feature is aimed at admins of organizations and enterprises.

2. Record the starting values. Without a baseline, there will be nothing to compare against in a month.

3. Compare the number of generated findings with the number of resolved ones. If the gap is large, review a few dozen findings at random and work out what they were: real holes or noise.

4. Compare repositories with each other. If one team resolves almost everything and another almost nothing, the cause is more likely process than the scanner.

5. Do not draw conclusions about the quality of the model itself from these metrics alone. A resolved finding is not the same as a discovered vulnerability, and missed issues never show up in such statistics.

In scale, this is a small update: a new tab with metrics, not a new model or agent. But it is exactly this kind of change that shows AI checks in GitHub moving from a "switch it on and hope" mode to one where their effectiveness can be measured. Once GitHub discloses the full list of metrics, it will become clear how deep this analytics lets you dig.