Skip to content

advanced-security

Subscribe to all “advanced-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

Code scanning default setup is now available for self-hosted runners on GitHub.com. To use default setup for code scanning, assign the code-scanning label to your runner. Default setup now uses actions/github-script instead of the GH CLI. If your organization has a policy which limits GitHub Actions you will need to allow this action in your policy.

Code scanning sees assigned runners when default setup is enabled. As a result, if a runner is assigned to a repository which is already running default setup, you must disable and re-enable default setup to initiate using the runner.

Larger runners are in beta support, with the limitations that you can only define one single larger runner at the org level with the label code-scanning, and Swift analysis is not supported.

For more information, see “Using labels with self-hosted runners.”

Runner with code-scanning label

This is now available on GitHub.com. Self-Hosted runners for default setup are already supported from GitHub Enterprise Server 3.9.

See more

CodeQL 2.15.4 is rolling out to users of GitHub code scanning on github.com this week, and all new functionality will also be included in GHES 3.12. Users of GHES 3.11 or older can upgrade their CodeQL version.

Important changes in this release include:

  • Performance improvements on large runners (instances with 8 to 16 vCPUs) lead to a reduction in end to end analysis time between 5% and 15%, due to more effective parallelization. Where possible, upgrading to larger instances is recommend for projects that currently use 4 or fewer vCPUs and take more than 10 minutes to analyze.
  • Analysis times for C and C++ code bases of any size are reduced on average by 6%
  • TypeScript 5.3, Java 21 and Python 3.12 are now supported.
  • We have resolved a problem causing scan timeouts on macOS (the default for Swift analysis). This problem affected up to 10% of scans for some projects. Although timeouts may still occur, they are now expected in less than 0.5% of scans. We are actively addressing the remaining issues.

For a full list of changes, please refer to the complete changelog for version 2.15.4.

See more

Reduce pull request noise and fix multiple security alerts at once with Dependabot grouped security updates.

Starting today, you can enable grouped security updates for Dependabot at the repository or organization-level. When you click “Enable” for this feature, Dependabot will collect all available security updates in a repository and attempt to open one pull request with all of them, per ecosystem, across directories. There is no further configuration available at this time.

Known limitations

  • Dependabot will NOT group across ecosystem (e.g. it will not group pip updates and npm updates together)
  • Dependabot WILL group across directories (e.g. if you have multiple package.json’s in different directories in the same repository)
  • If you have version updates enabled as well, Dependabot will NOT group security updates with version updates
  • If you use grouping for version updates, your groups configuration in dependabot.yml will NOT apply to security updates

To enable this feature, go to your repository or organization settings page, then go to the Code security and analysis tab, and click "Enable" for grouped security updates (this also requires each affected repository to enable Dependency graph, Dependabot alerts, and Dependabot security updates). When you enable this feature, Dependabot will immediately attempt to create grouped security pull requests for any available security updates in your repository.

We'd love to hear your feedback as you try this feature! Join the discussion within GitHub Community.

See more

GitHub Advanced Security users can now use the REST API to enable or disable secret scanning validity checks for a repository, organization, or enterprise. Validity checks retrieve a status for supported tokens from their relevant partner (active, inactive, or unknown). This status is displayed in the secret scanning alert view and the REST API.

See more

We have partnered with our sister team at Microsoft to bring some improvements to the NuGet ecosystem for Dependabot updates:

  • Updater logic re-written in C#, making it easier for users of NuGet to contribute to dependabot-core
  • Improvement in detection of where package dependencies are declared in .NET projects
  • Improved support for implicit dependencies
  • Improved support for peer dependencies

Learn more about Dependabot.

See more

CodeQL 2.15.3 is rolling out to users of GitHub code scanning on github.com this week, and all new functionality will also be included in GHES 3.12. Users of GHES 3.11 or older can upgrade their CodeQL version.

Important changes in this release include:

For a full list of changes, please refer to the complete changelog for version 2.15.3.

See more

Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale. We've heard your feedback, which is helping us improve throughout this beta period.

Starting today, you can now create Dependabot auto-triage rules using CVE IDs or GHSA IDs to target subsets of alerts.

How do I learn more?

How do I provide feedback?

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

See more

We're simplifying how Dependabot operates! Previously, if Dependabot encountered errors in its last run, it would automatically re-run the job when there were changes in the package manifest (like adding or changing dependencies). This often led to Dependabot running more than needed and creating unscheduled pull requests. To streamline the process and stick to the schedules you set, this automated re-run feature is being deprecated.

