Skip to content

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

Copilot in GitHub Support (Alpha)

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

New rate limit for the audit log API endpoints is active

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

2FA requirement status on the People pages

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

Secret scanning shows metrics for push protection at the organization level

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

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

Select a query suite when enabling code scanning with default setup at the organization level

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

Updates to the audit log api requests streaming public beta

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

Dependabot alerts can be enabled at the repository, organization, and enterprise levels in GHES 3.9

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

New rate limit is coming for the audit log API endpoints

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

Security risk and coverage pages are now generally available and replace the enterprise-level overview page

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

Dependabot pull requests pause for inactivity in enterprises

Enterprise users will now notice added functionality where Dependabot security and version updates may be paused for repositories.

If you are an enterprise user that uses Dependabot updates and there has been no activity in a repository, such as merging, closing, or any other interaction, with Dependabot pull requests for a period exceeding 90 days, the updates will be paused. To resume activity, simply merge or close one of Dependabot's pull requests, or modify the Dependabot config file in the repository.

This change will help Dependabot be more focused to the repositories you care about and reduce use of GitHub Actions minutes on inactive Dependabot pull requests.

If you are using security overview with GitHub Advanced Security, you will be able to see which repositories in your organization have been paused from the security coverage view.

You will also be able to see whether Dependabot has been paused for a repository by querying the /repos/{owner}/{repo}/automated-security-fixes REST API endpoint, which will return both the enablement status and paused status of the repository.

When will Dependabot become paused?

This change only applies to repositories where Dependabot pull requests exist but remain untouched. If no Dependabot pull requests have been opened, Dependabot will never become paused.

The following must be true for at least 90 days:

  • Has not had a Dependabot PR merged
  • Has not had changes made to the Dependabot config file
  • Has not had any @dependabot comment-ops performed
  • Has not had any Dependabot PRs closed by the user
  • Has received at least one Dependabot PR before the 90 day window
  • Has at least one Dependabot PR open at the end of the 90 day window
  • Has had Dependabot enabled for this entire period

How will Dependabot let me know?

Dependabot will add a notice to the body of all open Dependabot pull requests and add a dependabot-paused label to them. Dependabot will also add a banner notice in the UI of your repository settings page (under “Dependabot”) as well as your Dependabot alerts page (if Dependabot security updates are affected).

Who can use this feature?

This change does not apply to Dependabot alerts or subsequent notifications. So, only repositories that have automated Dependabot version updates or security updates, but haven't interacted with these pull requests for a while, will be affected.

Learn more about this change
Learn more about how to interact with the REST API

See more

Code scanning default setup is now available for all CodeQL supported languages, excluding Swift

Code scanning default setup is now available for all CodeQL supported languages, excluding Swift. This includes supporting JavaScript/TypeScript, Ruby, Python, Go, Java/Kotlin, C/C++, and C# at the repository level. We will extend support to include Swift soon. We are also working to extend all CodeQL language support to the organization level.

Default setup detects the languages in the repository and automatically analyzes JavaScript/TypeScript, Ruby, Python, and Go. With this enhancement, you can customize the configuration to also analyze Java/Kotlin, C/C++, and C#. The configuration can be viewed and edited at any time, during or after set up.

You can also use the REST API to include CodeQL supported languages in the default setup configuration.

What if the analysis for a language fails in default setup?

It is possible for the CodeQL analysis for a particular language to fail, such as when the code can't be compiled. If the CodeQL analysis for 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.
  1. 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.
  1. 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.

Why aren't some languages automatically included in the default setup configuration ?

Java (including Kotlin), C/C++, and C# 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.

Java (including Kotlin), C/C++, and C# are not included in bulk code scanning setup from the organization level. We are working to extend all CodeQL language support to the organization level soon.

For more information on code scanning default setup, see Configuring code scanning automatically.

See more

New expandable event payload view is generally available in all audit logs

The Enterprise and Organization audit log UI and user security logs UI now include an expandable view that displays the full audit log payload of each event.

image

Customers can now see the same event metadata when searching your audit log via U/I, exporting audit logs to a JSON file, querying the audit log API, or streaming your audit logs to one of our supported streaming endpoints.

See more

Code scanning default setup automatically updates when the languages in the repository change

Code scanning default setup now automatically updates when the languages in a repository change.

If a repository that uses default setup changes to include the languages JavaScript/TypeScript, Ruby, Python, or Go, the configuration will automatically update to include these languages. If the new configuration fails, we’ll resume the previous configuration automatically so that the repository does not lose coverage. The configuration will also automatically update if a repository removes a language.

