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

When analyzing a Python project with code scanning using CodeQL through advanced setup, we would try to automatically install dependencies for the project. Over the past months and years, we’ve made significant improvements to the Python analysis, which means CodeQL no longer needs to fetch these dependencies in order to analyze a codebase.

Therefore, starting now, we have disabled automatic dependency installation for new users of CodeQL for Python. This should improve scan times for Python projects, while having minimal impact on results. Code scanning users that have already set up CodeQL to scan at least one Python project will not see any changes to newly configured repos: the new behaviour only applies to those with no prior Python projects set up. We encourage existing users that configured code scanning with CodeQL via advanced setup to disable dependency installation by setting setup-python-dependencies: false as described in documentation.

Users of GitHub Enterprise Server (GHES) will benefit from this change starting version 3.11. We plan to deprecate all dependency installation (including for existing users) by the end of 2023.

See more

npm will now check the linked source commit and repository when you view a package's provenance information on npmjs.com. If the linked source commit or repository cannot be found, an error displays at the top of the page and alongside the provenance information to let you know that provenance for this package can no longer be established. This can happen when a repository is deleted or made private.

Note: In future releases, publishing a public package with provenance from a private source repository will not be allowed.

Read more about viewing npm provenance and publishing with provenance.

See more

Today we are making further improvements to granular access tokens in npm.

Highlights of this update are

  • Custom Expiration Times: You can now create granular access tokens with custom expiration times, allowing for durations that span multiple years.
  • Increased Token Limit: We have expanded the maximum limit for granular access tokens creation to 1000. This enables maintainers with a large amount of packages to secure their publishing workflows more efficiently.

We recommend using granular access tokens with least privileges (for example one token per package) for automating your publishing and org management activities.

Read more about creating a granular access tokens here.

See more

The 2023 updates to our ISO/IEC 27001:2013 certificate can be downloaded now. In addition, we have completed the processes for ISO/IEC 27701:2019 (PII Processor), ISO/IEC 27018:2019, and CSA STAR certifications. Those certificates can also 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 > Compliance settings tab of their organization: https://github.com/organizations/"your-org"/settings/compliance.

For detailed guidance on accessing these reports, read our compliance documentation for organizations and enterprises.

Check out the GitHub blog for more information.

See more

After we released Swift in beta on the 1st June, we are now adding support for long awaited Swift 5.8.1 and Xcode 14.3.1. This release also brings better support for Swift 5.x on Linux, which now supports versions up to and including 5.8.1.

Swift 5.8.1 support is available starting with CodeQL version 2.13.5. Code scanning users on GitHub.com will automatically benefit from the latest CodeQL version, while those on GitHub Enterprise Server can update using these guidelines. Security researchers can set up the CodeQL CLI and VS Code extension by following these instructions.

While our Swift analysis support remains in public beta we welcome your input. If you have any feedback or questions about the Swift beta, consider joining our community in the #codeql-swift-beta channel in the GitHub Security Lab Slack.

See more

During two-factor authentication and when entering sudo mode for sensitive actions on GitHub.com, TOTP codes could be successfully used multiple times within their validity window. To improve security, this reuse is no longer allowed on GitHub.com, and will be updated in GHES with version 3.10.

Systems that have attempted to script the login flow, across multiple parallel jobs, may break as a result of this change.

Learn more about two-factor authentication with TOTP.

See more

The latest release of CodeQL for VS Code includes new functionality for creating lists of target repositories for multi-repository variant analysis with GitHub code search.

Multi-repository variant analysis (MRVA) allows 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. Curated lists of up to 1,000 widely-used public GitHub repositories are included with MRVA to help you get started quickly – you can even trigger an MRVA run against up to 1,000 repositories in a single GitHub organization.

