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

Lower permissions for GitHub Enterprise Cloud Team Sync for Microsoft Entra ID

You can now use GitHub Enterprise Cloud Team Sync for Microsoft Entra ID with a new lower permission, GroupMember.Read.All, to sync group state into GitHub.

The new permission provides the least privileged permissions needed in order to access data and function correctly. New installations will request the new permission while existing installations will continue to work without interruption.

Administrators who wish to reduce the permissions of their existing installation can reinstall the application, or use the App Role Assignments API to modify the permissions of their existing service.

Learn more about team synchronization.

See more

Enterprise audit logs can be streamed to two endpoints (private beta)

You can now stream your Enterprise’s audit log to two of GitHub’s supported streaming endpoints.

This update allows you as an Enterprise owner to easily employ your choice of tools for log storage and analysis. When managing your Enterprise, you may need to employ multiple tools to ensure compliance and maintain a strong security posture. This can involve different teams, requiring different levels of access, employing different technology to accomplish their objectives in supporting your Enterprise’s security and compliance requirements. By streaming your audit logs to two endpoints, you can employ multiple log storage and analysis tools without the need for a complex log routing architecture or deal with increased latency.

Interested in signing up? Please reach out to your GitHub account manager or contact our sales team to have this feature enabled for your Enterprise. Once enabled, you can follow our documents setting up audit log streaming to set up a second stream.

See more

Add repository permissions to custom organization roles

You can now add repository permissions to custom organization roles, granting a specific level of access to all the repositories in your organization.

This builds on the release of organization-wide permission grants in GitHub’s pre-defined organization roles. These updates enable admins to easily scale access management across large teams and organizations.

Creating a custom organization role using the new repository permissions. The role is based on the Write base role, and adds 3 permissions - delete issues, request solo merge, and update repo properties

Using repository permissions in organization roles

Organization roles do not have to contain organization permissions (i.e. read_org_audit_log) in order to include a repository role and permissions (i.e. close_issue). This lets you create your own versions of the pre-defined organization base roles like Write or Triage, assigning those roles to everyone in your organization to ensure a set standard of access that matches your requirements.

A popular use case is to create elevated roles for your on-call rotation. For instance, a role based on Write with the “Jump the merge queue” and “Request a solo merge” repository permissions added so that your on-call team can get that fixed quickly. Using the APIs you can automate assignment of this role to your current on-call, granting them those elevated permissions as a break-glass or shift-based privilege.

Managing repository access

Both the UI for organization role creation and the REST API have been updated to support repository permissions.

In addition, we’ve updated the repository access management page to distinguish between access granted by the repository owner to a user or team versus organization-wide grants made by the organization owner. This helps explain how a user got access to a specific repository.

The new repository collaborators view, showing the organization based access.

For more information, see GitHub’s documentation as well as the REST API methods for automating role creation and assignment.

See more

GitHub Enterprise Server 3.14 is generally available

GitHub Enterprise Server 3.14 is generally available

