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

Programmatic audit log configuration and multi-endpoint streaming

Audit logs play a critical role in keeping enterprises secure and auditing enterprise activity for compliance. Since becoming generally available in January 2022, audit log streaming has been used by over 2000 enterprises to transmit audit logs to Enterprises’ preferred streaming endpoints. We are excited to announce three new features that will help you programmatically configure audit log streaming to multiple endpoints of your choosing. In doing so, we aim to empower you to select and employ tools that best support your security and compliance objectives.

Audit log steaming to a user defined HTTPS event collector

You can now enroll in a private preview that allows you to stream your audit logs to a user defined HTTPS event collector. This allows audit logs to written to any endpoint capable of accepting an HTTP post and meets our requirements for streaming GitHub audit logs. By introducing a user defined HTTPs event collector, you are empowered to stream your audit logs to the tool you feel best supports your enterprise’s needs.

Configure audit log streaming to a HTTPS Event Collector in the log streaming settings page for your Enterprise audit log

This private preview is only available to GitHub Enterprise Cloud customers. Enterprise administrators 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. Let us know what you think by providing feedback on our community discussion post.

Enterprise audit logs can be streamed to two endpoints

You can participate in a public preview to stream your Enterprise’s audit log to two of GitHub’s supported streaming endpoints. You can stream your audit log to two endpoints of the same type, or you can stream to two different providers.

Log streaming settings page showing two configured streams. One to Datadog and the other to Splunk

This update allows you to use your preferred 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 dealing with increased latency.

This public preview is available to all GitHub Enterprise Cloud customers. We plan to ship this feature to GitHub Enterprise Server when this feature is released as generally available. To set up multiple streams, follow the instructions for each provider for setting up audit log streaming.

Configure audit log streaming via GitHub’s REST API

You can now 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 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.

This feature is generally available on GitHub Enterprise Cloud (GHEC) and will be included in the release of GitHub Enterprise Server (GHES) version 3.16. To learn more, check out our documentation for the REST API endpoints for enterprise audit logs

See more

Migrate repositories with GitHub Enterprise Importer using GitHub owned blob storage – Private Preview

You can now enroll in a private preview to use GitHub-owned storage when migrating repositories to GitHub Enterprise Cloud using GitHub Enterprise Importer (GEI). This means that you no longer need to provide GEI with access to a customer-owned storage account via shared access keys to perform repository migrations. Instead, migrations can now be performed with repository archives uploaded directly to GitHub.com.

Once enrolled in the preview, repository migrations can be initiated to use GitHub-owned storage via the gh gei and gh bbs2gh command line extensions by passing in the --use-github-storage flag.

Repository migrations using the gh gei command line extension and passing in the --use-github-storage flag

If you’re interested in participating in this private preview, please reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. For additional technical details, instructions for running repository migrations with GitHub owned storage, or to provide feedback on this feature, please check out our community discussion post.

See more

Enhanced 2FA management for orgs and enterprises [Public Preview]

Enterprise settings page with the selected option to enable two-factor authentication for all organizations within the enterprise. An option to enforce only secure methods of authentication is also been selected. There is a warning informing the admin that members without two-factor authentication will need to add it to re-gain access.

Enterprises now have more control over their two-factor authentication (2FA) policies for all members of their organization through an enhanced 2FA enrollment experience in GitHub.
With this update, enterprise and organization administrators can ensure that users are maintaining secure 2FA methods when accessing enterprise and org resources. Currently, GitHub defines SMS/text message as an insecure method of 2FA, and TOTP authentication applications, the GitHub Mobile app, security keys, and passkeys as secure methods. Members without a secure method of 2FA configured, or who have insecure 2FA configured, will be prompted to configure secure 2FA before being allowed to access resources.

Enterprises can enable this new 2FA policy alongside a general 2FA requirement for their members, and current enterprises with a 2FA requirement can update their 2FA settings to add this secure methods enforcement. Members who are non-compliant with the new 2FA policy will no longer be removed from organizations, lessening a historical friction around enforcing 2FA policies at an enterprise or organization level, and instead be prevented from accessing enterprise or organization resources while non-compliant.

This new policy enables enterprises to protect their resources by only allowing access for users who meet the required security standards, without compromising organization membership integrity.

Learn more about the new enterprise policy for requiring only secure methods of two-factor authentication and about how GitHub is securing developer accounts using 2FA.

See more

The GitHub Enterprise Server 3.15 Release Candidate is available

The GitHub Enterprise Server 3.15 release candidate is here

You can now download the GitHub Enterprise Server 3.15 release candidate to try out the new features in this latest version. Version 3.15 gives customers enhanced deployment requirements and security controls. Here are a few more highlights in the 3.15 release:

  • We have 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. For more information on how to increase the root disk size in the appliance, see increasing storage capacity.

  • We have also updated minimum server specs recommended to run GHES. For more information, see minimum recommended requirements.

  • You can now interact with project status updates using GraphQL and webhooks. This unlocks 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. Both the UI and API are supported. 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.

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.15, check out release notes, or download the 3.15 release candidate now.

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

See more

Organizations can now enable 2FA requirement without removing non-compliant members [GA]

Enterprises can now broadly roll out two-factor authentication (2FA) to all members of their organization through an enhanced 2FA enrollment experience in GitHub. With this update, non-compliant users will no longer be removed from organizations when an organization begins enforcing 2FA.

