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

Enterprise and organization administrators can now set limits on token lifetimes for the personal access tokens (PATs) used against their resources. These policies mandate token rotation on a regular basis and reduce how long a compromised token is good for, while also providing a lever to reduce the use of less-secure PATs in your company. This public preview is available for all enterprises and organizations, and will be included in GHES 3.16.

Administrators can choose a maximum lifetime between 1 and 366 days for fine-grained PATs and PATs (Classic).
The policies for each token type are distinct, so you can promote the use of fine-grained tokens with a longer lifetime while driving down PAT (Classic) usage with a very short lifetime requirement.

Screenshot of the policy UI for fine-grained PATs, showing that fine-grained PATs must expire within 90 days and that enterprise administrators are exempt

The policies apply when tokens are created, regenerated, or used.

If you want to create a PAT for a specific organization, but that organization or enterprise has a lifetime policy, your lifetime options will be restricted. Additionally, if you try to use an already-created PAT in an organization or enterprise with a policy, the call will fail if the token has too long a lifetime.

If your enterprise has audit log streaming enabled, you’ll be able to track when this policy has blocked a PAT from being used.

Allowing infinite-lifetime fine-grained PATs

With this change, developers can now create fine-grained tokens with no expiration for personal projects, an option that developer feedback said was needed to migrate from PATs (Classic) to more secure fine-grained PATs.

Enterprises and organizations have a 366 day expiration policy for fine-grained tokens by default, so developers still can’t create infinite lifetime fine-grained PATs for use against an organization they’re a member of, unless the administrator relaxes the policy.

For more information, see our documentation on Enterprise and Organization PAT policies.

Join the discussion within GitHub Community for feedback and questions.

See more

Now you can find answers to commonly asked questions about GitHub Enterprise Cloud in the GitHub Trust Center, a comprehensive resource for understanding how GitHub meets security, privacy, and compliance standards. Designed with transparency in mind, this resource centralizes key information, empowering you to build on GitHub with complete confidence.

Key Highlights:

  • GitHub Enterprise Cloud FAQ: Addressing common questions on security, compliance, data residency, and privacy practices.
    • Security Practices: Detailed explanations of GitHub’s encryption, access management, and threat detection features.
    • Data Residency: Information on data storage locations and residency options.
    • Compliance and Certifications: Discover compliance standards, such as SOC 2, ISO 27001, and GDPR.
    • Privacy and Data Protection: Insight into GitHub’s approach to handling data in accordance with global privacy laws.

How to Access:

Visit the GitHub Trust Center and explore the GitHub Enterprise Cloud FAQ for all your security, privacy, and compliance queries.

Stay informed by regularly visiting the GitHub Trust Center, where updates are provided to ensure you have the latest insights.

Explore the new GitHub Trust Center today and build with confidence!

See more

GitHub Enterprise Cloud’s open support for the System for Cross-domain Identity Management (SCIM) specification is now generally available for Enterprise Managed Users (EMUs). This allows administrators to mix and match their preferred choices of SAML and SCIM identity systems, providing the flexibility required to meet access management needs.

This release also includes significant improvements for security and auditing:
– A new reduced personal access token (PAT) scope, scim:enterprise, now lets you grant a least privilege, enterprise-level permission set just for read and write access to GitHub’s EMU SCIM API. Use of the admin:enterprise PAT scope is no longer required or recommended.
– New audit log entries exist for SCIM events to enable debugging of any provisioning failures with SCIM APIs.

Learn more about lifecycle management of Enterprise Managed Users with the SCIM API.

See more

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

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

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 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 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

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 November 4, 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 November 4, 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 November 4, 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 November 4 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 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

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

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

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 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

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