GitHub Enterprise Server 3.14 gives customers enhanced deployment requirements and security controls. Here are a few highlights in the 3.14 release:

  • SCIM for GHES is a popularly requested enterprise identity management feature, now available in public beta! SCIM stands for “System for Cross-domain Identity Management” and is a leading standard for user lifecycle management in SaaS applications. Enterprise administrators can configure SCIM for their GitHub Enterprise Server instance, which supports automatic provisioning of new user accounts and groups through our SCIM API. We support several paved path applications such as Entra ID and Okta that combine SAML and SCIM support in one place. Additionally, you may bring your own SAML identity provider and SCIM implementation to GitHub Enterprise Server to satisfy your unique identity and user lifecycle management needs. To get started, visit our SCIM documentation for GitHub Enterprise Server. While in public beta, we recommend testing SCIM support for your identity system in a non-production GHES environment before adding SCIM to your current setup. SCIM support can be added onto existing SAML implementations, but it will require using a new application that supports automated provisioning via SCIM in your IdP. Existing private beta customers should also reconfigure their implementation with updated IdP applications.

  • SAML settings are now visible as a read-only configuration in the enterprise settings page. Enterprise administrators are able to view these settings in the same place where SCIM support is configured for your enterprise instance.

  • We’re introducing custom organization roles, allowing you to delegate some of the organization’s administrative duties to trusted teams and users. Organization admins will have both the UI and API to manage these custom roles. See custom organization roles.

  • Code scanning option for repository rules is now available in public beta in GHES. Now, you can create a dedicated code scanning rule to block pull request merges instead of relying on status checks. This makes it easier than ever to prevent new vulnerabilities from being introduced into a code base. See set code scanning merge protection.

  • Dependabot grouped security updates are now generally available. This feature automatically groups Dependabot pull requests and lets you specify several additional options to fine tune groupings. You can enable grouped security updates for Dependabot at the repository or organization-level. If you would like more granular control over Dependabot’s grouping, you can also configure the dependabot.yml file in a repository.

  • With Generation 2 VM support, Operators can scale the GHES appliance vertically. New installs of 3.14 and later will boot on newer generation hardware by supporting both boot firmwares, BIOS, and UEFI. See Generation 2 VMs.

  • On an instance with multiple replica nodes, to start or stop replication for all nodes in a single configuration run, Operators can use the ghe-repl-start-all and ghe-repl-stop-all commands.

Read more about GitHub Enterprise Server 3.14 in the release notes, or download it now. If you have any issues upgrading your GitHub Enterprise Server Appliance to version 3.14, or problems using new features, please contact our Support team.

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

See more

The GitHub Enterprise Server 3.14 Release Candidate is available

The GitHub Enterprise Server 3.14 release candidate is here

GitHub Enterprise Server 3.14 gives customers enhanced deployment requirements and security controls. Here are a few highlights in the 3.14 release:

  • SCIM for GHES is a popularly requested enterprise identity management feature, now available in public beta! SCIM stands for “System for Cross-domain Identity Management” and is a leading standard for user lifecycle management in SaaS applications. Enterprise administrators can configure SCIM for their GitHub Enterprise Server instance, which supports automatic provisioning of new user accounts and groups through our SCIM API. We support several paved path applications such as Entra ID and Okta that combine SAML and SCIM support in one place. Additionally you may bring your own SAML identity provider and SCIM implementation to GitHub Enterprise Server to satisfy your unique identity and user lifecycle management needs. To get started, visit our SCIM documentation for GitHub Enterprise Server. While in public beta we recommend testing SCIM support for your identity system in a non-production GHES environment before adding SCIM to your current setup. SCIM support can be added onto existing SAML implementations, but will require using a new application that supports automated provisioning via SCIM in your IdP. Existing private beta customers should also reconfigure their implementation with updated IdP applications.

  • SAML settings are now visible as a read-only configuration in the enterprise settings page. Enterprise administrators are able to view these settings in the same place where SCIM support is configured for your enterprise instance.

  • We’re introducing custom organization roles, allowing you to delegate some of the organization’s administrative duties to trusted teams and users. Organization admins will have both the UI and API to manage these custom roles. See custom organization roles.

  • Code scanning option for repository rules is now available in public beta in GHES. Now, you can create a dedicated code scanning rule to block pull request merges instead of relying on status checks. This makes it easier than ever to prevent new vulnerabilities from being introduced into a code base. See set code scanning merge protection.

  • Dependabot grouped security updates are now generally available. This feature automatically groups Dependabot pull requests and lets you specify several additional options to fine tune groupings. You can enable grouped security updates for Dependabot at the repository or organization-level. If you would like more granular control over Dependabot’s grouping, you can also configure the dependabot.yml file in a repository.

  • With Generation 2 VM support, Operators can scale the GHES appliance vertically. New installs of 3.14 and later wll boot on newer generation hardware by supporting both boot firmwares, BIOS, and UEFI. See Generation 2 VMs.

  • On an instance with multiple replica nodes, to start or stop replication for all nodes in a single configuration run, Operators can use the ghe-repl-start-all and ghe-repl-stop-all commands.

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.14, check out release notes, or download the 3.14 release candidate now.
If you have any feedback or questions about the release candidate, please contact our Support Team.

