Security add-ons look simple until the billing unit shifts under you. With GitHub Advanced Security pricing, the big surprise for many platform teams is that the cost of protecting your code against vulnerabilities usually tracks active committers, rather than total seats, repositories, or headcount. This model applies consistently whether your organization operates on GitHub Enterprise Cloud or GitHub Enterprise Server.
That matters because procurement, engineering, and security often count different things. If you want a clean 2026 budget, start by analyzing your commit history, then map your product scope to that data.
Key Takeaways
- Active Committer Model: GitHub Advanced Security (GHAS) billing is driven by the number of unique active committers over a 90-day window, not by repository counts or total seat licenses.
- Strategic Scoping: Because cost scales with the number of contributors, platform teams should focus on identifying the specific repositories in scope and their associated contributor activity to ensure accurate budget forecasting.
- Billing Flexibility: Enterprises can choose between metered billing for usage-based flexibility or subscription-based licensing for budget predictability, with custom enterprise agreements often providing better rates than public list pricing.
- The 90-Day Lookback: Frequent turnover, seasonal contractors, or occasional contributors can cause budget drift, making it essential to audit current commit history rather than relying on standard headcount reports.
What GitHub Advanced Security costs in 2026
In 2026, GitHub Advanced Security remains an add-on, rather than a default component of GitHub Enterprise. Public list pricing is now structured around two primary product offerings for enterprise buyers.
This is the current public list view:
| Product | Public list price | Billing unit |
|---|---|---|
| GitHub Code Security | $30 per month | Per active committer |
| GitHub Secret Protection | $19 per month | Per active committer |
| Full GHAS coverage | $49 per month | Per active committer |
GitHub billing documentation describes charges based on the number of active committers, utilizing a 90-day activity window. It is important to note that while enterprise plans were the original focus, the GitHub Team plan now includes access to GitHub Secret Protection.
The first takeaway is simple: repositories do not have a flat sticker price. A repository with two active developers costs far less than one with 200. Likewise, a 500-seat enterprise contract does not translate to 500 GHAS charges if only 140 people commit to in-scope repositories.
That distinction helps platform teams explain security spend to finance departments. GHAS is structured more like a usage-linked security license than a flat collaboration seat.
GitHub also supports multiple buying patterns to accommodate different organizational needs. Some enterprises prefer metered billing, while others choose subscription billing for a fixed number of licenses over a set term, typically a year, with a true-up process if usage exceeds the limit. Large customers may secure custom pricing through enterprise agreements, so the public list should be treated as a maximum estimate rather than a guaranteed quote.
As of May 2026, GitHub added hard budget limits for these security tools. That gives administrators firmer control if the rollout scope for the platform begins to widen.
One final pricing boundary is worth noting. Some security features are available at no charge for certain public repositories on GitHub.com. However, private repositories and enterprise-hosted environments still require paid coverage.
What counts as a billable committer, and what doesn’t
For most platform teams, the billing unit causes more confusion than the dollar amount. GitHub’s model usually counts an active committer as any user who pushed code to a GHAS-enabled private repository in the last 90 days.
That means a seat and a billable user are not the same thing. A staff engineer who reviews pull requests but never pushes code to these private repositories may not count. However, a contractor who made one emergency fix six weeks ago will be included in your unique committers count for the month. A manager with admin rights does not matter unless that person actively contributes to the software development life cycle by pushing code.
A small pilot can become expensive if one pilot repo has a long tail of occasional contributors.
Repositories also behave differently than many buyers expect. GitHub does not charge you per repository. Still, enabling GHAS on more private repositories usually raises costs because more people become active committers inside the billing window.
The 90-day lookback is where budget drift often starts. If your organization has seasonal work, short-term vendors, or frequent internal transfers, your count of unique committers may stay higher than your weekly development count. Therefore, a standard headcount report is a weak forecast tool for your GHAS spend.
Bots are another useful edge case. GitHub App bots are generally ignored for GHAS billing, so automated commits from those apps should not create extra license charges.
This is also why broad enablement can feel uneven across teams. A monorepo with 60 frequent contributors may cost less to protect than 20 small services touched by 140 engineers across several business units. The repository count is larger in the second case, yet the bill is driven by people, not code containers.
If you want a second source for how Microsoft frames active-user security billing, the Microsoft Learn billing guide for the Azure DevOps version is useful context. While the product surface for the Azure DevOps version of GHAS differs slightly, the underlying budget logic is familiar and consistent.
A simple framework to estimate GitHub Advanced Security spend
A clean estimate starts with one dataset: unique committers to the repos you plan to protect over the last 90 days. If that number is wrong, every later budget line will be wrong too. To make this easier, many platform teams build a pricing calculator to model these scenarios before committing to a plan.
Use this basic formula for list-price planning:
Monthly GHAS cost = active committers x selected product rate
If you enable both GitHub Code Security and GitHub Secret Protection across the same repo scope, the public list rate is $49 per active committer per month. If you enable only one product, use that specific rate.
For mixed rollouts, estimate each repo group on its own. Then combine the totals. That avoids double counting and keeps your model easy to explain.
A practical cost model has four steps:
- Pull the 90-day unique committer count for the repos in scope.
- Split those repos by product coverage, such as GitHub Secret Protection only or full GHAS.
- Apply list pricing, then swap in your contract rate if procurement has one.
- Add an adoption ramp if the rollout will phase in over several quarters.
These sample scenarios show how fast the numbers move based on active, unique committers and the level of GHAS coverage applied:
| Scenario | Active committers in scope | Coverage | Estimated monthly list cost | Estimated annual list cost |
|---|---|---|---|---|
| Small pilot | 40 | Secret Protection only | $760 | $9,120 |
| Mid-size platform rollout | 80 | Full GHAS coverage | $3,920 | $47,040 |
| Large app group | 250 | Code Security only | $7,500 | $90,000 |
| Broad enterprise rollout | 600 | Full GHAS coverage | $29,400 | $352,800 |
The lesson is clear. GHAS can look affordable at pilot scale and expensive at org scale, even when the per-user math is easy.
List pricing also hides an important budget choice. Volume billing via metered usage matches real activity, but it can fluctuate. Subscription billing through annual committed licenses gives finance more predictability, but it creates overbuy risk if a repo program slows down.
If you are comparing GHAS with vendors that charge by repo, application, or user band, this overview of GHAS alternatives shows how different the packaging can be. The right benchmark is not the sticker price alone. It is the price against your actual contributor pattern.
When GHAS is cost-effective, and when it isn’t
GHAS usually makes the most sense when GitHub is already your core developer platform. In that setup, native features like code scanning, dependency checks, secret scanning, and push protection can reduce tool sprawl and policy drift.
The cost picture improves when most of your spend maps to people who actively ship code. A repo with 400 readers and 35 committers is a good example. Many seat-based tools would price that repo against the larger number, but GHAS does not.
Where the math works well
Platform teams often get better value when they centralize security controls in the same place developers work every day. Whether you are using GitHub Enterprise Cloud or GitHub Enterprise Server, integrated security lowers rollout friction and reduces the need for duplicate scanners across CI, IDEs, and pull request workflows.
Because GHAS leverages static analysis and SAST to identify issues, it functions as a powerful gatekeeper for your codebase. Core features like code scanning and secret scanning provide automated visibility, while push protection prevents credentials from ever entering your history. Furthermore, you can use Copilot Autofix to remediate vulnerabilities efficiently, which helps developers address findings without leaving their existing workflow.
It is also wise to conduct a secret risk assessment before performing a wide enablement of these features across your organization. GHAS tends to work well in high-repo environments because there is no direct per-repo fee; enabling 200 small services is not automatically worse than protecting 20 large ones. What matters is how many unique people commit to them.
Custom enterprise pricing can improve the case further. If you have a large committed GitHub footprint, ask for both a metered option and a term-based quote. Public list pricing is useful for first-pass budgeting, but it is not always the final number on the deal.
Where it can feel expensive
The model becomes harder to love when many occasional contributors touch in-scope repos. Contractors, support engineers, release managers, and internal transfer staff can all lift the active committer count without matching your ideal risk profile.
It can also be a poor fit if you already pay for overlapping AppSec tools with broad coverage and low marginal cost. In that case, GHAS may add convenience more than savings.
Licensing is only part of the budget, too. You still need time for rollout, policy tuning, alert triage, and engineering follow-up. If your teams won’t fix findings, wide enablement creates noise before it creates value.
A staged rollout often works better. Start with repos that hold production services, customer data paths, or high-change code. Then review the active committer count after one billing cycle before you expand scope.
Frequently Asked Questions
Does a user count as a billable committer if they only review pull requests?
No, billable committers are generally defined as users who actively push code to a GHAS-enabled repository within a 90-day rolling window. Reviewers, admins, or managers who do not push code to those specific repositories do not contribute to your billable count.
Do GitHub App bots or automated systems increase my GHAS bill?
No, automated activity generated by GitHub App bots is typically excluded from GHAS billing. You are only charged for human users who meet the criteria of an active committer.
Why does a 500-seat enterprise contract not equal 500 GHAS licenses?
GHAS charges are tied to active engagement rather than the total number of people in your GitHub organization. If you have 500 seats but only 150 of those users push code to protected repositories, you will only be charged for the 150 active committers.
How does the 90-day window impact seasonal project budgets?
Because the billing logic looks back at activity over 90 days, contractors or developers who push code during a short-term project will remain in your billing count for three months. This can cause your monthly costs to remain elevated even after that specific project or contributor has stopped pushing code.
Conclusion
For platform teams, the core rule is simple: GitHub Advanced Security pricing follows the number of active committers rather than total seats or repository counts. Once that distinction becomes clear, your budget model is much easier to justify to stakeholders.
While public 2026 list prices provide a helpful baseline, enterprise quotes often vary based on your specific needs. The most accurate forecast starts by identifying your unique committers over a 90-day window, defining a tight repository scope, and choosing between metered growth and traditional committed licenses.
If you model GitHub Advanced Security based on actual developer activity instead of broad organizational charts, the financial planning process becomes predictable and manageable. By focusing on each active committer as the primary unit of value, you can ensure your investment in GHAS delivers the security coverage your platform requires.