However, if you’d prefer to target different repositories, you can also create your own custom lists. To help make it easier to identify the most relevant repositories to include in your custom lists we have just released a new integration with the GitHub search API in the CodeQL extension. With this new feature, you can restrict the repositories appearing in your custom lists by the contents of source files, file paths, file location, or any other supported search qualifier.

For more information about how to use GitHub code search with MRVA, see Using GitHub code search to add repositories to a custom list in the CodeQL for VS Code documentation.

See more

You can now easily find all alerts associated with a specific language with the new language filter on the code scanning alerts page.

To show all the code scanning alerts for a language, type 'language:javascript' in the Filter alerts text box.

Language filter

You can also use a file path filter to see all the alerts located in specific files or directories to sort and manage them efficiently by focusing on a specific part of the code related to the project.
This can be useful to manage lots of alerts on big repositories (monorepos) to review all alerts specific to the part of the code you are responsible for faster.

To apply the file path filter, type 'path:' and the path to the file or directory in the Filter alerts text box.

Path filter

This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.10.

Learn more about filtering code scanning alerts.

See more

We've shipped a small fix to improve security around creation of pull requests in public repos.

Prior to this fix and under very specific conditions, a user could create a pull request in a public repo even though they did not have push access to either the base or head branch and were not a member of the repo's organization. Often these pull requests were created by mistake and quickly closed, but could still trigger unexpected GitHub Actions or other CI jobs.

This fix has no impact on the common open source workflow where a user forks a public repo, makes a change in their fork, and then proposes their change using a pull request. This fix also has no impact on pull requests already created.

We want to hear from you! Let us know if you have questions or feedback.

See more

All eligible GitHub Enterprise accounts can now try GitHub Advanced Security for free for 14 days. GitHub Advanced Security provides integrated security with unparalleled access to curated security intelligence. This unlocks your ability to keep your code, supply chain, and secrets secure before pushing the code to production. During the trial, you can try features such as:

  • Code scanning to help find and remediate security issues in your code
  • Secret scanning to prevent and detect secret exposures across your organization
  • Dependency review to catch vulnerable dependencies before introducing them to your environment

Explore our documentation to learn more about GitHub Advanced Security features and how to deploy them in your organization.
GitHub Advanced Security on Enterprise Cloud

See more

Today, we're extending CodeQL code scanning support to Swift! Developers working on Swift libraries and apps on Apple platforms can now benefit from our best-in-class code security analysis. We currently identify issues such as path injection, unsafe web view fetches, numerous cryptographic misuses and other types of unsafe evaluation or processing of unsanitized user-controlled data. During this beta, we’ll gradually increase our coverage of distinct weaknesses.

