enterprise

Subscribe to all “enterprise” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

GitHub Enterprise Server 3.16 is now generally available

GitHub Enterprise Server 3.16 enhances deployment efficiency, monitoring capabilities, code security, and policy management. Here are a few highlights in the 3.16 release:

  • The reliability, observability, and efficiency of ghe-config-apply have been improved. As a result, you may experience reduced downtime when ghe-config-apply is run.

  • The monitor dashboard has been optimized with concise, actionable metrics, providing a quick overview of the appliance’s operational health. For more details, see the monitor dashboard.

  • When reviewing code security configurations, you can now filter repositories more easily with new options that sort by the status of specific GHAS features. For more details, see new advanced filters for code security configurations.

  • You can now apply code security configurations to archived repositories, simplifying rollouts and ensuring features like Dependabot, code scanning, and secret scanning are automatically reapplied if a repository is unarchived. Additionally, you can now create and manage code security settings at the enterprise level, reducing repetitive setup at the organization level. For more details, see enterprise-level code security configurations.

  • Monitor prevention metrics alongside detection and remediation metrics for Dependabot and GitHub Advanced Security features, including secret scanning and code scanning. This expanded visibility is now available in the enhanced security overview dashboard at both the organization and enterprise levels. For more information, see enhanced security overview dashboard.

  • Organization owners can now allow their users to set custom properties during repository creation. This ensures appropriate rules are enforced from the moment of creation and improves discoverability of new repositories. For more information, see custom properties.

  • Organization owners can now configure policies to restrict the usage of deploy keys across all the repositories of your organizations, giving you more control and greater security over your deploy keys. For more information, see enforcing a policy for deploy keys.

To learn more about GHES 3.16, check out the release notes or download it now. If you have any issues upgrading to version 3.16 or experience any issues using these new features, please contact our support team.

Join the community discussion to share your feedback and ask questions.

See more

Enterprise-owned GitHub Apps are now generally available

The general availability of enterprise-owned GitHub Apps brings several updates based on feedback from the public preview.

Most significantly, organizations and users can now transfer private visibility Apps to their enterprise, where they will become usable by the entire enterprise.

In addition, permission updates made to an enterprise-owned App are now automatically accepted by all of the organizations in the enterprise.

These updates allow enterprise owners to consolidate multiple per-organization Apps into a single registration that is managed efficiently at the enterprise level.

image

For enterprise-managed (EMU) users and organizations, both private and internal Apps can be transferred to the enterprise. Private Apps are those that only the owning account can use, while internal Apps are those that any organization and user in the enterprise can use. However, Enterprise Classic organizations and standard user accounts can only transfer private Apps, as internal Apps are not supported in Enterprise Classic.

At this time, internal is the only visibility setting allowed for enterprise-owned Apps, which means that only organizations in that enterprise can install it, and only users in the enterprise can authorize it. Any App that is transferred to an enterprise will be updated to be internal and uninstalled from the user account that owned it, if applicable.

To reduce abuse vectors, enterprises cannot transfer Apps to another enterprise, and organizations and users cannot transfer an App to an enterprise that they are not part of.

As in the preview, only an enterprise owner can manage Apps owned by the enterprise. However, we are actively working on App manager roles and permissions that will allow users and teams to manage specific Apps, as well as manage all of the Apps in an enterprise. These new fine-grained permissions will be introduced for both the enterprise and the organization—keep an eye out for these in the middle of the year.

For more information about enterprise-owned Apps, see our docs page. These updates will be available in GHES 3.17.

To share feedback, ask questions, and more, please join our discussion in the GitHub Community.

See more

Introducing GitHub Secret Protection and GitHub Code Security

GitHub Advanced Security: Introducing GitHub Secret Protection and Code Security

At GitHub, we believe that investing in the security of your codebases should be straightforward, cost-effective, and accessible for everyone. Today, we’re announcing changes to pricing plans and availability of GitHub Advanced Security (GHAS), aligning with our ongoing mission to help organizations of all sizes secure their code with the flexibility they seek.

