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.10 is generally available

GitHub Enterprise Server 3.10 gives customers more control over how their instance is used and run. Here are a few highlights:

  • GitHub Projects is generally available, with additions that help teams manage large projects
  • Always deploy safely, with custom deployment protection rules for GitHub Actions and new policy control over runners
  • Start finding vulnerabilities in all your repositories, in just a few clicks with a new default setup experience for GitHub Advanced Security code scanning, and track security coverage and risk at the enterprise level
  • Fine-grained personal access tokens (PATs) bring granular control to PATs
  • Branch protections meet more compliance needs with more control over merge policies
  • Backup instances faster and more incrementally, for more confident operations

If you are upgrading from Enterprise Server 3.8 then this release also includes an upgrade from MySQL 5.7 to 8, which will increase I/O utilization. Please read this page for more details on this increase and how to mitigate it if you see an unacceptable degradation of performance on your instance.

To learn more about about GitHub Enterprise Server 3.10 read the release notes,
or download it now.
If you have any feedback or questions, please contact our Support team.

See more

Earlier this year, we announced the roll out of enterprise accounts to all GitHub Enterprise customers. Enterprise accounts enable enterprise customers to manage and scale their users and Organizations through one administrative portal.

As part of this transition, customers upgrading from a Free or Teams plan Organization to the Enterprise plan now have an enterprise account.

If you are currently on GitHub Enterprise with a single organziation, a free upgrade flow will soon be available on your Organization's Billing settings page, for you to transition into an enterprise account. Stay tuned for the announcement on when that is live.

To learn more, read our documentation about enterprise accounts or about upgrading your account's plan.

See more

The administrator account (ending in _admin) of Enterprise Managed User enterprises is now required to enter sudo mode before taking sensitive actions. As with standard user accounts, the administrator must provide their password or a second factor credential to enter sudo mode.

Sudo mode is a GitHub security feature that validates the user's session before they perform a sensitive action, like creating a personal access token, deleting an organization, or updating their credentials.

Until now this mode was disabled for all Enterprise Managed Users (EMUs), as they had no credentials on GitHub.com and therefore could not provide one for the sudo mode prompt. As a result, EMU accounts are able to take sensitive actions without being asked for a credential. However, the admin for the EMU enterprise does have credentials on GitHub.com and will now be asked for them before taking sensitive actions.

For more information about sudo mode, see "Sudo mode". To learn more about Enterprise Managed Users, see "About Enterprise Managed Users".

See more

The GitHub Enterprise Server 3.10 release candidate is here

GitHub Enterprise Server 3.10 gives customers more control over how their instance is used and run. Here are a few highlights:

  • Code Scanning configuration can be customized per repository, allowing repository owners to decide which languages to analyze by default.
  • Fine-grained personal access tokens (PATs) are now available as a public beta on Enterprise Server, giving developers and administrators granular control over the permissions and repository access granted to a PAT.
  • Assess security risk and coverage data across all organizations in an enterprise via the Code Security tab.
  • Define who can merge pull requests, and how they are merged, to make it easier for you to meet your compliance and security goals.
  • Reduce data transfer required to backup your Enterprise Server by utilizing incremental backups of MySQL data in backup-utils v3.10.0.
  • GitHub Projects is now generally available in Enterprise Server.

If you are upgrading from Enterprise Server 3.8 then this release also includes an upgrade from MySQL 5.7 to 8, which will increase I/O utilization. Please read this page for more details on this increase and how to mitigate it if you see an unacceptable degradation of performance on your instance.

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

Read more about GitHub Enterprise Server 3.10 in the release notes, or download the release candidate now. If you have any feedback or questions, please contact our Support team.

See more

We are excited to announce the alpha release of Copilot in GitHub Support, a faster way to find answers to your GitHub related questions! Copilot in GitHub Support is an AI-powered assistant that answers questions based on our official GitHub Enterprise Cloud documentation.

Initially, we’re offering the Copilot experience to a limited number of randomly selected GitHub Enterprise Cloud customers. We hope to continue rolling out the experience to a wider audience over the coming months.

If your ticket is selected, you’ll be provided with an option to opt-in while creating your support ticket. During the alpha, GitHub will be reviewing answers provided and collecting feedback from participating customers to improve the accuracy.

Copilot in GitHub Support is part of our ongoing effort to make GitHub the best place for all developers to collaborate, innovate, and ship great software. We believe that Copilot in GitHub Support will enhance your experience and productivity.

We look forward to hearing from you and learning from your feedback.

