codeql-action
codeql-action copied to clipboard
Allow setting tags for sarif uploads
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.
Hi @pmatos Can you provide more details on this scenario? I'm not sure I get what you're hoping to accomplish. Thanks!
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.
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.
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 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.
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?
@turbo or @AlonaHlobina could you have a look at this?
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.