Having recently completed a technical and financial evaluation of GitHub Advanced Security (GHAS) for a client organization of approximately 200 developers, I wanted to share a detailed breakdown of the pricing model and its practical implications. The per-committer pricing structure is deceptively simple, but its real-world application requires careful analysis of your development workflows and seat definitions.
Our primary findings centered on the definition of a "committer." GitHub defines this as any user who has authored a commit in the last 90 days to any repository with GHAS enabled. For a 200-developer shop, this does not necessarily mean 200 licenses. However, in our assessment, we found the following:
* **License Count Reality:** After analyzing six months of commit history, we identified a core of ~175 active committers. However, this number fluctuated monthly by +/- 15 individuals. The 90-day window means you cannot efficiently license on a monthly basis; you must license for the peak potential number over a rolling quarter.
* **Indirect Costs & Setup:** The list price is only one component. Significant internal costs are incurred for:
* **Pipeline Integration:** Enabling Code Scanning (CodeQL) requires CI/CD pipeline modifications. Expect several days of engineering effort per major pipeline template to configure the scans, manage results, and establish failure thresholds.
* **Alert Triage Overhead:** Secret Scanning and Dependency Review generate a substantial volume of initial alerts. We established a dedicated, part-time "security champion" role (approximately 4 hours/week) for the first three months to triage, classify false positives, and define policies.
* **Repository Enablement Strategy:** You must decide between an "enable-all" approach (simpler management, higher license count) or a targeted, repository-by-repository rollout (complex management, potential for missed repos).
A critical pricing pitfall we encountered involves **fork-based workflows and external contributors**. If a repository has GHAS enabled, and an external contributor opens a Pull Request from their fork, they are *not* counted as a committer for your organization. However, if your internal developers are regularly committing to multiple repositories across the organization (e.g., shared library repos, microservices), they will be counted for each 90-day period they are active in *any* GHAS-enabled repo.
From a pure cost-benefit perspective, the value hinges on your ability to operationalize the findings. The tooling is excellent, but without integrating it into developer workflow (e.g., blocking high-severity secrets, failing CI on critical CVEs), it becomes a costly dashboard of unaddressed issues. For a 200-user shop, the annual commitment is substantial, and you must budget for the ongoing internal operational cost, not just the GitHub invoice.
I'm interested in hearing from other organizations of similar size. How did your actual committer count compare to your total developer headcount? What strategies did you employ to manage license sprawl, particularly in monorepo or highly collaborative multi-repo environments?
- Mike
- Mike