Dependabot will still run jobs according to your schedule, and you'll have the option to manually trigger jobs whenever necessary.

See more

Secret scanning will now use AI to detect unstructured passwords in git content and generate an alert. Alerts for passwords appear in a separated tab from regular secret scanning alerts.

Generic secret detection is available for repositories with a GitHub Advanced Security license. The feature is in a limited beta and access will be granted through a waitlist.

screenshot of a secret scanning alert for an AI-detected password

See more

Secret scanning has a new, AI-powered regular expression generator for custom patterns. Within the existing custom patterns page, GitHub Advanced Security users can launch a generative AI experience where you input a text description of what pattern you would like to detect, include optional example strings that should be detected, and get matching regular expressions in return.

The generator is in a limited beta and access will be granted through a waitlist.

screenshot of the regular expression generator

See more

Banner announcing the new overview dashboard states prioritization made simple with security insights

A new asset in security management is now available for GitHub enterprise users. Reinforcing the “shift left” philosophy, this feature is designed to integrate security into the heart of the development lifecycle, empowering your organization to proactively identify and address vulnerabilities.

Key advantages

Historical context

By comparing historical and current data, you can visibly track improvements in your security landscape and demonstrate the value of security investments.

Reporting period drop-down menu for the new overview dashboard

Customized focus

Sharpen your focus with filters that dissect your security data by teams, repositories, or any categorization that aligns with your goals. Whether it’s tracking team performance or monitoring metrics across a core group of repositories with the repository topic filter, there’s a plethora of options available to meet your needs.

Drop-down of filters for the new overview dashboard

Prioritization made simple

With clear insights into severity and net resolve rate—security’s version of developer velocity—the dashboard shows you if your resources are aligned with the most severe threats and if remediation speed is in harmony with security demands.

Security alerts trends graph grouped by severity and the net resolve rate tile from the new overview dashboard

Strategic alignment

Gain a strategic perspective with the Repositories “Top 10” list, which shows you repositories with the largest number of open alert counts, to understand where to direct your attention first.

Repositories top 10 list from the new overview dashboard

Shift left

The dashboard, which is accessible by everyone in the organization, helps you drive best security practices by understanding potential issues as early as possible, reducing risk and workload down the line.

New overview dashboard

This overview dashboard is now available as a beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.13.

Learn more about the new overview dashboard and send us your feedback

See more

Secret scanning will now detect the following non-provider patterns:

  • HTTP basic authentication header
  • HTTP bearer authentication header
  • MongoDB connection string
  • MySQL connection string
  • Postgres connection string
  • OpenSSH private key
  • PGP private key
  • RSA private key

Detection of these patterns must be enabled within a repository or organization’s security settings by checking the box next to “Scan for non-provider patterns.” Resulting secrets will appear in a new, separate tab on the secret scanning alert list called “Other.”

screenshot of secret scanning alerts showing a tab called Other with alerts for five non-provider patterns

Detection of non-provider patterns is currently in beta and is available for enterprises with a GitHub Advanced Security license only. Additional patterns will be added throughout the beta.

See more

GitHub Advanced Security users can now filter their secret scanning alerts by validity in the UI at the repository, organization, and enterprise level. Valid statuses are active, inactive, or unknown. Validity checks must be enabled for the repository, organization, or enterprise.

See more

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

We have partnered with Onfido to scan for their tokens to help secure our mutual users in public repositories. Onfido tokens allow developers to interact with Onfido's API in order to integrate secure and reliable identity verification solutions into their applications and services, helping to enhance user onboarding processes and protect against fraud. GitHub will forward any exposed tokens found in public repositories to Onfido, who will then notify the customer about the leaked token. Read more information about Onfido API tokens.

GitHub Advanced Security customers can also scan for and block Onfido tokens in their private repositories.

See more

