security

Subscribe to all “security” 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

npm provenance public beta

npm packages built on a cloud CI/CD system (like GitHub Actions) can now publish with provenance, meaning the package has verifiable links back to its source code and build instructions.

The cloud CI/CD system securely communicates this information by sending provenance information in a signed OIDC JWT to Sigstore's public-good servers, which returns a signing certificate that is sent to the registry along with your built package.

Here's an example of how to do a build with provenance in a GitHub Actions workflow:

name: Publish Package to npmjs
on:
 release:
   types: [created]
jobs:
 build:
   runs-on: ubuntu-latest
   permissions:
     contents: read
     id-token: write
   steps:
     - uses: actions/checkout@v3
     - uses: actions/setup-node@v3
       with:
         node-version: '18.x'
         registry-url: 'https://registry.npmjs.org'
     - run: npm install -g npm
     - run: npm ci
     - run: npm publish --provenance --access public
       env:
         NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Once published, packages display provenance on the registry website:

Provenance displayed on the registry website

Dependencies with provenance can also be verified from the command line with npm audit signatures.

For more information, see generating provenance.

See more

Fixed bug that allowed a hovercard URL to be used to display the name, description, and star count of any repository

On March 30, 2023, we fixed a bug that allowed a dependency graph hovercard URL to be used to retrieve the name, description, and star count of any repository on GitHub.com. The bug was introduced on March 28, 2023 and our investigation has found no evidence of exploitation. To exploit the bug, a specific header needed to be set when making a request to the URL and the numeric ID of a repository provided. The URL would then return the HTML content designed to be used for a hovercard UI element with the repository name, description, and star count in the response.

This bug was reported to GitHub via the GitHub Bug Bounty program.

See more

Secret scanning now detects secrets leaked historically in issues

GitHub Advanced Security customers using secret scanning can now view any secrets exposed historically in an issue's title, description, or comments within the UI or the REST API. This expanded coverage will also detect and surface secrets matching any custom pattern defined at the repository, organization, or enterprise levels.

See more

Secret scanning now shows metadata for active GitHub tokens

Users with access to secret scanning alerts can now view metadata for any active GitHub token leaked in their repositories. Metadata includes details like the token's owner, expiration date, and access permissions. With this information, security teams can assess a leak's potential impact and prioritize remedial action accordingly.

This feature builds on our previous release in January, which introduced validity checks for leaked GitHub tokens.

github

See more

Secret scanning now shows metrics for custom patterns

GitHub Advanced Security users can now view alert metrics for custom patterns at the repository, organization, and enterprise levels directly from the custom pattern's page. Custom patterns with push protection enabled also show metrics like total secrets blocked and bypassed.

We welcome feedback in our code security discussion.

custom pattern metrics

See more

Repository security advisories REST API

You can now programmatically view and act on repository advisories via a new REST API. New endpoints to create, view, list, and update advisories are available to all. Additionally, new webhooks have been introduced that will alert maintainers when advisories are published or when a private vulnerability report is submitted.

Current advisory permissions extend to API usage.

See more

Organization APIs for fine-grained PATs management

Organization owners can now automate the approval and auditing of fine-grained personal access tokens (PATs) in their organization using a GitHub app. New APIs and webhook events allow a GitHub app to be notified of new PAT requests in an organization, review the request, and then approve or deny the PAT. They also provide a view of all approved fine-grained PATs for an organization, with the ability to revoke their authorization as well. These APIs and events are part of the ongoing fine-grained PAT public beta that launched last year.

Mermaid diagram indicating how a request from a user triggers a webhook event to an app, who can then review the request and choose to approve it. Later, the application can review all approved PATs, and choose to revoke one, resulting in an email notification to the user who created the PAT.

Details included in the webhook event and API listings include the repositories and permissions requested, the expiration time of the token, and the user's explanation for what they plan to do with the PAT. The personal_access_token_request events are generated when a request is created, approved or denied by an administrator or application, or cancelled by the requesting user.

Only a GitHub app is able to call these APIs, either acting on its own or on behalf of a signed-in organization administrator.
The organization_personal_access_tokens permission is needed to manage the active tokens, while the organization_personal_access_token_requests permission enables the app to recieve webhooks about requests and call the request management APIs.

Organizations must have the personal access token approval flow enabled in order to manage these requests, otherwise fine-grained personal access tokens are automatically approved for the organization (which generates a personal_access_token_request: approved event).

