If you want to use GitHub Advanced Security features on any repository apart from a public repository on GitHub.com, you will need a license. For more information about GitHub Advanced Security, see "About GitHub Advanced Security."
Each license for GitHub Advanced Security specifies a maximum number of accounts, or seats, that can use these features. Each active committer to at least one repository with the feature enabled uses one seat. An active committer is someone who authored at least one commit that was pushed to the repository in the last 90 days.
To discuss licensing GitHub Advanced Security for your enterprise, contact GitHub's Sales team.
We record and display two numbers of committers for GitHub Advanced Security on GitHub.com:
- Committers is the number of committers who contributed to at least one private repository in an organization and who use a seat in your enterprise license. That is, they are also an organization member, an external collaborator, or have a pending invitation to join an organization in your enterprise.
- Unique to this repository/organization is the number of committers who contributed only to this repository, or to repositories in this organization. This number shows how many license seats you can free up by disabling GitHub Advanced Security for that repository or organization.
If there are no unique committers, all active committers also contribute to other repositories or organizations that use GitHub Advanced Security. Disabling the feature for that repository or organization would not free any seats on your license.
When you remove a user from your enterprise account, the user's license is freed within 24 hours.
Note: Users can contribute to multiple repositories or organizations. Usage is measured across the whole enterprise account to ensure that each member uses one seat regardless of how many repositories or organizations the user contributes to.
When you enable or disable Advanced Security for repositories, GitHub displays an overview of changes to the use of your license. If you disable access to GitHub Advanced Security, any seats used by "unique" committers are freed up.
If you are over your license limit, GitHub Advanced Security continues to work on all repositories where it is already enabled. However, in organizations where GitHub Advanced Security is enabled for new repositories, repositories will be created with the feature disabled. In addition, the option to enable GitHub Advanced Security for existing repositories will not be available. If you change the visibility of a public repository to private then GitHub Advanced Security will be disabled for that repository.
As soon as you free up some seats, by disabling GitHub Advanced Security for some repositories or by increasing your license size, the options for enabling GitHub Advanced Security will work again as normal.
You can enforce policies to allow or disallow the use of Advanced Security by organizations owned by your enterprise account. For more information, see "Enforcing policies for Advanced Security in your enterprise" in the GitHub Enterprise Cloud documentation.
For more information on viewing license usage, see "Viewing your GitHub Advanced Security usage."
The following example timeline demonstrates the events during a month that affect billing for GitHub Advanced Security in an enterprise. For each month, you will find events, the total committer count, and the total number of committers that GitHub would bill for.
|Date||Events during the month||Total committer count||Committers billed for the month|
|A member of your enterprise enables GitHub Advanced Security for repository X. Repository X has 50 committers over the past 90 days.||50||50|
|Developer A leaves the team working on repository X. Developer A's contributions continue to count for 90 days.||50||50|
|Developer B pushes a commit to repository X for the first time. Developer B's usage is pro-rated, because the developer began contributing to repository X partway through the month.||50 + 1|
|50 + 0.8|
|October and November||Developer A's contributions to repository X continue to count because the contributions were within the past 90 days. GitHub now bills for developer B for the entire month because developer B now has contributions within the past 90 days.||51||51|
|90 days have passed since developer A's last contribution to repository _X. The 90 days lapsed after December started, so GitHub bills for developer A for the entire month.||51 - 1|
|Developer C joins the company and pushes a commit to repository X for the first time. Developer C's usage is pro-rated at 70% for 21 out of 30 days.||50 + 1|
|51 + .07|
|GitHub no longer bills for developer A. GitHub bills for developer C for the entire month.||51||51|
|A member of your enterprise disables GitHub Advanced Security for repository X. The 51 contributors to repository X do not work in any other repositories with GitHub Advanced Security. GitHub bills for the developers' usage in repository X for February.||51 - 51|
|No repository owned by your enterprise has GitHub Advanced Security enabled.||0||0|
When you decide which repositories and organizations to prioritize for GitHub Advanced Security, you should review them and identify:
- Codebases that are the most critical to your company's success. These are the projects for which the introduction of vulnerable code, hard-coded secrets, or vulnerable dependencies would have the greatest impact on your company.
- Codebases with the highest commit frequency. These are the most actively developed projects, consequently there is a higher risk that security problems could be introduced.
When you have enabled GitHub Advanced Security for these organizations or repositories, assess which other codebases you could add without incurring billing for unique committers. Finally, review the remaining important and busy codebases. If you want to increase the number of seats in your license, contact GitHub's Sales team.