advanced-security

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.

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.

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.

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.

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.