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

Delete stale code scanning configurations to close outdated alerts

Code scanning configurations can now be deleted from the code scanning alert page. This could be used to delete stale configurations causing alerts to remain open, or delete old configurations which are no longer used.

Code scanning can be configured to use different tools, target different languages, or even analyze different parts of the codebase in the same repository. In certain circumstances more than one of these configurations may produce the same alert. However, if one of the configurations is no longer used and becomes 'stale' you may find that the alert is fixed in one configuration but not in the stale configuration, which is potentially confusing. Today we are releasing a new feature that allows you to easily delete stale configurations which cause alerts to remain open after they've been fixed.

In the code scanning alert page, the counter in the 'Affected branches' sidebar shows the number of configurations for the branch. Click a branch to view the configuration details, and delete configurations as required. A configuration is deleted for a branch, so may have an impact on the status of other alerts on the same branch. When a configuration is deleted, a timeline entry is recorded on the alert, and repositories in an organization also record an audit log entry. If a configuration is deleted by mistake, re-run the analysis to update the alert and reinstate the configuration.

Delete code scanning configurations

Read more about removing stale code scanning configurations and alerts.

See more

Use multi-repository variant analysis (beta) to run CodeQL queries at scale

Today we have released multi-repository variant analysis for CodeQL in public beta to help the OSS security community power up their research with CodeQL.

CodeQL is the static code analysis engine that powers GitHub code scanning. Out of the box, CodeQL is able to find many different types of security vulnerability and flag them up in pull requests.

But one of CodeQL’s superpowers is its versatility and customizability: you can use it to find virtually any pattern in source code. As such, it’s a great tool for finding new types of vulnerabilities – once you’ve identified an interesting pattern, model it as a CodeQL query, and then run it against your repository to find all occurrences of that pattern! But most vulnerabilities are relevant to many codebases. Wouldn’t it be amazing if you could easily run your query against many repos at the same time? Well, now you can with multi-repository variant analysis — which we’ve just shipped in public beta!

Screenshot 2023-02-22 at 16 39 39

This new feature will allow security researchers to run CodeQL analyses against large numbers of repos, straight from the CodeQL extension for VS Code, making it possible to identify new types of security vulnerabilities in the most popular open-source codebases.

Checkout the CodeQL for VS Code documentation to get learn how to get started with multi-repository variant analysis. We'd also love to hear your feedback on this GitHub community discussion.

See more

Security advisories now have multiple types of credits

You can now designate different types of credits to users who contribute to GitHub security advisories.

These new credit types mirror those in the CVE 5.0 schema:

  • finder
  • reporter
  • analyst
  • coordinator
  • remediation developer
  • remediation reviewer
  • remediation verifier
  • tool
  • sponsor
  • other

Going forward, GitHub will automatically apply the the reporter credit type to anyone credited after submitting a private vulnerability report and the analyst type to anyone credited after submitting an edit to the global Advisory Database. We've also retroactively applied those labels to previously credited individuals who took those actions.

Further reading:

See more

SMS and TOTP can now both be registered 2FA methods

You can now set up both SMS and an authenticator app (TOTP) for two-factor authentication on your GitHub.com account. Previously these methods were mutually exclusive, and you needed to create a "fallback" SMS registration that could be used for account recovery.

2FA settings page showing both authenticator app and SMS registered

With this update, we are removing the fallback SMS option, and will migrate all fallback SMS registrations to be standard 2FA methods today. A small set of users had both a primary and fallback SMS registration on their account – they continue to have that fallback SMS registration, and will receive email about it today.

To learn more about setting up 2FA and GitHub's account recovery methods, see "Configuring 2FA" and "Configuring 2fa recovery methods"

See more

Preferred 2FA methods and settings improvements

The Primary field on two-factor authentication methods has been removed, and replaced with a Preferred option. This new option sets your preferred 2FA method for account login and use of the sudo prompt. You can choose between TOTP, SMS, security keys, or GitHub Mobile as your preferred 2FA method.

Additionally, you can now update your 2FA methods inline at https://github.com/settings/security, rather than going through the initial 2FA setup flow again.

image

With this change, device-specific preferences for 2FA have been removed – each login will always default to your preferred method. If you previously set a default on one of your devices, your most recent choice has been copied to your account-wide preference. Otherwise, no preference will be set, and GitHub will select from your available second factors in this order: security keys, GitHub Mobile, TOTP, and then SMS.

To learn more, see "Changing your preferred two-factor authentication method" and "Configuring two-factor authentication".

See more

Unlink your email in case of 2FA lockout

You can now unlink your email address from a two-factor enabled GitHub account in case you’re unable to sign into it or recover it. When the worst occurs, and a user is unable to find an SSH key, PAT, or a device that’s been previously signed into GitHub in order to recover their account, they may want to start fresh with a new GitHub.com account. Since accounts on GitHub are required to each have a unique email address, though, locked out users can have difficulty starting a new account using their preferred email address.

