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

Removed unencrypted Git protocol and certain SSH keys

GitHub changed which keys are supported in SSH and removed the unencrypted Git protocol.
You can read more about the motivation behind these changes in our blog post from last September.
As a reminder, these changes were:

  • Removed all support for DSA keys
  • Required SHA-2 signatures on all RSA keys uploaded after November 2, 2021 (RSA keys uploaded prior to the cutoff may still use SHA-1 signatures)
  • Removed legacy SSH algorithms HMAC-SHA-1 and CBC ciphers
  • Permanently disabled the unencrypted Git protocol
See more

Opt in needed to keep OAuth Device Authorization Flow working

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

Discover code scanning partner integrations on the GitHub Actions tab

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

GitHub Actions: Reusable workflows can be referenced locally

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

GitHub Actions: Prevent GitHub Actions from approving pull requests

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

GitHub Actions: Changes to permissions in workflows triggered by Dependabot

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

Container signing added to the Publish Docker Container workflow for GitHub Actions

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 receive dependabot secrets

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

Expiration dates of SAML-authorized PATs available via API

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

GitHub Actions: Granular personal access token scopes for self-hosted runners in enterprises

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

GitHub Actions: Workflows triggered by Dependabot PRs will respect permissions key in workflows

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

Deprecation Notice: Recover Accounts Elsewhere

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
View more changes