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

Code scanning flags up potential security vulnerabilities in pull requests — well before code is merged and deployed. Starting today, such alerts will be more visible: they will appear as a review on the pull request Conversation tab. As with any review, developers can then have a conversation about specific areas of the code that was changed.

And of course, from the code review by the GitHub code scanning bot, you can dive deeper into the alert: view the details, check the data flow paths, and dismiss an alert.

Code scanning alert

Code scanning and branch protection rules

Users were already able to configure code scanning as a required check in the branch protection settings in a repository.

With the new code scanning functionality, developers can start a conversation about code scanning alerts. Branch protection rules that require all conversations to be resolved before a PR can be merged apply equally to conversations about code scanning alerts: as soon as a code reviewer comments on a code scanning alert, the PR can not be merged until the conversation is marked as resolved. This helps ensure comments made on alerts are addressed prior to merging.

As you'd expect, when an alert is fixed, the conversation around the alert gets resolved and the PR can be merged.

PR merge blocked because of unresolved conversation

Learn more about GitHub Advanced Security and code scanning.

See more

Users can now add a comment when dismissing a code scanning alert.
Add a dismissal comment to a code scanning alert

It is optional to provide a dismissal comment. Dismissal comments are recorded in the alert timeline. They can also be set via the code scanning REST API when updating an alert, and retrieved through the new dismissed_comment attribute.

This feature is now available to all users on GitHub.com and will be released in GHES 3.6.

See more

On March 30, 2022, we released CodeQL Action v2, which runs on the Node.js 16 runtime. The CodeQL Action v1 will be deprecated at the same time as GHES 3.3, which is currently scheduled for December 2022.

How does this affect me?

Users of GitHub.com, GitHub AE, and GitHub Enterprise Server 3.5 (and later)

All users of GitHub code scanning (which by default uses the CodeQL analysis engine) on GitHub Actions on the following platforms should update their workflow files:

  • GitHub.com (including open source repositories, users of GitHub Teams and GitHub Enterprise Cloud)
  • GitHub AE
  • GitHub Enterprise Server (GHES) 3.5 and later

Users of the above-mentioned platforms should update their CodeQL workflow file(s) to refer to the new v2 version of the CodeQL Action.

Users of GitHub Enterprise Server 3.4 (and older)

Users of GitHub Enterprise Server 3.4 (and older) are not recommended to update their configuration to use the v2 version of the CodeQL Action:

  • GHES 3.3 (and older) does not support running Actions using the Node 16 runtime and is therefore unable to run the v2 version of the CodeQL Action. Please upgrade to a newer version of GitHub Enterprise Server prior to changing your CodeQL Action workflow files.
  • While GHES 3.4 does support Node 16 Actions, it does not ship with v2 of the CodeQL Action. Users who want to migrate to v2 on GHES 3.4 should request that their system administrator enables GitHub Connect to download v2 onto GHES before updating their workflow files.

The upcoming release of GitHub Enterprise Server 3.5 will ship with v2 of the CodeQL Action included.

Exactly what do I need to change?

To upgrade to the CodeQL Action v2, open your CodeQL workflow file(s) in the .github directory of your repository and look for references to:

  • github/codeql-action/init@v1
  • github/codeql-action/autobuild@v1
  • github/codeql-action/analyze@v1
  • github/codeql-action/upload-sarif@v1

These entries need to be replaced with their v2 equivalents:

  • github/codeql-action/init@v2
  • github/codeql-action/autobuild@v2
  • github/codeql-action/analyze@v2
  • github/codeql-action/upload-sarif@v2

Can I use Dependabot to help me with this upgrade?

Yes, you can! For more details on how to configure Dependabot to automatically upgrade your Actions dependencies, please see this page.

What happens in December 2022?

In December 2022, the CodeQL Action v1 will be officially deprecated (at the same time as the GHES 3.3 deprecation). At that point, no new updates will be made to v1, which means that new CodeQL analysis capabilities will only be available to users of v2. We will keep a close eye on the migration progress across GitHub. If many workflow files still refer to v1 of the CodeQL Action we might consider scheduling one or more brownout moments later in the year to increase awareness.

See more

The CodeQL runner has been deprecated in favor of the CodeQL CLI. As previously announced, starting March 14th, the CodeQL bundle now no longer includes the CodeQL runner. This deprecation only affects users who use CodeQL code scanning in 3rd party CI/CD systems; users of GitHub Actions are not affected.

GitHub Enterprise Server (GHES)