See more

In early July, GitHub announced a new rate limit was coming for the audit log API endpoints. Starting today, each audit log API endpoint will impose a rate limit of 1,750 queries per hour per user, IP address, enterprise, or organization. This is higher than the previously stated change to 15 queries per minute, in order to allow integrators more time to adjust workflows and scripts which programmatically query the audit log API. We intend to enforce a limit of 15 queries per minute on or after November 1st, 2023.

This rate limit will be enforced on each combination of an individual user, IP address and entity path (/orgs/<org_name>/audit_log or /enterprises/<enterprise_name>/audit_log) independently.

To adapt to these changes and avoid rate limiting, programs or integrations querying the audit log API should query at a maximum frequency of 1,750 queries per hour. Additionally, applications querying the audit log API should be updated to honor HTTP 403 and 429 responses to dynamically adjust to the back-pressure exerted by GitHub.

For additional information, please consult our documentation on handling rate limits for requests from personal accounts and rate limits for GitHub Apps. Alternatively, enterprises seeking access to near real-time data should consider streaming your enterprise audit log.

See more

As part of the two-factor authentication requirement program on GitHub.com, the People pages of enterprises and organizations have been updated to include the 2FA requirement status of members and collaborators. As an administrator, you can see which of your users have not yet enabled 2FA but are required to do so because of an action they have take in one of your organizations, or elsewhere on GitHub.com.

A clock icon will appear as a user's 2FA status will show if the user is required to enable 2FA. When the icon is red, they are past the due date for enabling 2FA, and are at risk of being blocked from accessing GitHub.com until they enable it. Clicking the clock icon will display the user's enrollment date.
256704235-eb7cb75d-2806-4aa6-aa44-aa9148bfb828

You can filter the UI to show only users who have a pending requirement. Enrollment dates are also now included in the CSV and JSON downloads of enterprise and organization memberships.

To learn more about the 2fa enrollment program, see our blog post with more details. For information about viewing your members, see the organization and enterprise documentation.

See more

Organization owners and security managers can now view metrics associated with push protection usage across their organization.

The overview shows a summary of how many pushes containing secrets have been successfully blocked across the organization by push protection, as well as how many times push protection was bypassed.

You can also find more granular metrics, including:

  • the secret types that have been blocked or bypassed the most
  • the repositories that have had the most pushes blocked
  • the repositories that are bypassing push protection the most
  • the percentage distribution of reasons that users give when they bypass the protection

These metrics are found under the Security tab of your organization and are based on activity from the last 30 days.

screenshot of push protection metrics, showing overall secrets blocked and details on most blocked types, repositories with most pushes blocked, and bypassed secret metrics

See more

Code scanning default setup is now available for Swift analysis with CodeQL! Default setup now supports all CodeQL supported languages at the repository level. This includes JavaScript/TypeScript, Ruby, Python, Go, Java, Kotlin, C/C++, C#, and Swift. We're working to support enabling code scanning at the organization level for all CodeQL languages soon.

Default setup automatically detects the languages used in a repository, and automatically analyzes JavaScript/TypeScript, Ruby, Python, and Go. You can also optionally customize the configuration to analyze Java/Kotlin, C/C++, C# and Swift. The configuration can be viewed and edited at any time, during or after set up. You can also use the REST API to include languages in the default setup configuration.

Java, Kotlin, C/C++, C# and Swift are not automatically included in the default setup configuration because they often require more advanced configuration. Code written in these languages needs to be compiled in order for CodeQL analysis to proceed. CodeQL will attempt to build your code automatically but may fail if your code requires bespoke build steps.

If a language fails in default setup, you will see an error message on the repository's settings page, in the code security and analysis section. To resolve the situation you can:

  1. Deselect the language from the configuration and continue to use default setup for the successful languages.
  2. Convert to advanced setup. The advanced setup uses a yml file and allows you to provide the build information required for the CodeQL analysis to succeed.
  3. Debug and fix the cause of the language failure. The Actions log will provide the failure reason so you can resolve this for a successful analysis.

For more information, see the documentation for when a particular language is causing default setup to fail. For more information on code scanning default setup, see Configuring code scanning automatically.

See more

You now have the option to select either the "Extended" or "Default" query suite when setting up code scanning with default setup for eligible repositories within your organization.

The multi-repo enablement panel on the security coverage page with a focus on code scanning enablement and the new query suite selection menu

