GitHub code scanning across 500 repos: a 2026 rollout that avoids alert overload

Summary. GitHub made github-codeql-config-file generally available on 4 August 2026, a repository property that applies one CodeQL configuration file across an entire organisation without a GitHub Actions workflow in every repository. That removes the last technical excuse for not scanning a 500-repository estate. It does not remove the reason most rollouts stall, which is alert volume: in a survey of 250-plus application security stakeholders published on 22 January 2026, 71% rated alert fatigue a moderate to critical challenge, and 50% said their teams spend 40% or more of their time triaging findings before any fix begins. The cost is per person, not per repository: GitHub Secret Protection is $19 per active committer per month and GitHub Code Security is $30, as listed on 5 August 2026, so 200 active committers on both is $9,800 a month, about ₹8.5 lakh at 87 to the dollar. The rollout that works stages queries and severities, not repositories. The one that fails turns everything on in one afternoon and hands 40,000 alerts to four people.

The failure mode, precisely

A large rollout usually goes the same way. Someone enables default setup organisation-wide on a Friday. By Monday the security overview holds tens of thousands of findings, most of them medium severity, most of them in code nobody has touched in three years. Engineering leads see a red dashboard on repositories they own and did not ask for. The security team spends two months triaging, ships no fixes, and the programme quietly reverts to "scan the important repos".

Nothing was misconfigured. The scan worked. The failure is a queueing problem: findings arrive at machine speed and get resolved at human speed, and if you do not throttle the arrival rate deliberately, the queue is the outcome.

Marcelo Oliveira, Vice President of Product Management at GitHub, described the underlying shift in a 23 March 2026 post:

Security teams are increasingly responsible for protecting code written across many ecosystems, not just the core enterprise languages traditionally covered by static analysis.

That widening scope is exactly why arrival-rate control matters more in 2026 than it did when static analysis covered four languages.

What changed on 4 August 2026

Before this release you had two options. Default setup was low-maintenance but barely configurable. Advanced setup gave you full control over queries, paths and threat models, and required writing and maintaining a GitHub Actions workflow file in every repository, which at 500 repositories is a maintenance liability nobody wants to own.

The new github-codeql-config-file repository property closes that gap. Set it to the path of a CodeQL configuration file and code scanning merges your settings with its built-in defaults. You can add queries, exclude paths and set threat models while keeping default setup's low-maintenance behaviour, and any threat models and CodeQL model packs chosen in the default setup interface are preserved in the merged configuration. GitHub's own recommendation is to use this for customising security analysis at scale.

Two details make it usable across an estate. Repository properties support organisation-wide default values, and organisation owners decide whether individual repositories may override them, so one configuration file in a central repository can be inherited everywhere, enforced everywhere, or tailored by teams where a team genuinely needs it. And there is new syntax for pointing at a configuration file in another repository where only the repository name is required: leave out the ref and file path and the reference falls back to a default configuration file path on the main branch of a repository in the same organisation. If that central repository is private, you grant default setup access by configuring a Git Source private registry for the organisation instead of managing a token in a workflow.

This is generally available on github.com now and ships with GitHub Enterprise Server 3.23.

The rollout sequence that keeps the queue survivable

Stage the analysis, not the estate. Scanning every repository from week one is fine and gives you the inventory you need. What you stage is which findings become someone's problem.

Week 1. Scan everything, alert on nothing new. Enable default setup across the organisation with the central configuration file set to the security-extended posture off and only the default query suite on. You are building a baseline, not a backlog. Nobody is assigned anything yet.

Week 2. Measure the baseline, then split it. Two piles: findings on code changed in the last 90 days, and everything older. The recent pile is the one developers can act on with context still in their heads. The old pile is security debt and gets its own programme with its own timeline. Conflating them is what produces the red dashboard nobody looks at.

Week 3. Turn on pull-request enforcement for new code only. Code scanning results surface in the pull request alongside other findings, which is where developers already are. New findings on changed code become blocking; existing findings do not. This is the single decision that determines whether developers experience the programme as help or as an obstacle. Teams already familiar with GitHub's CodeQL code scanning setup for AI and prompt-injection risks will recognise the same principle applied to a different query pack.