See more

Revised release plan for Copilot subscription-based network routing

On July 31 we announced that network requests for Copilot would be routed based on a user’s Copilot subscription, giving customers the ability to block access to Copilot Individual. This change enables Copilot Business and Copilot Enterprise customers to make sure all Copilot users on their networks are accessing Copilot through their Copilot Business or Copilot Enterprise subscription, and that all Copilot user data is handled according to the terms of their Copilot Business or Copilot Enterprise agreement.

We have rolled back that release in order to allow customers more time to make any necessary adjustments to their firewall settings.

On October 31, 2024 we will enable the feature and ensure that users are accessing Copilot through the specific endpoints for their Copilot subscriptions. This means only Copilot Business users will be able to connect to Copilot Business endpoints and only Copilot Enterprise users will be able to connect to Copilot Enterprise endpoints.

Important next steps to ensure continued access to Copilot

Between now and October 31, all Copilot customers should ensure they are following the firewall settings published in our docs. Specifically, this means customers should ensure access is allowed to the wildcard hostname https://*.githubcopilot.com, along with the other listed hostnames.

In order to ensure continued access to Copilot after October 31, all Copilot customers should:

  • Ensure access is allowed to the subscription-specific hostnames https://*.business.githubcopilot.com (for Copilot Business) or https://*.enterprise.githubcopilot.com (for Copilot Enterprise)
  • Update their IDE clients to at least these minimum versions:
  • For Visual Studio Code, use Copilot Chat version 0.17 or later
  • For JetBrains IDEs, use Copilot version 1.5.6.5692 or later
  • For Visual Studio, use version VS 2022 17.11 or later

Customers with an account rep that want to block access to Copilot Individual on their network before October 31 should follow these instructions instead of the previously published firewall docs:

  • Ask their account rep to opt them into the feature without waiting
  • Block access to https://*.individual.githubcopilot.com
  • Ensure access is allowed to the subscription-specific hostnames https://*.business.githubcopilot.com (for Copilot Business) or https://*.enterprise.githubcopilot.com (for Copilot Enterprise)
  • Update their IDE clients to at least these minimum versions:
  • For Visual Studio Code, use Copilot Chat version 0.17 or later
  • For JetBrains IDEs, use Copilot version 1.5.6.5692 or later
  • For Visual Studio, use version VS 2022 17.11 or later

Read more about subscription-based network routing here.

See more

Enterprise Managed User accounts now require email verification

Enterprise managed users (EMUs) must now prove ownership of their email addresses. Existing EMU account email addresses do not have to take this step unless the email address matches one on another GitHub.com account.

Enterprises with EMU accounts that have conflicts have received notification from GitHub regarding specific accounts that have an email address which also exists on another github.com account. Certain 3rd party applications may not work correctly until they have reverified their email address.

New EMU accounts will have their enterprise’s shortcode appended to their email address’s prefix until it is verified, or their administrator changes the email address to another value.

To verify an email address, follow the steps outlined in our documentation. EMU account email addresses are defined by your identity provider, and cannot be changed directly within GitHub. You will need to work with your IdP administrator to change your email address if necessary.

Some users may find that 3rd party GitHub Apps and OAuth apps may not handle the placeholder email correctly, resulting in missing data in these apps. In rare cases, Enterprise Owners may also find that their email provider does not support the “plus addressing” scheme in use. Developers can review our best practices for OAuth and GitHub App implementation, including the use of the id field when storing user reference data so that email address changes are not disruptive to a user’s apps experience.

See more

Introducing metered billing for GitHub Enterprise and GitHub Advanced Security

Today, we are expanding our “pay-as-you-go” model to include GitHub Enterprise (GHE) and GitHub Advanced Security (GHAS) — unifying the GitHub product portfolio as metered services. This provides our customers a frictionless procurement & billing experience, adds flexibility with self-provisioning & pay-as-you-go pricing, and expands pathways to purchase GitHub products through Microsoft.

