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

Secret scanning supports bypass controls for push protection (public beta)

For GitHub Advanced Security customers that use secret scanning, you can now specify which teams or roles have the ability to bypass push protection. This feature is in public beta on GitHub Enterprise Cloud.

screenshot of the bypass list in settings

This is managed through a new bypass list, where organizations can select which teams or roles are authorized to bypass push protection and act as reviewers for bypass requests. If an individual not included in this list needs to push a commit that is initially blocked, they must submit a bypass request. This request is then reviewed by an authorized individual who can either approve or deny it, determining whether the commit can proceed into the repository.

Please note, this feature is not yet compatible with web UI pushes.

See more

Code scanning now allows configuring rulesets to prevent pull requests from being merged (beta)

The code scanning option for repository rules is now available in public beta. Code scanning users can now create a dedicated code scanning rule to block pull request merges, instead of relying on status checks.
Making it easier than ever to prevent new vulnerabilities from being introduced into your code base.

code scanning rule

Configuring code scanning merge protection with rulesets can be done at the repository or organization levels and for repositories configured with either default setup or advanced setup. Additionally you can also use the REST API to set merge protection with rulesets.

You can use rulesets to prevent pull requests from being merged when one of the following conditions is met:
– A required tool found a code scanning alert of a severity that is defined in a ruleset.
– A required code scanning tool’s analysis is still in progress.
– A required code scanning tool is not configured for the repository.

Note: Merge protection with rulesets is not related to status checks. If the code scanning rule is configured for the repository in parallel with an alert threshold and the merge protection rule for the code scanning check run, the two functionalities will work simultaneously. For more information about status checks, see about status checks.

This beta is now available on GitHub.com and will be available on GHES 3.14. The organisation wide rules is only available for GitHub enterprise. For more information, see Configuring merge protection for all repositories in an organization.

We look forward to your feedback on the code scanning option for repository rules in the GitHub community.

See more

Dependabot multi-directory configuration public beta now available

This public beta enables developers to use a directories key to list multiple directories for the same ecosystem configuration in the dependabot.yml file.

Previously, developers with multiple package manifests for the same ecosystem (e.g. npm, pip, gradle) across multiple directories had to create separate dependabot.yml configurations for each of those directories. This could lead to many duplicated configurations, and high maintenance costs if a developer wished to make a change that spanned multiple directories.

A new dependabot.yml key, directories, is now available in public beta. The directories key accepts a list of strings representing directories, and can be used instead of directory.

Below is an example dependabot.yml multi-directory configuration setup, including how you can use the directories key:

version: 2
updates:
  - package-ecosystem: "bundler"
    directories:
      - "/frontend"
      - "/backend"
      - "/admin"
    schedule:
      interval: "weekly"

This example configuration applies to both security and version updates.

Wildcards and globbing support (i.e. using * to represent a pattern of directories) is coming soon in our next public beta releases, with an expected public beta launch within the next few months. Stay tuned for more!

If a developer still wishes to explicitly enumerate configurations for the same ecosystem using directory, they can still choose to do so; the directory key still accepts single-directory entries. For more information on the directory key, check out the dependabot.yml configuration options for the directory key documentation.

See more

CodeQL 2.17.1: AI-powered autofixes for C#, new Ruby queries and more Java models

CodeQL is the static analysis engine that powers GitHub code scanning. CodeQL version 2.17.1 has been released and has now been rolled out to code scanning users on GitHub.com.

CodeQL code scanning now supports automatic fix suggestions for C# alerts on pull requests, powered by Copilot. This is automatically enabled for all private repositories for all GitHub Advanced Security customers. For the first time, autofix covers nearly all security queries for a language, with 49 supported queries for C# from our Default and Extended suites. Use our public discussion for questions and feedback.

Also included in this release:

For a full list of changes, please refer to the complete changelog for version 2.17.1. All new functionality will also be included in GHES 3.13. Users of GHES 3.12 or older can upgrade their CodeQL version.

See more

Enterprise enablement trends for security products (public beta)

For enterprise owners and security managers dedicated to managing security products, we are excited to announce a new capability: you can now gain historical insights into security products enablement trends across your GitHub enterprise. This overview helps you understand how security product coverage is being implemented across your company.