The GitHub Advanced Security billing REST API and CSV download now includes the email addresses for active committers. This provides information for insights into Advanced Security license usage across your business. Here is an example response from the GitHub Advanced Security billing REST API:

      "advanced_security_committers_breakdown": [
        {
          "user_login": "octokitten",
          "last_pushed_date": "2023-10-26",
          "last_pushed_email": "octokitten@email.com"
        }

Read more about the GHAS billing API here and the GHAS billing CSV download here.

This is available now on GitHub.com and will ship to GitHub Enterprise Server 3.12

See more

GitHub Advanced Security users can now use the REST API to retrieve the validity status of a secret scanning token and retrieve all tokens of a particular validity status. The API will return the status of the token as of the last validity check. Valid statuses are active, inactive, or unknown. Validity checks must be enabled for the enterprise, organization, or repository.

See more

Auto-triage rules are a powerful tool to help you reduce alert and pull request fatigue substantially, while better managing your alerts at scale.

What's changing?

Starting today, you can define your own rules to control and enforce Dependabot behaviors across organizations and individual repositories.

  • You can now define which alerts receive pull requests to resolve them, rather than targeting all alerts.
  • You can enable and enforce those Dependabot security update rules across organizations, in addition to individual repositories.
  • You can enable, disable, or enforce how GitHub default rulesets are applied across your organization.
  • You can also now enable and enforce custom auto-dismiss (alert ignore and snooze) rules across organizations.

Dependabot auto-triage rules list

Auto-triage rules are defined by alert targeting criteria, the behaviors you'd like Dependabot to automatically perform for these alerts, as well as how you want the rule to be enabled or enforced across your organization.

Alerts can be targeted based on metadata related to the advisory, dependency, and how it's used. For this public beta, currently supported attributes at the organization level are: severity, scope, package-name, cwe, and ecosystem. At the repository level, you can also target specific manifest files.

Create a stacked Dependabot auto-triage ruleset

For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. You can proactively filter out false positives, snooze alerts until patch release, choose which alerts open Dependabot security updates, and – as rules apply to both future and current alerts – manage existing alerts in bulk.

This feature is free for open source (all public repositories) and available for use in private repositories through GitHub Advanced Security.

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 a flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns and has helped millions of repositories filter out false positive alerts. Today’s ship exposes our rules engine at the organization and repository levels, so you can create and enforce custom rules, too.

How do I create a rule?

From your organization or repository settings page, admins and security managers can navigate to Code security and analysis settings. Under Dependabot, select Dependabot rules to add or modify your own custom rules or modify GitHub presets.

How do I enforce rules for my organization?

Enforce a Dependabot auto-triage rule

At the organization level, rules can be set with the following states.

State Description
Enabled This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Any individual repository can choose to disable the rule.
Enforced This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Individual repositories cannot override this setting.
Disabled This rule will be disabled and hidden across your organization.

At the repository level, rules can be set to enabled or disabled if they're not enforced.

Which criteria are supported?

Rules can be created across the following attributes:

Attribute Description
severity Alert severity, based on CVSS base score, across the following values: low, medium, high, and critical.
scope Scope of the dependency: development (devDependency) or runtime (production).
package-name Packages, listed by package name.
cwe CWEs, listed by CWE ID.
ecosystem Ecosystems, listed by ecosystem name.
manifest Manifest files, listed by manifest path.

Note: manifest is only available at the repository level.

Target alerts based on attributes

How do I control how Dependabot automatically generates pull requests for alerts?

You can use the alert criteria (above) to indicate which alerts Dependabot will attempt to open pull requests to resolve. To use auto-triage rules with Dependabot updates, you must disable Dependabot's option to always open pull requests to resolve all open alerts from the repository Code security and analysis settings.

How do I control how Dependabot automatically closes or reopens alerts?

Similar to Dependabot pull request rules, you can control how Dependabot filters out false postives (with dismiss indefinitely) or snoozes alerts (with dismiss until patch).

How many custom rules can I create?

At the time of public beta, you can create 20 rules per organization and 10 rules for each repository. Want more? Let us know!

How will this activity be reported?

Auto-dismissal activity is shown in webhooks, REST, GraphQL, and the audit log for Dependabot alerts. Alerts are dismissed without a notification or new pull request and appear as a 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.

Who can create and modify rules?

Auto-triage rules are free for open source repositories. Anyone who can enable Dependabot alerts for a public repository will be able to create custom rules for it. Customers of GitHub Advanced Security can create and manage custom rules across private repositories and at the organization level.

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 (by any other auto-dismiss rule).

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 do I learn more?

How do I provide feedback?

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

See more

Secret scanning automatically detects leaked secrets across all public packages on the npm registry. If secret scanning detects a potential secret, we notify the service provider who issued the secret. The service provider validates the string and then decides whether they should revoke the secret, issue a new secret, or contact the committer directly. Package maintainers will not receive secret scanning alerts for these detections.

See more