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

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

No two codebases are the same and each is subject to different security risks and threats. Such risks and threats can be captured in a codebase's threat model which, in turn, depends on how the code has been designed and will be deployed. To understand the threat model you need to know what type of data is untrusted and poses a threat to the codebase. Additonally, you need to know how that unstrusted (or tainted) data interacts with the application. For example, one codebase might only consider data from remote network requests to be untrusted, whereas another might also consider data from local files to be tainted.

CodeQL can perform security analysis on all such codebases, but it needs to have the right context. It needs the threat model in order to behave slightly differently on different codebases. That way, CodeQL can include (or exclude) the appropriate sources of tainted data during its analysis, and flag up the most relevant security vulnerabilities to developers who work on the 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. Using new CodeQL threat model settings for Java, you can now optionally mark local sources of data as tainted. This includes data from local files, command-line arguments, environment variables, and databases. You can enable the local threat model option in code scanning to help security teams and developers uncover and fix more potential security vulnerabilities in their code.

CodeQL threat model settings can be configured in repositories running code scanning with CodeQL via default setup in the GitHub UI. Alternatively, you can specify it through advanced setup (in an Actions workflow file).

If your repository is running code scanning default setup on 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.

If your repository is running code scanning advanced setup on 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.

CodeQL threat model settings (beta) in code scanning default setup is available on GitHub.com for repositories containing Java code. It will be shipped in GitHub Enterprise Server 3.13.

See more

Code scanning default setup is now available for self-hosted runners on GitHub.com. To use default setup for code scanning, assign the code-scanning label to your runner. Default setup now uses actions/github-script instead of the GH CLI. If your organization has a policy which limits GitHub Actions you will need to allow this action in your policy.

Code scanning sees assigned runners when default setup is enabled. As a result, if a runner is assigned to a repository which is already running default setup, you must disable and re-enable default setup to initiate using the runner.

Larger runners are in beta support, with the limitations that you can only define one single larger runner at the org level with the label code-scanning, and Swift analysis is not supported.

For more information, see “Using labels with self-hosted runners.”

Runner with code-scanning label

This is now available on GitHub.com. Self-Hosted runners for default setup are already supported from GitHub Enterprise Server 3.9.

See more

CodeQL 2.15.4 is rolling out to users of GitHub code scanning on github.com this week, and all new functionality will also be included in GHES 3.12. Users of GHES 3.11 or older can upgrade their CodeQL version.

Important changes in this release include:

  • Performance improvements on large runners (instances with 8 to 16 vCPUs) lead to a reduction in end to end analysis time between 5% and 15%, due to more effective parallelization. Where possible, upgrading to larger instances is recommend for projects that currently use 4 or fewer vCPUs and take more than 10 minutes to analyze.
  • Analysis times for C and C++ code bases of any size are reduced on average by 6%
  • TypeScript 5.3, Java 21 and Python 3.12 are now supported.
  • We have resolved a problem causing scan timeouts on macOS (the default for Swift analysis). This problem affected up to 10% of scans for some projects. Although timeouts may still occur, they are now expected in less than 0.5% of scans. We are actively addressing the remaining issues.

For a full list of changes, please refer to the complete changelog for version 2.15.4.

See more

CodeQL 2.15.3 is rolling out to users of GitHub code scanning on github.com this week, and all new functionality will also be included in GHES 3.12. Users of GHES 3.11 or older can upgrade their CodeQL version.

Important changes in this release include:

For a full list of changes, please refer to the complete changelog for version 2.15.3.

See more

Code scanning default setup now automatically attempts to analyze all CodeQL supported languages in a repository. This means default setup supports all CodeQL languages at the organization level, including enabling code scanning from an organization's Security Overview coverage page or settings page.

Previously, users would have to manually include the languages C, C++, C#, Java, or Kotlin in a default setup analysis, and enabling these languages was not supported at the organization level. Now, code scanning default setup automatically attempts to analyze all languages supported by CodeQL in a repository. If any analyses fail, the failed language will be automatically deselected from the code scanning configuration. Any alerts from the successfully analyzed languages will be shown on GitHub. This means code scanning will automatically set up the best possible configuration to get started easily with CodeQL and show the most relevant alerts to developers.