The CodeQL runner was shipped as part of GitHub Enterprise Server (GHES) versions up to and including 3.3.x. GitHub Enterprise Server 3.4 and later no longer include the CodeQL runner. We strongly recommend that customers migrate to the CodeQL CLI, which is a feature-complete replacement for the CodeQL runner and has many additional features.

How does this affect me?

If you’re using CodeQL code scanning on GitHub Actions, you are not affected by this change.

If you’ve configured code scanning to run the CodeQL runner inside another CI/CD system, we recommend migrating to the CodeQL CLI as soon as possible.
Starting April 1st, changes to both the CodeQL analysis engine and the code scanning API are not guaranteed to be compatible with older CodeQL runner releases.

What actions should I take?

You should configure your CI/CD system to use the CodeQL CLI before upgrading to GHES 3.4.0. When setting up the CodeQL CLI, we recommend that you test the CodeQL CLI set up to verify that the CLI is correctly configured to analyze your repository.

Learn more about migrating from the CodeQL runner to the CodeQL CLI here.

See more

The code scanning alert page now shows the analysis origin for an alert. Code scanning alerts can originate from different analysis configurations on a repository. These may be using different tools or targeting different languages or areas of the code. For example, an alert generated using the default CodeQL analysis with GitHub Actions will have a different analysis origin from an alert generated externally and uploaded via the code scanning API. If an alert is generated by multiple analysis origins, the alert may be fixed in one origin but remain open in another.

code-scanning-analysis-origins

Code scanning now shows the details of the analysis origin of an alert. If an alert has more than one analysis origin, it is shown in the ‘Affected branches’ sidebar and in the alert timeline. You can hover over the analysis origin icon in the ‘Affected branches’ sidebar to see the alert status in each analysis origin. If an alert only has a single analysis origin, no information about analysis origins is displayed on the alert page.

These improvements will make it easier to understand your alerts — in particular those that have multiple analysis origins. This is especially useful for setups with multiple analysis configurations, such as mono repos.

Read more about code scanning analysis configurations

See more

The code scanning alert page now always shows the alert status and information for the default branch. There is a new ‘Affected branches’ panel in the sidebar to see the status of the alert in other branches. If the alert does not exist in your default branch, the alert page will show the status as ‘In branch’ or ‘In pull request’ for the location where the alert was last seen.

This improvement makes it easier to understand the status of alerts which have been introduced into your code base.

The alert list page is not changed and can be filtered by branch. You can use the code scanning API to retrieve more detailed branch information for alerts.

Read more about alert details.

See more

GitHub code scanning helps open source maintainers and organizations find potential vulnerabilities in their code, before these can make their way into deployments. CodeQL, our very own analysis engine, powers the majority of those checks. Over the past few months, we have been working hard to improve the depth and breadth of our analysis to cover more CWEs, add support for a host of new language versions, and improve our platform compatibility.

Before we dive into the details: If you haven’t tried GitHub code scanning with CodeQL yet, you can enable it now on your repositories by following this guide! It’s free for open-source projects and available as part of GitHub Advanced Security for our enterprise customers.

All improvements below are available to users of GitHub code scanning on GitHub.com today, and will be part of the next GitHub Enterprise Server release (GHES version 3.5). Users of other GHES versions can also update their CodeQL version to benefit from these analysis improvements straight away.

Language Support

Today, CodeQL already supports JavaScript/TypeScript, Python, Ruby, Java, C#, Go, and C/C++. These languages are themselves under constant development, and we now support the following language versions:

  • C# 10 / .NET 6,
  • Python 3.10,
  • Java 17, and
  • TypeScript 4.5

The standard language features in those language releases are now fully supported by CodeQL.

Performance and Compatibility

For our Linux users, we have fixed an issue that caused the CodeQL CLI to be incompatible with systems running glibc version 2.34 and older.

For users of the CodeQL Apple Silicon support (beta), we are now bundling a native Java runtime for improved performance. Rosetta 2 and macOS Developer Tools are still required for other CodeQL components.

Security Coverage

The Common Weakness Enumeration (CWE) system is an industry-standard way of cataloging insecure software development patterns. CodeQL runs hundreds of queries out of the box that are able to detect an even greater number of CWEs. We went back through our existing queries, and aligned dozens of them with updated CWE IDs to give users better insight into the potential impact of a security issue when an alert is flagged up by code scanning.

