GitHub Advanced Security (GHAS) is licensed by active committer, not by repository or by total developer headcount, and that single rule drives almost every cost surprise organisations encounter. GHAS adds code scanning, secret scanning, dependency review, and security overview on top of a GitHub Enterprise or Azure DevOps subscription. As of recent changes, the capability set is also available as two standalone, separately purchasable products — Secret Protection and Code Security — so buyers no longer have to take the whole bundle to get one capability. Understanding the committer-based meter and the new product split is the core of the buyer-side decision, and it connects to the wider security-SKU choices in our complete Microsoft licensing guide.
For platform and security teams, GHAS is attractive because it embeds scanning directly in the developer workflow rather than bolting on a separate tool. For procurement, the attraction is only realised if the committer count is managed deliberately, because the meter counts more people than teams typically expect.
What GHAS includes
The Advanced Security capability set centres on a few pillars. Code scanning uses static analysis (including the CodeQL engine) to find vulnerabilities and coding errors before they merge. Secret scanning detects credentials, tokens, and keys committed to repositories, with push protection that can block secrets from being committed in the first place. Dependency review and the dependency graph surface vulnerable open-source components, and the security overview gives security teams an organisation-wide view of risk across repositories.
Historically these shipped as a single GHAS add-on. The current direction packages them into two products: Secret Protection (secret scanning and push protection) and Code Security (code scanning, dependency features, and the broader code-analysis tooling). The practical effect is that an organisation that only wants secret scanning across all repositories can license Secret Protection alone, rather than paying for the full code-analysis suite it will not use.
The active-committer meter
GHAS licences are consumed by unique active committers to repositories where the capability is enabled. An active committer is, broadly, a user who has pushed a commit to an enabled repository within a defined recent window. The same person committing to ten enabled repositories consumes one licence, not ten — but every distinct human who commits to any enabled repository consumes a licence.
This is where costs surprise buyers. Enabling GHAS organisation-wide across every repository pulls in occasional contributors, contractors, and service-adjacent committers who would not appear in a naive "number of developers" estimate. The committer count an organisation actually pays for is frequently higher than its named developer headcount, because the meter is behaviour-based, not seat-based.
The scoping lever: because the meter counts active committers to enabled repositories, the single most effective cost control is scoping which repositories have GHAS enabled. Turning the capability on everywhere maximises both coverage and committer count. Enabling it on the repositories that hold production, customer-facing, or sensitive code — and managing it through policy rather than blanket activation — aligns spend with actual risk. Measure your real active-committer count on a representative set of repositories before you size a purchase.
Where GHAS is licensed: GitHub vs Azure DevOps
GHAS capabilities are available both on GitHub Enterprise and, as GitHub Advanced Security for Azure DevOps, inside Azure DevOps. The two are licensed and billed through different channels — GitHub Enterprise versus an Azure subscription — and the committer-based logic applies in both. Organisations running code across both platforms should count committers per platform and avoid assuming a single enterprise agreement automatically covers both. Where both platforms are in use, consolidating the security tooling decision is worth doing deliberately rather than letting each platform's licensing accrete independently.
Secret Protection vs Code Security at a glance
| Dimension | Secret Protection | Code Security |
|---|---|---|
| Core capability | Secret scanning, push protection | Code scanning (CodeQL), dependency review |
| Primary buyer | Stop credential leaks everywhere | Find vulnerabilities in code pre-merge |
| Licensing meter | Active committer | Active committer |
| Typical scope | Often broad across all repos | Often focused on high-risk repos |
| Available on | GitHub Enterprise & Azure DevOps | GitHub Enterprise & Azure DevOps |
Buyer-side cost levers
Three levers control GHAS cost. The first is repository scope, already noted: enable each product where it earns its keep rather than universally. The second is the product split: if the driver is preventing secret leaks, Secret Protection alone across the estate may cost less than full GHAS, while Code Security is reserved for the repositories where deep static analysis matters most. The third is committer hygiene — understanding which automation accounts, bots, and dormant contributors are inflating the active-committer count and addressing them through repository configuration and access governance.
It is also worth aligning the GHAS decision with whatever native or third-party application-security tooling you already run. Paying for overlapping SAST and secret-scanning coverage across two tools is a common redundancy. The right question is which platform should own which control, not whether to buy everything from one vendor.
The decision sequence
The practical buyer sequence is: (1) inventory where code lives — GitHub Enterprise, Azure DevOps, or both; (2) measure the real active-committer count on the repositories you would actually enable, not your total developer headcount; (3) decide whether you need Secret Protection, Code Security, or both, and on which repository scope each; (4) model cost against the measured committer count under realistic scope, not blanket activation; (5) reconcile against existing application-security tooling to remove overlap; (6) revisit committer counts each quarter, since they drift as projects and contractors change.
The mistake to avoid is enabling everything everywhere "for full coverage" and discovering the committer bill at the first true-up. Scope deliberately, license the product you need, and measure committers before you commit. For adjacent decisions, see Microsoft Purview audit licensing, Microsoft Security Copilot pricing, and the consumption model in Azure OpenAI commitment & pricing. For the broader entitlement and renewal picture, the Microsoft EA guide covers how security SKUs fold into an enterprise agreement, and our Microsoft licensing experts measure committer counts and scope GHAS to actual risk.