A warning banner is shown in the repository settings page if any languages fail and are deseslected. The "edit configuration" page shows all languages in the configuration, and allows users to change the language selection if required. For more information about the languages and versions supported by CodeQL and code scanning, see Supported languages and frameworks. To learn more about code scanning, see About code scanning.

This change is already available on GitHub.com and will be available in GitHub Enterprise Server 3.12.

See more

To enable developers to write code as securely as possible in their language of choice and using the latest features available, we constantly update code scanning with CodeQL. As such we are happy to announce that CodeQL now supports analyzing code written in Go 1.21.

Go 1.21 support is available by default in GitHub.com code scanning, CodeQL version 2.14.6, and GHES 3.11. For more information about the languages and versions supported by CodeQL and code scanning, see Supported languages and frameworks. To learn more about code scanning, see About code scanning.

See more

In February 2022, we introduced experimental CodeQL queries that utilize machine learning to identify more potential vulnerabilities. This feature was only available for JavaScript / TypeScript code and was available to code scanning users that enabled the optional security-extended or security-and-quality query suites.

We disabled this experimental feature for new code scanning users in June 2023. Today, we're sunsetting it for all users.

Any currently open code scanning alerts from these queries (Rule ID starts with js/ml-powered/) will be closed. Closed alerts will still be visible in the code scanning alerts view in your repository’s Security tab. The complete history of each alert will remain accessible by clicking on the alert.

CodeQL will continue to run the existing non-ML versions of these queries and provide you with highly precise and actionable alerts.

We’ve learned a lot from the feedback and experience of the repositories that participated in this experiment, and we’ve since ramped up our investment in AI-powered security technology. This new technology is already boosting our ability to cover more sources and sinks of untrusted data in order to significantly increase the coverage and depth of all queries.

See more

With CodeQL model packs for Java, users can improve their code scanning results by ensuring that any custom Java libraries and frameworks used by their codebase are recognised by CodeQL.

The out-of-the-box CodeQL threat models provide great coverage for identifying large numbers of potential vulnerabilities in GitHub repositories using code scanning. We are continually working to improve CodeQL's ability to recognize and track potential sources of untrusted data to potentially-vulnerable locations ('sinks'). To do that, we keep a close eye on the most widely-used open-source libraries and frameworks. That way, CodeQL can recognize untrusted data that enters an application through, for example, commonly-used web frameworks. We are even using advances in AI to boost our threat modeling efforts and help developers write even more secure code.

There will always be cases which are not covered by CodeQL's standard threat models, such as custom-built or inner-sourced frameworks and libraries. Using CodeQL's new model pack functionality for Java (beta), security teams and security-conscious developers can create custom models that help CodeQL detect and flag additional security vulnerabilities. These custom model packs work seamlessly in GitHub code scanning, which means developers get the most relevant code scanning alerts during their day-to-day work.

CodeQL model packs are part of the CodeQL package management ecosystem. The packs contain structured data which describe whether a method within a library is a taint source, sink, or propagator (also known as a flow summary). You can create CodeQL model packs for Java using the CodeQL model editor, a new feature in the CodeQL extension for VS Code. The CodeQL model editor includes support for:

  • identifying methods in your codebase that aren't recognised by the standard CodeQL analysis
  • interactively classifying those methods as a source, sink, or summary
  • automatically generating a CodeQL model pack that can be easily added to code scanning.

For more information about using CodeQL model packs in code scanning, see:

For more information about using the CodeQL model editor, see Using the CodeQL model editor.

See more

Code scanning with CodeQL now supports Java codebases that use Project Lombok. Previously, code scanning users were able to scan Java applications that contained Lombok code, but all the contents of files containing Lombok code were either skipped or users had to apply a workaround to prepare the applications for scanning. The improved support means that code with Lombok features will be automatically scanned without requiring any workaround.

As more code will now be analyzed by the CodeQL engine, we can establish more accurate data flow (or lack thereof) through Lombok code. This might have an impact on the number of alerts produced by a scan. The most common scenario is that additional alerts appear in the newly-analyzed code. Conversely, there is a very small chance that some existing alerts are closed.

