Changelog

Subscribe to all Changelog 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

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

Bypass controls for push protection are generally available

Secret scanning bypass privileges for push protection are now generally available.

These controls allow you to choose who is allowed to bypass push protection, and introduce a review and approval cycle for pushes containing secrets from all other contributors. This can ensure push protection blocks are not accidentally bypassed and prevent secrets from being committed to your repositories.

Controls for bypass privileges can be set as part of your organization’s security configurations or at the repository level in your code security settings. You can add specific roles or teams to your bypass list. The individuals in these roles and teams will be able to bypass push protection themselves, and will act as reviewers for any bypass requests submitted by another contributor. The requests can be approved or denied, determining whether the commit can proceed into the repository.

screenshot of bypass privileges within security configurations

Reviewers can view the requests under the Security tab at either the organization level or repository level. Requests can also be accessed through audit log and webhook events.

Learn more about secret scanning and push protection, or join the discussion in the 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

Secret scanning: improvements for alerts with known public leaks and enterprise duplicates

You can now view exact locations of known public leaks for a secret scanning alert, as well as any repositories with duplicate alerts across your enterprise. Public leak and duplicate alert labels are now also surfaced via the REST API.

What are public leak and multi-repo labels?

To help you triage and remediate secret leaks more effectively, GitHub secret scanning now indicates if a secret detected in your repository has also leaked publicly with a public leak label on the alert. The alert also indicates if the secret was exposed in other repositories across your organization or enterprise with a multi-repo label.

These labels provide additional understanding into the distribution of an exposed secret, while also making it easier to assess an alert’s risk and urgency. For example, a secret which has a known associated exposure in a public location has a higher likelihood of exploitation. Detection of public leaks is only currently supported for provider-based patterns.

The multi-repo label makes it easier to de-duplicate alerts and is supported for all secret types, including custom patterns. You can only view and navigate to other enterprise repositories with duplicate alerts if you have appropriate permissions to view them.

Both indicators currently apply only for newly created alerts.

Learn more

Learn more about reviewing alert labels and how to secure your repositories with secret scanning. Let us know what you think by participating in our GitHub community discussion or signing up for a 60 minute feedback session.

See more

Copilot secret scanning for generic passwords is generally available

Copilot secret scanning is now generally available. Copilot secret scanning, which detects generic passwords using AI, offers greater precision for unstructured credentials that can cause security breaches if exposed. Over 350,000 repositories have already enabled this password detection.

To enable Copilot secret scanning, select “Scan for generic secrets” within your code security and analysis settings at the repository level, or the code security global settings at the organization level. You can also use the Update a repository API endpoint for enablement at the repository level. Support for enablement through your organization’s code security configurations, as well as enablement for organizations and enterprises with the API, will come in a future release.

Password detection is backed by the Copilot API and is available for all repositories with a GitHub Advanced Security license. You do not need a Copilot license to enable generic secret detection. Passwords found in git content will create a secret scanning alert in the “Experimental” tab, separate from regular alerts.

In effort to reduce false positives and detections of secrets that are used in tests, Copilot secret scanning will not:
– detect more than 100 passwords per push
– detect secrets in media files (.svg, .png, .jpeg)
– detect secrets in language files (.js, .py, .ts, .java, .cs, or .rb) that contain test, mock, or spec in the filepath
– detect additional secrets in files where five or more alerts have been marked as false positive

Note that passwords will not be detected in non-git content, like GitHub Issues or pull requests. Passwords are also excluded from push protection, another feature of secret scanning designed to prevent sensitive information from being pushed to your repository.

Learn more about secret scanning and generic secret detection or join our community discussion.

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

New Terminology for GitHub Previews

As part of our commitment to improving your experience at GitHub, we’re simplifying the terminology we use to refer to products that are in testing and validation stages. Starting on October 18, 2024, you’ll start seeing the word “Preview” instead of “Alpha” or “Beta” to describe our features that are not yet generally available.

What’s Changing?

Our goal with this update is to create a more consistent, clear process that helps our customers understand the state of new features and how they fit into their development workflows.

  • As shown in the table below, we’re reducing the number of terms we’re using but keeping the same flexibility for giving early access and gathering customer feedback before a General Availability (GA) launch.
  • The key difference between “Private” and “Public” previews is whether the release is publicly announced.