Following our March announcement of the public beta of the enablement trends report for organizations, which allowed monitoring of enablement trends for all security products within your GitHub organization, we’ve expanded this capability to the enterprise level. The addition of an owner filter further simplifies the navigation of metrics for repositories owned by specific organizations.

Enterprise enablement trends report

Explore enablement trends and gain historical insights into the activation status of GitHub security features:
* Dependabot alerts
* Dependabot security updates
* Code scanning
* Secret scanning alerts
* Secret scanning push protection

Historical data is available from January 1, 2024, with the exception of Dependabot security updates data, which is available from January 17, 2024.

To access the enablement trends report, navigate to your enterprise account. In the enterprise account sidebar, click Code Security.

This feature is now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.14.

Learn more about security overview and join the discussion within the GitHub Community

See more

Dependabot Updates on Actions for GitHub Enterprise Cloud and Free, Pro, and Teams Users

Starting today, developers using GitHub Enterprise Cloud (GHEC) and Free, Pro, and Teams accounts can enable their repositories and/or organizations to run Dependabot updates as an Actions workflow. With this change, the job that Dependabot runs to generate pull requests will run in GitHub Actions. This is the start of an effort to consolidate Dependabot’s compute platform to Actions, with further migration plans to be announced later.

Who can opt-in?

GHEC, Free, Pro, and Teams administrator users can enable Dependabot on Actions today.

What if I’m on Enterprise Server (GHES)?

GitHub Enterprise Server (GHES) and Proxima users already run Dependabot on Actions; no further steps are required to enable Dependabot on Actions for these users.

Why choose to run Dependabot as an Actions workflow today?

Enabling Dependabot on Actions will yield performance benefits like faster Dependabot runs and increased visibility into errors to manually detect and troubleshoot failed runs. Actions APIs and webhooks will also be able to detect failed runs and perform downstream processing should developers wish to configure this in their CI/CD pipelines. There will be no change or impact to the Dependabot functionality, and there will be no impact to billed Actions minutes (i.e. Dependabot runs are free).

Will this count towards Actions minutes or costs?

This does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone. Beginning today, using Dependabot as an Actions workflow is free for everyone and generally available on all repositories.

What’s the next migration phase for Dependabot on Actions?

Over the course of the next year, we are migrating all Dependabot workflows to run on Actions compute infrastructure. You can opt-in today to gain access to these benefits, but they’ll be coming soon to all repos without needing to opt-in as well. We’re excited for faster runs, increased troubleshooting visibility, and other future benefits running Dependabot on Actions will unlock. We’ll be in close contact with those organizations who own repositories with Actions disabled and Dependabot enabled as we kick off the compute infrastructure migration. If you have questions or concerns, please contribute to our community discusson or contact our support team.

How to enable Dependabot on Actions?

GHEC, Free, Pro, and Teams administrator users can enable Dependabot on Actions runners at either the repository or organization level from the Code security and analysis settings pages. For more information, see our documentation on enabling Dependabot on Actions runners.

When will Dependabot support self-hosted runners and larger GitHub-Hosted runners?

May 2024

When will VNETs be supported?

This work is still in progress; we don’t yet have an estimated date when these will be available.

Can I use Actions workflows and APIs to trigger Dependabot jobs?

Today, Dependabot jobs can only be triggered from the Dependabot UI, and not by Actions workflows or APIs.

If I see a Dependabot job fail in Actions, how can I restart it?

Check out our documentation on re-running a verison updates job or re-running a security updates job.

If I enable Dependabot on Actions, can I later opt-out?

At this time, you can opt out of enabling Dependabot on Actions. However, this ability will change within the next year as we consolidate Dependabot’s compute platform to Actions.

What if I don’t want to turn on Actions for my repository or organization? What happens if Actions is disabled in a repository but Dependabot is enabled to run on Actions?

During this opt-in phase of the compute infrastructure migration, if you enable Dependabot on Actions but disable Actions at the repository or organization level, Dependabot will run on the legacy compute infrastructure. Please enable Actions either in your Dependabot-enabled repository or across your organization if you wish to opt in to run Dependabot on Actions.

Read more about Dependabot on GitHub Actions runners.

Join the discussion within GitHub Community.

See more

Configure organization-level CodeQL model packs for GitHub code scanning

You can now add organisation-level CodeQL model packs to improve code scanning coverage for your GitHub organization. This ensures that custom libraries and frameworks are recognised by CodeQL.