Announcing new pricing plans for GitHub Advanced Security

Starting April 1, 2025, GitHub Advanced Security will be available as two standalone security products: GitHub Secret Protection and GitHub Code Security. In addition, these products will become available to GitHub Team plan customers for the first time.

GitHub Secret Protection

New customers can purchase GitHub Secret Protection, which includes features that help detect and prevent secret leaks (e.g. secret scanning, AI-detected passwords, and push protection for secrets). Secret Protection will be available for $19 per month per active committer, with features including:

  • Push protection, to prevent secret leaks before they happen
  • AI detection with a low rate of false positives, so you can focus on what matters
  • Secret scanning alerts with notifications, to help you catch exposures before they become a problem
  • Custom patterns for secrets, so you can search for sensitive organization-specific information
  • Security overview, which provides insight into distribution of risk across your organization
  • Push protection and alert dismissal enforcement for secrets, which supports governance at enterprise scale

In addition, we’re launching a new scanning feature to help organizations understand their secret leak footprint across their GitHub perimeter. This feature will be free for GitHub Team and Enterprise organizations.

GitHub Code Security

New customers will also be able to purchase Code Security, which detects and fixes vulnerabilities in your code before it reaches production. Code Security will be available for $30 per month per active committer with features including:

  • Copilot Autofix for vulnerabilities in existing code and pull requests for developer-first security management
  • Security campaigns to address security debt at scale
  • Dependabot features for protection against dependency-based vulnerabilities
  • Security overview, which provides insight into distribution of risk across your organization
  • Security findings for third-party tools

Availability for GitHub Team customers

Starting April 1, 2025, customers on the GitHub Team plan can purchase Secret Protection and Code Security. These products will be available through a consumption-based, pay-as-you-go model (i.e., metered billing) to ensure security remains affordable, scalable, and accessible for all customers on GitHub.

Get started today

Existing customers with plans managed with a GitHub or Microsoft sales account team can transition to the new GitHub Advanced Security plans at start time of renewal for renewal dates after April 1, 2025. Please contact your account team for further details. For existing self-serve customers, instructions on how to transition to the new GitHub Advanced Security plans will be announced over the coming months through GitHub’s roadmap and changelog.

GitHub Team customers can choose to purchase Secret Protection or Code Security from their organization settings pages starting April 1, 2025.

See more

Introducing metered billing for GitHub Enterprise and GitHub Advanced Security server usage

Scaling your GitHub usage just got easier! We are expanding our pay-as-you-go usage-based billing and licensing reporting interface to include GitHub Enterprise (GHE) and GitHub Advanced Security (GHAS) Server-only usage.

We announced pay-as-you-go billing for GHE and GHAS on August 1, 2024 to give customers flexible self-provisioning and pricing. Since then, enterprise accounts on github.com created on or after that date could generate a GitHub Enterprise Server key for the appropriate license count when license adjustments were needed. This required all users, including Server-only users, to be represented in the enterprise account’s user list on GitHub Enterprise Cloud.

Now, you can track and monitor your Server-only license usage for both Enterprise and Advanced Security as a separate line item on the Billing & Licensing > Licensing page.

Note that it will still be required to add all Server-only users to your GitHub Enterprise Cloud enterprise user list to account for their license usage and generate a license key with the appropriate license count. This update does not change this compliance requirement.

Enterprise Server summary in licensing

For existing customers who already have GHE or GHAS, your plan and existing billing method will remain as-is.

If you are interested in pay-as-you-go usage-based billing and have a GitHub account team, please connect with them to discuss whether switching to this model is an option for you.

Check out our documentation to learn more about usage-based billing for licenses.

See more

It is easier to track your progress with fixed code scanning CodeQL security alerts on the Security Overview page

Now it is easier to see how many of your historical CodeQL alerts received autofix suggestions and how many of those alerts were resolved across all the repositories in your organization.

Historical alerts are those found in your default and protected branches, indicating potential existing security issues in your code. You can stay informed about the progress of historical alert resolution and expediting this process as it is essential for accurately assessing your security risks.