Weeks 4 to 8. Add query packs one at a time. Extend the central configuration file, one addition per week, and watch the alert count after each. If a pack adds 4,000 findings across the estate, that pack needs a triage plan before it needs enabling. Exclude generated code, vendored dependencies and test fixtures by path in the same file rather than dismissing alerts one by one afterwards.

Weeks 8 onward. Burn the debt pile down deliberately. This is where automation earns its keep, and where the numbers below matter.

Throughout. Let teams override where it is real. A repository holding Terraform has different useful queries from one holding a Java service. Organisation-wide defaults with permitted overrides, rather than a single enforced file, is the setting that prevents teams from disabling scanning altogether to escape irrelevant findings.

Why staging queries beats staging repositories

The instinct is to pick fifty important repositories and scan those first. It reads as cautious and it produces a worse outcome, for three reasons.

You lose the inventory. Until every repository has been analysed once you do not know where the estate's risk actually sits, and the fifty a security team nominates are rarely the fifty holding the exposed credentials. The first full scan is the most valuable artefact of the whole programme, and it costs nothing extra because billing follows committers rather than repositories.

You train people to ignore the tool. A repository that gets scanning in month six arrives with six months of accumulated findings on day one, which is the alert flood again, just delayed and repeated per team. Scanning everything from week one and enforcing only on new code means each team's first experience is a single finding on a pull request they are already reading.

And you cannot report coverage honestly. "Scanning enabled on 10% of repositories" is not an answer to a board question about attack surface; "scanning on 100%, enforcement on new code, debt burn-down running at 400 alerts a month" is. Staged queries let you say the second sentence from week three.

The remediation numbers that decide your debt plan

GitHub publishes real figures for Copilot Autofix, and they change the arithmetic of a backlog programme.

Autofix fixed more than 460,000 security alerts during 2025, with average resolution in 0.66 hours against 1.29 hours without it. It generates automatic fixes for 90% of alert types in JavaScript, TypeScript, Java and Python. Agentic autofix went to public preview on 10 July 2026 and goes further: assign a code scanning alert to Copilot and it explores relevant files across the codebase, proposes a fix, reruns the original analysis to confirm the alert closes, iterates if needed, and opens a draft pull request. Fix generation typically takes two to four minutes. It works on alerts from CodeQL and from third-party scanners uploaded as SARIF.

Two constraints on the budget. Agentic autofix requires both a GitHub Code Security or GitHub Advanced Security licence and a Copilot licence with Copilot cloud agent enabled. And during public preview it draws down the organisation's AI Credits, consumed only when a fix actually runs on an alert you assigned, while the activity also consumes GitHub Actions minutes. A debt burn-down that assigns 5,000 alerts to Copilot is a credit and minutes decision as much as a security one, so run a hundred first and measure.

GitHub has also been widening what gets detected. Its AI-powered security detections complement CodeQL in ecosystems that traditional static analysis covers poorly, including Shell and Bash, Dockerfiles, Terraform configurations in HCL, and PHP. In internal testing GitHub reported processing more than 170,000 findings over a 30-day period with more than 80% positive developer feedback. Expect coverage to grow, which is another argument for staging: the query surface is not static.

What it costs, per person not per repository

The billing unit is the active committer, which is why a 500-repository estate does not cost five times a 100-repository one. The same 200 engineers are committing across all of them. That inverts the usual instinct to limit scanning to "important" repositories in order to save money: restricting scope by repository saves very little and leaves the rest of the estate dark. Scope by query and severity instead.

Some capability is already included without the add-on. CodeQL, Copilot Autofix, dependency graph, Dependabot security updates and version updates, secret scanning and push protection appear on GitHub's plan comparison as included at the Team and Enterprise tiers as of 5 August 2026, with the deeper controls sitting behind the paid add-ons. Read that comparison against your actual tier before assuming you need to buy anything, and note that GitHub Enterprise itself starts at $21 per user/month for the first 12 months, so the security add-ons can cost more than the platform they sit on.

Metrics that answer the question you will actually be asked