Swift joins our existing supported languages (C/C++, Java/Kotlin, JS/TS, Python, Ruby, C#, and Go), which in sum run nearly 400 checks on your code, all while keeping false positive rates low and precision high.

Set up code scanning on your Swift repositories today and receive actionable security alerts right on your pull requests. Read more about our supported Swift versions and platforms here.

Swift support is available starting with CodeQL version 2.13.3. GitHub.com users are automatically updated, while GitHub Enterprise Server users can update using these guidelines. Security researchers can set up the CodeQL CLI and VS Code extension by following these instructions.

This is just the start for Swift support in GitHub Advanced Security, keep an eye on the main GitHub blog for further announcements. If you have any feedback or questions about the Swift beta, consider joining our community in the #codeql-swift-beta channel in the GitHub Security Lab Slack. Thanks to all Swift community members who have participated in the private beta.

See more

Secret scanning's push protection feature is now generally available for all free public repositories on GitHub.com.

You can enable push protection for any public repository on GitHub.com from your repository's "Code security and analysis" settings in the UI or REST API. If you're an organization or enterprise owner, you can also also bulk-enable secret scanning.

For your repositories that are not a part of an organization, you can bulk-enable secret scanning and push protection in your personal "Code security and analysis" settings.

See more

Secret scanning's push protection feature is now generally available for GitHub Advanced Security customers.

Customers can enable push protection for any private repository that has GitHub Advanced Security. Push protection can also be enabled for any public repository, for free. To bulk enable push protection, customers can visit their organization and enterprise's "Code security and analysis" settings in the UI or REST APIs.

Push protection is also available for any custom pattern defined at the repository, organization, and enterprise level. See step 11 under "Defining a custom pattern for a repository" for more details in our documentation.

See more

Starting today, Dependabot will be able to auto-dismiss npm alerts that have limited impact (e.g. long-running tests) or are unlikely to be exploitable. With this ship, Dependabot will cut false positives and reduce alert fatigue substantially.

On-by-default for public repositories, and opt-in for private repositories, this feature will result in 15% of low impact npm alerts being auto-dismissed moving forward – so you can focus on the alerts that matter, without worrying about the ones that don’t.

What’s changing?

When the feature is enabled, Dependabot will auto-dismiss certain types of vulnerabilities that are found in npm dependencies used in development (npm devDependency alerts with scope:development). This feature will help you proactively filter out false positives on development-scoped (non-production or runtime) alerts without compromising on high risk devDependency alerts.

Dependabot alerts auto-dismissal list view

Frequently asked questions

Why is GitHub making this change?

At GitHub, we’ve been thinking deeply about how to responsibly address long-running issues around alert fatigue and false positives. Rather than over-indexing on one criterion like reachability or dependency scope, we believe that a responsibly-designed solution should be able to detect and reason on a rich set of complex, contextual alert metadata.

That’s why, moving forward, we’re releasing a series of ships powered by an underlying, all-new, flexible and powerful alert rules engine. Today’s ship, our first application, leverages GitHub-curated vulnerability patterns to help proactively filter out false positive alerts.

Why auto-dismissal, rather than purely suppressing these alerts?

Auto-dismissing ensures any ignored alerts are 1) able to be reintroduced if alert metadata changes, 2) caught by existing reporting systems and workflows, and 3) extensible as a whole to future rules-based actions, where Dependabot can decision on subsets of alerts and do things like reopen for patch, open a Dependabot pull request, or even auto-merge if very risky.

How does GitHub identify and detect low impact alerts?

Auto-dismissed alerts match GitHub-curated vulnerability patterns. These patterns take into account contextual information about how you’re using the dependency and the level of risk they may pose to your repository. To learn more, see our documentation on covered classes of vulnerabilities.

How will this activity be reported?

Auto-dismissal activity is supported across webhooks, REST, GraphQL, and the audit log for Dependabot alerts. In addition, you can review your closed alert list with the resolution:auto-dismissed filter.

How will this experience look and feel?

Alerts identified as false positives will be automatically dismissed without a notification or new pull request, and appear as special timeline event. As these alerts are closed, you’ll still be able to review any auto-dismissed alerts with the resolution:auto-dismissed filter.

How do I reopen an automatically dismissed alert?

Like any manually dismissed alert, you can reopen an auto-dismissed alert from the alert list view or details page. This specific alert won’t be auto-dismissed again.

What happens if alert metadata changes or advisory information is withdrawn?

Dependabot recognizes and immediately responds to any changes to metadata which void auto-dismissal logic. For example, if you change the dependency scope and the alert no longer meets the criteria to be auto-dismissed, the alert will automatically reopen.

How can I enable or disable the feature?

This feature is on-by-default for public repositories and opt-in for private repositories. Repository admins can opt in or out from your Dependabot alerts settings in the Code Security page.

Is this feature available for enterprise?

Yes! In addition to all free repositories, this feature will ship immediately to GHEC and to GHES in version 3.10.

What’s next?

Next, we’ll expose our underlying engine – which enables Dependabot to perform actions based on a rich set of contextual alert metadata – so you can write your own custom rules to better manage your alerts, too.

How do I learn more?

How do I provide feedback?

Let us know what you think by providing feedback — we’re listening!

See more