In most cases, the out-of-the-box CodeQL threat models provide the best coverage for identifying potential vulnerabilities in your GitHub repositories using code scanning. The CodeQL team at GitHub keeps a close eye on the most widely-used open-source libraries and frameworks to ensure CodeQL recognizes untrusted data that enters an application. For cases which cannot be covered by default, such as custom-built or inner-sourced frameworks and libraries, you can create custom CodeQL model packs to help CodeQL detect additional security vulnerabilities in your code.

Configuring CodeQL model packs in the organisation code security and analysis settings

When you configure CodeQL model packs at scale, the packs will be used in every code scanning analysis that uses default setup in the organization. By default, code scanning will download the latest version of each model pack, meaning that the latest changes to the pack (such as adding information about new frameworks) will automatically be included. Alternatively, you can configure specific sets of CodeQL models to use by stating a specific version (or version range). For more information, see Editing your configuration of default setup in the GitHub documentation.

You can use the CodeQL model editor in VS Code to easily create custom CodeQL model packs for libraries and frameworks written in C# and Java/Kotlin. Custom CodeQL model packs are also supported for code written in JavaScript and Ruby and we will be adding support for these and other CodeQL-supported languages in the CodeQL model editor in the future.

This functionality is now available on GitHub.com and will be available in GitHub Enterprise Server 3.14.

See more

Secret scanning for historically existing secrets found in GitHub discussions and pull requests

Secret scanning has recently expanded coverage to GitHub discussions and pull requests.

GitHub is now performing a backfill scan, which will detect any historically existing secrets found in GitHub discussions and pull request bodies or comments.

For repositories with secret scanning enabled, if a secret is detected in a discussion or pull request, you will receive a secret scanning alert for it. Public leaks detected in public GitHub discussion or pull requests will also be sent to providers participating in the secret scanning partnership program.

Sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

Learn how to secure your repositories with secret scanning or become a secret scanning partner.

See more

Secret scanning changes to detection and validation for Google Cloud Platform, Slack

GitHub secret scanning now supports validity checks for Google Cloud Platform (GCP) account credentials and Slack webhooks. This improvement involves changes to how account credentials for GCP are detected and alerted on.

What’s changing

Secret scanning alerts for Slack webhooks now support validity checks, in addition to previously supported Slack API tokens.

In addition, secret scanning now also alerts on complete GCP service account credential objects which include the fully matched private key, private key ID, and certificate URLs. These alerts support validity checks. As part of this change, you will no longer receive alerts for GCP private key IDs.

About validity checks

Validity checks indicate if the leaked credentials are active and could still be exploited. If you’ve previously enabled validation checks for a given repository, GitHub will now automatically check validity for alerts on supported token types.

Validity checks are available for repositories with GitHub Advanced Security on Enterprise Cloud. You can enable the feature at the enterprise, organization, or repository level from the “Code security and analysis” settings page by checking the option to “automatically verify if a secret is valid by sending it to the relevant partner.”

Share feedback

Sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

Learn more about secret scanning or our supported patterns for validity checks.

See more

CodeQL 2.17.0: Support for Java 22, Swift 5.10, TS 5.4, C# 12

CodeQL is the static analysis engine that powers GitHub code scanning. CodeQL version 2.17.0 has been released and has now been rolled out to code scanning users on GitHub.com.

Important changes in this release include:

For a full list of changes, please refer to the complete changelog for version 2.17.0. All new functionality will also be included in GHES 3.13. Users of GHES 3.12 or older can upgrade their CodeQL version.

See more

CodeQL threat model settings are now available for C# (beta)

Use CodeQL threat model settings for C# (beta) to adapt CodeQL’s code scanning analysis to detect the most relevant security vulnerabilities in your code.

CodeQL’s default threat model works for the vast majority of codebases. It considers data from remote sources (such as HTTP requests) as tainted. We previously released CodeQL threat model settings for Java to allow you to optionally mark local sources of data (such as data from local files, command-line arguments, environment variables, and databases) as tainted in order to help security teams and developers uncover and fix more potential security vulnerabilities in their code. CodeQL threat model settings are now available for C#, meaning that you can now enable similar local sources of taint in your code scanning analysis of code wriitten in C#.

