codeql

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

Now, you can view Prevention metrics alongside Detection and Remediation metrics and in an enhanced security overview dashboard. This update is available at both the organization and enterprise levels.

New prevention tab on the security overview dashboard

New to the dashboard, the Prevention insights tab highlights CodeQL pull requests alerts and will soon include secret scanning push protection insights. It’s designed to help you shift from merely responding to vulnerabilities to actively preventing them, the ultimate goal in application security. With this dashboard, you and your team can proactively keep vulnerabilities at bay, successfully blocking threats before they ever reach production.

Deep dive into the CodeQL pull request alerts

For a deeper analysis, the new CodeQL pull request alerts report is also available at both the organization and enterprise levels. This report allows you to:

  • Track historical metrics for CodeQL pull request alerts
  • Monitor code as it progresses from feature branches to the default branch
  • Analyze metrics by CodeQL rule, autofix status, and repository

The enhanced dashboard is now generally available on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.16.

Learn more about pull request alerts and join the discussion within the GitHub Community

See more

Now you can remediate existing security issues in your public repositories faster with Copilot Autofix for CodeQL alerts. Following our general availability release for all Advanced Security customers, Copilot Autofix for CodeQL alerts is now generally available (GA) for all public repositories, for free.

Powered by GitHub Copilot, this feature provides automatic fixes for vulnerabilities found by CodeQL, both on pull requests and for historical alerts that already exist in a codebase.

Importantly, you stay in full control of your codebase: Copilot Autofix will try and suggest fixes for CodeQL alerts in pull requests, but it’s ultimately up to you to decide whether you wish to accept Copilot’s suggestion wholly, partially, or not at all. The same applies to historical alerts in a codebase: you can request an autofix from Copilot, then review it, and decide whether you want to open a PR with the fix suggestion or commit straight to the affected branch (or neither).

Example of Copilot Autofix generation on the alert page

Copilot Autofix is available for all public repositories that use code scanning CodeQL, and is enabled by default for alerts on PRs. It does not generate additional notifications. If you would like to enable Copilot Autofix on your organization’s private repositories, please have a look at this blog post where we announce Autofix for GitHub Advanced Security.

For more information, see: About Copilot Autofix for CodeQL code scanning. If you have feedback for Copilot Autofix for code scanning, please join the discussion here.

See more

New Export CSV button highlighted on the CodeQL pull request alerts report

You can now export data from the CodeQL pull request alerts report in CSV format, enabling you to analyze prevention and autofix metrics offline or archive the data for future use. This functionality is available at both the organization and enterprise levels. Exports will respect all filters applied, allowing you to focus on the specific data most relevant to your needs. You can download all data where you have an appropriate level of access.

Learn more about tracking metrics on CodeQL pull request alerts and join the discussion within the GitHub Community.

See more

CodeQL code scanning can now analyze Java and C# code without having to observe a build. This makes it easier to roll out the security analysis on large numbers of repositories, especially when enabling and managing repositories with GHAS security configurations.

CodeQL is the analysis engine that powers GitHub code scanning. When analyzing source code, it is important that the analysis engine has detailed knowledge of all aspects of the codebase. Now, the analysis engine no longer depends on observing the build process for Java and C# code, resulting in higher setup success and adoption rates for CodeQL code scanning (Java and C#).