What to Expect

These changes are now live in customer-facing documentation as of today.

Here’s an overview of the changes:

Previous Terminology New Terminology Details
Alpha Private Preview
  • Not publicly announced
  • Limited number of customers
Private Beta
Technical Preview Technical Preview
  • Used for experiments and research projects primarily from GitHub Next
  • Limited number of customers
Limited Public Beta Public Preview
  • Publicly announced on the GitHub Changelog and includes GitHub Docs
  • May be open to all, or limited to selected customers behind a waitlist
Public Beta
General Availability General Availability
Deprecation Closing Down
  • Signals that a product or service is being phased out
Sunset Retired
  • Marks the official end of a product or feature’s life
  • No longer available, supported, or maintained

Thanks for being part of the GitHub community! These updates are designed to provide clearer communication and a smoother experience as we roll out new features.

See more

New code security configurations let you set security features at the organization level

Now you can simplify the rollout of GitHub security products within your organization. Code security configurations now allow you to define collections of security settings and apply those settings to groups of repositories. Configurations help you maintain security settings for important features like code scanning, secret scanning, and Dependabot.

As previously announced in August, starting today, you can no longer enable or disable GitHub security features from the organization-level security coverage view, which has been deprecated and replaced with code security configurations for managing these settings.

Learn more about code security configurations and send us your feedback.

See more

Actions: Runner groups now available for organizations on Free plan

Starting today, organizations on all plans, including the Free plan, can now utilize GitHub Actions runner groups with self-hosted runners. Runner groups enable you to manage runner permissions and control access to these runners across your organization.

Please note that GitHub-hosted larger runners are not available to free organizations and therefore cannot be included in runner groups. For more details about managing access to self-hosted runners using runner groups, please refer to our documentation.

See more

What’s New in Mobile, October Update

In the landscape image, a dark red gradient shape is positioned partially off-canvas from the top-right. The text "What's New in GitHub Mobile" is centered in the foreground and followed by a description of the October update.

August and September contained a number of improvements to GitHub Mobile, including Focused Notifications for those high-priority items in your Inbox, a contribution graph widget on Android, and a continued focus on accessibility.

Introducing Focused Notifications

View important notifications first with the new Focused filter in the Inbox.

A screenshot of the GitHub Mobile app showing certain notifications filtered down by priority

Learn more about Focused Notifications in the Changelog blog post.

iOS

What’s new

  • When accessing content protected by SAML single sign-on (SSO) login, authenticate directly with your organization without logging out.
  • Achievement badges rotate in your palm, just as it would in real life.

Bug fixes

  • Activate filters in Explore via keyboard navigation.
  • Assistive technologies iterate through reviewer information in the pull requests.
  • Confirm saving draft or deleting content before dismissing modal forms.
  • Description of a forked repository isn’t cut off when using large text sizes.
  • Dismiss triage sheet view with mouse on iPadOS.
  • Dismiss user status update, repository watch settings or the edit “My Work” view using the Escape key on a connected hardware keyboard.
  • Filter bar doesn’t clip at large accessibility sizes.
  • Font sizes respect the user’s Dynamic Type preference when composing comments.
  • Hide “Read More” button when Explore item doesn’t include truncated content.
  • Hovering over Copilot button with trackpad or mouse on iPadOS shows a pointer effect.
  • Improved support for large accessibility sizes within user profiles, account lists, pull request review line numbers, repository headers, the Explore view, code review view, comment author usernames, and editing Home “My Work” items.
  • Items in the Explore feed no longer truncate when using large text sizes.
  • Merge confirmation dialog appears as a modal on iPadOS.
  • Merging or marking a pull request as ready for review updates the pull request state in the Inbox and Recent Activity list.
  • Moving an item from one project group to another updates the title of the group.
  • Project pickers for a repository shows projects owned by the repository owner.
  • Repositories in lists no longer truncate their content when using large text sizes.
  • Scale badge icons on repository profile with font size.
  • Tapping a user avatar or username within comments navigates to the user profile.
  • Tapping on links to issue and pull request comments scrolls to the destination comments.
  • The area next to floating elements no longer blocks scrolling.
  • Toast messages no longer overlap with other floating elements on the screen.
  • Toolbars for user input fields scale with font size.
  • User and organization details no longer truncate when using large text sizes.
  • Username in a comment doesn’t disappear when using large text sizes.
  • VoiceOver announces “Jump to file” and “Dismiss line selection” buttons when reviewing file changes.
  • When sharing an issue or pull request, assistive technologies distinguish between the two types of content.
  • When viewing a list of workflow runs that have no runs yet, an empty state displays on the screen.

