GitLab-native code annotations to exclude findings from the results

This issue records @twoodham's feature idea from this Slack thread.

At the moment we can use custom rulesets to disable entire rules if they yield false positives in certain contexts. This strategy does not work for situations where users want to disable only a sub-set of findings that may be triggered by the application of a certain rule. (Example). We could use analyzer specific annotations (like nosec or nosemgrep) but this bleeds details about the underlying scanner, makes it difficult for us to change underlying scanners and is not very user-friendly as users would have to learn different annotations for different scanners which should be transparent to them.

Proposal

An analyzer-agnostic, GitLab-native code annotation with which we could frame portions of the source-code that should be excluded from the results. If we would use a source comment-based approach, the main difficulty would be to consider all of the different comment types we have for different language but tree-sitter could do that for us. We could deploy this as a post-analyzer that first identifies the scopes/line number ranges that should be excluded by looking for the annotations and then excludes them from the report in a second step.

We could have a new configuration variable available to define the string used to disable rules. It would have a sane default like gitlab-sast-ignore, but customers could override it if they already have a code comment convention and they are bringing their project into gitlab. More bonus points to be awarded if the handling of this config value could be exploded into an array, allowing customers time to transition to the gitlab-native string from what they’re using already.

Update regarding Advanced SAST

With the introduction of Advanced SAST and consolidation of scanners, we can make this change relevant only for the Advanced SAST, and consider backward compatibility for semgrep transitioning to the Advanced SAST.

/cc @gitlab-org/secure/vulnerability-research @twoodham @theoretick @connorgilbert @amarpatel @wayne @hbenson