Screenshot of total alerts fixed with an accepted autofix out of all with a suggested autofix.

The new “Alerts fixed with autofix suggestions” tile on the Security Overview provides you with the total number of fixed vulnerabilities compared to the total suggested autofixes for existing alerts. This will help you stay informed about the security trends in your organization.

Learn more about Copilot Autofix for CodeQL code scanning and security overview.

To leave feedback for Copilot Autofix for code scanning, join the discussion.

See more

GitHub Enterprise Server 3.16 release candidate is now available

GitHub Enterprise Server 3.16 enhances deployment efficiency, monitoring capabilities, code security, and policy management. Here are a few highlights in the 3.16 release:

  • The reliability, observability, and efficiency of ghe-config-apply have been improved. As a result, you may experience reduced downtime when ghe-config-apply is run.

  • The monitor dashboard has been optimized with concise, actionable metrics, providing a quick overview of the appliance’s operational health. For more details, see the monitor dashboard.

  • When reviewing code security configurations, you can now filter repositories more easily with new options that sort by the status of specific GHAS features. For more details, see new advanced filters for code security configurations.

  • You can now apply code security configurations to archived repositories, simplifying rollouts and ensuring features like Dependabot, code scanning, and secret scanning are automatically reapplied if a repository is unarchived. Additionally, you can now create and manage code security settings at the enterprise level, reducing repetitive setup at the organization level. For more details, see enterprise-level code security configurations.

  • Monitor prevention metrics alongside detection and remediation metrics for Dependabot and GitHub Advanced Security features, including secret scanning and code scanning. This expanded visibility is now available in the enhanced security overview dashboard at both organization and enterprise levels. For more information, see enhanced security overview dashboard.

  • Organization owners can now allow their users to set custom properties during repository creation. This ensures appropriate rules are enforced from the moment of creation and improves discoverability of new repositories. For more information, see custom properties.

  • Organization owners can now configure policies to restrict the usage of deploy keys across all the repositories of your organizations, giving you more control and greater security over your deploy keys. For more information, see enforcing a policy for deploy keys.

Release candidates are a way for you to try the latest features early, and they help us gather feedback to ensure the release works in your environment. They should be tested on non-production environments. Read more about the release candidate process.

To learn more about GHES 3.16, check out release notes, or download the 3.16 release candidate now.

If you have any feedback or questions about the release candidate, please contact our support team.

See more

Verify email address to secure Enterprise Managed User accounts

As previously announced, Enterprise Managed Users (EMUs) must now prove ownership of their email addresses to secure their accounts and prevent any accidental data leaks by third party GitHub Apps and OAuth applications. In January 2025, we also updated the /user/emails REST endpoint to return a placeholder email address with the enterprise’s shortcode appended (e.g. email+shortcode@domain.com) until the EMU user has verified their email address.

While unverified emails may not affect most of your actions on GitHub, some GitHub Apps and OAuth apps may not handle this placeholder email properly. This may prevent you from accessing those apps or result in incomplete data being displayed. These apps may also prompt you to verify your email on GitHub before proceeding.

For example, GitHub Desktop might incorrectly prompt users to update their email in their Git config to their placeholder email. However, updating your Git config email could lead to commit misattribution as opposed to fixing it. While this experience is updated in GitHub Desktop v3.4.17-beta3, we recommend users verify their email address in response to such prompts.

Learn more about how to verify your email address.
App developers should also review our best practices for OAuth and GitHub App implementation to avoid disrupting the user experience in your apps.

See more

Edit and validate Copilot Autofix suggestions with Copilot Workspace

Copilot Autofix suggestions for code scanning alerts can now be edited and validated using Copilot Workspace for pull requests.

Copilot Workspace for Copilot Autofix for code scanning

With this, GitHub Advanced Security users can:

  • Review and integrate Copilot Autofix suggestions within the context of the pull request, benefiting from an improved diff-viewing experience.
  • Refine and address code scanning alerts directly within the pull request, utilizing an enhanced code editing experience.
  • Build, test, and run proposed changes in the pull request without impacting your personal build and test environment.

