GitHub Advanced Security pricing and licensing. You pay for who pushes code, on the repositories you enable.

GitHub Advanced Security is two products billed per active committer: Secret Protection at $19 and Code Security at $30 a month. The count follows the repositories you enable, which is why first quotes ran 20 to 40 percent high.

How is GitHub Advanced Security priced in 2026?

GitHub Advanced Security is sold as two products, each priced per active committer per month. GitHub Secret Protection lists at $19 and GitHub Code Security lists at $30, so a committer covered by both costs $49 a month before discount.

The split took effect on April 1, 2025. Before that, the features came in one bundle sold only to GitHub Enterprise customers. Both products are now available on the GitHub Team plan as well as GitHub Enterprise. Customers with an existing Advanced Security contract could switch to the new products at their first renewal after that date.

The rate is published, so the negotiation is mostly about quantity. The number of active committers depends on which repositories have each product switched on. That is an engineering setting, and it is usually changed long before procurement sees a quote.

What counts as an active committer?

An active committer is any user whose commit was pushed to a repository with the product enabled in the last 90 days, regardless of when the commit was written. GitHub counts each person once across all repositories and organizations in the enterprise, so the bill tracks unique people who push.

Why developer headcount is the wrong input

Most enterprise software prices access, meaning who can open the product. This meter prices activity, meaning whose commits reached an enabled repository. A large engineering organization often has far more people with repository access than people who push in a given quarter, and it also has automation that pushes constantly without being a person.

Neither fact shows up in a headcount. That is why a quote built on headcount and a quote built on measured committers routinely differ by a fifth or more.

How the 90 day window catches occasional contributors

A contractor who pushed one commit at the start of a quarter stays a billable committer for 90 days. So does an intern, a partner developer, or an engineer from another team who fixed one bug in your payments repository.

None of them needed a security product bought on their behalf. They are counted only because the repository they touched was in scope.

Which automation identities count

GitHub ignores GitHub App bots, such as Dependabot and the GitHub Actions bot, when counting committers. Pipelines that push under an ordinary user account, often called a machine user or service account, are counted like any person. In the deals we benchmarked, those bot and pipeline identities added 5 to 12 percent to the billable total.

Why does the first GitHub Advanced Security quote come back high?

The first quote is usually sized on organization wide enablement or on developer headcount, rather than on measured committers in the repositories that hold sensitive code. In roughly 7 of the 10 cases we benchmarked, organization wide enablement inflated the active committer count by 15 to 30 percent against the repositories that needed coverage.

• Organization wide enablement. A security configuration applied to every repository pulls in documentation sites, sandboxes, forks of internal tools and archived experiments. Each one adds its committers.
• Headcount sizing. The account team takes the GitHub Enterprise seat count and quotes against it, which assumes every seat pushes to a covered repository every quarter.
• Machine users left in scope. Service accounts that push version bumps, generated code or release tags sit in the count until someone removes them or converts the automation to a GitHub App.
• Both products by default. The quote carries Secret Protection and Code Security because that matches the old bundle, without checking whether the security policy names both.

Should you enable Advanced Security on every repository?

The standard reseller advice is to switch everything on for full coverage and size the purchase on developer headcount. We disagree. Headcount sizing makes a scoping decision look like simple arithmetic, and the count then grows with every new repository. Classify repositories by risk first, enable Code Security where production or regulated code lives, and decide Secret Protection coverage separately.

That last point matters more since the 2025 split. Secret Protection costs $19, and leaked credentials can come from any repository, so wider coverage for secrets can be worth paying for. Code Security at $30 belongs on the code you ship to customers and the code that handles regulated data.

What does GitHub Advanced Security cost for 1,000 committers?

At list price, 1,000 active committers on both products cost $588,000 a year. The same organization can pay far less once scope, automation and product choice are settled. Say a hypothetical company has 1,000 active committers across all repositories, 800 of them in repositories that hold sensitive code, and 60 machine user accounts pushing into those repositories.

Scope alone takes $117,600 a year off scenario A. Removing machine users takes another $35,280. The product decision changes the result the most: if the requirement names only code scanning, scenario D is less than half of A.

Scenario E shows why the cheapest line is not automatically the right one. Wide secret coverage plus scoped code scanning costs more than C, but it may be the right purchase if your security team treats leaked credentials as the larger risk. Price the option that matches the policy, then negotiate the rate.

Do you need Code Security, Secret Protection or both?

Buy the product your security requirement names, and buy both only when the policy calls for both secret scanning and code scanning. Start from the written control, such as a secure development standard or an audit finding, and map each line to one product.

When Secret Protection alone is enough

If the requirement is to keep credentials and tokens out of source control, Secret Protection covers it. Push protection blocks the secret before it lands, and secret scanning finds what is already in history. GitHub also offers a free secret risk assessment to Team and Enterprise organizations, which shows the current leak footprint before you buy anything.

When Code Security earns its price

If the requirement is static analysis of your own code and review of vulnerable dependencies, Code Security covers it with CodeQL, Copilot Autofix and dependency review. Check first whether another scanning tool already does this job. Paying for two static analysis products on the same repositories is a common and avoidable cost.

