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.
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.
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.
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.
Organizations can now grant teams permission to manage security alerts and settings on all their repositories. The "security manager" role can be applied to any team and grants the team's members the following permissions:
Dependency review is now generally available for all public repositories and for private repositories with GitHub Advanced Security enabled. Dependency review helps you understand dependency changes and the security impact of these changes when reviewing pull requests. It provides an easily understandable visualization of dependency changes with a rich diff on the "Files Changed" tab of a pull request and shows:
Learn more about dependency review
Learn more about GitHub Advanced Security
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.
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.
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.
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.
pull_request trigger?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.
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.
.yml workflow file:
- run: git checkout HEAD^2
if: ${{ github.event_name == 'pull_request' }}Read more about setting up code scanning using Actions.
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.
GitHub code scanning with CodeQL works seamlessly with GitHub Actions. For users of other CI/CD systems, we provided a way to run the code analysis using the CodeQL runner. The CodeQL runner acts as the glue between your CI/CD system and the CodeQL analysis engine (CLI).
In response to customer feedback, we have now transferred all CodeQL runner functionality natively into the CodeQL CLI. This means that there are fewer components to install, use, and update if you're running CodeQL code scanning on a 3rd party CI/CD system.
As of CodeQL CLI 2.6.2 (released today), there is now full feature parity between the CodeQL CLI and the runner. We are therefore announcing the deprecation of the CodeQL runner. This affects users of 3rd party CI/CD systems; users of CodeQL code scanning on GitHub Actions are not affected.
The CodeQL runner will continue to be part of the GitHub Enterprise Server releases up to and including the 3.3.x series. It will no longer be part of GitHub Enterprise Server starting the 3.4.0 (scheduled for 2022). The CodeQL CLI is a feature-complete replacement for the CodeQL runner, and is fully compatible with GitHub Enterprise Server.
The CodeQL bundle will continue to contain the CodeQL runner until March 2022. In the run-up to the final release we will start displaying clear deprecation warnings. After March 2022, code scanning API change on GitHub.com will likely not be compatible with older CodeQL runner releases. The CodeQL CLI is a feature-complete replacement for the CodeQL runner, and is fully compatible with GitHub.com.
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. Version 2.6.2 of the CodeQL CLI has full feature parity with the CodeQL runner and allows you to analyze codebases on 3rd party CI/CD systems in the same way as the CodeQL runner.
New users of CodeQL code scanning should use CodeQL CLI version >= 2.6.2.
You should configure your CI/CD system to use the CodeQL CLI before March 2022 and/or 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 create and analyze databases.
Learn more about how to migrate from the CodeQL runner to CodeQL CLI 2.6.2 here.
GitHub Advanced Security customers can now edit their custom patterns defined at the repository, organization, and enterprise levels. After a user edits and saves a pattern, secret scanning searches for matches both in a repository's entire git history and in any new commits. Editing a pattern will close alerts previously associated with the pattern if they no longer match the updated version.
The new editing feature comes along with other UI and UX updates, with additional improvements like dry-runs in the works.
Now that users can edit their patterns, we're also taking custom patterns out of beta on cloud. Over 50 enterprises have adopted the feature and written over 100 unique patterns since the initial release in June.
User-defined patterns will be generally available on server next quarter in GitHub Enterprise Server 3.3.
Learn more about custom patterns
Learn more about secret scanning
GitHub Advanced Security customers can now view all their private repo secret scanning alerts in the organization security tab. This view is currently only available to organization owners, but will soon also be available to users with the security manager role.
For API use cases, please see the recent secret scanning org-level REST API release.
Learn more about security overview
Learn more about GitHub Advanced Security
GitHub Advanced Security customers can now retrieve private repository secret scanning results at the organization level via the GitHub REST API. This new endpoint, in beta, supplements the existing repository-level endpoint.
For more information:
You can now easily find all alerts associated with your pull request with the new pull request filter on the code scanning alerts page.
To show all the code scanning alerts for a specific pull request, type 'pr:123' in the Filter alerts text box. This will return both the alerts that the pull request introduces and the existing alerts on the branch.
The pull request checks page shows the alerts introduced in a pull request, but not existing alerts on the pull request branch. The new "View all branch alerts" link on the Checks page takes you to the code scanning alerts page with the specific PR filter already applied, so you can see all the alerts associated with your PR. This can be useful to manage lots of alerts, and to see more detailed information for individual alerts.
The CodeQL package manager is now available in public beta on GitHub.com. CodeQL packages can contain CodeQL queries and CodeQL libraries — and of course you can express dependencies between packs. You can upload your packs to the package registry on GitHub.com, and CodeQL will automatically fetch any required dependencies when running queries from a pack. This makes it simple to create and share CodeQL queries and libraries!
CodeQL packs of course also integrate with GitHub code scanning (example below). Alternatively, you can use packs using the CodeQL CLI (version 2.6.0-beta.1 and up) on your local machine. More documentation about CodeQL packs can be found here.
You can integrate CodeQL packs into GitHub code scanning workflows by specifying that you want to run the CodeQL 2.6.0 beta version, and then specify the pack(s) you'd like to run. For example:
- uses: github/codeql-action/init@v1
with:
tools: https://github.com/github/codeql-action/releases/tag/codeql-bundle-v2.6.0-beta.1
packs: codeql/csharp-queries1@~1.2.3, octo-org/csharp-securityAlternatively, you can select CodeQL packs by specifying a list of package references in the packs section of your CodeQL configuration file. For example:
- queries/DeadCodeCondition.ql
- queries/GlobalUseBeforeInit.qls
packs:
- codeql/csharp-queries@~1.2.3 # latest version compatible with 1.2.3
- octo-org/csharp-security # latest version For more information, see Configuring code scanning.
All of our own CodeQL queries and libraries are now also released as CodeQL packs at github.com/codeql.
For each language there is a query pack containing all CodeQL queries for that language (from our open source repository). These packs are named codeql/<language>-queries. For example, the CodeQL pack containing the standard C/C++ queries is called codeql/cpp-queries.
We've also released packs with all CodeQL standard libraries for each language. These packs are named codeql/<language>-all (e.g. codeql/cpp-all). If you're writing your own query pack, you'll likely want to express a dependency on the CodeQL standard libraries for that language.
You can choose the permission levels required for users to view and access your CodeQL packs. Currently, all CodeQL packs default to Internal and should manually be set to Public. If you want to make your CodeQL pack visible to everyone, go to the settings section of the package and Change package visibility to Public.
All CodeQL packs can be downloaded and installed using the CodeQL CLI. You do not need to use the docker pull command shown on the package page. For more information, see Publishing and using CodeQL packs.
For more information, see About CodeQL packs.
We have shipped improvements to the code scanning alerts branch filter! These changes make it clearer which code scanning alerts are being displayed on the alerts page.
By default, the code scanning alerts are filtered to show alerts for the default branch of the repository only. You can use the branch filter to display the alerts on any of the non-default branches. Any branch filter that has been applied is shown in the search bar.
We have simplified the search syntax to the format branch: You can use this syntax multiple times in the search bar to filter on multiple branches. The previous syntax ref:refs/heads/[branch name] is still supported, so any saved URLs will continue to work.
We now show security-severity levels for CodeQL security alerts in code scanning. security-severity levels help you understand in more detail the risks posed by security alerts, allowing you to assess the potential impact of the alerts, and make the right decision on which alerts to fix first. The severity level of security alerts can be critical, high, medium, or low.
The new security-severity levels are displayed on all security alerts. For example, if a PR triggers security alerts, the security-severity is visible on the alert annotations under the Files changed tab. You can also see the security-severity for each alert present in a repository by clicking Security > Code scanning alerts.
Security severity levels are displayed on code scanning alerts that are generated by security queries.
CodeQL automatically calculates security-severity levels and assigns an exact numerical score to each security query. To calculate the security-severity of an alert, we first group all CVEs reported by the CWEs assigned to the security query. We then calculate the 75th percentile of the CVSS score for those CVEs. Finally, we translate numerical scores to critical, high, medium, or low using the following definitions:
| Severity | Score Range |
|---|---|
| None | 0.0 |
| Low | 0.1 – 3.9 |
| Medium | 4.0 – 6.9 |
| High | 7.0 – 8.9 |
| Critical | 9.0 – 10.0 |
security-severity levels cause pull request check failureBy default, any code scanning alerts with a security-severity of critical or high will cause pull request check failure. You can specify which security-severity level for code scanning results should cause check failure by going to the Security & Analysis tab in the repository settings.
Severity levels for non-security alerts remain as error, warning, or note. By default, any code scanning results with the severity of error will cause check failure. You can change this setting using the dropdown on the Security & Analysis tab in the repository settings. It allows two selections that apply to the security and non-security alerts.
You can also access security_severity_level data for security queries using the /alerts endpoint of the code scanning API.
security-severity to a CodeQL queryYou can add the expected security-severity level to the your custom security queries by adding the numerical score to the @security-severity query metadata property in the .ql file.
The new security-severity levels for security queries have been deployed to GitHub.com. These improvements will also be available in GitHub Enterprise Server 3.2.
Learn more about CodeQL and code scanning by reading the documentation.