In the same January 2026 survey, 73% of respondents said their board or executive leadership had asked about application attack surface or risk posture in the past 12 months, while only 30% were very confident they had visibility into 90% or more of that attack surface. The gap is not a tooling gap. It is that most programmes report activity rather than risk.

Report these instead:

• Percentage of repositories with scanning enabled, and the named list of those without it, with an owner against each.

• Alerts on code changed in the last 90 days, tracked separately from historical debt. This is the number that reflects whether the programme is working.

• Median time from alert to merged fix, split by whether Autofix was used.

• Debt burn-down rate against the historical pile, with a projected clear date.

• Coverage by language, since the estate almost certainly contains ecosystems CodeQL covers differently.

Four of those five come out of the security overview and the code scanning API without a spreadsheet. The list of repositories without scanning, with owners, is the one that requires actual work and the one executives find most useful.

India-specific considerations

GitHub Enterprise Server 3.23 is the on-premises path. The configuration-file property is generally available on github.com and ships with GitHub Enterprise Server 3.23. Indian teams running GHES for data-residency reasons should plan the rollout around that version rather than assuming parity today.

DPDP and what a scan touches. Code scanning analyses source, and source repositories frequently contain personal data in test fixtures, seed files and configuration. Under the Digital Personal Data Protection Act 2023 that is worth an explicit look before you widen scanning, because secret scanning and push protection will start surfacing exactly the files nobody remembered committing. Treat the first scan as a discovery exercise for data as well as vulnerabilities, and read it alongside the wider DPDP engineering playbook for Indian startups.

Budget in rupees, buy in dollars. At 87 to the dollar, both add-ons for 200 committers is roughly ₹1.02 crore a year. That is a board-level line item in most Indian engineering organisations, so the staged rollout matters commercially too: a pilot on one business unit's committers produces a defensible number before the full commitment.

Supply chain sits next to this, not inside it. Code scanning finds vulnerabilities in code you wrote. The dependency and build-provenance side is a separate programme, and the two are usually funded together; our software supply chain security practice covers that half, including the npm provenance attestations and cooldown policy changes that landed this year.

A note on who should own this

The rollout is a platform engineering job with a security owner, not the reverse. The configuration file lives in a repository, is reviewed in pull requests, and changes behaviour across hundreds of repositories, which makes it production configuration. Version it, review it, and roll it out to a canary organisation first. The teams that treat the central CodeQL configuration as a security document rather than as code end up with a file nobody reviews and an alert spike nobody predicted.

The real cost of an AppSec rollout is the triage, not the licence.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based technology consultancy founded in 2021, CMMI Level 5, MSME certified and ISO 27001:2022 certified, with senior engineering teams that run application security rollouts as platform work: baseline inventory, a versioned central CodeQL configuration, staged query enablement, pull-request enforcement on new code, and a debt burn-down plan with real burn rates. We design programmes aligned with DPDP requirements and work with your existing GitHub Enterprise tier rather than selling you a new one. If you have a few hundred repositories and no appetite for a 40,000-alert Monday, talk to us about a staged rollout.

References

1. GitHub Changelog, Customize code scanning default setup at scale, 4 August 2026.

1. GitHub Changelog, Agentic autofix for code scanning alerts in public preview, 10 July 2026.

1. GitHub Changelog, CodeQL 2.26.2 adds Swift 6.3.3 and Kotlin 2.4.10 support, 4 August 2026.

1. Marcelo Oliveira, GitHub expands application security coverage with AI-powered detections, GitHub, 23 March 2026.

1. GitHub, Advanced Security plans and pricing, read 5 August 2026.

1. GitHub, Pricing: plans for every developer, read 5 August 2026.

1. GitHub Docs, Customizing default setup with a configuration file.

1. GitHub Docs, Repository properties for code scanning.

1. GitHub Docs, Code scanning workflow configuration options.

1. GitHub Docs, Giving your organization access to private registries.

1. Payton O'Neal, The 2026 State of AI-Era AppSec: key findings from our survey, StackHawk, 22 January 2026.

1. GitHub Changelog, Code scanning shows AI security detections on pull requests, 14 July 2026.

Last updated: 5 August 2026.