GitHub has added AI Scan metrics to Security overview. Organization and enterprise administrators can now see how many findings AI Scan generated for pull requests, how many were resolved, the remediation rate, which repositories generated findings, the trend over a selected period, and how often developers applied autofix suggestions.
That gives teams a better question than “Is the feature enabled?” You can start asking whether the feature is finding useful work, whether developers are responding, and where the rollout needs attention. The metrics are in public preview, so treat them as a decision aid and keep validating important findings in the pull requests themselves.
What changed in Security overview
The page formerly called “CodeQL pull requests” is now “Code scanning on pull requests.” It has separate CodeQL and AI Scan tabs. Existing CodeQL metrics are under the CodeQL tab, while the AI Scan tab contains metrics for AI-generated pull request findings.
The first useful distinction is between the count of findings and the count of findings with an autofix suggestion. A finding tells you that AI Scan identified something worth reviewing. An autofix suggestion tells you that GitHub generated a possible change. Those are related signals, not interchangeable measures of severity or quality.
The four questions the metrics can answer
1. Is AI Scan finding work?
The total findings metric shows whether the feature is producing reviewable output across the selected repositories and time range. A low count does not automatically mean the feature is weak. It may mean your pull requests do not contain the patterns AI Scan targets, or that coverage is still narrow. Use the repository breakdown before making that call.
2. Are developers resolving findings?
The remediation rate is more useful than a raw findings total because it adds a response signal. Still, read the denominator and reporting period carefully. A small number of findings can produce a volatile rate, and a resolved finding does not tell you whether the fix was applied by autofix, written manually, or handled by changing the surrounding code.
3. Where is the feature helping or getting ignored?
The repository breakdown turns an organization-wide number into an ownership queue. Look for repositories with findings but no resolution activity, then ask whether the issue is unclear ownership, noisy results, missing review time, or a workflow that does not surface the suggestion well. Do not rank teams from this number alone. Use it to choose where to investigate.
4. Are autofix suggestions useful?
The autofix signal helps you see how often developers apply the suggestions. That is a useful product signal, but it is not a safety score. A suggestion can be applied and still need review, tests, and a check that the change matches the application's intent. Keep normal pull request review in the loop.
A practical rollout workflow
Start with a baseline. Capture the selected organization or enterprise scope, reporting period, repository set, total findings, remediation rate, and autofix activity. Write down the date and filters. Without that context, the next dashboard view is difficult to compare with the first one.
Next, segment the results. Separate active production repositories from archived, experimental, and low-change repositories. A repository that rarely opens pull requests should not carry the same expectation as a high-change service. Use the repository list to find patterns, not to create a leaderboard.
Then sample the underlying pull requests. Pick a few findings with and without autofix suggestions. Check whether the finding is understandable, whether the suggested change is safe, and whether the team could see it at the right point in review. This is where you learn whether a dashboard change reflects better security work or just more activity.
Finally, give every follow-up an owner. A repository with findings but no resolution should lead to one of a few actions: fix a workflow problem, tune the team's expectations, investigate a noisy result, or accept a documented risk. The metric is valuable when it produces a small queue someone can act on.
Do not confuse coverage with impact
GitHub's AI Scan coverage view answers a different question: which repositories have the feature enabled after policy, prerequisites, and opt-outs are evaluated? Our earlier guide on tracking AI Scan enablement covers that rollout inventory. Metrics add the next layer by showing what happened after the feature was enabled.
An enabled repository may have no findings in the selected period. A repository with many findings may be healthy if its team is resolving them quickly. A high autofix rate may show that the suggestions are useful, or it may show that reviewers are accepting changes without enough scrutiny. Always connect the aggregate to a sample of real pull requests.
Availability and source material
GitHub announced the change in its October 13 changelog entry. The AI Scan documentation describes the feature, and the GitHub Community discussion is the place to follow preview feedback. Check your plan and role before promising an organization-wide report, because preview availability and access can change.
The useful shift is from enablement to feedback. Use coverage to find repositories that need a rollout decision, use AI Scan metrics to find where the feature is producing and resolving work, and use pull request review to decide whether the work is good. That combination gives security teams a much more honest view than any single number.