2FA will be enforced via conditional access policies, which means members who have not yet enabled 2FA will continue to have their organization membership, but be blocked from visiting any organization resources until they enable 2FA.

This enables organizations to enable a broader 2FA enrollment without disrupting the membership status of their members who are yet to enable 2FA. This also enables members without elevated privileges to enable or disable 2FA on their accounts without losing organization membership.

Learn more about how GitHub is securing developer accounts using 2FA, and why we’re urging more organizations to join us in these efforts.

See more

EMU OIDC CAP support is now enhanced to protect web sessions [Public Preview]

If you are using GitHub Enterprise Cloud with EMU and using OpenID Connect (OIDC) SSO, this new feature, currently in public preview, will help enforce IdP-defined IP restrictions to protect all web interactions on GitHub.

Currently, when your enterprise uses OIDC-based SSO and if any of the enterprise members change their IP address, GitHub can validate their access to your enterprise and its resources using your IdP’s Conditional Access Policy (CAP). IdP CAP validations previously covered only non-interactive flows where users authenticate with a personal access token or SSH key.

With this launch, we are now extending these validations to include all interactive web flows. If you already had IdP CAP turned ON previously, you will need to explicitly opt-in into extended protection for web sessions from their enterprise’s “Authentication security” settings. If you enable IdP CAP support after today’s public preview launch, you will still need to opt in to get the coverage across web flows.

When this feature is generally available, we plan to have both interactive and non-interactive flows protected by the IdP CAP validations for all customers by default and remove the additional step of requiring to opt-in.

Learn more about GitHub’s support for your IdP’s Conditional Access Policy.

See more

Copilot subscription-based network routing is now enforced

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.

Today we enabled 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

View an organization’s REST API activity with API insights in public preview

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, currently in public preview, 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 public preview feature is enabled for 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 this community discussion.

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

Repository deploy keys are controlled by enterprise and organization policy [GA]

GitHub Enterprise Cloud enterprise and organization administrators can now configure policies to restrict the usage of deploy keys across all the repositories of their organizations, giving you more control and greater security over your deploy keys.

Deploy keys provide SSH access to a single repository and are often used by integrations with external servers to a repository without using a personal GitHub account. However, this makes it hard to track the lifecycle of deploy keys across your repositories, as they exist outside of a user context and have no timed expiration capability. Now with the ability to set deploy key policies, you can more easily track and manage your deploy keys across your repositories.

All new enterprises and organizations will have the deploy key policy disabled by default.

For compatibility reasons, the deploy key policy will be enabled by default for all existing enterprises and organizations. You may want to explicitly disable the setting after evaluating and replace your deploy key usage with more secure alternatives like GitHub Apps.

For more details, learn more about the new policy for managing deploy keys.

See more

Announcing GitHub for Nonprofits

Now, verified nonprofits can access the GitHub Team plan for free or receive 25% off the GitHub Enterprise Cloud plan through GitHub for Nonprofits. This includes nonprofit organizations that are 501(c)(3) or equivalent and are non-governmental, non-academic, non-commercial, non-political in nature, and have no religious affiliation.

You can sign up here to get exclusive discounts automatically applied to your account. Join GitHub for Nonprofits, where technology meets purpose, and together, let’s create a more sustainable and equitable future for all.

Join the discussion within GitHub Community.

See more

Enterprises can create GitHub Apps for use within the Enterprise

Enterprise owners can now create GitHub Apps owned by their enterprise, with access restricted to just the organizations and members in the enterprise. Previously, if you wanted to share an app across multiple organizations within your enterprise, you had to either:

  • Duplicate the app for each organization, leading to management overhead and potential inconsistencies, or
  • Make the app public, potentially exposing it to users outside your enterprise.

With this update, you can now safely share an app across your entire enterprise without exposing it to the rest of GitHub.com, and manage your critical apps in a more secure and centralized location.

This also simplifies distribution and management for Copilot Extensions. You can now build custom extensions and share them across your enterprise without making them public – allowing you to create tools specific to your company’s needs and workflows, while keeping them private. Use of a single app across your enterprise ensures consistency and makes it easier to update extensions across all of your teams.

A screenshot of the GitHub app creation page, showing a single visibility option that reads "Only avocado-corp-owned organizations"

These apps can only be installed on organizations in your enterprise, and only members of your enterprise can sign in to them. To ensure the security of your app, user accounts cannot install these apps, only sign in to them. When users or organizations leave your enterprise, they immediately lose access to enterprise-owned apps, and the apps lose access to those users and organizations.

Besides the limitations on where they can be installed and who can sign in, these are standard GitHub Apps. Organization and repository administrators can install them depending on the permissions requested, and they have access to all of the organization and repository APIs that other apps do. Like other apps, they support Copilot Extensions and can be used in Copilot Chat.

Today, only enterprise owners can create and manage these applications. In the future we’ll add support for the App Manager role that exists for organization-owned applications as well, to make it easier for administrators to delegate access to apps in a secure manner.

To learn more about this public beta, see our documentation on GitHub Apps and the enterprise.

See more

New PAT rotation policies preview and optional expiration for fine-grained PATs

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

Discover the GitHub Enterprise Cloud FAQ in the New GitHub Trust Center

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
View more changes