How to add an AdditionalTaintStep globally ?

[hugo-syn]

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 :)

[hugo-syn]

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

[owen-mc]

Which language are you analyzing?

[hugo-syn]

Which language are you analyzing?

I'm analyzing Java

[smowton]

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.

[hugo-syn]

I would like to add a more complex additional step like the ones here, but globally: https://github.com/GitHubSecurityLab/CodeQL-Community-Packs/blob/7a6a71525bd2d3466718bd36b4c5b1b114bac532/java/lib/ResearchMode.qll#L86

[smowton]

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

[hugo-syn]

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"

2. 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 

3. 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/[email protected]!'
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

[aeisenberg]

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.

[hugo-syn]

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

[aeisenberg]

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.

[smowton]

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.

[hugo-syn]

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