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

GitHub Advanced Security customers using secret scanning can now specify a custom link via the organization level REST API that will show in the message when push protection detects and blocks a potential secret. Admins can use the custom link to point their developers to company-specific guidance on secrets.

Previously, admins could only set a custom link through the UI.

See more

GitHub verified teachers using GitHub Classroom get access to GitHub’s groundbreaking, browser-based IDE, Codespaces. Teachers can enable Codespaces in GitHub Classroom and then choose it as the preferred editor when creating assignments.

We heard your feedback and from today, students can directly launch existing or new Codespaces from the Open in Codespaces button in readme.
student-codespaces-readme-link

For more information check out our documentation. Your feedback is welcome at our Education Community Forum.

See more

Organization administrators can now filter fine-grained personal access tokens (PATs) by their permissions in the organization settings UI. Both pending token requests and active tokens can be filtered by permission, such as issues_write and members_read.

image

After setting a filter, only tokens with that permission will be shown in the table.

To learn more about fine-grained PATs, see "Reviewing fine-grained personal access tokens" and "Managing requests for fine-grained personal access tokens".

See more

On September 15, 2022, we fixed a bug on GitHub.com that allowed OAuth tokens (such as personal access tokens) to bypass SAML single sign-on (SSO) requirements to view organization issue data using the /issues GitHub API endpoint.

The SAML SSO bypass could only happen when the token owner was a member of a SAML SSO protected organization, had the necessary permissions to view the issue data, and was using an OAuth token that was not authorized for use with SAML SSO. Integrations using an OAuth token matching the above criteria would also bypass SAML SSO requirements when making requests to the /issues API endpoint.

The accessible data included the title, body, labels, and assignee of the issue, but did not include comments on the issue itself. The bug did not allow organization members to view repository, issue, or other organization data that they did not have permission to view.

See more

Starting today, two-factor authentication (2FA) will be enforced for maintainers of all high-impact npm packages. A package is marked as a high impact package when they have more than 1 million weekly downloads or have more than 500 dependents. Maintainers of such packages will be notified 15 days in advance to enroll for 2FA.

To learn more about configuring 2FA, see Configuring two-factor authentication.
To learn more about 2FA in general, see About two-factor authentication.
For questions and comments, open a discussion in our feedback repository.

See more

CodeQL comes with a built-in package manager that helps you share and manage custom queries. Last year, we announced the public beta of CodeQL packaging — including direct integration into GitHub code scanning. This makes it easier to roll out custom queries to your repositories and gives you full control over exactly which queries are run.

This functionality will soon be released for users of GitHub Enterprise Server (GHES): it will be available with GHES 3.7. This release also includes support for using packs that are published to GitHub Container Registries (GHCR) hosted on GHES.

How do I use CodeQL query packs in code scanning?

To use CodeQL query packs in code scanning, specify a with: packs: entry in the uses: github/codeql-action/init@v2 section of your code scanning workflow. By default code scanning downloads packs the from GHCR on GitHub.com, so if you want to run one of the standard CodeQL query packs or any other public CodeQL query pack, then simply include the pack scope/name and version requirements here. You can find the full documentation here.

If you want to run packs from the GHCR on GHES, then you need to tell code scanning how to access and authenticate to the appropriate registry. For an example of how to do this in your code scanning workflow, see Downloading CodeQL packs from GitHub Enterprise Server in the GitHub documentation.

How do I publish my own CodeQL packs?

You can publish you own CodeQL packs using the CodeQL CLI. By default, the CodeQL CLI publishes packs to the GHCR on GitHub.com. If you want to publish packs to the GHCR associated with your instance of GHES, you need to tell the CodeQL CLI how to access and authenticate to the registry you want to work with. For a full example of how to specify these details, see Working with CodeQL packs on GitHub Enterprise Server in the CodeQL CLI documentation.

Where can I find more information about CodeQL packaging and code scanning?

This changelog post only provides a brief summary of how you can use CodeQL packs in code scanning. For more information, see:

See more

You can now retrieve all your Dependabot alerts at the GitHub enterprise level via the REST API. This new API endpoint supplements the recently introduced Dependabot alerts REST API, Dependabot alerts org-level REST API, and Dependabot alerts webhook.

For more information, see Dependabot alerts in the REST API reference or learn more about Dependabot alerts in our documentation.

See more

Customers can now deterministically restrict their workflows to run on a specific set of runners using the names of their runner groups in the runs-on key of their workflow YAML. This prevents the unintended case where your job runs on a runner outside your intended group because the unintended runner shared the same labels as the runners in your intended runner group.
Example of the new syntax to ensure a runner is targeted from your intended runner group:

runs-on:
  group: my-group
  labels: [ self-hosted, label-1 ]

In addition to the workflow file syntax changes, there are also new validation checks for runner groups at the organization level. Organizations will no longer be able to create runner groups using a name that already exists at the enterprise level. A warning banner will display for any existing duplicate runner groups at the organization level. There's no restriction on the creation of runner groups at the enterprise level.
This feature change applies to enterprise plan customers as only enterprise plan customers are able to create runner groups.

See more

GitHub Actions workflows often specify the version of an action using the commit SHA. Since commit SHAs are immutable, this ensures that Actions always picks the same version. Commit SHAs, however, are not very human friendly, so best practice is to include the semver version in a comment next to the SHA. Dependabot will now update the semver version in comments when updating Actions workflows with a commit SHA version.

Dependabot is open source, and we're thankful to first-time contributor @jproberts for this great addition!

Learn more about Dependabot

See more

GitHub Enterprise Cloud customers that use Enterprise Managed Users (EMUs) can now participate in a private beta for a new user role that has restricted visibility of internal repositories. This role helps companies to work with contractors and collaborators in a flexible and managed fashion on specific projects, while also sharing code and ideas without restrictions amongst employees.

