GitHub Advanced Security counts who pushes code, and the first quote ran 20 to 40 percent high

The metric is the committer, not the seat and not the repository. That single design choice is why the bill rarely matches developer headcount, and why the scope decision made by an engineer sets a number procurement later has to defend.

Prepared by Redress Compliance · August 15, 2026 · Microsoft advisory. Based on 25 to 35 benchmarked GitHub and Microsoft deals, 2024 to 2025.

• Scope to the repositories that genuinely hold sensitive code, since organization wide enablement is the most common reason a quote comes back high.
• Exclude bot and pipeline identities first, which removes 5 to 12 percent before any other negotiation begins.
• Choose the SKU that matches the requirement, rather than buying both by reflex.
• Understand the 90 day window, because a contractor who pushed once still counts for a quarter.
• Count before you quote, producing your own committer number against your intended scope rather than reacting to theirs.
• Treat the enablement decision as commercial, since it is made in an engineering tool and priced on a procurement line, per the EA renewal brief.

The standard reseller line is that the product should be switched on everywhere for full coverage, then sized on developer headcount. In roughly 7 of the 10 estates we benchmarked, organization wide enablement inflated the active committer count by 15 to 30 percent against the repositories that actually held sensitive code. The headcount framing is the part that quietly does the damage, because it makes a scoping decision look like an arithmetic one.

The metric deserves a moment on its own, because it is unusual and it is not intuitive. Most enterprise software prices access: who can open the thing. This prices activity: who pushed. A large engineering organization can have far more people with repository access than people who commit in any given quarter, and it can also have automation that commits constantly without being anyone at all. Neither of those facts is visible from a developer headcount, which is why a quote built on headcount and a quote built on committers routinely differ by a fifth or more.

The 90 day window compounds it in a specific way. A contractor who pushed a single commit at the start of a quarter remains a billable committer for the rest of it, as does an intern, a partner developer, or a colleague from an adjacent team who fixed one bug. None of those people are wrong to have pushed, and none of them need a security product bought on their behalf. They are counted because the scope let them be, and the scope was set by whoever enabled the repositories.

That is the practical conclusion, and it sits with engineering rather than procurement. The committer count that drives the bill is fixed the moment someone decides which repositories have scanning switched on, months before anyone sees a quote. Scope to the repositories that hold sensitive code, exclude bot and pipeline identities, pick the SKU that matches the requirement, and produce your own count against that scope before the vendor produces theirs. Coverage everywhere is a spending decision wearing the clothes of a security one. The wider Microsoft security position sits in the threat protection brief, and the estate library in the Microsoft practice.

Across roughly 25 to 35 GitHub and Microsoft deals benchmarked in 2024 and 2025, the first quote consistently overshot:

The patterns: enablement decided in an engineering tool, automation counted as users, and both SKUs bought by reflex.

The buyer side move is to control the scope before the quote. The wider library sits in the Microsoft practice.

How is GitHub Advanced Security licensed?

Per committer, not per seat or per repository. It is an add on bought on top of GitHub Enterprise, and it meters the unique users who push code to repositories where it is switched on, which is why the bill rarely matches developer headcount.

What counts as a committer?

Any account that has pushed a commit to a repository with the product enabled. On the cloud product a committer is active if they pushed in the last 90 days. Bots and service accounts that push code can also count, which is where much of the unexpected volume comes from.

Why does the first quote come back high?

Because it is usually sized on organization wide enablement rather than on the repositories that hold sensitive code. The first quote ran 20 to 40 percent above the count buyers expected in the deals we benchmarked, and organization wide enablement pulled in 15 to 30 percent more active committers than the scoped repositories needed.

How much do bots add to the bill?

Bot and pipeline identities pushing code added 5 to 12 percent to the billable committer total. They are easy to miss because nobody thinks of automation as a licensed user, and easy to exclude once someone has looked at the list.

What changed with the 2025 SKU split?

The single product became two: Code Security, covering code scanning, CodeQL and dependency review, and Secret Protection, covering secret scanning and push protection. They are sold separately at roughly 30 dollars per committer per month each, so buying both when one covers the need doubles the rate.

Do most estates need both SKUs?

Not by default. Buying both when one covered the requirement doubled the per committer rate on 4 in 10 estates we reviewed. Decide which half the security requirement actually calls for before accepting a quote that assumes the full original feature set.

What is the main cost control lever?

Repository scope. You decide which repositories have scanning switched on, and that decision sets the committer count that drives the bill. Enabling it organization wide is the most common reason a quote comes back far higher than expected.

How should coverage be decided?

As a scoping decision rather than a headcount exercise. Identify the repositories that genuinely hold sensitive code, enable there, exclude bot and pipeline identities, and choose the SKU that matches the requirement. Coverage everywhere is a spending decision disguised as a security one.