Code scanning's default query suite has been carefully designed to ensure that it looks for the security issues most relevant to developers, whilst also minimizing the occurrence of false positive results. However, if you and your developers are interested in seeing a wider range of alerts, you can enable the extended query suite. This suite includes everything from the default query suite, plus additional queries with slightly lower precision and severity.

Choose a query suite

The query suite selection can be made whenever you enable code scanning with default setup:

  • When using "Enable all" on the organization settings page.
  • When enabling a single or multiple repositories on the security coverage page.
  • When enabling on a repository's settings page.
  • When using the "Enable or disable a security feature for an organization" endpoint.

Previously, our system would automatically choose the default query suite when you enabled code scanning with default setup. Now, you can choose either the extended or default query suite.

Recommend a query suite

Additionally, you can specify either the extended or default query suite as the preferred choice for your organization. This preference determines which query suite is "recommended" when a user is enabling code scanning setup with default setup.

The recommended setting for code scanning query suites and the resulting recommended tag on the organization settings page

These improvements have shipped to GitHub.com and will be available in GitHub Enterprise Server 3.11.

Learn more about configuring default setup for code scanning and send us your feedback
Learn more about GitHub Advanced Security

See more

In April, we announced that GitHub Enterprise Cloud customers could join a public beta for streaming API request events as part of their enterprise audit log. As part of that release, REST API calls against enterprise's private and internal repositories could be streamed to one of GitHub's supported streaming endpoints.

However, we've discovered the need to expand our api call coverage against private and internal repositories in order to capture other security significant api routes. Additionally, we've determined several api routes targeting internal and private repositories generate significant event volumes with little auditing or security value. To address these concerns, we partnered with GitHub's security team to define a set of auditing and security significant controllers to serve as the basis for the public beta. These adjustments to the beta should increase signal and decrease the noise generated by the api request event being streamed.
image (4)

Note: hashed_token and token_id have been redacted for security reasons.

Enterprise owners interested in the public beta can still follow the instructions in our docs for enabling audit log streaming of API requests. We welcome feedback on the changes made to this feature on our beta feedback community discussion post.

See more

With GHES 3.9, you and your organization can better manage your Dependabot alerts thanks to more granular enablement controls. You can now enable Dependabot alerts at the repository, organization, and enterprise level, rather than having to enable Dependabot alerts across an entire enterprise at once.

This release also adds support for “automatically enable for new repositories” at the organization and enterprise levels.

Enterprise admins still need to opt in to Dependabot alerts via GitHub Connect, which approves outbound calls for advisories to sync.

Learn more about changes for GHES 3.9 for Dependabot.

See more

GitHub provides Enterprise customers with the ability to programmatically retrieve enterprise and organization audit log events in near real-time using the audit log API. A high-quality audit log is an essential tool used by enterprises to ensure compliance, maintain security, investigate issues, and promote accountability. To support these objectives, the audit log API needs to be highly reliable, consistently available, and extremely scalable.

Recognizing the audit log API's importance as a data source to enterprises, each audit log API endpoint will impose a rate limit of 15 queries per minute per enterprise or org starting August 1st, 2023. Based on a thorough analysis of event generation data, we are confident that the new rate limit will continue to support customers in accessing near real-time data via the audit log API. Additionally, query cost is a crucial consideration, and in the future, the audit log may impose further rate limiting for high-cost queries that place significant strain on our data stores.

What can you do to prepare for these changes? First, programs or integrations querying the audit log API should be adjusted to query at a maximum frequency of 15 queries per minute. Additionally, applications querying the audit log API should be updated to be capable of honoring HTTP 429 responses, enabling them to dynamically adjust to the back-pressure exerted by our systems. Alternatively, Enterprises seeking access to near real-time data should consider streaming your enterprise audit log.

See more

Today we are announcing the general availability of our organization and enterprise-level security risk and coverage pages.

Additionally, the alert-centric pages for Dependabot, code scanning, and secret scanning are also now generally available at both the organization and enterprise levels.

The enterprise-level security overview page has been replaced by the risk and coverage pages as previously announced. The risk page is designed to help you assess security exposure, and the coverage view is intended to help you manage security feature enablement.

To access the new enterprise-level risk and coverage pages, follow these steps:

  1. Navigate to your profile photo in the top-right corner of GitHub.com.
  2. Click Your enterprises.
  3. From the list of enterprises, select the enterprise you wish to view.
  4. In the enterprise account sidebar, click on Code Security.

These improvements have shipped to GitHub.com and will be available in GitHub Enterprise Server 3.10.

Learn more about the new risk and coverage pages and send us your feedback

See more