In the 2FA recovery flow, a new option is presented at the bottom of the page, which will allow a user to remove their email address from a GitHub account:

image

Selecting this option will send emails to each of the addresses on file for the account, each one containing a unique link. Following the link will remove the respective email address from the GitHub account, making it available again for a new account.

For more information, see Unlinking your email from a locked account.

See more

CodeQL code scanning is now 16% faster

CodeQL is the engine that powers GitHub code scanning, used by more than 100,000 repositories to catch security vulnerabilities before they cause issues in deployments.

CodeQL is fully integrated into the Pull Request workflow, so it has to be as fast as possible to keep developers unblocked.

We're constantly working on performance improvements, from incremental optimizations to fundamental research, all with the goal of speeding up the nearly 150,000 checks we run every single day, without compromising our best-in-class precision and low false-positive rate.

With the recent release of CodeQL version 2.12, we looked back at the performance gains compared to version 2.11 (September 2022) to see how far we've come. We compared the analysis time for the same 55,000 repositories on GitHub.com and found an average improvement of 15.7% across all supported languages:

codeql performance 2 11 2 12 improvement

Users on GitHub.com automatically run the latest CodeQL version. Customers on GitHub Enterprise Server can update by following the sync processes explained here.

See more

Code scanning can be set up not to fail a pull request check

Code scanning can now be set up to never cause a pull request check failure.

By default, any code scanning alerts with a security-severity of critical or high will cause a pull request check failure.
You can specify which security-severity level for code scanning results should cause the code scanning check to fail, including None, by going to the Code security and Analysis tab in the repository settings.

Screenshot code-scanning-settings

This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.9. Learn more about severity levels for security alerts and Code scanning results check failures on pull requests.

See more

Enable private vulnerabilty reporting organization-wide

Organization admins and security managers can now enable private vulnerability reporting for all public repositories within an organization at once.

With this enhancement, you no longer have to enable the feature for each repository individually.

Find this option under your organization's "Settings" tab under "Code security and analysis".

Private vulnerability reporting

See more

Second-factor validation after 2FA setup

GitHub.com users who set up two-factor authentication will see a prompt after 28 days, asking them to perform 2FA and confirm their second factor settings. This prompt helps avoid account lockout due to misconfigured authenticator applications (TOTP apps), especially those that failed to save the TOTP secret after validating it during set up.

This prompt appears in existing sessions if you haven't already performed 2FA as part of a sudo prompt or signing in on another device. If you find that you can't perform 2FA, you'll be presented with a shortcut that allows you to reset your 2FA setup.

image

All users that enable 2FA will be eligible for this prompt, including users required to enable it by their organization or GitHub itself.

To learn more about two-factor authentication, see "Configuring two-factor authentication".

See more

Fixed bug affecting npm package and organization maintainers

GitHub Security was recently notified about a caching issue affecting npm. This bug had been present since 2016 and sporadically caused npm maintainers to be re-invited upon removal from packages or organizations. Our Security team investigated potential instances of the issue and believe this bug only occurred if a user was removed, followed shortly by the addition of a different member. This bug affected npm-cli version 6 and above, and was fixed in version 7+.

Out of an abundance of caution, we are recommending all npm users review the maintainers of their projects and organizations for any discrepancies that may be a result of this bug and remove any unexpected members. Please feel free to reach out to us with any additional questions or concerns through the following contact form: https://www.npmjs.com/support.

See more

Explore the content of your npm packages with the new code explorer

You can now view the content of a package with the updated code explorer directly on the npmjs.com portal. We have improved the reliability, performance and have now made this feature available for free. You no more need to download a package to view its content. With this feature, you can easily scrutinise packages to make sure it is safe for use in your application. The code explorer provides syntax highlighting for .js, .ts, .md, .json and other commonly used file types in npm packages. You can also view the content of any previous version of a package.

Start by exploring the npm package.

See more

Limit scope of npm tokens with the new granular access tokens

You can now create access tokens with limited scope using the new granular access tokens functionality in npm. With granular access tokens, you can:

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

Tokens with least privileges protects your npm packages from accidental or malicious misuse of your token. These tokens also allow you to manage your npm org and teams from a CI/CD pipeline. Granular access tokens are specifically built for automation and do not require 2FA. We recommend using granular access tokens with least privileges while you automate publishing and org management activities.

See more

Incremental improvements on security advisory form

We've recently released a few minor user experience improvements for our GitHub Security Advisory form:

  • You're no longer required to fill out as many fields in the form before submitting it, so you can publish faster.
  • You now fill out title/description first in the form.
  • You can now access the CVSS Calculator as a top-level attribute, rather than it being the bottom of a dropdown menu.

Further reading:

See more
View more changes