You can always view the repository’s default setup configuration from the Code security and analysis settings page. Additionally, you can use the tool status page to view useful information about your setup and debug any failed languages.

Default set up makes it easy to get started with code scanning. The supported languages are currently JavaScript/TypeScript, Python, Ruby and Go and the list is constantly evolving. For more information on code scanning default setup, see Configuring code scanning automatically.

See more

Organization-level code scanning default setup for CodeQL is now generally available

Today we are announcing the general availability of code scanning default setup enablement at the organization level.

Code scanning enable all default setup button on the organization's 'Settings' page

You can use code scanning default setup to enable CodeQL analysis for pull requests and pushes on eligible repositories without committing any workflow files. Currently, this feature is only available for repositories that use GitHub Actions and it supports analysis of JavaScript/TypeScript, Python, Ruby and Go. We plan to add support for additional languages soon.

This feature is also available as a public beta in GitHub Enterprise Server 3.9 and will be generally available in GitHub Enterprise Server 3.10.

Learn more about configuring code scanning at scale using CodeQL and the "Enable or disable a security feature for an organization" REST API
Learn more about GitHub Advanced Security

See more

EMU innersource restricted users private beta is now guest collaborators

In late 2022 we launched a private beta of innersource restricted users allowing customers with enterprise managed users (EMU) to assign an IdP-defined role to users who should not be granted access to internal repositories in any organization they are not expressly a member. We have made improvements to align product behavior with beta customer feedback and are updating the feature name to "guest collaborators" to better reflect the expected use cases. Guest collaborators are distinct from outside collaborators because they are always IdP-defined users intended to be fully managed within an enterprise's security boundary.

Existing private beta customers will see visual changes reflecting the transition from "restricted users" to "guest collaborators" over the coming days. We have also submitted Azure AD and Okta app changes to support a "guest collaborator" role to replace "restricted user". While the guest collaborators feature remains in private beta, we are working toward an upcoming public beta release adding the ability to selectively add guest collaborators to individual repositories without granting organization membership. At public beta release, we will have more information on how to transition your existing app integration without any breaking change.

We are still accepting private beta enrollments for customers if you would like to test the existing capabilities of the feature. Please reach out to your account team or contact our sales team for more details.

See more

Code scanning can filter alerts by language and file path

You can now easily find all alerts associated with a specific language with the new language filter on the code scanning alerts page.

To show all the code scanning alerts for a language, type 'language:javascript' in the Filter alerts text box.

Language filter

You can also use a file path filter to see all the alerts located in specific files or directories to sort and manage them efficiently by focusing on a specific part of the code related to the project.
This can be useful to manage lots of alerts on big repositories (monorepos) to review all alerts specific to the part of the code you are responsible for faster.

To apply the file path filter, type 'path:' and the path to the file or directory in the Filter alerts text box.

Path filter

This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.10.

Learn more about filtering code scanning alerts.

See more

Choose which languages to enable in code scanning default setup for your repository

Code scanning now has the option to enable default setup for a subset of languages in a repository. This lets you customize the configuration to suit your repository's needs, for example deselecting a language which is failing the analysis.

Default set up makes it easy to get started with code scanning. The supported languages are currently JavaScript/TypeScript, Python, Ruby and Go and the list is constantly evolving.

When you choose default setup, we automatically tailor a code scanning configuration for the repository. By default we will enable the best CodeQL configuration for all languages in your repository. However, if there is a language that you'd prefer to disable in code scanning, you can now customize the languages in your default setup configuration.

Use the 'edit configuration' page or REST API to edit the default setup configuration for a repository. You can customize the languages and query suites used in the analysis. The configuration can be viewed and edited at any time, during or after set up. 

{
  "state": "configured",
  "languages": ["javascript-typescript", "ruby"],
  "query_suite": "default", 
  "updated_at": "2023-02-24T20:00:42Z"
}

For more information on code scanning default setup, see Configuring code scanning automatically.

See more

Enterprise managed users connector support for Ping Federate is now in public beta

GitHub Enterprise Cloud customers with enterprise managed users (EMU) can now integrate with Ping Federate as a formally supported SSO and SCIM identity provider in public beta. To get started, download the Ping Federate "GitHub EMU Connector 1.0" from the add-ons tab on the download page, under the "SaaS Connectors" heading. Add the connector to your Ping Federate installation and consult the Ping Federate documentation in addition to GitHub's SAML SSO and SCIM documentation for configuration.

PIC-Square-Logo-Primary

The "GitHub EMU Connector" is maintained and supported by our partner, Ping Identity. Ping additionally maintains their own release notes for this connector.

See more
View more changes