Skip to content

security-and-compliance

Subscribe to all “security-and-compliance” 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

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

GitHub secret scanning protects users by searching repositories for known types of tokens. By identifying and flagging these tokens, our scans help prevent data leaks and fraud.

We have partnered with Canadian Digital Service (CDS) to scan for their tokens and help secure our mutual users on public repositories. Canadian Digital Service tokens allow users to send email and text messages using the Government of Canada’s Notify service. GitHub will forward access tokens found in public repositories to CDS, which will then revoke the token and contact the impacted users to help them generate new tokens. You can read more information about CDS's tokens here.

All users can scan for and block CDS tokens from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block CDS tokens in their private repositories.

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with LogicMonitor to scan for their tokens and help secure our mutual users on public repositories. LogicMonitor tokens allow users to authenticate requests to LogicMonitor's REST API. GitHub will forward access tokens found in public repositories to LogicMonitor, which will then inform their portal contacts for remediation. You can read more information about LogicMonitor's tokens here.

All users can scan for and block LogicMonitor tokens from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block LogicMonitor tokens in their private repositories.

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Highnote to scan for their tokens and help secure our mutual users on public repositories. Highnote tokens allow users to authenticate with Highnote’s GraphQL API. GitHub will forward access tokens found in public repositories to Highnote, which will then revoke the token and work with impacted users to generate a new token. You can read more information about Highnote’s tokens here.

GitHub Advanced Security customers can also scan for Highnote tokens and block them from entering their private repositories. All users can enable push protection for public repositories, for free.

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Aiven to scan for their tokens and help secure our mutual users on public repositories. Aiven tokens allow users to interact with Aiven hosted services and the Aiven API. GitHub will forward access tokens found in public repositories to Aiven, and the Aiven Customer Success Team will contact project owners via the normal service channel and work with them to rotate and revoke the affected credentials. Aiven will not revoke credentials without prior communication and acknowledgement from the project owner. You can read more information about Aiven’s tokens here.

GitHub Advanced Security customers can also scan for Aiven tokens and block them from entering their private repositories. All users can enable push protection for public repositories, for free.

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

If you are an organization or enterprise owner, you will now receive a secret scanning summary email when the historical scan completes. The email notification will tell you how many, if any, secrets were detected across all repositories within your organization or enterprise. You'll also receive a link to your security overview page for each secret, where you can view details for each detected secret.

Previously, secret scanning would send one email per repository where secrets were detected, provided that you were watching the repository and had email notifications enabled in your user settings enabled. While repository administrators will still receive an email notification per repository, organization and enterprise owners will now receive only a single notification upon the historical scan's completion.

To receive notifications:

  • For the first historical scan after you enable secret scanning, you must have email notifications enabled in your user settings. You do not need to watch any repositories to receive the secret scanning summary email.
  • For future historical scans, such as for newly added patterns, you will receive an email notification for each repository where a secret was found. You must be watching the repository where the secret was detected and have email notifications enabled in your user settings.

summary email after backfill scan

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Doppler to scan for their tokens and help secure our mutual users on public repositories. Doppler tokens allow users to access and manage their secrets from their existing tooling and infrastructure. GitHub will forward access tokens found in public repositories to Doppler, who will revoke the tokens and email affected customers. You can read more information about Doppler tokens here.

GitHub Advanced Security customers can also scan for Doppler tokens and block them from entering their private and public repositories with push protection.

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

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Rootly to scan for their tokens and help secure our mutual users on public repositories. Rootly tokens allow users to authenticate against the Rootly API and create incidents programmatically. GitHub will forward access tokens found in public repositories to Rootly, who will notify workspace owners and let them revoke token within a few seconds. You can read more information about Rootly tokens here.

GitHub Advanced Security customers can also scan for Rootly tokens and block them from entering their private and public repositories with push protection.

See more

GitHub Advanced Security customers can now enable validity checks for supported partner patterns in their repository, organization, or enterprise level code security settings.

When you enable the checkbox in your settings, GitHub will automatically check validation for patterns on a cadence by sending the pattern to our relevant partner provider. You can use the validation status on leaked secrets to help prioritize secrets needing remediation action.

As we continuously work with our partners to add support for more patterns, we'll update the "Validity check" column in our documented supported patterns list.

auto check for validity checkbox in settings

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Grafana Labs to scan for their tokens and help secure our mutual users on public repositories. Grafana tokens allow users to manage all resources within Grafana installations, and Grafana Cloud tokens can be used to authorize data ingestion requests and to manage the lifecycle of stacks. GitHub will forward access tokens found in public repositories to Grafana Labs, and they will automatically revoke the token and notify affected customers. You can read more information about Grafana's various tokens below:

GitHub Advanced Security customers can also scan for Grafana tokens and block them from entering their private and public repositories with push protection.

See more

Available in public beta today, the security coverage page now includes multi-repository enablement, which lets you enable or disable security features across several repositories at once. This feature improves upon the “enable all” feature that only allows you to enable one security feature at a time for all repositories within the organization.

Multi-repository enablement also allows you to filter repositories based on attributes such as team or repository topic, and to enable or disable security features for only those repositories in just a few clicks.

 

multi-repository enablement panel on security coverage page

The following security features can be enabled/disabled using multi-repository enablement:

  • Dependency graph
  • Dependabot alerts
  • Dependabot security updates
  • GitHub Advanced Security
  • Code scanning default setup
  • Secret scanning
  • Push protection

These improvements have shipped as a public beta to GitHub.com and will be available in GitHub Enterprise Server 3.10.

Learn more about multi-repository enablement and send us your feedback

Learn more about GitHub Advanced Security

See more

When changes in a repository make a Dependabot pull request out-of-date, Dependabot will automatically rebase it so that it is able to be merged without your manual effort. With this release, if a PR has not been merged for 30 days, Dependabot will stop rebasing it and will include a note about this in the PR body. You will still be able to manually rebase and merge the pull request. We've heard your feedback about Dependabot noisiness and are making Dependabot quieter and more focused on repositories you care about. For enterprise customers, this improvement has the added benefit of enhanced efficiency with your self-hosted GitHub Actions runners. For Enterprise Server customers, this update will be available to you in GHES 3.10.

See more

You can now filter by repository topic or team on the enterprise-level Dependabot, code scanning, and secret scanning pages in security overview.

Code scanning enterprise-level page filtered by repository topic and showcasing the team drop-down

These improvements have shipped to GitHub.com and will be available in GitHub Enterprise Server 3.9.

Learn more security overview and send us your feedback

Learn more about GitHub Advanced Security

See more

You can now fetch release notes, changelogs and commit history for Docker update pull requests with Dependabot. This will allow you to quickly evaluate the stability risk of the dependency upgrade. To enable support, add the org.opencontainers.image.source label to the Dockerfile with the URL of the source repository. Additionally, the repository should be tagged with the same tags as the published Docker images. This allows Dependabot to understand which repo and commit is associated each version/tag of a Docker image. Here's an example repository demonstrating this setup.

Did you know? Dependabot's internal library for identifying dependency updates is open source. If you notice a Dependabot pull request is missing metadata, you can leverage the transparency of open source to debug the root cause – for example, if the package maintainer needs to fix their metadata annotation.

See more

GitHub Advanced Security customers using secret scanning can now view any secrets exposed historically in an issue's title, description, or comments within the UI or the REST API. This expanded coverage will also detect and surface secrets matching any custom pattern defined at the repository, organization, or enterprise levels.

See more