To learn more about these APIs, see "List requests to access organization resources with fine-grained PATs" and the "personal_access_token_request webhook event". To learn more about fine-grained PATs, and how to enable them for your organization, see "Setting a personal access token policy for your organization".

If you have feedback or bugs to report about fine-grained PATs, please let us know in the dedicated feedback discussion.

See more

Fixed bug that allowed private issues and pull request titles to be shown in search results

GitHub Security was notified about an issue where private issue and pull request titles would be displayed in search results. Our Security team investigated potential instances and determined that this only occurred when the author of the commit was authorized to view the issue or pull request and the commit was titled as a link to the private issue or pull request. Additionally, this only happened while using the new code search (beta). This issue was introduced when the new code search (beta) launched and was fixed on January 17, 2023. As this issue has been addressed, there is no further action that is required by any user.

See more

Code scanning API to enable default setup with CodeQL on a repository

Code scanning have shipped an API for repositories to programmatically enable code scanning default setup with CodeQL.

The API can be used to:

  • Onboard a repository to default setup: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=configured
  • Specify which CodeQL query suite to use in the default setup configuration: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f query_suite=extended
  • View the current default setup configuration for a repository: gh api /repos/[org]/[repo-name]/code-scanning/default-setup
  • Offboard a repository from default setup: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=not-configured

When you onboard a repository via the API, you will recieve a workflow run ID which can be used to monitor the setup progress. This can be used to see the status and conclusion of the run: gh api repos/[org-name]/[repo-name]/actions/runs/[run-id] --jq '.status, .conclusion'

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

For more information, see "Get the code scanning default setup configuration" and "Update the code scanning default setup configuration".

See more

General availability of granular access token on npm

Today we are making the granular access token feature on npm generally available.

Granular access token, allows you to:

  • Restrict token access to specific packages and/or scopes
  • Grant tokens access to specific organizations for org and user management
  • Set a token expiration date
  • Limit token access based on IP address ranges
  • Select between read and/or write access for the token

We recommend using granular access tokens with least privileges for automating your publishing and org management activities. You can allow your package to be published without 2FA using granular access tokens from your trusted CI/CD systems. Additionally, you can also configure your package to require 2FA when publishing from a local machine to defend against account hijacking.

Read more about creating a granular access token here.

See more

You can now use the “security extended” query suite in code scanning default setup with CodeQL

You can now enable the "security extended" query suite for repositories using code scanning default setup with CodeQL. This query suite can be selected during set up, or changed at any time by viewing and editing the CodeQL configuration.

Code scanning's default query suites have been carefully designed to ensure that they look for the security issues most relevant to developers, whilst also minimizing the occurrence of false positive results. However, if you and you developers are interested in seeing a wider range of alerts you can enable the security extended query suite. This suite includes the same queries as in the default query suite, plus:

  • extra queries with slightly lower severity and precision.
  • extra experimental queries.

If you enable the security extended suite you may see more CodeQL alerts in your repository and on pull requests. For more information, see "About code scanning alerts".

Code scanning default setup query suites

Code scanning default setup view configuration

Read more about code scanning default setup.

See more

SSH Certificate requirement update

The "Require SSH certificates" policy now allows GitHub apps to call Git APIs using a user-to-server token, bringing them up to parity with OAuth app support.

The SSH certificate requirement mandates that users in your organization call Git APIs using an SSH certificate issued by your organization, in place of their own SSH key or a PAT.
To support automation, it has an exception in place for OAuth apps and GitHub app server-to-server tokens, which allows applications you've approved to call Git APIs for your organization.
With this change, we are extending that exception to GitHub app user-to-server tokens, for when a user has signed into a GitHub app that's installed in your organization.

Screenshot of the SSH Certificate requirement checkbox

This change also applies when the enterprise-level setting requires SSH certificates across all organizations in the enterprise.

To learn more, see "Managing your organization's SSH certificate authorities" or "Managing SSH certificate authorities for your enterprise".

See more

Fixed bug that allowed removed users to retain access to the organization

GitHub Security was notified about an issue where users still had access to organizations after being removed. Our Security team investigated potential instances and determined there were occasional instances where users’ permissions were not fully removed when teams were deleted or they were part of a team when they were removed from the organization. While we investigated the root causes, which stemmed from background job and permissions issues, a manual fix has been implemented since October 20, 2022. We have addressed the underlying issues and the need for the previously implemented manual fix. We have also cleaned up any users that were not removed when they should have been. There is no further action that is required by any organization.

See more
View more changes