When both are justified

Both make sense where a regulator, customer contract or internal policy names secret scanning and code scanning together. Even then, the two products do not need the same scope. Each product counts committers only on the repositories where that product is switched on.

How do you count your own committers before the quote?

GitHub gives you the data to produce your own number, and you should have it before the account team sends theirs. Pull it for the repositories you intend to cover.

1. Check the organization settings. The Advanced Security section of the organization settings shows how many active committers the organization has on covered repositories.
2. Call the billing endpoint. GET /orgs/{org}/settings/billing/advanced-security returns active committers per repository with each user's login and last push date, plus a distinct total for the organization. The advanced_security_product parameter splits the result between code_security and secret_protection.
3. Download the usage report. On metered billing, the usage page under Billing and Licensing has a button to request a usage report that finance can reconcile against the invoice.
4. Mark the machine users. Take the login list and tag every account that belongs to a pipeline, then decide whether it can move to a GitHub App or out of scope.
5. Test the scope before you enable it. Model the committer total for your proposed repository list, then apply security configurations to those repositories only.

Disabling a product on a repository frees the licenses of committers who no longer push to any covered repository. Scope can therefore be adjusted during the term as well, which is the reason to keep the repository list under change control.

What will the account team say, and how should you answer?

GitHub Advanced Security is sold both by GitHub's own sales team and by Microsoft account teams, often inside a wider Microsoft agreement. The lines below come up in most conversations, and each has a precise reply.

• "Enable it across the organization for full coverage." Reply that coverage follows your repository risk classification, and that you will extend scope through security configurations when that classification changes.
• "We sized it on your Enterprise seats so there are no surprises." Reply with your measured committer count from the billing endpoint for the scoped repositories, plus an agreed growth allowance.
• "You had Advanced Security before, so you need both products." Reply with the requirement mapping and ask them to price each product as a separate line.
• "Metered billing means you only pay for what you use." Reply that metered billing has no predefined limit, so it passes every new committer straight to the invoice. Accept it only with a budget alert and a controlled scope, or buy a fixed volume for the year.
• "The price is fixed by the new plans." Reply that the list price is published, and the discount, the term and the true up basis are still open, particularly when the purchase sits alongside an Enterprise Agreement renewal.

The committer count is fixed the moment someone decides which repositories have scanning switched on, months before anyone sees a quote.

Which contract terms should you ask for?

Ask for terms that tie the bill to measured committers on an agreed scope and keep each product separate. These are the ones we push for most often.

• A written committer definition. Quote GitHub's own definition in the order, including the 90 day window and the exclusion of GitHub App bots, so the count cannot drift.
• Separate lines per product. Secret Protection and Code Security priced and counted separately, so you can drop or reduce one without reopening the other.
• A price hold for the term. The per committer rate fixed for every year of the agreement, including committers added through true up.
• A stated true up basis. Growth measured from the billing report on an agreed date, with no charge for short peaks.
• A reduction right at anniversary. The ability to lower the committed volume when scope shrinks or a scanning tool is consolidated.
• Co termination with the wider agreement. If GitHub is bought through Microsoft, align the dates with your Enterprise Agreement so the purchase is negotiated with the rest of the spend, as covered in our EA renewal brief.

What have we seen in recent GitHub Advanced Security deals?

Across roughly 25 to 35 GitHub and Microsoft deals we benchmarked in 2024 and 2025, the first quote ran 20 to 40 percent above the committer count buyers expected. Three patterns explained most of the gap between the quote and what the buyer needed, and each can be dealt with before the quote arrives.

Patterns in the deal file

• Scope set in an engineering tool. Enablement was decided by whoever configured the repositories, with no commercial review, and organization wide enablement was the most common cause of a high quote.
• Automation counted as users. Bot and pipeline identities pushing under user accounts sat in the count until someone read the login list.
• Both products bought by reflex. In 4 in 10 cases the buyer took both Code Security and Secret Protection when one covered the stated requirement, paying a second per committer rate for a product the policy did not name.

Advanced Security is one part of the wider Microsoft security spend, which our threat protection brief covers. For the GitHub Enterprise seats themselves, see the GitHub Enterprise licensing guide, and for the rest of the Microsoft library, the Microsoft knowledge hub.

What to do next

1. Six months before renewal. List the repositories that hold sensitive code and treat that list as the licensing boundary for Code Security.
2. Five months before. Decide the Secret Protection scope separately, using the free secret risk assessment to see where secrets actually leak.
3. Four months before. Pull the committer list for the scoped repositories over the last 90 days from the billing endpoint, and tag every machine user.
4. Three months before. Map the written security requirement to one product or both, and exclude or convert the pipeline accounts.
5. Two months before. Request a quote priced per product on your own count, with the contract terms above, and negotiate it together with the GitHub Enterprise seats as set out in our GitHub Enterprise negotiation article.
6. At signature. Put the repository list under change control so scope cannot grow without a commercial review. Our Microsoft practice builds the scope model and committer count with you.

Frequently asked questions