Enterprise accounts on GitHub.com, created on or after August 1, 2024, will support a consumption-based metered billing model for both GHE and GHAS — enabling you to pay for the licenses you consume in a given month at month’s end as opposed to pre-purchasing for the month ahead.

Further, as part of this release, pay-as-you-go enterprises will enjoy:

  • Access to our new, enhanced billing platform
  • Expanded self-provisioning experiences for GHE and GHAS – including the option to set up an Enterprise Managed Users (EMUs) configuration
  • The ability to add your Azure subscription as a new payment method across your entire account
  • Eligibility for Microsoft Azure Consumption Commitments (MACC) and Azure Commitment Discounts (ACD) when connected to an Azure subscription

For existing customers with GitHub Enterprise (GHE) already, your plan and existing billing method will remain as is. If you have an account team, please connect with them to discuss whether this new billing method is an option for you. For customers without an account team, an in-product prompt will be shown once your account is eligible for this option. If you are upgrading from a Free or Team plan through a GitHub Enterprise trial, your new enterprise will immediately support consumption-based metered billing for GHE and GHAS.

Learn more about this change by reading our article on our new metered billing offerings.

See more

Copilot network requests are now routed based on subscription

Note: This feature has been rolled back. For the latest information about this capability, view this new post. 

Starting today, network requests for Copilot are routed based on a user’s Copilot subscription. Requests for Copilot Individual, Copilot Business, and Copilot Enterprise users now route through different endpoints.

This change enables Copilot Business and Copilot Enterprise customers to make sure all Copilot users on their networks are accessing Copilot through their Copilot Business or Copilot Enterprise subscription, and that all Copilot user data is handled according to the terms of their Copilot Business or Copilot Enterprise agreement. In essence, customers will be able to use their network firewall to explicitly allow access to Copilot Business or Copilot Enterprise, and/or block access to Copilot Individual.

In 90 days, on October 31, 2024 we will enable enforcement of the user’s subscription on the new endpoints, ensuring only Copilot Business users can connect to Copilot Business endpoints and only Copilot Enterprise users can connect to Copilot Enterprise endpoints.

Read more about subscription-based network routing here.

See more

GitHub Copilot Chat and pull request summaries are now powered by GPT-4o

Copilot Chat and pull request summary generation now use GPT-4o, bringing the performance of OpenAI’s latest flagship model to all developers.

Copilot Chat is available in Visual Studio, VS Code, JetBrains IDEs, GitHub Mobile apps, and GitHub.com.

To use the new GPT-4o model in your IDE, ensure you are using at least the minimum version of Copilot Chat specified here:

What this means for Copilot users

With this upgrade to GPT-4o, Copilot users will experience the following benefits:

  1. Faster response times – up to 55% faster TTFT (time to first byte)
  2. More accurate and reliable Copilot Chat responses – our testing showed a 60% increase in user satisfaction.

Commitment to quality

The upgrade process focused on our unwavering commitment to quality, safety, and security. Here’s what that entailed:

  1. Offline and online evaluation: We performed rigorous offline and online testing to ensure the model brings tangible benefits to users. This involved thorough benchmarking and running simulations of real-world software development scenarios to validate the improved performance and accuracy of GPT-4o.
  2. Red teaming: To preemptively address any potential safety issues, we conducted extensive red teaming exercises. These tests challenged the model to ensure it meets our high standards for safety and reliability in diverse coding environments.

We can’t wait to see what you create with the new GPT-4o-powered Copilot!

Let us know your feedback and join the discussion within the GitHub Community.

Happy coding!

See more

Actions Usage Metrics is generally available