All GitHub Advanced Security users can use this feature in private repositories on GitHub.com. A Copilot license is not required.

To learn more about code scanning alerts and Copilot Autofix, see About Copilot Autofix for CodeQL code scanning. If you have feedback regarding Copilot Autofix for code scanning, please join the discussion here.

See more

EMU enterprise access restrictions via corporate proxies (public preview)

With this preview, GitHub Enterprise Cloud accounts with Enterprise Managed Users (EMU) can decide to allow EMU enterprise traffic to github.com only via their existing corporate proxies. Unapproved traffic would be blocked.

With enterprise access restrictions via corporate proxies, you can now configure your network proxy or firewall to inject a header into your users’ web and API requests to github.com. This signal tells GitHub to block the request if it is from a user outside of your EMU enterprise – helping ensure that only the accounts you control are used on your corporate network. This enables highly regulated EMU customers to define a secure network strategy in order to reduce the risk of intentional or accidental data leaks by allowing access only to a strictly governed EMU enterprise.

This new network restriction covers API and UI access to github.com and will work in tandem with access rules that enable Copilot traffic to flow properly for enterprise managed users. Copilot access is managed using a different network policy that helps control which version of Copilot (Enterprise, Business, or Individual) is allowed on your network. See Configuring your proxy server or firewall for Copilot for detailed guidance on that GA feature.

This feature is currently available by request to EMU enterprises with licensed users. To request access, contact your account manager in GitHub’s Sales team or sign up here.

If you’re currently trialing EMU or are early in adopting an existing EMU environment, we recommend exploring GitHub Enterprise Cloud with data residency which offers a unique subdomain of GHE.com, so the proxy header is not required to differentiate traffic to your enterprise’s resources. This is the optimal solution for customers who have data residency needs in addition to applying network controls on public github.com access.

Learn more about restricting access to GitHub.com using a corporate proxy.

See more

Setup user for EMU enterprises requires 2FA or use of a recovery code

A setup user is responsible for configuring an identity provider for any new Enterprise Managed User (EMU) enterprise account. After your first login to this user account, we strongly recommend you setup 2FA in addition to saving your enterprise recovery codes.

All subsequent login attempts for the setup user account will require a successful 2FA challenge response or the use of an enterprise recovery code to complete authentication. If you do not at least save your enterprise recovery codes, you will be locked out of the account.

Learn more about the setup user on your GHEC enterprise account with Enterprise Managed Users – EMU or data residency.

See more

Audit log streaming of API requests is generally available

Audit log streaming of API requests targeting your enterprise’s private assets is now generally available. This feature provides you as enterprise administrators new visibility into the API activity within your enterprise.

Audit logs play a critical role in an enterprise owners’ ability to monitor and secure their enterprise. Many enterprises leverage GitHub’s API ecosystem to automate and operate their enterprise at scale. However, API use can also create unique security and operational challenges that must be managed. To help manage these challenges, API requests targeting your enterprise’s private assets can be included in your enterprise’s audit log streams. Please note that API requests targeting public repositories will be omitted from your enterprise’s audit log stream. This new data will allow you as an enterprise owner to:

  • Better understand and analyze API usage targeting your private enterprise assets;
  • Identify and diagnose potentially misconfigured applications or integrations;
  • Track the authentication tokens being used by specific applications or integrations;
  • Troubleshoot API requests contributing to API rate limiting;
  • Analyze API activity when performing forensic investigations; and
  • Develop API specific anomaly detection algorithms to proactively identify potentially malicious API activity.

    An example event payload can be found below:

Example API request audit log event.

Note: Sensitive fields have been redacted for security reasons.

To start streaming API requests, you can follow the instructions in our docs for enabling audit log streaming of API requests. Once enabled, you should begin seeing API request events in your audit log stream.

See more

Code scanning: CodeQL Action v2 is now retired