Improved support for Java applications built using Lombok is available for code scanning users on GitHub.com starting today and GitHub Enterprise Server users starting with 3.11. CodeQL CLI will provide out of the box support starting with the upcoming version 2.14.4. Security researchers can set up the CodeQL CLI and VS Code extension by following these instructions.

See more

In addition to scanning push and pull requests, code scanning default setup now also analyzes repositories on a weekly schedule. This ensures that a scan with the most recent version of CodeQL is run regularly on your code, better protecting both active and inactive repositories. This allows users to always benefit from CodeQL engine and query improvements which are continuously released, and which could uncover new potential vulnerabilities.

When setting up code scanning, the fixed time for the weekly scan is randomly chosen. The scan will take place at the same time every week, and the schedule is displayed after the setup is completed, so you can easily see when the next scheduled analysis will occur. The scheduled analysis will be automatically disabled if a repository has seen no activity for 6 months. Opening a PR or pushing to the repo will re-enable the scheduled analysis.

Screenshot that shows the weekly scheduled scan

This has shipped to GitHub.com and will be released with GitHub Enterprise Server 3.11.

See more

We have released a new API for people who write custom CodeQL queries which make use of dataflow analysis. The new API offers additional flexibility, improvements that prevent common pitfalls with the old API, and improves query evaluation performance by 5%. Whether you’re writing CodeQL queries for personal interest, or are participating in the bounty programme to help us secure the world’s code: this post will help you move from the old API to the new one.

This API change is relevant only for users who write their own custom CodeQL queries. Code scanning users who use GitHub’s standard CodeQL query suites will not need to make any changes.

With the introduction of the new dataflow API, the old API will be deprecated. The old API will continue to work until December 2024; the CodeQL CLI will start emitting deprecation warnings in December 2023.

To demonstrate how to update CodeQL queries from the old to the new API, consider this example query which uses the soon-to-be-deprecated API:

class SensitiveLoggerConfiguration extends TaintTracking::Configuration {
  SensitiveLoggerConfiguration() { this = "SensitiveLoggerConfiguration" } // 6: characteristic predicate with dummy string value (see below)

  override predicate isSource(DataFlow::Node source) { source.asExpr() instanceof CredentialExpr }

  override predicate isSink(DataFlow::Node sink) { sinkNode(sink, "log-injection") }

  override predicate isSanitizer(DataFlow::Node sanitizer) {
    sanitizer.asExpr() instanceof LiveLiteral or
    sanitizer.getType() instanceof PrimitiveType or
    sanitizer.getType() instanceof BoxedType or
    sanitizer.getType() instanceof NumberType or
    sanitizer.getType() instanceof TypeType
  }

  override predicate isSanitizerIn(DataFlow::Node node) { this.isSource(node) }
}

import DataFlow::PathGraph

from SensitiveLoggerConfiguration cfg, DataFlow::PathNode source, DataFlow::PathNode sink
where cfg.hasFlowPath(source, sink)
select sink.getNode(), source, sink, "This $@ is written to a log file.",
 source.getNode(),
  "potentially sensitive information"

To convert the query to the new API:

  1. You use a module instead of a class. A CodeQL module does not extend anything, it instead implements a signature. For both data flow and taint tracking configurations this is DataFlow::ConfigSig or DataFlow::StateConfigSigif FlowState is needed.
  2. Previously, you would choose between data flow or taint tracking by extending DataFlow::Configuration or TaintTracking::Configuration. Instead, now you define your data or taint flow by instantiating either the DataFlow::Global<..> or TaintTracking::Global<..> parameterized modules with your implementation of the shared signature and this is where the choice between data flow and taint tracking is made.
  3. Predicates no longer override anything, because you are defining a module.
  4. The concepts of sanitizers and barriers are now unified under isBarrier and it applies to both taint tracking and data flow configurations. You must use isBarrier instead of isSanitizer and isBarrierIn instead of isSanitizerIn.
  5. Similarly, instead of the taint tracking predicate isAdditionalTaintStep you use isAdditionalFlowStep .
  6. A characteristic predicate with a dummy string value is no longer needed.
  7. Do not use the generic DataFlow::PathGraph. Instead, the PathGraph will be imported directly from the module you are using. For example, SensitiveLoggerFlow::PathGraph in the updated version of the example query below.
  8. Similar to the above, you’ll use the PathNode type from the resulting module and not from DataFlow.
  9. Since you no longer have a configuration class, you’ll use the module directly in the from and where clauses. Instead of using e.g. cfg.hasFlowPath or cfg.hasFlow from a configuration object cfg, you’ll use flowPath or flow from the module you’re working with.