Actions Usage Metrics is now generally available for all GitHub Enterprise Cloud customers. Actions Usage Metrics enables you to view data about your Actions workflow runs throughout your organization. You can use this data to identify opportunities to optimize your pipelines and reduce wasted runtime minutes which, when addressed, can lead to faster runs and increased developer productivity. Actions Usage Metrics breaks down the utilization of workflows, jobs, source repositories, and operating systems for GitHub hosted runners and self-hosted runners. All of this data is available in the UI and can be exported and shared as a .csv file if you wish to integrate your usage data with internal or third party tools.

Actions Usage Metrics screen shot!

To learn more about Actions Usage Metrics, check out our docs or head to our community discussion to ask questions and provide feedback.

See more

Audit log streaming can now be configured via GitHub’s REST API – Private Beta

Enterprise Owners on GitHub Enterprise Cloud (GHEC) can join a private beta allowing them to configure audit log streaming via the REST API. This private beta grants access to new API endpoints for the following audit log streaming actions:

  • GET Endpoint Configuration: Retrieve the audit log streaming configuration for your Enterprise.
  • Stream Key Endpoint: Provide the customer with an audit streaming key. This key is essential for our customers to encrypt their secrets before sending them via an API call.
  • POST Endpoint: Create new audit log stream configurations.
  • PUT Endpoint: Update existing audit log stream configurations.
  • DELETE Endpoint: Delete existing audit log stream configurations.

With the introduction of these new REST API endpoints, enterprise owners can programmatically create, update, delete and list their Enterprise’s audit log streams. By allowing programmatic updates to the audit log streaming configuration, customers can automate tasks like rotating your audit log streaming secrets.

These new audit log streaming endpoints will impose a rate limit of 15 API requests per hour to protect the availability of the audit log streaming service. For the time being, these endpoints are only accessible via personal access token (PAT) classic and OAuth token with admin:enterprise scope.

Enterprise owners interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. Enterprise owners can follow instructions for these API endpoints, and provide feedback on their experience on our community discussion.

See more

Pre-defined organization roles that grant access to all repositories

Organization owners can now grant a user or team access to all of the repositories in their org with a single click. Five 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.

Pre-defined roles ship natively with GitHub. We will add more pre-defined roles over time that support common personas like “CI/CD Admin” or “Security Manager”.

A screenshot showing the five new roles in the organization settings

Introducing pre-defined roles and organization-wide repository permissioning

These five new roles showcase an expansion of organization roles – the ability to also include repository-level base roles (like read) and permissions (like close issue). When granted, the recipient has those privileges on all of the repositories in the organization, current and future. While organization owners cannot yet create organization roles that include repository permissions, that will be supported in the coming months.

A screenshot of the Triage role expanded to show the repository permissions included in the role

This new functionality of organization roles helps organizations replace automation that watches for new repository creation and adds the right users or team to every repository.

UI updates to show role assignments

When users and teams are assigned access across all repositories, this is called out in the team and repository view rather than list all of the accesses.

A screenshot showing that this team has access to all of the repositories in the organization. Below it is a listing of the repositories that the team has been given specific access to.

In addition, the Roles Management view in the organization settings has been updated to show indirect assignments – these are roles that a user or team recieves due to a team that they are a member of. This provides a full accounting of all organization roles that a user or team has within the organization.

A screenshot showing a user that has been granted two roles. One is directly assigned, and has a remove button on the right hand side of the row. The other is indirectly assigned via a team named org-member-parent-team, and does not have a remove option.

The APIs for organization role management have been updated to support these pre-defined roles. You’ll find a base_role field in the description of the organization role, which is the repository role (like read) that is included in the organization role.

You can learn more about organization roles at “Using organization roles“.

See more

Updated components to Enterprise Licensing

We revamped the Enterprise Cloud Licensing page content.

ghe-subscription-example

  • Enhanced Usability: We’ve simplified how license usage is presented for enterprises using the Visual Studio Subscription with GitHub Enterprise license bundle, making it clearer and easier to understand your usage metrics.

  • Optimized CSV Download Experience: We updated the Licensing page’s CSV download feature to provide better feedback on the report’s status. For reports with a large volume of data, we now email the CSV report to you once it’s ready.

Join the discussion within GitHub Community.

See more
View more changes