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

On March 16 2022 the OAuth Device Authorization flow will become an "opt in" feature for all OAuth and GitHub Apps. This change reduces the likelihood of Apps being used in phishing attacks against GitHub users.

If you own or manage an OAuth App or GitHub App that makes use of the OAuth Device Authorization flow, you should enable it for your Apps via its settings page:

Enable device flow

The OAuth Device Authorization flow API endpoints will respond with status code 400 to Apps that have not opted in to this feature.

Learn more about the OAuth Device Authorization flow.

See more

GitHub code scanning supports a wide variety of code analysis engines through GitHub Actions workflows — including our own CodeQL engine. Users can now discover and configure Actions workflow templates for partner integrations straight from their repository's "Actions" tab under a category called "Security". Workflows are recommended based on the repository's content: we will suggest analysis engines that are compatible with the source code in your repository.

Configure workflow

Code scanning and our own CodeQL analysis engine are freely available for public repositories. Analysis engines and services provided by partners might require a subscription. You can also configure code scanning for organization-owned private repositories where GitHub Advanced Security is enabled.

Learn more about code scanning workflows on GitHub Actions tab.

See more

You can now reference local reusable workflows more easily. With this release, reusable workflows that are in the same repository as the calling repository can be referenced with just the path and filename: {path}/{filename}.

For example:

jobs:
  call-workflow-in-local-repo:
    uses: ./.github/workflows/workflow-2.yml

When referenced this way, the called workflow will be from the same commit as the caller workflow.

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

We have introduced a new policy setting that controls whether GitHub Actions can approve pull requests. This protects against a user using Actions to satisfy the "Required approvals" branch protection requirement and merging a change that was not reviewed by another user.

To prevent breaking existing workflows Allow GitHub Actions reviews to count towards required approval is enabled by default. However, an organization admin can disable it under the organization's Actions settings.

image

See more

Starting 12-09-2021, GitHub Actions workflows triggered by Dependabot for the create, deployment, and deployment_status events will always receive a read-only token and no secrets.

Starting 12-09-2021, GitHub Actions workflows triggered by Dependabot for the pull_request_target event on pull requests where the base ref was created by Dependabot will always receive a read-only token and no secrets.

Both changes are designed to prevent potentially malicious code from executing in a privileged workflow.

Learn more about using Actions and Dependabot together

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

We have added support for sigstore container signing to the default GitHub Actions starter workflow for publishing container images. New workflows on public repositories will use this by default. If you have an existing workflow, you will need to update your workflow to take advantage of this capability.

For more information, please read the announcement on the GitHub Blog.

See more

GitHub Actions workflows triggered by Dependabot will now be sent the Dependabot secrets.

This change will enable you to pull from private package registries in your CI using the same secrets you have configured for Dependabot to use and will improve how Actions and Dependabot work together.

Learn more about using Actions and Dependabot together

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

GitHub recently introduced the ability to set an expiration date when creating or regenerating a personal access token (PAT). For a PAT that is authorized to access an organization protected by SAML single sign-on (SSO), the expiration date of that PAT is now available via the GET /orgs/{org}/credential-authorizations API.

Organization administrators can use the following gh command to see the expiration dates of all PATs that are authorized to access their org by authenticating with a PAT that has the read:org scope:

gh api --paginate /orgs/:org/credential-authorizations --jq='.[] | [.authorized_credential_expires_at]'

Learn more about authorizing a personal access token for use with SAML single sign-on.

See more

Managing self-hosted runners within an enterprise no longer requires personal access tokens with the admin:enterprise scope. Tighten down the permissions on your token by using the manage_runners:enterprise scope instead. A token with this scope can be used to authenticate to use many endpoints to manage your enterprise's self-hosted runners.

Learn more about self-hosted runners for your Actions workflows.

See more

In March we made a change in GitHub Actions that forced workflows triggered by Dependabot to run with a read-only token. This change was made to protect your repositories from potentially malicious dependencies in the same way we prevent pull requests from forks from having privileged access to your repository. We received a lot of feedback from you on how this impacted your workflows and while it was great to be in a safe configuration by default, you wanted to have the option to continue working as you had prior to this change.