On December 13, 2023, we released CodeQL Action v3, which runs on the Node.js 20 runtime. In January 2024, we announced that CodeQL Action v2 would be retired at the same time as GitHub Enterprise Server (GHES) 3.11. This retirement period has elapsed and CodeQL Action v2 is now discontinued. It will no longer be updated or supported, and while we will not be deleting it except in the case of a security vulnerability, workflows using it may eventually break. New CodeQL analysis capabilities will only be available to users of v3.

For more information about this retirement, please see the original retirement announcement from January 2024.

How does this affect me?

Default setup

Users of code scanning default setup do not need to take any action in order to automatically move to CodeQL Action v3.

Advanced setup

Users of code scanning advanced setup need to change their workflow files in order to start using CodeQL Action v3.

Users of GitHub.com and GitHub Enterprise Server 3.12 (and newer)

All users of GitHub code scanning (which by default uses the CodeQL analysis engine) on GitHub Actions on the following platforms should update their workflow files:

  • GitHub.com (including open source repositories, users of GitHub Teams and GitHub Enterprise Cloud)
  • GitHub Enterprise Server (GHES) 3.12 (and newer)

Users of the above-mentioned platforms should update their CodeQL workflow file(s) to refer to the new v3 version of the CodeQL Action. Note that the upcoming release of GitHub Enterprise Server 3.12 will ship with v3 of the CodeQL Action included.

Users of GitHub Enterprise Server 3.11 (and older)

GitHub Enterprise Server 3.11 (and older) is now retired. For more information on using the CodeQL Action on a retired GitHub Enterprise Server version, refer to the relevant sections of the CodeQL Action v2 retirement announcement.

Exactly what do I need to change?

To upgrade to CodeQL Action v3, open your CodeQL workflow file(s) in the .github directory of your repository and look for references to:

  • github/codeql-action/init@v2
  • github/codeql-action/autobuild@v2
  • github/codeql-action/analyze@v2
  • github/codeql-action/upload-sarif@v2

These entries need to be replaced with their v3 equivalents:

  • github/codeql-action/init@v3
  • github/codeql-action/autobuild@v3
  • github/codeql-action/analyze@v3
  • github/codeql-action/upload-sarif@v3

Can I use Dependabot to help me with this upgrade?

Yes, you can! For more details on how to configure Dependabot to automatically upgrade your Actions dependencies, please see this page.

See more

REST API insights for organizations is now generally available

As a GitHub Enterprise Cloud organization owner, you and your designated users can now use API insights to visualize REST API activity for your entire organization or specific apps and users. This new feature helps you understand the sources of your REST API activity and manage against your primary rate limits—giving you visibility into the timeframe, apps, and API endpoints involved.

Who can access it

The API insights feature is available only at the organization level. By default, only organization owners can access it. However, organization owners can grant access to non-owners by creating a custom role at the organization level, assigning the permission named View organization API insights to the custom role, and then assigning the custom role to an organization member or team. See the documentation for managing organization custom roles.

Where to find it

The API insights feature is available to all GitHub Enterprise Cloud organizations. To access it on your organization home page, select Insights near the top of the page, and then select REST API on the left side of the page.

An image of an organization homepage where selecting Insights and then REST API will navigate to the new API insights feature.

How to use it

Use the Period and Interval drop-downs to choose the range of time displayed in the chart and how granularly to display REST API requests on the chart. These drop-downs also set the time range for the “Total REST requests,” the “Primary-rate-limited requests,” and the Actors table below the chart.

An image of the API insights feature page showing the Period drop-down expanded for selecting the time period of REST API activity to include.

The Actors table displays the GitHub Apps and users that made REST API requests in the current organization within the selected time period. Select a GitHub App to display its REST API activity and any primary rate-limiting. Select a user to display their personal REST API activity from personal access tokens (PATs) and OAuth apps acting on their behalf.

An image of the API insights feature page showing a table of actors, including GitHub Apps and users, that created REST API activity in the selected time period.

Tell us what you think

We welcome your feedback in the Enterprise community discussions.