Taking all of the above changes into account, here’s what the updated query looks like:

module SensitiveLoggerConfig implements DataFlow::ConfigSig {  // 1: module always implements DataFlow::ConfigSig or DataFlow::StateConfigSig
  predicate isSource(DataFlow::Node source) { source.asExpr() instanceof CredentialExpr } // 3: no need to specify 'override'
  predicate isSink(DataFlow::Node sink) { sinkNode(sink, "log-injection") }

  predicate isBarrier(DataFlow::Node sanitizer) {  // 4: 'isBarrier' replaces 'isSanitizer'
    sanitizer.asExpr() instanceof LiveLiteral or
    sanitizer.getType() instanceof PrimitiveType or
    sanitizer.getType() instanceof BoxedType or
    sanitizer.getType() instanceof NumberType or
    sanitizer.getType() instanceof TypeType
  }

  predicate isBarrierIn(DataFlow::Node node) { isSource(node) } // 4: isBarrierIn instead of isSanitizerIn

}

module SensitiveLoggerFlow = TaintTracking::Global<SensitiveLoggerConfig>; // 2: TaintTracking selected 

import SensitiveLoggerFlow::PathGraph  // 7: the PathGraph specific to the module you are using

from SensitiveLoggerFlow::PathNode source, SensitiveLoggerFlow::PathNode sink  // 8 & 9: using the module directly
where SensitiveLoggerFlow::flowPath(source, sink)  // 9: using the flowPath from the module 
select sink.getNode(), source, sink, "This $@ is written to a log file.", source.getNode(),
  "potentially sensitive information"

While not covered in this example, you can also implement the DataFlow::StateConfigSig signature if flow-state is needed. You then instantiate DataFlow::GlobalWithState or TaintTracking::GlobalWithState with your implementation of that signature. Another change specific to flow-state is that instead of using DataFlow::FlowState, you now define a FlowState class as a member of the module. This is useful for using types other than string as the state (e.g. integers, booleans). An example of this implementation can be found here.

This functionality is available with CodeQL version 2.13.0. If you would like to get started with writing your own custom CodeQL queries, follow these instructions to get started with the CodeQL CLI and the VS Code extension.

See more

The code scanning REST API updated_at field has been improved to help you review your most recently changed alerts.

The updated_at timestamp now returns the alert's most recent state change on the branch that you requested. We consider a state change to be a significant event, including an alert being introduced, fixed, dismissed, reopened or reintroduced. This is implemented in both the repo API and org API so it can be used consistently at scale.

Previously, the updated_at timestamp changed whenever an alert was found in an analysis or the alert state changed, and so was updated very regularly. This improvement lets you efficiently use updated_at to sort and focus on your most recently changed alerts.

The code scanning REST API list alerts endpoints code-scanning/alerts returns the value for the default branch, unless another branch is specificed. The alert endpoint code-scanning/alerts/{alert_number} reports at the alert level, so will return the maximum value for the alert across all branches.

This is now live on GitHub.com for the repository level API. This will be live for the organization level API over the next few days because it requires data reindexing. This will ship to GitHub Enterprise Server version 3.11. For more information, see the code scanning REST API documentation.

See more

Code scanning default setup is now available for Swift analysis with CodeQL! Default setup now supports all CodeQL supported languages at the repository level. This includes JavaScript/TypeScript, Ruby, Python, Go, Java, Kotlin, C/C++, C#, and Swift. We're working to support enabling code scanning at the organization level for all CodeQL languages soon.

Default setup automatically detects the languages used in a repository, and automatically analyzes JavaScript/TypeScript, Ruby, Python, and Go. You can also optionally customize the configuration to analyze Java/Kotlin, C/C++, C# and Swift. The configuration can be viewed and edited at any time, during or after set up. You can also use the REST API to include languages in the default setup configuration.