During the testing of this feature, we validated that the analysis results were as accurate as the previous methodology. This feature was previously in public beta earlier this year (Java, C#), when it became the new default analysis mode for new users of CodeQL code scanning for these languages. Some customers experienced time significant savings as some tasks that previously took weeks now are achievable in minutes.

CodeQL’s new zero-configuration analysis mechanisms for both Java and C# are available on GitHub.com. If you are setting up CodeQL code scanning for these repositories, you will benefit from this analysis mechanism by default. If you set up CodeQL code scanning for Java or C# before their respective public beta releases of this feature, your analysis will remain unchanged (but can be migrated by disabling the current configuration and re-enabling code scanning using default setup). This new functionality will also be released to our GitHub Enterprise Server (GHES) customers starting with version 3.14 for Java and 3.15 for C#.

Repositories that use code scanning advanced setup will continue to use whichever analysis mechanism is specified in the Actions workflow file. The template for new analysis configurations now uses the new analysis mechanism by specifying `build-mode: none`. The old analysis mechanisms remain available. Users of the CodeQL CLI can find more documentation here.

Learn more about GitHub code scanning. If you have any feedback about these new analysis mechanisms for Java and C#, please join the discussion here.

See more

You can now track prevention metrics for CodeQL pull request alerts with the new CodeQL pull request alerts report—available at both the organization and enterprise level. These insights empower you to proactively identify and mitigate security risks before they reach your default branch.

Enterprise-level CodeQL pull request alerts report

With this report, you can historically track metrics for CodeQL pull request alerts as code moves from feature branches to the default branch. Gain insights into:

  • Unresolved and merged alerts: Understand what security vulnerabilities made it to the default branch.
  • Fixes (autofix and manual): Track which alerts were addressed before merging.
  • Dismissed alerts: See which alerts were deemed false positive or risk accepted.

Additionally, analyze metrics by CodeQL rule, autofix status, and repository.

Historical data is available starting from May 1, 2024.

To access these reports, click your profile photo in the top-right corner of GitHub.com and select the organization or enterprise you want to view. For organizations, go to the Security tab and find CodeQL pull request alerts in the sidebar. For enterprises, click Code Security in the sidebar, then select CodeQL pull request alerts.

These reports are now generally available on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.15.

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

See more

Today, we’ve announced the general availability of Copilot Autofix for CodeQL alerts in GitHub code scanning! Powered by GitHub Copilot, this feature brings automatic fixes for vulnerabilities found by CodeQL into the developer workflow.

Through a deep integration in GitHub pull requests, autofixes help developers to fix vulnerabilities quickly and early in the development process, thereby preventing new vulnerabilities from entering your codebase. Data from our beta programme shows that vulnerabilities with a fix suggestion are fixed 3x faster across all vulnerability types, and even faster for complicated vulnerability types like cross-site scripting (7x faster) and SQL injection (12x faster). For security debt that already exists in your codebases, Copilot Autofix can help you with on-demand autofixes for historical alerts. Copilot Autofix for CodeQL code scanning was previously called “code scanning autofix”, and is now generally available for all GitHub Advanced Security customers on GitHub.com.

As developers start using autofixes, security teams can see an overview of how their organisation adopts autofixes generated by Copilot on their security overview dashboard. This includes detailed information about remediation rates.

For more information, see: About Copilot Autofix for CodeQL code scanning. If you have feedback for Copilot Autofix for code scanning, please join the discussion here.

Example of Copilot Autofix operating on a CodeQL alert in a pull request

See more

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

Important changes by version include:

For a full list of changes, please refer to the complete changelog for versions 2.17.6, 2.18.0, and 2.18.1. All new functionality will be included in GHES 3.15. Users of GHES 3.14 or older can upgrade their CodeQL version.

See more

Code scanning autofix for alerts in default branch is now available in public beta for all GitHub Advanced Security customers. This feature empowers developers to reduce the time and effort spent remediating existing alerts and reduce the number of vulnerabilities in the code base.

Powered by GitHub Copilot, code scanning generates fixes for alerts in all CodeQL supported languages.

Example autofix page for a Missing regular expression anchor vulnerability detected with CodeQL

With code scanning autofix, you can reduce security debt by generating fixes for alerts that are detected on the main or default branches of your repository. On the alert pages where autofix is available, press the ‘Generate fix’ button to get a natural language explanation of the suggested fix, along with a preview of the code suggestion. You can accept the fix by creating a PR with the fix and even edit the fix as part of the PR flow. These code suggestions can include changes to multiple files, and where needed, autofix may also add or modify dependencies.

Example of the autofix generation process, showing the Generate fix button

Code scanning autofix is automatically enabled on private repositories for all GitHub Advanced Security customers.

You can configure code scanning autofix for a repository or organisation. You can also use ‘Policies for Code security and analysis’ to allow autofix for CodeQL code scanning for an enterprise.

Enterprise level settings view of Autofix for CodeQL

The fix generation for any given alert depends on the context and location of the alert. In some cases, code scanning won’t display a fix suggestion for an alert if the suggested code change fails syntax tests or safety filtering.

You do not need a Copilot license to use autofix for existing alerts. For more information, see About code scanning autofix.

Provide feedback for code scanning autofix here.

See more

When rolling out code scanning default setup at scale (e.g., via code security configurations), GitHub checks if an advanced CodeQL setup already exists for each repository. If an advanced setup exists, GitHub retains it and does not enable the default setup.

Starting today, it will be easier to understand if a repository will be converted during an at scale rollout.

Previously, GitHub would consider a repository to be using an advanced setup if the repository had ever had a CodeQL analysis. After this change, a repository is now considered as using an advanced CodeQL setup only if:

  • In the last 90 days, there has been a CodeQL analysis for the default branch, and
  • the workflow file associated with the latest CodeQL analysis in the default branch has not been deleted or disabled.

How does this affect me?

The improvements to the detection of existing CodeQL setups impacts you only if you are doing a rollout of code scanning at scale using (e.g.,) code security configurations and had previously used CodeQL via an advanced setup on some of your repositories.

If you are doing a rollout at scale, and want a repository to be considered for conversion to default setup, you can now delete or disable the associated yml file or you can delete the associated configurations for API-based advanced setups.

These changes will simplify enabling default setup at scale by increasing the number of repositories that are converted from advanced to default setup during an at scale rollout.

How do I convert my repo from advanced setup to default setup?

You can always enable default setup at the repository level. If there is a yml workflow file in the repository, GitHub will disable it for you. If you are doing API uploads, however, you need to adjust your CI/CD systems to stop submitting analyses. Note that while default setup is enabled, all CodeQL uploads via the API will be rejected.

How do I convert my repos from advanced setup to default setup at scale?

To convert multiple repos you have two options.
1. Use the default setup repository-level API, or
2. Use organization-level code security configurations to configure all the GHAS products in one go.

Note that repositories will be converted from default to advance only if they meet any of following criteria:

  • The latest CodeQL analysis on the default branch is older than 90 days old.
  • All CodeQL configurations have been deleted.
  • (Exclusively for yml-based advanced setups) The workflow file has been deleted or disabled.

Can I use an API to bulk disable advanced setups that use yml workflow files?

Yes. You can directly disable the associated workflow file by calling the Actions endpoint via the REST API. To do so, you will need to know the name of the workflow file. The name of the workflow file can be found in the code scanning /analyses endpoint.

See more

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

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

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