Refer to the documentation for API insights for more details about understanding your organization’s REST API activity and investigating primary rate-limiting.

See more

Enterprise repository properties, policies and rulesets – Public Preview

We are excited to announce the launch of new governance at scale features for enterprise accounts in public preview. This preview includes enterprise custom repository properties, enterprise repository policies and enterprise rulesets to help enterprise administrators manage more at greater scale.

Check out this video on managing your repositories at scale across the enterprise and learn more below.

Enterprise custom properties

Enterprise customers can now enrich repositories with metadata and govern protections for branches, pushes, and tags across your entire enterprise using repository custom properties and rulesets.

Enterprise custom properties screenshot
With custom properties available at the enterprise level, you can ensure consistent properties across organizations without manual synchronization and de-duplication. Enterprise and organization properties share a common namespace to prevent confusion when searching or targeting rulesets with properties.
To learn more about enterprise custom properties, head over to the docs.

Enterprise rulesets

Enterprise rulesets screenshot

Enterprise-level rulesets enforce consistent code governance rules to ensure thorough reviews of critical repositories with pull requests, and protect important locations from unauthorized pushes. Rule insights and push rule bypasses are also available at the enterprise level, providing complete visibility into the rulesets.

Enterprise repository policy

We are also introducing repository policies, which allow you to effectively manage repository lifecycle events such as deletions and visibility from the enterprise level. Enterprise administrators can target enterprise polices over repositories in organizations, as well as repositories homed under personal namespaces for any company using enterprise managed users.

Enterprise repository policy screenshot
Repository policies extend the ruleset framework to help you govern repositories beyond the code itself. These policies manage lifecycle events, enhancing the security, compliance and resilience of your repositories. You can enable repository policies per organization, and the preview launches with five policies:
– Restrict visibility
– Restrict creations
– Restrict deletions
– Restrict transfers
– Restrict names

To learn more about enterprise repository policy, head over to the docs.

Feedback

To ask questions or share feedback, join our discussion in the GitHub Community.

See more

GitHub Enterprise Server 3.15 is now generally available

GitHub Enterprise Server 3.15 is now generally available

GitHub Enterprise Server 3.15 is now available for download. Some key features & highlights you can find in this release include:

  • Updated root disk size requirements. New installations of GitHub Enterprise Server version 3.15 and upgrades to 3.15 now require a root disk size of at least 400GB. System will not boot otherwise. This requirement addresses disk utilization trends and proactively mitigates critical issues we have observed with insufficient root disk sizing. For more information on how to increase the root disk size in the appliance, see increasing storage capacity.

  • Updated minimum server specs recommended to run GitHub Enterprise Server (GHES). For more information, see minimum recommended requirements.

  • Project status updates using GraphQL and webhooks, unlock new ways to automate how you provide and gather project status update information. For more information, see GitHub Projects.

  • Custom properties now support new property types: multi select and true/false. Organization repositories can now be queried and filtered via properties via the UI and API. Read about filtering repositories.

  • Code security configurations are now available in GHES. These configurations simplify the rollout of GitHub security products at scale. They help you define collections of security settings and apply them across groups of repositories. We have retired the old organization-level code security settings UI experience along with the API parameters that complemented it. For more information, see code security configurations.

  • Secret scanning push protection is now supported for content upload REST API endpoints – create a blob and create or update file contents. Push protection blocks you from pushing secrets to a repository and generates a secret scanning alert whenever you bypass the block.

  • CodeQL‘s support for Swift and Kotlin is now generally available. CodeQL is the static analysis engine that powers GitHub code scanning.

  • Organization owners can now grant a user or team access to all of the repositories in their org with a single click. New pre-defined roles have been added to the organization settings, under Organization Roles > Role Management, where all organization owners can view and assign them. These can be further customized as well to grant specific repository permissions across your organization. For more information, see organization roles.

To learn more about GHES 3.15, check out the release notes or download it now. If you have any issues upgrading to version 3.15 or experience any issues using these new features, please contact our Support team.

Join the community discussion to share your feedback and ask questions.

See more
View more changes