We’ve added and improved detection for a large number of CWEs. These are the most significant changes:

  • CWE-190 – Integer Overflow: The cpp/uncontrolled-arithmetic query for C/C++ detects potential user-controlled inputs to calculations that could produce an overflow condition
  • CWE-319 – Cleartext Transmission of Sensitive Data: The cpp/cleartext-transmission query for C/C++ detects network transmissions of sensitive data without encryption
  • CWE-120 – Buffer Overflow: The cpp/very-likely-overrunning-write query for C/C++ now detects cases of out-of-bounds writes based on advanced range analysis
  • CWE-732 – Incorrect Permission Assignment for Critical Resource: The cpp/open-call-with-mode-argument (and optional cpp/world-writable-file-creation) query for C/C++ detect issues that could lead to stack memory disclosure or attacker-writable files
  • CWE-295 – Improper Certificate Validation: The java/insecure-trustmanager query for Java now detects missing or lax certificate handling that could lead to man-in-the-middle attacks
  • CWE-829 – Inclusion of Functionality from Untrusted Control Sphere: The js/insecure-dependency query for JavaScript/TypeScript detects dependency downloads over unencrypted communication channels
  • CWE-347 – Improper Verification of Cryptographic Signature: The js/jwt-missing-verification query for JavaScript/TypeScript detects scenarios in which a JWT payload is not verified with a cryptographic secret or public key
  • CWE-918 – Server-Side Request Forgery: SSRF detection queries for Python have been improved, and now differentiate between partially and fully (py/full-ssrf) user-controlled URLs

Behind the scenes, we’re also working on support for mobile application security, with additional support for Kotlin and Swift on our roadmap. In the meantime, we’ve also added more coverage for mobile security issues for our existing Java support:

See more

GitHub code scanning supports a wide variety of code analysis engines through GitHub Actions workflows — including our own CodeQL engine. Users can now discover and configure Actions workflow templates for partner integrations straight from their repository's "Actions" tab under a category called "Security". Workflows are recommended based on the repository's content: we will suggest analysis engines that are compatible with the source code in your repository.

Configure workflow

Code scanning and our own CodeQL analysis engine are freely available for public repositories. Analysis engines and services provided by partners might require a subscription. You can also configure code scanning for organization-owned private repositories where GitHub Advanced Security is enabled.

Learn more about code scanning workflows on GitHub Actions tab.

See more

Users can now retrieve all their code scanning alerts at the GitHub organization level via the REST API. This new API endpoint supplements the existing repository level endpoint.

This API is available on GitHub.com starting today and will also be available to GitHub Enterprise Server users starting version 3.5.

Learn more about the code scanning REST API
Learn more about GitHub Advanced Security

See more

We have released improvements to the code scanning API:

  • We've added the fixed_at timestamp to alerts. This is the first time that the alert was not detected in an analysis. You can use this data to better understand when code scanning alerts are being fixed.
  • We've enabled sorting of alert results using sort and direction on either created, updated or number. Use this to see the alerts that are most important to you first. For more information, see List code scanning alerts for a repository.
  • We've added a Last-Modified header to the alerts and alert endpoint response. For more information, see Last-Modified in the Mozilla documentation.
  • We've added relatedLocations to the SARIF response when you request a code scanning analysis. The field may contain locations which are not the primary location of the alert. See an example in the SARIF spec and read about getting a code scanning analysis for a repository.
  • We've added help and tags data to the webhook response alert rule object. For more information, see Code scanning alert webhooks events and payloads.
  • PATs with the public_repo scope now have write access for code scanning endpoints on public repos, if the user has permission. This is a bug fix and is now inline with the documentation.

For more information, see the Code scanning in the API reference.

See more

We’ve improved the depth of CodeQL's Python analysis by adding support for more libraries and frameworks, including:

  • FastAPI
  • aiomysql
  • aiopg
  • asyncpg
  • Django REST framework
  • The os.path module
  • Flask-Admin
  • toml
  • ruamel.yaml
  • SQLAlchemy

As a result, CodeQL can now detect even more potential sources of untrusted user data, steps through which that data flows, and potentially dangerous sinks in which this data could end up. This results in an overall improvement of the quality of the code scanning alerts.

We carefully choose and prioritize the libraries and frameworks supported by CodeQL based on their popularity and through user feedback. These improvements are now available to users of CodeQL code scanning on GitHub.com, and will also be available in the next release of GitHub Enterprise Server (3.4).

See more

