codeql-action icon indicating copy to clipboard operation
codeql-action copied to clipboard

Allow setting tags for sarif uploads

Open pmatos opened this issue 4 years ago • 8 comments

It would be useful at time of upload to be able to either tag sarif upload of override the tool name.

Software artifacts that can be build differently from the same sources (for example cross-builds) could use a way to differentiate between vulnerabilities in different artifacts.

pmatos avatar Aug 03 '20 06:08 pmatos

Hi @pmatos Can you provide more details on this scenario? I'm not sure I get what you're hoping to accomplish. Thanks!

jhutchings1 avatar Aug 03 '20 14:08 jhutchings1

Hi @pmatos Can you provide more details on this scenario? I'm not sure I get what you're hoping to accomplish. Thanks!

Sure - apologies if I was too terse.

I am discussing racket/racket here. In our CI, we can build from the same sources 3 different types of compiler: let's call it a, b and c. Each of these, due to the way they are compiled (mainly compile-time parameters) can have different static analysis results.

We run the LLVM static analyzer scan-build on the three different compilation modes, create sarif files and upload. The problem is that github aggregates the results based on tool name. The tool name is clang for all of the three modes. However, it would be good to tag the results as well. So we can tag the results during the sarif upload and call them vulnerabilities-a, vulnerabilities-b and vulnerabilities-c for each of the compilation modes.

pmatos avatar Aug 03 '20 15:08 pmatos

Also, I recall that this is relevant not only for different compilation modes but also different architectures. So, in arm32 you might get one set of vulnerabilities and in arm64 another set. The same tool clang will create both sarif files but it would be great to distinguish which of the architecture contain some vulnerability. If you nowadays just use upload-sarif for both arm32 and arm64 vulnerabilities they will be conflated in the vulnerabilities panel under the clang tool.

pmatos avatar Aug 03 '20 15:08 pmatos

I have added a workaround - which hope it works - to trick the system into splitting the vulnerabilities. Instead of splitting by tag (which is what makes sense) I split by toolname. That's what https://github.com/racket/racket/commit/e62b3b8c1c2212e8ffa54f1589347cf95dbe1cbf is about.

pmatos avatar Aug 03 '20 15:08 pmatos

@pmatos Thanks for clarifying (and sorry for the delay). It sounds like this is the same pattern we're using the matrix parameter for. That would allow you to separate the vulnerabilities according to a particular configuration without changing the tool name.

jhutchings1 avatar Sep 02 '20 23:09 jhutchings1

Sorry - I know this is an old convo :) but the closest thing to what seems like a general case - "one tool, many artifacts" - sarif problem :) Is using matrix still the best "workaround" here?

jpcmonster avatar Dec 04 '23 16:12 jpcmonster

@turbo or @AlonaHlobina could you have a look at this?

jhutchings1 avatar Dec 04 '23 18:12 jhutchings1

It sounds like what you want is to you want is to specify a custom category for each configuration.

This will allow you to run multiple analyses over the same code when it is built for different platforms and using different configurations.

aeisenberg avatar Dec 04 '23 19:12 aeisenberg