Users are granted this new role by being marked as "Restricted Users" in your identity provider. Enterprise members granted this role can be added to Organizations as members, and added to Organization teams – but they won't be able to see internal repositories in other Organizations unless explicitly added to those repositories one-by-one.

If you would like to enroll your EMU enterprise in this private beta, please reach out to your account team or contact our sales team for more details.

See more

Removing the security vulnerability banner

The yellow banner stating "We found potential security vulnerabilities in your dependencies" is being removed. Please use the "Security" alert count in your repository navigation as an indicator for when your repository has Dependabot alerts. You can also adjust your notifications settings to opt-in to email and web notifications, as well as email digests for your Dependabot alerts.

About this change

We've been working to steadily improve our security alert notifications and indicators. As part of our notifications strategy, we are removing this legacy banner.

Available alert notifications and indicators

Today, when Dependabot detects a dependency-based vulnerability, Dependabot lets you know based on your user notifications settings and repository watching settings. You can opt to receive:

  • Web-based notifications on alerts in your GitHub inbox
  • Email based notifications on alerts
  • Email digests (weekly or daily roll-ups of alerts).

From the UI, you can also use the "Security" alert count in your repository navigation as an indicator for when your repository has alerts. This Security tab includes the count for all active Dependabot alerts, code scanning alerts, secret scanning alerts, and any security advisories that you have permissions to view.

Learn more about GitHub Advanced Security, Dependabot alerts, and configuring notifications for alerts.

See more

GitHub Enterprise Cloud customers can now participate in a private beta displaying SAML single sign-on (SSO) identities for relevant users in audit log events.

SAML SSO gives organization and enterprise owners a way to control and secure access to resources like repositories, issues, and pull requests. Organization owners can invite GitHub users to join an organization backed by SAML SSO, allowing users to become members of the organization while retaining their existing identity and contributions on GitHub.

With the addition of SAML SSO identities in the audit log, organization and enterprise owners can easily link audit log activity with the user's corporate identity, used to SSO into GitHub.com. This not only provides increased visibility into the identity of the user, but also enables logs from multiple systems to quickly and easily be linked using a common SAML identity.

Enterprise owners interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. Once enabled, enterprise and organization owners can provide feedback at the logging SAML SSO authentication data for enterprise and org audit log events community discussion page.

See more

a photo of a devcontainer.json with openFiles, postAttachCommand, and onAutoForward defined

A development container allows you to create a full-featured development environment to use in your codespace. Codespaces use the devcontainer.json file to define the environment you will be working in within your codespace. We've added new features to devcontainers.json to help you customize the initial experience when you open a codespace.

Define the initial layout of your codespace with openFiles

You can use openFiles to define what files are open by default. If you specify multiple files, the files will open up in order from left to right. The first file defined will be the focused file. openFiles is specific to the Codespaces customization, and is only enabled in the Codespaces web editor for now. Use openFiles to improve your default development environment and ensure that you're setting contributors up for success!

Run scripts after your client connects to your codespace with postAttachCommand

postAttachCommand enables you to run scripts in the terminal after your client connects to the codespace. This change enables you to define multiple postAttachCommand definitions and they will run on separate terminals. This enables you to start your server and watch for changing files after launch from your devcontainer.json.

Combine these features into a full initial codespace experience

These changes to postAttachCommand, combined with the existing openPreview option in the onAutoForward property, enable you to create codespaces with a default layout that ensures a great Codespaces launch experience for users of your repository.

Read more about postAttachCommand, onAutoForward, openFiles, and openPreview on our docs pages!

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Chief Tools to scan for their tokens and help secure our mutual users on public repositories. Chief Tools tokens allow users to access the Chief Tools API and perform automated actions on behalf of the user that created the token. GitHub will forward access tokens found in public repositories to Chief Tools, who will immediately revoke the token and email the owner of the leaked token with instructions on next what to do next. You can read more information about Chief Tools tokens here.

GitHub Advanced Security customers can also scan for Chief Tools tokens and block them from entering their private and public repositories with push protection.

See more

We have streamlined our account recovery flow to help us verify your identity in the instance you lose access to your two-factor authentication (2FA) device and get locked out of your npm account.

If you lose access to your 2FA device and your recovery codes, you can now sign in to your npm account using your username and password and then request an account recovery. You will be asked to fill the form as shown below. We recommend you provide as much information as possible when requesting an account recovery.

recover_accounts

Read more about how you can recover your 2FA enabled accounts here.

For accounts with 2FA, linking your GitHub account and Twitter account in your profile settings will help verify your identity quicker.

Note: The new account recovery flow tries to gather and map information about your identity such that our support team can address your request sooner. Since there is a manual review in place, this recovery process will take few days to complete. We recommend our users generate and keep a copy of their recovery code to be used as the primary recovery option and avoid getting locked out of your account for a prolonged period of time.

See more

CodeQL now officially supports customizing the build configuration for Go analysis in the Actions workflow file. This aligns the Go configuration experience with the C/C++, C#, and Java analysis. The new customization options allow for more flexibility, for example when the build fails, or if analysis is desired on different source files.

All your existing CodeQL workflows for Go analysis will continue to work and continue to be supported. You don’t need to take any action to keep Go analysis running.

Example Actions workflow steps using Go build customization

steps:
  - name: Checkout repository
    uses: actions/checkout@v3

  - name: Initialize CodeQL
    uses: github/codeql-action/init@v2
    with:
      languages: go

  - name: Build code
    run:
      # You can modify these commands or add new commands to customize the build process
      make bootstrap
      make release

  - name: Perform CodeQL Analysis
    uses: github/codeql-action/analyze@v2

Learn more about CodeQL and code scanning.

See more