The latest release of the CodeQL CLI supports including markdown-rendered query help in SARIF files so that the help text can be viewed in the code scanning UI. This functionality is now available for code scanning on GitHub.com and will be available in GitHub Enterprise Server 3.4.

The CodeQL query help text is displayed in the code scanning UI whenever the query generates an alert. The query help explains the problem in more detail, and shows examples of vulnerable and fixed code. Until now, code scanning only displayed the query help for alerts generated by the default CodeQL queries. With the release of CodeQL CLI 2.7.1, the query help for your own custom queries will be uploaded to GitHub and displayed in code scanning.

Example of custom CodeQL query help

Writing query help for custom CodeQL queries

When you write your own queries, we recommend that you write a query help file so that other users can properly understand the impact an alert has on the security of their code. For custom query help in your repository there are no restrictions on the content, but we recommend that you follow the Query help style guide to make the help text as useful as possible.

You should write query help for custom queries in your repository in a markdown file alongside the corresponding query. CodeQL code scanning looks for query help files written in markdown that share the same name as the corresponding query file. For example, if your query file is MyCustomQuery.ql, the query help file should be named MyCustomQuery.md.

For users of 3rd party CI/CD systems

When using CodeQL with GitHub Actions, the query help will automatically be imported from markdown files that are stored alongside the corresponding custom queries. The query help is inserted into SARIF files generated during the analysis step and made available in the code scanning UI.

If you use a different CI/CD system, you have to add the --sarif-add-query-help flag to the codeql database analyze command to include the query help in your SARIF results files. For more information, see Analyzing databases with the CodeQL CLI.

See more

It's now easier to debug problems with CodeQL code scanning: an optional flag in the Actions workflow file will trigger diagnostic data to be uploaded as an artifact to your Actions run. To do this, you can modify the init step of your Actions workflow:

- name: Initialize CodeQL
  uses: github/codeql-action/init@v1
  with:
    debug: true

The data will be uploaded as an Actions artifact named debug-artifacts, attached to the workflow run. Such artifacts contain CodeQL logs, CodeQL databases, and the SARIF files that were produced.

These artifacts will help you when you're debugging problems with CodeQL code scanning. When contacting GitHub support, they might ask for this data too.

Learn more about Troubleshooting the CodeQL workflow.

See more

We’ve improved the depth of CodeQL's analysis by adding support for more libraries and frameworks and increasing the coverage of our existing library and framework models. JavaScript analysis now supports most common templating languages, and Java now covers more than three times the endpoints of previous CodeQL versions. As a result, CodeQL can now detect even more potential sources of untrusted user data, steps through which that data flows, and potentially dangerous sinks in which this data could end up. This results in an overall improvement of the quality of the code scanning alerts.

We carefully choose and prioritize the libraries and frameworks supported by CodeQL based on their popularity and through user feedback. These improvements are now available to users of CodeQL code scanning on GitHub.com, and will also be available in the next release of GitHub Enterprise Server (3.3).

Java

We've improved coverage for the following libraries:

JavaScript

We've added support for the following templating languages:

Learn more about CodeQL and code scanning.

See more

Developers and security researchers using the CodeQL CLI and VS Code extension can now build databases and analyze code on machines powered by Apple Silicon (e.g. Apple M1).

In order to use the CodeQL CLI and/or the VS Code extension on Apple Silicon, please make sure to install the Xcode command-line developer tools and Rosetta 2.

For detailed instructions on how to set up the CLI on supported platforms, please refer to the CodeQL CLI guide.

Learn more about CodeQL and code scanning.

See more

Code scanning alerts now integrate with GitHub Issues task lists to make it easy to prioritize and track your alerts with all your development work.

You can use the task list feature in markdown to track a code scanning alert in an issue. When you add a code scanning alert to a task list in an issue, a "tracked in" pill will show on the corresponding alert page. The code scanning alerts page also shows which alerts are tracked in issues.

You can also create a new issue from a code scanning alert, which automatically adds the code scanning alert to a task list in the new issue.
Demo: tracking code scanning alerts in task lists

This feature has now shipped in beta for all users on GitHub.com.

Learn more about tracking code scanning alerts in Issues using task lists.

See more

Ruby is the 10th most popular language within the open source community. To help more open source maintainers and organizations find potential vulnerabilities in their code, we’ve added Ruby support (beta) to the CodeQL engine that powers GitHub code scanning.

Our CodeQL analysis identifies security issues in your code, along with the flow of data to the vulnerable location. To help secure services and tools created with Ruby, the CodeQL beta release spots many of the most common security issues:

We’ve been putting this beta through its paces by analyzing some of the world's largest Ruby codebases at GitHub and select customers. The feedback has been overwhelmingly positive, and in many cases CodeQL identified real vulnerabilities, all while keeping the number of false-positives at a minimum.

CodeQL for Ruby is available by default in GitHub.com code scanning, the CodeQL CLI, and the CodeQL extension for VS Code starting today. It will also be included in GitHub Enterprise Server 3.4. Ruby joins the list of supported CodeQL languages, which also includes C/C++, C#, Java, JavaScript/TypeScript, Python, and Go.

We currently support all common Ruby versions, up to and including 3.02. Check out the documentation for more details on compatibility.

To start using the new Ruby analysis, simply update your existing workflow file by adding Ruby to the language matrix:

jobs:
  analyze:
    name: Analyze
    ...
    strategy:
      fail-fast: false
      matrix:
        # add here
        language: ['ruby']

If you’re new to code scanning, set up a CodeQL analysis workflow from the Security tab in your repository.

Want to contribute or write your own CodeQL queries for Ruby? This guide will help you get started.

To give us feedback, join the Ruby beta discussion in the public CodeQL repository, which is also a good place to ask questions about anything CodeQL.

See more

Code scanning runs analysis tools that scan your code on the triggers defined in your .yml Actions workflow file. The default CodeQL workflow analyzes your code each time you push a change to the default branch and when you raise a pull request against the default branch.

We have made some improvements for users who are not able to run analyses using the default on:pull_request GitHub Actions trigger). These changes will make it easier to use code scanning for users of other CI/CD platforms, as well as users who can only use the on:push triggers in Actions.

Scanning pull requests (using GitHub Actions)

If you use GitHub Actions, we recommend that you configure code scanning to analyse all pull requests using the on:pull_request trigger in the Actions workflow (default). Developers will see code scanning results right in their pull requests, alongside the code review by their colleagues.

The pull_request trigger also produces the most accurate results: alerts shown on the pull request are identified by comparing the results for the pull request merge commit against the target branch baseline. This best reflects the future state of the code after the pull request has been merged.

Scanning code on every push (using GitHub Actions)

You can also scan your code using the on:push triggers, which will perform a scan each time you push code to a branch (regardless of whether there is a pull request).

Previously, alerts identified in on:push workflows would not show up on any pull request. However, our recent changes have improved this. When an on:push scan returns results that we can map to a pull request, we will flag up these alerts on the PR. The alerts shown on the PR are those identified by comparing the existing analysis of the head of the branch to the analysis for the target branch that you are merging against. Note that if the pull request's merge commit is not used, alerts can be less accurate when compared to the approach that uses on:pull_request triggers.

This is a less cost effective way to use code scanning because your code will be analysed each time you push to the branch, even before a pull request is opened.

If you scan both on:push and on:pull_request, we will choose to show the results from the merge analysis.

Scanning on push (or for every commit) using other CI/CD systems

Some other CI/CD systems can exclusively be configured to trigger a pipeline when code is pushed to a branch, or even exclusively for every commit. This is a less cost effective way to run code scanning, but with our recent improvements we will now provide alerts in developers' pull requests using this approach. Whenever such an analysis pipeline is triggered and results are uploaded to the SARIF API, code scanning will try to match the analysis results to an open pull request. If an open pull request is found, the results will be published as described above.

How do I update my Actions workflow to use the pull_request trigger?

  1. If you are setting up code scanning for the first time, use the default CodeQL analysis workflow which will scan the merge commit on pull request.

  2. If you have setup code scanning to scan on push and would like to update it to scan on the pull request, update your .yml workflow file to look like this:

on:
  push:
    branches: [ main ]
  pull_request:
    # The branches below must be a subset of the branches above
    branches: [ main ]

You will still need to analyze your default branch on:push because it provides the base analysis for the comparison.

  1. If you have setup code scanning to scan the head commit on pull request and would like to update it to scan the merge commit, delete the following lines from your .yml workflow file:
     - run: git checkout HEAD^2
       if: ${{ github.event_name == 'pull_request' }}

Read more about setting up code scanning using Actions.

See more

We've added support for Java 16 standard language features (such as records and pattern matching) to CodeQL. Code using those features can now benefit from CodeQL's security analysis as part of code scanning.

We also continue to support older Java versions. CodeQL is able to analyze code written in Java version 7 through 16.

Learn more about CodeQL and code scanning.

See more