Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

How to add an AdditionalTaintStep globally ? #18391

Answered by smowton
hugo-syn asked this question in Q&A
Discussion options

Hi, I would like to define and import an TaintTracking::AdditionalTaintStep for all the default path queries. Is it possible to do this ? If yes how can I do this, maybe with the extension model feature but I'm not sure.

Thanks :)

You must be logged in to vote

One approach you could take would be to customize CodeQL 2.17.4, the version the securitylab Java queries are built against. Then check out the source of https://github.com/GitHubSecurityLab/CodeQL-Community-Packs and run the query suite from there, so that it's using the standard library you just customised, not one packaged with a pack.

The downside is that you'd get the 2.17.4 versions of the standard query suite. A way around that could be to have two customised bundles: one of whatever version is running the standard query suite, presumably the latest, and one 2.17.4 to run the security-lab queries. If you're using these customised bundles in an Actions context, you might use a category

Replies: 3 comments 18 replies

Comment options

I found Customization.qll which seems a good candidate, but I have a file for each pack I don't know which one I should modify

You must be logged in to vote
0 replies
Comment options

Which language are you analyzing?

You must be logged in to vote
4 replies
Comment options

Which language are you analyzing?

I'm analyzing Java

Comment options

Is https://codeql.github.com/docs/codeql-language-guides/customizing-library-models-for-java-and-kotlin/ useful for your use case? That specifically handles additional taint steps that relate to library methods, e.g. propagating taint from a particular function call's parameter to its return value.

Comment options

Comment options

The tooling for this sort of customisation for usage on Actions is not very mature, but you might consider using the GitHub Security Lab's tooling at https://github.com/advanced-security/codeql-bundle-action and in particular its support for providing a Customizations.qll file documented at https://github.com/advanced-security/codeql-bundle-action?tab=readme-ov-file#customizations

Comment options

Hi @smowton I'm having issues with what you linked.

Here is what I tried:

  1. Workspace creation (not very sure)
$ cat codeql-workspace.yml
provide:
 - "java-customizations/qlpack.yml"
 - "/home/user/.codeql/packages/codeql/java-all/5.0.0/qlpack.yml"
  1. Custom pack creation
$ find java-customizations/
java-customizations/
java-customizations/synacktiv
java-customizations/synacktiv/java_customizations
java-customizations/synacktiv/java_customizations/Customizations.qll
java-customizations/qlpack.yml
java-customizations/codeql-pack.lock.yml
$ cat java-customizations/qlpack.yml
---
library: true
warnOnImplicitThis: false
name: synacktiv/java-customizations
version: 0.0.1
dependencies:
 codeql/java-all: ^5.0.0 
  1. Build the bundle
$ codeql-bundle -b codeql-bundle-linux64.tar.gz -w codeql-workspace.yml -o /tmp/output -p linux64 -l INFO java-customizations /home/user/.codeql/packages/codeql/java-all/5.0.0/
INFO: Creating custom bundle of codeql-bundle-linux64.tar.gz using CodeQL pack(s) in workspace .
INFO: Unpacking provided bundle codeql-bundle-linux64.tar.gz to /tmp/tmpicf7tabu.
INFO: Validating the CodeQL CLI version part of the bundle.
INFO: Found CodeQL CLI version 2.20.1.
CRITICAL: Failed to build custom bundle with reason: 'Could not resolve dependency codeql/java-all@^5.0.0 for pack synacktiv/java-customizations@0.0.1!'
INFO: Removing temporary directory /tmp/tmpicf7tabu used to build custom bundle.

I don't understand what I'm missing here do you have an idea ?

I can resolve the packs :

$ codeql resolve packs | grep -i 'codeql/java-all' -A 4
 codeql/java-all:
 @1.1.2: (library) /home/user/.codeql/packages/codeql/java-all/1.1.2/qlpack.yml
 @4.2.0: (library) /home/user/.codeql/packages/codeql/java-all/4.2.0/qlpack.yml
 @5.0.0: (library) /home/user/.codeql/packages/codeql/java-all/5.0.0/qlpack.yml
You must be logged in to vote
14 replies
Comment options

One thing that looks fishy to me is the java-sec.qls suite being inside of a custom pack. There is a limitation with query suites that a suite contained in a pack cannot reference queries from another pack. Instead, you can just have a qls file that exists outside of any packs.

You can run a query suite by passing it on the command line and it will automatically resolve all of the referenced packs (assuming they are all available in the registry or in --additional-packs.

I'm not sure if that will fix the problem you are having with codeql-bundle, but it's the next thing I'd try.

Comment options

Hi @aeisenberg thank you very much this fix my problem ! But not the codeql-bundle one.

Comment options

I am not familiar with codeql-bundle so I can't help much. Perhaps there's a flag you can use that avoids compiling the queries. This would mean that queries would need compilation immediately before analysis, but maybe that's ok. For example, the codeql pack bundle command accepts --no-precompile.

Comment options

One approach you could take would be to customize CodeQL 2.17.4, the version the securitylab Java queries are built against. Then check out the source of https://github.com/GitHubSecurityLab/CodeQL-Community-Packs and run the query suite from there, so that it's using the standard library you just customised, not one packaged with a pack.

The downside is that you'd get the 2.17.4 versions of the standard query suite. A way around that could be to have two customised bundles: one of whatever version is running the standard query suite, presumably the latest, and one 2.17.4 to run the security-lab queries. If you're using these customised bundles in an Actions context, you might use a category (https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning#configuring-a-category-for-the-analysis) so two different jobs, customised-latest-std-queries and customised-2.17.4-seclab-queries can report alerts individually without interfering.

In theory there's a cleaner way, to find the standard library pack your third-party pack needs (here, java-all 1.0.0 AKA the standard lib shipped with 2.17.4), customise it, then rewrite the third-party pack's dependencies to refer to the customisation just created. However I don't believe anyone has ever written tooling to do that. It may be possible to adapt https://github.com/advanced-security/codeql-bundle to do something like that.

Answer selected by hugo-syn
Comment options

Alright thank you very much for your help and time I'll do this :)

Comment options

Hi @aeisenberg thank you very much this fix my problem ! But not the codeql-bundle one.

(In case you're still having the same issue)

I ran into the same problem (but with v2.20.4, and the codeql/java-examples pack). I found that I had to change all my imports in the Customizations module to "private", preventing them from being re-exported (as per https://codeql.github.com/docs/ql-language-reference/modules/#import-statements).

So changing import java to private import java stopped the conflict errors during query pre-compilation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

AltStyle によって変換されたページ (->オリジナル) /