code-scanning

Subscribe to all “code-scanning” 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

CodeQL, the static analysis engine that powers GitHub code scanning, can now analyze C# projects without needing a build. This public beta capability enables organizations to more easily roll out CodeQL at scale. Previously, CodeQL required a working build to analyze C# projects. By removing that requirement, our large-scale testing has shown that CodeQL can be successfully enabled for over 90% of C# repos without manual intervention.
This new way of analyzing C# codebases is now enabled by default for all code scanning users on GitHub.com. CodeQL CLI users can enable this feature using the build-mode: none flag, starting with version 2.17.6.

Repositories with an existing code scanning setup, default or advanced, will not experience any changes. If code scanning is working for you today it will continue to work as-is, and there is no need to change your configuration.

  • Repositories using code scanning default setup will automatically benefit from this new analysis approach.
  • Repositories using advanced setup for code scanning via workflow files will have the option to choose a build-mode. The default value for newly configured C# repositories will be build-mode: none.
  • CodeQL CLI users will not experience any change in the default behaviour, for compatibility with existing workflows. Users that want to enable this feature can now use the --build-mode none option. Generally, you should set the --build-mode option when using the CLI to make it easier to debug and persist the configuration should default behaviour change at any point in the future.

The new mechanism for scanning C# is available on GitHub.com and will be available with CodeQL CLI 2.17.6. While in public beta, this feature will not be available on GitHub Enterprise Server for default setup or advanced setup for code scanning. As we continue to work on scanning C# projects without the need for working builds, send us your feedback.

See more

You can now use the REST API to create and manage code security configurations, as well as attach them to repositories at scale.

The API supports the following code security configuration actions for organizations:
– Create, get, update, and delete configurations
– Set and retrieve default configurations
– List all configurations
– Attach configurations to repositories

The API is now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.15.0. You can learn more about security configurations, the REST API, or send us your feedback.

See more

CodeQL is the static analysis engine that powers GitHub code scanning. CodeQL version 2.17.5 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/C++ alerts, powered by Copilot. This is automatically enabled for all private repositories for all GitHub Advanced Security customers. Autofix covers all security queries for C/C++ from our Default suite. Use our public discussion for questions and feedback.

Also included in this release:
– C/C++ now supports adding models for sources, sinks and summaries in data extension files, making it easier to expand support to new libraries.
– Python adds support for opml library and C/C++ adds partial support for Boost.Asio network library.
– All the CodeQL CLI commands that produce SARIF will output a minified version to reduce size.

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

See more

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

This changelog combines significant updates from the release of CodeQL 2.17.2,2.17.3, and 2.17.4:

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

See more

Configurations are collections of security settings that organization administrators and security managers can define to help roll out GitHub security products at scale.

Starting today, you can enforce configurations. This new feature allows you to prevent users at the repository level from changing the security features that have been enabled and disabled in the configuration attached to their repository.

You can mark a configuration as enforced or unenforced at the bottom of the configurations edit page under the policy section:
Configuration Enforcement

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

See more

The new Tool group-by option on the security overview trends graph provides a visualization of alert trends, organized by the security tools that detected each vulnerability. It’s designed to improve your ability to track and analyze the effectiveness of your scanning tools, enabling more strategic decision-making.

Example of the alert trends chart grouped by security tool

With this new functionality, you can:
* Pinpoint which tools are detecting the most critical vulnerabilities.
* Monitor the performance of your scanners over time.
* Prioritize your remediation efforts based on detailed insights.

To access this feature, navigate to the Security tab at the organization level on GitHub, and choose the Tool option in the Group by dropdown.

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

Learn more about the security overview dashboard for your organization and send us your feedback

See more

When uploading a SARIF file that contains multiple SARIF runs for the same tool and category,
Code Scanning combines those runs into a single run.

Combining multiple runs within the same SARIF file is an undocumented feature that was originally intended to simplify uploading multiple analyses for the same commit. Since then, we have introduced the explicit concept of category to be able to upload multiple analysis for the same commit, thus better aligning with the SARIF Specification.

Today, we are starting the deprecation path for the combination of multiple SARIF runs with the same tool and category within the same file. Specifically, in the next few days, the github/codeql-action/upload-sarif action will start showing a deprecation warning when using 3rd party tools that rely on the combination of multiple SARIF runs with the same tool and category within the same file. While showing the deprecation warning, the upload of the SARIF file will succeed.

We expect to fully stop combining multiple SARIF runs with the same tool and category within the same file in June 2025 (for github.com) and in GHES 3.18, at which point the upload of the SARIF file will fail.

How does this affect me?

You are affected if you are using the github/codeql-action/upload-sarif action to upload results from a 3rd party Code Scanning tool and the tool generates multiple runs with the same category in a single SARIF file.
If that is the case, you will start seeing the deprecation warning, and you should work with the tool provider so that each run in the SARIF file has a distinct tool or category.

You are affected if you are using github/codeql-action/upload-sarif action to upload multiple SARIF files from a 3rd party tool. You can end up with multiple SARIF files if the tool either generates multiple SARIF files itself or if you are using a matrix build to run multiple analyses. Specifically, if you are doing a matrix build that generates multiple SARIF files and have a dedicated job to upload all the SARIF files together. For example, your workflow might look like the following if you analyze two apps using a matrix build but then have a dedicated upload job to upload all the SARIF files together:

jobs:
  analyze:
    ...
    strategy:
      matrix:
        app: ['app1', 'app2']

    steps:
    - name: SAST Scan
      ...

    - name: Temporary store SARIF file
      uses: actions/upload-artifact@v4
      with:
        name: sarif-${{ matrix.app }}
        path: "results"

  upload:
      name: Upload SARIF
      needs: analyze
      steps:
      - name: Fetch SARIF files
          uses: actions/download-artifact@v4
          with:
          path: ../results
          pattern: sarif-*
          merge-multiple: true

      - name: Upload Results
          uses: github/codeql-action/upload-sarif@v3

In this case, you need to make the call to the github/codeql-action/upload-sarif action to include a distinct category. For example, you can embed the step in the matrix job and use the matrix variables to generate a unique category. In this way, the example above becomes:

jobs:
  analyze:
    ...
    strategy:
      matrix:
        app: ['app1', 'app2']

    steps:
    - name: SAST Scan
      ...

    - name: Upload Results
      uses: github/codeql-action/upload-sarif@v3
      with:
        category: ${{ matrix.app }}

Note that changing the value of the category causes older alerts to remain open, and you might want to delete the configuration using the previous category value.

You are not affected if you are only using CodeQL via the github/codeql-action action. For the few repositories that rely on this behavior, the CodeQL CLI (starting version 2.17.0) includes backwards compatible logic.

You are not affected if you are uploading multiple SARIF files for the same commit using one of the documented approaches.

What’s next?

In June 2025, SARIF uploads to github.com that contain multiple runs with the same tool and category will be rejected.

See more

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

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

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

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

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

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

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

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.15. You can learn more about security configurations or send us your feedback.

See more