If your repository is running code scanning default setup on C# or Java code, go to the Code security and analysis settings and click Edit configuration under Code scanning default setup. Here, you can change the threat model to Remote and local sources. For more information, see the documentation on including local sources of tainted data in default setup.

Threat model setting in CodeQL default configuration

If your repository is running code scanning advanced setup on C# or Java code, you can customize the CodeQL threat model by editing the code scanning workflow file. For more information, see the documentation on extending CodeQL coverage with threat models. If you run the CodeQL CLI on the command-line or in third party CI/CD, you can specify a --threat-model when running a code scanning analysis. For more information see the CodeQL CLI documentation.

As part of this work, we made changes to some of the queries included in the default code scanning suite for C# to better align with local and remote threat model settings. As a result you may see slightly fewer alerts when using the default threat model for remote sources. For more information about which queries are impacted, see the changelog for CodeQL 2.17.0.

CodeQL threat model settings (beta) in code scanning default setup is available on GitHub.com for repositories containing Java and C# code. Support for configuring threat model settings for C# will be shipped in GitHub Enterprise Server 3.14. Users of GHES 3.12 or older can also upgrade the version of CodeQL used in code scanning.

See more

Advanced filtering capabilities for the security overview dashboard

Today, we’re releasing security tool-specific filters for the security overview dashboard and secret scanning metrics page.

Security tool-centric filters in the filter bar drop-down on the overview dashboard

Have you ever wondered, “How well is my organization handling SQL injections?” or “How quickly are we responding to [partner name] secret leaks?” Maybe you’re curious about the pace of updating your npm dependencies. Well, wonder no more!

With our new security tool filters, you can tailor your search to the exact details you’re curious about, giving you a more focused and relevant report for your needs.

Discover the new filters that are designed to transform your security analysis:

  • Dependabot filters: Zero in on a specific ecosystem, package, and dependency scope.
  • CodeQL/third-party filters: Drill down to the rule that matters most to you.
  • Secret scanning filters: Get granular with filters for secret type, provider, push protection bypassed status and validity.

These features are now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.14.

Learn more about security overview and send us your feedback

See more

Secret scanning now detects secrets in GitHub wikis

Secret scanning is expanding coverage to GitHub wiki content. If secret scanning is enabled for your repository, you’ll automatically begin to receive alerts for newly introduced secrets found in your GitHub wiki.

Publicly leaked secrets in GitHub wikis will also be sent to secret scanning partners participating in the secret scanning partner program.

Share feedback or learn more

Sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

Learn how to secure your repositories with secret scanning or become a secret scanning partner.

See more

Code security configurations let organizations easily roll out GitHub security products at scale

Code security configurations simplify the rollout of GitHub security products at scale by defining collections of security settings that can be applied to groups of repositories. Your organization can apply the ‘GitHub recommended’ security configuration, which applies GitHub’s suggested settings for Dependabot, secret scanning, and code scanning. Alternatively, you can instead create your own custom security configurations. For example, an organization could create a ‘High risk’ security configuration for production repositories, and a ‘Minimum protection’ security configuration for internal repositories. This lets you manage security settings based on different risk profiles and security needs. Your organization can also set a default security configuration which is automatically applied to new repositories, avoiding any gaps in your coverage.

With security configurations, you can also see the additional number of GitHub Advanced Security (GHAS) licenses that are required to apply a configuration, or made available by disabling GHAS features on selected repositories. This lets you understand license usage when you roll out GitHub’s code security features in your organization.

Security configurations are now available in public beta on GitHub.com, and will be available in GitHub Enterprise Server 3.14. You can learn more about security configurations or send us your feedback.

See more

Dependabot grouped security updates generally available

Dependabot grouped security updates are now generally available. This feature automatically groups Dependabot pull requests, lets you specify several additional options to fine tune your groupings.

You can enable grouped security updates for Dependabot at the repository or organization-level. 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 collect all available security updates in a repository and attempt to open one pull request with all of them, per ecosystem, across directories.

If you would like more granular control over Dependabot’s grouping, you can also configure the dependabot.yml file in a repository to group by any of the following:

  • Package name
  • Dependency type (production vs development)
  • Semver update level (patch, minor, major)

For additional information, check out the Dependabot configuration file documentation.

For GitHub Enterprise Server users, grouped security updates will be available in Version 3.14.

See more
View more changes