In April we introduced the permissions key in the Actions workflow config which enables you to control which permissions are given to a particular workflow or job.

Starting October 11, 2021 workflow runs on push and pull_request events triggered by Dependabot will begin to respect the permissions specified in your workflows putting you back in control of how you manage automatic dependency updates. The default token permissions will remain read-only.

In addition to the permissions change we are working to enable workflows triggered by Dependabot to use Dependabot secrets. This change will enable you to use those secrets to pull dependencies from private repositories.

Learn more about the permissions key in Actions workflows

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

Recover Accounts Elsewhere allows a user to store a recovery token with a third-party recovery partner to use as a recovery method when their account is protected by two-factor authentication. Effective immediately, we will no longer be allowing new recovery tokens to be stored using Recover Accounts Elsewhere.

On December 1st, 2021, account recovery tokens stored using Recover Accounts Elsewhere will no longer be accepted as a recovery option when contacting support to recover access to your account. You will still be able to use our other recovery mechanisms to recover your account.

If you have registered an account recovery token using this feature, we recommend you take this opportunity to download your two-factor recovery codes. You can also revoke your recovery tokens using these steps:

  1. Navigate to the Account Security page.
  2. Scroll down to "Recovery tokens" and client "Edit".
  3. Click "Revoke token" for each token.

We'll be sending occasional email notifications throughout the deprecation period to all users with recovery tokens registered.

Questions? Take a look at our updated documentation on account recovery, or contact GitHub Support.

See more

Maintainers now have additional control over when they must approve Actions runs for new contributors.

preview

In April, we shipped an update for GitHub Actions that required maintainers to approve Actions runs for first-time contributors in their repositories. Based on your feedback we have added additional settings to give you more control over this behavior.

Learn more about approving first time contributor pull requests

See more

GitHub Actions now lets you control the permissions granted to the GITHUB_TOKEN secret.

The GITHUB_TOKEN is an automatically generated secret that lets you make authenticated calls to the GitHub API in your workflow runs. Actions generates a new token for each job and expires the token when a job completes. The token has write permissions to a number of API endpoints except in the case of pull requests from forks which are always read. These new settings allow you to follow a principle of least privilege in your workflows.

Setting permissions in the workflow

A new permissions key supported at the workflow and job level enables you to specify which permissions you want for the token. Any permission that is absent from the list will be set to none.

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  issues: read|write|none
  packages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

Pull requests from public forks are still considered a special case and will receive a read token regardless of these settings.

Setting the default permissions for the organization or repository

A new admin setting lets you set the default permissions for the token in your organization or repository.

You can choose between two options:

  • Read/write for all scopes (current default)
  • Read repo contents

Setting the default to contents:read is sufficient for any workflows that simply need to clone and build. If you need additional permissions you will need to specify those in your workflow yaml.

image

Learn more about setting the token permissions

For questions, visit the GitHub Actions community

To see what’s next for Actions, visit our public roadmap

See more

To prevent unexpected changes from potentially slipping in after auto-merge is enabled on a pull request, auto-merge is now disabled automatically when new changes are pushed by a user without write access to the repository.

Note: users without write access can still update their pull requests to bring in changes from the base branch without having auto-merge disabled, but auto-merge will be disabled if the update results in merge conflicts that have to be resolved. This is to prevent merge-conflicts being deliberately used as a way to introduce code that hasn't been fully reviewed by the people with write access to the project.

Learn more about automatically merging pull requests when all merge requirements have been met.

See more

Starting March 1st, 2021 workflow runs that are triggered by Dependabot from push, pull_request, pull_request_review, or pull_request_review_comment events will be treated as if they were opened from a repository fork. This means they will receive a read-only GITHUB_TOKEN and will not have access to any secrets available in the repository. This will cause any workflows that attempt to write to the repository to fail.

This change will affect all repositories, both public and private, regardless of how they are configured, and is being made to prevent potentially compromised dependencies from capturing secrets referenced in your workflows.

If your workflow needs to have a write token or access to secrets, you can use the pull_request_target event; however, please read
Keeping your GitHub Actions and workflows secure: Preventing pwn requests
to better understand the risks.

For questions, visit the GitHub Actions community

To see what’s next for Actions, visit our public roadmap

See more