Java, Kotlin, C/C++, C# and Swift are not automatically included in the default setup configuration because they often require more advanced configuration. Code written in these languages needs to be compiled in order for CodeQL analysis to proceed. CodeQL will attempt to build your code automatically but may fail if your code requires bespoke build steps.

If a language fails in default setup, you will see an error message on the repository's settings page, in the code security and analysis section. To resolve the situation you can:

  1. Deselect the language from the configuration and continue to use default setup for the successful languages.
  2. Convert to advanced setup. The advanced setup uses a yml file and allows you to provide the build information required for the CodeQL analysis to succeed.
  3. Debug and fix the cause of the language failure. The Actions log will provide the failure reason so you can resolve this for a successful analysis.

For more information, see the documentation for when a particular language is causing default setup to fail. For more information on code scanning default setup, see Configuring code scanning automatically.

See more

CodeQL is the analysis engine that powers GitHub code scanning for over 100,000 repositories. We continuously improve our analysis capabilities, language support and performance to help open source developers and enterprises catch vulnerabilities before they make their way into production code. CodeQL is also an instrumental tool for the security researcher community and was used to identify 36 new CVE.

We release updates and improvements for CodeQL on a regular basis. We don’t get to call out all the improvements, but we want to highlight some of the most important updates we’ve shipped for CodeQL in the first half of the year:

  • Shortly before WWDC in June, we added beta support for Swift, which together with Kotlin completes CodeQL’s support for next-generation mobile development.
  • We’ve updated CodeQL to support these new language versions (view all): Swift 5.8.1, C#11 , .NET 7, Kotlin 1.8, Go 1.20, TypeScript 5.0 & 5.1, Ruby 3.2, Java 20.
  • We saw a 16% average performance improvement for CodeQL analyses.
  • We improved CodeQL modelling for popular Ruby libraries (SQLite, MySQL, Rack) and added coverage for more than 5000 API methods in Java, increasing analysis coverage and reducing false negatives.
  • We released a new mechanism called default setup, to configure CodeQL at the repo and the organization level.
  • We added 4 new memory-corruption queries for C/C++, 6 new queries for Java, 1 for Python and adjusted over 100 queries across all languages.
  • We started showing actionable information on the tool status page.
  • Enabled scanning Python repositories without installing dependencies.
  • We made the release process faster, 1 week, and optimised the roll-out strategy to get you on the latest release as quick as possible, benefiting from the latest updates in CodeQL.
  • Deprecated CodeQL Action v1 and enabled Dependabot to automatically move you to a newer version.

These features have been shipped across multiple versions of CodeQL from 2.12.0 up to 2.14.0, which are shipped with GHES 3.9 and upcoming 3.10. All users of CodeQL code scanning on GitHub.com automatically benefit from the latest improvements.

See more

You now have the option to select either the "Extended" or "Default" query suite when setting up code scanning with default setup for eligible repositories within your organization.

The multi-repo enablement panel on the security coverage page with a focus on code scanning enablement and the new query suite selection menu

Code scanning's default query suite has been carefully designed to ensure that it looks for the security issues most relevant to developers, whilst also minimizing the occurrence of false positive results. However, if you and your developers are interested in seeing a wider range of alerts, you can enable the extended query suite. This suite includes everything from the default query suite, plus additional queries with slightly lower precision and severity.

Choose a query suite

The query suite selection can be made whenever you enable code scanning with default setup:

  • When using "Enable all" on the organization settings page.
  • When enabling a single or multiple repositories on the security coverage page.
  • When enabling on a repository's settings page.
  • When using the "Enable or disable a security feature for an organization" endpoint.

Previously, our system would automatically choose the default query suite when you enabled code scanning with default setup. Now, you can choose either the extended or default query suite.

Recommend a query suite

Additionally, you can specify either the extended or default query suite as the preferred choice for your organization. This preference determines which query suite is "recommended" when a user is enabling code scanning setup with default setup.

The recommended setting for code scanning query suites and the resulting recommended tag on the organization settings page

These improvements have shipped to GitHub.com and will be available in GitHub Enterprise Server 3.11.

Learn more about configuring default setup for code scanning and send us your feedback
Learn more about GitHub Advanced Security

See more