Android

What’s new

Bug fixes

  • Actions workflow logs show clearer error messages.
  • Editing a file opened via permalink no longer shows an endless spinner.
  • Filtering notifications by repository is more accessible for TalkBack users.
  • Improved accessibility for bulk selection of notifications.
  • Improved keyboard accessibility when reordering shortcuts.
  • Improved keyboard navigation on Home tab.
  • Pull request review suggestions are accessible via keyboard navigation.
  • Releases are more accessible via keyboard navigation.
  • Replying to and resolving comments is more accessible with large fonts.
  • Subscribing or unsubscribing to an issue or pull request considers custom repository watch settings.
  • The code options screen is more accessible with large fonts.
  • When viewing a list of workflow runs that have no runs yet, an empty state displays on the screen.
See more

EPSS Scores in the GitHub Advisory Database

The GitHub Advisory Database now features the Exploit Prediction Scoring System (EPSS) from the global Forum of Incident Response and Security Teams (FIRST), helping you better assess vulnerability risks.

EPSS scores predict the likelihood of a vulnerability being exploited, with scores ranging from 0 to 1 (0 to 100%). Higher scores mean higher risk. We also show the EPSS score percentile, indicating how a vulnerability compares to others.

For example, a 90.534% EPSS score at the 95th percentile means:

  • 90.534% chance of exploitation in the next 30 days.
  • 95% of other vulnerabilities are less likely to be exploited.

Learn more in the FIRST’s EPSS User Guide.

This feature will be available in GitHub Enterprise Server version 3.16 and later.

See more

Now you can choose a specific branch when using Copilot Autofix for code scanning

When using Copilot Autofix for historical alerts, you can now choose the branch to which you want to commit an autofix. You can also decide whether to then open a pull request, check out the branch locally, or open it in GitHub Desktop.

Copilot Autofix provides automatic fix suggestions for code scanning alerts in your codebase.

Example of committing Copilot Autofix to branch

This update integrates Autofix more closely within the developer workflow, so you can quickly iterate on fix suggestions and collaborate on those with your team.

For more information, see: About Copilot Autofix for CodeQL code scanning. If you have feedback for Copilot Autofix for code scanning, please join the discussion here.

See more

Introducing Focused Notifications

Focused Notifications is now generally available on iOS and Android, helping you focus on the most important updates. Focused Notifications shows you notifications from the past 30 days that are more relevant to you, such as items that you’ve authored, items in which you’ve been directly mentioned, and items to which you’re assigned or you’ve manually subscribed. This helps you stay on top of what matters most while reducing notification noise.

focused notification screenshot on Github mobile

Learn more about GitHub for mobile, download GitHub for iOS today, and send us your feedback to help us improve.

See more

Upcoming replacement of enterprise code security enablement UI and APIs

In the coming months, the current interface for managing code security settings for an enterprise will be deprecated and replaced with new and improved code security configurations that will provide you a more consistent and scalable way to manage security settings across repositories within your enterprise.

The current REST API endpoint to enable or disable a security feature for an enterprise is now deprecated. It will continue to work for an additional year in the current version of the REST API before being removed in September of 2025, but note that it may conflict with settings assigned in code security configurations if the configuration is unenforced, potentially resulting in a security configuration being unintentionally removed from a repository. To change the security settings for repositories at the enterprise level, you can use the current enterprise-level security settings UI or the upcoming code security configurations API.

Send us your feedback!.

See more

Deprecation notice – Dependabot will no longer support Composer v1

As of November 6, 2024, Dependabot will no longer support Composer version 1, which has reached its end-of-life. If you continue to use Composer version 1, there’s a risk that Dependabot will not create pull requests to update dependencies. If this affects you, we recommend updating to a supported release of Composer. As of October 2024, the newest supported release of Composer is 2.8, and the long-term supported version is 2.2. View Composer’s official documentation for more information about supported releases.

