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

GitHub's Advisory Database now supports listing malware advisories. You can see them by searching "type:malware" on https://github.com/advisories.

If you have enabled Dependabot alerts on your repositories, GitHub will send Dependabot alerts for malware automatically. Note that Dependabot does not send update pull requests for malware as the only resolution is to delete the package and find an alternative.

See more

In February 2022, we launched a new feature called community contributions to security advisories.

We have made a handful of changes to the UX based on your feedback:

  • Fixed the breadcrumb on unreviewed advisories to more clearly display they are unreviewed.
  • Hid the link to submit a community contribution when it is not possible due to OSV constraints.
  • Added an information icon clarifying that not all ecosystems are supported.
  • Updated the auto-generated PR title to the format "[GHSA-####-####-####] Advisory Name" to be clearer on which advisory its for.
  • Fixed a bug that was adding unnecessary noise to the PR diff.
  • Added function to auto-post an affirming comment when a contribution is accepted.
  • Learn more about the GitHub Advisory Database
  • Learn more about GitHub community contributions
See more

You can now enable debug logging when you re-run jobs in a GitHub Actions workflow run. This gives you additional information about the job's execution and its environment which can help you diagnose failures.

To enable debug logging, select "Enable debug logging" in the re-run dialog.

Re-run dialog screenshot

You can also enable debug logging using the API or the command-line client.

For more details see
Re-running workflows and jobs.

For questions, visit the GitHub Actions community.

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

See more

Device verification protects new sessions if you don’t have two-factor authentication enabled, using an email notification. We’ve updated this feature to allow you to verify your sign in using GitHub Mobile. Device verification will by default use GitHub Mobile notifications. However, you can still request an email notification if your phone is unavailable.

For more information, read about “Authenticating in your browser.”

See more

Our newly available ISO/IEC 27001:2013 Certification report can be downloaded now.

  • For enterprises, administrators may download this report by navigating to the Compliance tab of the enterprise account: https://github.com/enterprises/"your-enterprise"/settings/compliance.
  • For organizations, owners may find these reports under 'Security' > Authentication Security settings tab of their organization: https://github.com/organizations/"your-org"/settings/security.
  • For everyone else, you may download this report at any time by navigating to the GitHub security page, https://github.com/security.

To learn more about this new report, check out our blog post.

See more

A variety of improvements to the npm 2FA experience are now in public beta, including:

  • Support for registering multiple second factors, such as security keys, biometric devices, and authentication applications
  • A new 2FA configuration menu to manage keys and recovery codes
  • Full CLI support for login and publish capabilities with physical security keys and biometric devices in npm 6 and higher
  • Ability to view and regenerate recovery codes

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

To further reduce the risk of a user using Actions to merge a change into a protected branch that was not reviewed by another person, the organization setting to disallow Actions from approving pull requests, which was introduced in January 2022, has been extended to also limit Actions from creating pull requests.

The Allow GitHub Actions to create and approve pull requests setting can be managed by admins in organization settings under Actions > General > Workflow permissions.

image

See more

Enterprise owners can now prevent organization owners from inviting outside collaborators to repositories in their enterprise. The "Repository outside collaborators" policy includes an additional option, "Enterprise admins only", which restricts the ability to invite outside collaborators only to users with admin permissions to the enterprise. For more info, see "Enforcing a policy for inviting outside collaborators to repositories".

Shows the new option "Enterprise admins only" in the "Repository outside collaborators" policy

See more

From today the OAuth Device Authorization flow feature must be manually enabled for all OAuth and GitHub Apps. This change reduces the likelihood of Apps being used in phishing attacks against GitHub users by ensuring integrators are aware of the risks and make a conscious choice to support this form of authentication.

If you own or manage an OAuth App or GitHub App that makes use of the OAuth Device Authorization flow, you can enable it for your App 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 enabled this feature.

Learn more about the OAuth Device Authorization flow.

See more

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

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