The StartRepositoryMigration GraphQL API endpoint will now require the sourceRepositoryUrl as an input field. While this is a breaking change to the StartRepositoryMigration GraphQL API schema, including this parameter was a de facto requirement already that will now be documented correctly. All StartRepositoryMigration GraphQL requests currently made without this input result in a failed migration. As such, this change should have minimal impact to those using the StartRepositoryMigration GraphQL API endpoint.
GitHub secret scanning now supports validity checks for Google Cloud Platform (GCP) account credentials and Slack webhooks. This improvement involves changes to how account credentials for GCP are detected and alerted on.
What’s changing
Secret scanning alerts for Slack webhooks now support validity checks, in addition to previously supported Slack API tokens.
In addition, secret scanning now also alerts on complete GCP service account credential objects which include the fully matched private key, private key ID, and certificate URLs. These alerts support validity checks. As part of this change, you will no longer receive alerts for GCP private key IDs.
About validity checks
Validity checks indicate if the leaked credentials are active and could still be exploited. If you’ve previously enabled validation checks for a given repository, GitHub will now automatically check validity for alerts on supported token types.
Validity checks are available for repositories with GitHub Advanced Security on Enterprise Cloud. You can enable the feature at the enterprise, organization, or repository level from the “Code security and analysis” settings page by checking the option to “automatically verify if a secret is valid by sending it to the relevant partner.”
Share feedback
Sign up for a 60 minute feedback session on secret scanning and be compensated for your time.
Learn more about secret scanning or our supported patterns for validity checks.
Enterprise owners of GitHub Enterprise Cloud with Enterprise Managed Users (EMUs) can now participate in a private beta introducing GitHub’s native IP allow list configuration to cover user namespaces. This feature will limit access to enterprise-managed user namespaces to the owning enterprise’s IP allow list. Access through the web UI, git protocol, and API are all filtered by the IP allow list. All credentials, including personal access tokens, app tokens, and SSH keys, are covered by this policy.
To enroll in this private beta and make this feature available for your enterprise, reach out to your GitHub Account Manager or contact our sales team.
CodeQL is the static analysis engine that powers GitHub code scanning. CodeQL version 2.17.0 has been released and has now been rolled out to code scanning users on GitHub.com.
Important changes in this release include:
- Full support for C# 12 and .NET 8 (fixed minor remaining issues)
- Support for Java 22
- Support for Swift 5.10
- Support for TypeScript 5.4
- Minor changes to C# queries to enable the recently released threat model settings feature (beta)
- Improvements to Go dependency retrival (up to 27% faster)
- Three new queries have been added, two of which were community contributions:
cpp/type-confusiondetects casts to invalid typesgo/uncontrolled-allocation-sizedetects slice memory allocation with excessive size valuejava/unvalidated-url-forwardprevents information disclosure due to unsafe URL construction
For a full list of changes, please refer to the complete changelog for version 2.17.0. All new functionality will also be included in GHES 3.13. Users of GHES 3.12 or older can upgrade their CodeQL version.
Docker Compose v1 has been deprecated as of July 2023. All customers utilizing Compose v1 on GitHub-hosted runners are encouraged to migrate to Compose v2. Per GitHub’s support policy we will remove this tool from our GitHub managed runner images effective July 9, 2024.
To avoid breaking changes, customers will need to update their Actions workflow files from using docker-compose to docker compose. After July 9, workflows will begin to fail that are using the previous syntax. Customers are advised to review the migration instructions to ensure they are making all the changes required.
For more information on GitHub managed images, see the runner-images repository.
Use CodeQL threat model settings for C# (beta) to adapt CodeQL’s code scanning analysis to detect the most relevant security vulnerabilities in your code.
CodeQL’s default threat model works for the vast majority of codebases. It considers data from remote sources (such as HTTP requests) as tainted. We previously released CodeQL threat model settings for Java to allow you to optionally mark local sources of data (such as data from local files, command-line arguments, environment variables, and databases) as tainted in order to help security teams and developers uncover and fix more potential security vulnerabilities in their code. CodeQL threat model settings are now available for C#, meaning that you can now enable similar local sources of taint in your code scanning analysis of code wriitten in C#.
If your repository is running code scanning default setup on C# or Java code, go to the Code security and analysis settings and click Edit configuration under Code scanning default setup. Here, you can change the threat model to Remote and local sources. For more information, see the documentation on including local sources of tainted data in default setup.
If your repository is running code scanning advanced setup on C# or Java code, you can customize the CodeQL threat model by editing the code scanning workflow file. For more information, see the documentation on extending CodeQL coverage with threat models. If you run the CodeQL CLI on the command-line or in third party CI/CD, you can specify a --threat-model when running a code scanning analysis. For more information see the CodeQL CLI documentation.
As part of this work, we made changes to some of the queries included in the default code scanning suite for C# to better align with local and remote threat model settings. As a result you may see slightly fewer alerts when using the default threat model for remote sources. For more information about which queries are impacted, see the changelog for CodeQL 2.17.0.
CodeQL threat model settings (beta) in code scanning default setup is available on GitHub.com for repositories containing Java and C# code. Support for configuring threat model settings for C# will be shipped in GitHub Enterprise Server 3.14. Users of GHES 3.12 or older can also upgrade the version of CodeQL used in code scanning.
We’ve got some exciting news to share! We’ve been closely listening to your feedback, and one common challenge many of you faced was reviewing, and submitting your pull request reviews on GitHub Mobile. We heard you loud and clear, and today, we’re thrilled to announce that approving PRs is now easier than ever before!
With our latest update, we made it easier to start, continue, and submit your code reviews on the go.
Now, whether you’re on the train, grabbing a coffee, or simply away from your desk, you can effortlessly contribute to your projects and keep the momentum going.
Download or update GitHub Mobile today from the Apple App Store or Google Play Store to get started.
Learn more about GitHub Mobile and share your feedback to help us improve.
Today, we’re releasing security tool-specific filters for the security overview dashboard and secret scanning metrics page.
Have you ever wondered, “How well is my organization handling SQL injections?” or “How quickly are we responding to [partner name] secret leaks?” Maybe you’re curious about the pace of updating your npm dependencies. Well, wonder no more!
With our new security tool filters, you can tailor your search to the exact details you’re curious about, giving you a more focused and relevant report for your needs.
Discover the new filters that are designed to transform your security analysis:
- Dependabot filters: Zero in on a specific ecosystem, package, and dependency scope.
- CodeQL/third-party filters: Drill down to the rule that matters most to you.
- Secret scanning filters: Get granular with filters for secret type, provider, push protection bypassed status and validity.
These features are now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.14.
Learn more about security overview and send us your feedback
To ensure that the Actions runners are truly ephemeral and more secure, we are now limiting execution timeouts on self hosted jobs to 5 days. If a job reaches this limit, the job is terminated and fails to complete.
Secret scanning is expanding coverage to GitHub wiki content. If secret scanning is enabled for your repository, you’ll automatically begin to receive alerts for newly introduced secrets found in your GitHub wiki.
Publicly leaked secrets in GitHub wikis will also be sent to secret scanning partners participating in the secret scanning partner program.
Share feedback or learn more
Sign up for a 60 minute feedback session on secret scanning and be compensated for your time.
Learn how to secure your repositories with secret scanning or become a secret scanning partner.
Available now, Actions users of our 2-vCPU GitHub-hosted Linux runners will be able to make use of hardware acceleration for Android testing. Previously this feature was only available on runners with 4 or more vCPUs.
To make use of this on Linux, Actions users will need to add the runner user to the KVM user group
- name: Enable KVM group perms
run: |
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' | sudo tee /etc/udev/rules.d/99-kvm4all.rules
sudo udevadm control --reload-rules
sudo udevadm trigger --name-match=kvm
You will then be able to make use of hardware acceleration when making use of Android emulator actions such as reactivecircus/android-emulator-runner.
For more information on how to set-up hardware acceleration, please see our documentation.
Today we are announcing exciting updates for GitHub Actions hosted runners, the cloud-based service that provides powerful virtual machines to developers and teams to integrate their automation and CI/CD workflows within GitHub. These updates mark a significant leap towards enhancing enterprise readiness for GitHub Actions and a testament to our commitment to simplifying the adoption of GitHub Actions hosted runners across all project sizes and complexities.
- Azure private networking functionality, that was previously in public beta, is now generally available. This feature allows you to run your Actions workflows on GitHub-hosted runners that are connected to your Azure virtual network, without compromising on security or performance.
- We are introducing additional runner SKUs to our hosted runner fleet including a 2 vCPU Linux runner and a 4 vCPU Windows runner, both equipped with auto-scaling and private networking functionalities. Both these SKUs are generally available starting today and are geared to support scenarios where smaller machine sizes suffice yet the demand for heightened security and performance persists.
- Apple silicon (M1) hosted runners, specifically macOS L (12-core Intel) and macOS XL (M1 w/GPU hardware acceleration) which were previously in public beta, are now generally available.
- We are also unveiling a GPU hosted runner (4 vCPUs, 1 T4 GPU) available in public beta. The GPU runners are available on Linux and Windows, and are enabled with auto-scaling and private networking functionalities. These runners empower teams working with machine learning models such as large language models (LLMs) or those requiring GPU graphic cards for game development to run their tests more efficiently as part of their automation or CI/CD process.
Get Started
- Azure private networking for GitHub-hosted runners is available across Team and Enterprise plans. To get started, navigate to the ‘Hosted Compute Networking’ section within your Enterprise or Organization settings. For more details, consult our documentation. To request support for additional Azure regions, please fill out this form. As a note, Azure private networking for GitHub Codespaces continues to remain in beta.
- The newly added 2 vCPU Linux and 4 vCPU Windows SKUs are generally available starting today across Team and Enterprise plans. To use these runners, create a GitHub-hosted runner by selecting the ‘2-core’ or ‘4-core’ size options in the runner creation flow.
- macOS L and macOS XL runners are generally available across Free, Team and Enterprise plans, and can be used by updating the runs-on key to use one of the GitHub-defined macOS runner labels. To learn more about pricing for these SKUs, refer to our documentation.
- GPU runners are available starting today in public beta across Team and Enterprise plans. To learn more about how to setup the runner, images, and pricing, refer to our documentation. To share your feedback and help us find the right additional GPU SKUs to support, please fill out this form.
We’re eager to hear your feedback on any and all of these functionalities. Share your thoughts on our GitHub Community Discussion.
Code security configurations simplify the rollout of GitHub security products at scale by defining collections of security settings that can be applied to groups of repositories. Your organization can apply the ‘GitHub recommended’ security configuration, which applies GitHub’s suggested settings for Dependabot, secret scanning, and code scanning. Alternatively, you can instead create your own custom security configurations. For example, an organization could create a ‘High risk’ security configuration for production repositories, and a ‘Minimum protection’ security configuration for internal repositories. This lets you manage security settings based on different risk profiles and security needs. Your organization can also set a default security configuration which is automatically applied to new repositories, avoiding any gaps in your coverage.
With security configurations, you can also see the additional number of GitHub Advanced Security (GHAS) licenses that are required to apply a configuration, or made available by disabling GHAS features on selected repositories. This lets you understand license usage when you roll out GitHub’s code security features in your organization.
Security configurations are now available in public beta on GitHub.com, and will be available in GitHub Enterprise Server 3.14. You can learn more about security configurations or send us your feedback.
macOS 14 (Sonoma) is now generally available. Over the next 12 weeks, jobs using the macos-latest runner label will migrate from macOS 12 (Monterey) to macOS 14 (Sonoma). During migration, you can determine if your job has migrated by viewing the Runner Image information in the Set up job step of your logs. This announcement also applies to larger macOS runners, for which the following runner labels can be used:
macos-latest-xlargemacos-latest-large
jobs:
build:
runs-on: macos-latest
steps:
- uses: actions/checkout@v4
- name: Build
run: swift build
- name: Run tests
run: swift test
To use macOS 14 directly, update runs-on: in your workflow file to macos-14, macos-14-xlarge, or macos-14-large:
jobs:
build:
runs-on: macos-14
steps:
- uses: actions/checkout@v4
- name: Build
run: swift build
- name: Run tests
run: swift test
The macOS 14 runner image has different tools and tool versions than macOS 12. See the full list of changed software.
Please note that once your workflows run on macOS 14 using latest they will not revert to run on older image versions. If you spot any issues with your workflows when using macOS 14, please let us know by creating an issue in the runner-images repository.
GitHub Education is excited to announce the launch of our redesigned experience for Learners! Our goal was to enhance the GitHub Education experience, with a focus on learning new skills, finding opportunities, and helping Learners connect and build their network.
The redesign promotes user-friendliness, accessibility, and intuitive navigation, to provide Learners with the ability to find the resources they need to pursue a career in tech.
You can explore the new design at https://education.github.com/ and share your feedback with us on the GitHub Community Discussions.
Not a GitHub Education Learner yet? Join now at https://education.github.com/discount_requests/application.
We’ve clarified the GitHub App creation experience for Enterprise Managed Users (EMUs), updating it for both users and organizations that would like to create an app.
GitHub Apps created within an EMU enterprise are only accessible within the enterprise – they’re blocked for anyone else. In addition, EMU user accounts are unable to install GitHub applications.
To reflect this limitation, we’ve updated the creation UI to disable the “Private” option for EMU users, which prevents users from creating apps that no one can install. We’ve also updated the “Public” option to instead read “This enterprise”, more accurately reflecting where the app can actually be installed.
For more information about EMUs, see “About Enterprise Managed Users“. For more about GitHub Apps, see “About GitHub Apps“.
Enterprises that own their user accounts can now use SSH CAs to access user-owned repositories. This is an optional setting that enterprises can enable in their enterprise SSH CA settings page. Enabling this setting allows developers to use a single SSH certificate for all of their interactions with GitHub across their user account’s repositories and their enterprise’s repositories.
This is available now for customers using Enterprise Managed Users in GHEC, and will be included in GHES 3.14. It is not available to GHEC Classic enterprises, where developers bring their own personal accounts to the enterprise; the enterprise does not own those accounts and cannot gain access to their repositories.
For more about SSH certificate authorities, see “Managing SSH certificate authorities for your enterprise“.
It’s been a little over a month since GitHub Copilot Enterprise became generally available. Check out what’s new below!
Enhanced contextual understanding and more relevant suggestions in GitHub.com
Copilot Chat in GitHub.com now uses faster and smarter embedding models to power content retrieval, giving Copilot higher quality and more relevant context when searching code and knowledge bases.
Copilot Chat in GitHub.com now knows about the programming languages used in the repository you’re looking at: Copilot could sometimes give answers based on a programming language not used by your project. Copilot now knows what programming languages a repository uses, so it can give code examples more tailored to your context.
Faster help with understanding pull request changes
It’s now easier to ask Copilot about the changed files in a diff: From the files changed view, you can now pick the files you’re most interested in asking Copilot about.
You can also now ask Copilot about specific lines in a diff more easily by clicking on the Copilot icon when you hover on a line of code.
Usability improvements
A big thank you to all of our customers for the great feedback you’ve been providing. We’ve made a whole bunch of small fixes, including:
You can now start typing your next question to Copilot while the current response is still generating: Previously you had to wait for Copilot’s message to complete generating before a follow-up question could be composed.
Keyboard up/down arrows can now be used to cycle through past messages: Perhaps you want to ask a similar question from earlier in the conversation history? Hitting the up key on your keyboard will now enable you to cycle through previous messages.
Copilot Chat in GitHub.com now has better support for Japanese and Chinese characters: Previously the message could be submitted to Copilot after the IME conversion selection but before the user was ready to send the message to Copilot.
Customers desire clear, relevant, and actionable insights about how Actions workflows are being used in their organization. Today, we are thrilled to announce that Actions Usage Metrics is available in public beta for GitHub Enterprise Cloud plans.
Time is the most important metric for DevOps and DevEx teams. The question they want answered is, “where are all my minutes going?” Actions Usage Metrics addresses this question and others by focusing on minutes used per workflow, job, repository, runtime OS, and runner type. This data helps organizations locate areas of improvement in their software delivery lifecycle, saving time and money.
Customers can filter data by any combination of workflows, jobs, repositories, runtime OS, and runner type to view total minutes, number of jobs, workflow executions, and more. All usage metrics, filtered or not, can be downloaded as a .csv file to use with your tool of choice.
By default, organization owners can access Actions Usage Metrics. However, access permissions can be granted to other members or teams using Actions fine-grained permissions. This ensures the right level of access to Actions Usage Metrics data, enabling informed decisions and improvements.
To learn more about Actions Usage Metrics, check out our docs or head to our community discussion.
Dependabot grouped security updates are now generally available. This feature automatically groups Dependabot pull requests, lets you specify several additional options to fine tune your groupings.
You can enable grouped security updates for Dependabot at the repository or organization-level. To enable this feature, go to your repository or organization settings page, then go to the Code security and analysis tab, and click “Enable” for grouped security updates (this also requires each affected repository to enable Dependency graph, Dependabot alerts, and Dependabot security updates). When you enable this feature, Dependabot will collect all available security updates in a repository and attempt to open one pull request with all of them, per ecosystem, across directories.
If you would like more granular control over Dependabot’s grouping, you can also configure the dependabot.yml file in a repository to group by any of the following:
- Package name
- Dependency type (production vs development)
- Semver update level (patch, minor, major)
For additional information, check out the Dependabot configuration file documentation.
For GitHub Enterprise Server users, grouped security updates will be available in Version 3.14.