See more

Copilot content exclusions now available for enterprise admins

Enterprise admins can now manage and apply content exclusions at the enterprise level. This expands upon previous capabilities where only org admins and repo admins could apply exclusions. Enterprise admins can now implement exclusions that apply to all users within the enterprise, providing a more comprehensive and centralized approach to managing content exclusions.

How to get started?

Enterprise admins can access Copilot Content Exclusions by navigating to the Policies tab, clicking on Copilot, and then selecting the Content Exclusions tab.

Enterprise admin Copilot Content Exclusions

Enterprise admins can learn more about excluding content with Copilot in our detailed documentation: Configuring Content Exclusions For GitHub Copilot

How will repo-level rules change with the introduction of enterprise-level rules?

There are no changes to repo-level rules with the introduction of enterprise-level settings. If a repo admin has excluded certain files from that repository, those exclusions will continue to apply to all users working on that repo within the enterprise.

How will org-level rules change with the introduction of enterprise-level rules?

Currently, org-level rules apply to all users across the enterprise. However, once enterprise-level settings are available and applied by enterprise admins, org-level rules will only affect users who are assigned Copilot seats from that specific org. This change allows for more targeted control within each organization, ensuring that org rules are scoped more precisely.

Important Details for Org Admins

If you haven’t set any rules at the org level yet, any rules you set going forward will only apply to users getting Copilot seats from your org.

If you are an existing org with rules already set up for content exclusions, here’s what you need to know:

Before November 8th:

  • If Enterprise Admins Do Not Set Rules: Org-level rules will continue to apply to all users across the enterprise, functioning as they do today.
  • If Enterprise Admins Set Rules: Once enterprise-level rules are applied, org-level rules will only apply to users with Copilot seats from your specific org.

After November 8th:

  • Org-level rules will no longer apply enterprise-wide. They will be limited to users who are assigned Copilot seats from your org, regardless of whether enterprise-level rules are applied.

Please coordinate with your enterprise admins to ensure that rules are set correctly for your organization.

Read Copilot content exclusions document to learn more about our exclusion rules.

See more

Copilot Chat in VS Code upleveled with new GitHub skills

New skills have been added to Copilot Chat in VS Code, enabling you to search across GitHub to find commits, issues, pull requests, repositories, and topics. GitHub Copilot will either automatically infer when to use the @github agent, or you can invoke it directly by asking questions like:
– @github What are all of the open PRs assigned to me?
– @github What are the latest issues assigned to me?
– @github When was the latest release?
– @github Show me the recent merged pr's from @dancing-mona

This functionality is available to all Copilot users, with Copilot Chat v0.20.3 or later and VS Code or VS Code Insiders 1.93 or later. Learn more about asking questions in Copilot Chat on VS Code and available skills

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

See more

Deprecation – Dependabot no longer supports Bundler v1

As of October 7, 2024, Dependabot no longer supports Bundler version 1, which has reached its end-of-life. If you continue to use Bundler version 1, Dependabot will be unable to create pull requests to update your dependencies. If this affects you, we recommend updating to a supported release of Bundler. As of October 2024, the newest supported version is 2.5.

View Bundler’s official support policies for more information about supported releases.

See more

Secret scanning non-provider patterns are generally available

Secret scanning support for non-provider patterns is now generally available for all GitHub Advanced Security customers.

Non-provider patterns are generic detectors that help you uncover secrets outside of patterns tied to specific token issuers, like HTTP authentication headers, connection strings, and private keys. You can enable them in your repository’s code security and analysis settings, or through code security configurations at the organization level.

Learn more about secret scanning and non-provider patterns, and join the GitHub Community discussion.

See more

Secret scanning alert lists renamed to “Default” and “Experimental”

The secret scanning alert lists are now named “Default” and “Experimental,” better reflecting the alert categories and making it easier for you to tell experimental alerts from default alerts.

The Default list includes alerts for provider patterns and custom patterns. The Experimental list includes alerts for non-provider patterns and AI-detected passwords. You can view the alert counts of these two lists in the organization-level Security tab in the sidebar, bringing more clarity and visibility into your alerts.

You can filter within the alert list using results:default and results:experimental.

Learn more about secret scanning and the supported patterns.

See more
View more changes