Document nosemgrep comment behavior in SAST

The Semgrep-based analyzer ignores findings on lines with matching nosemgrep annotations, but this isn't currently documented.

While analyzer-agnostic comments would be useful (see GitLab-native code annotations to exclude findi... (#384569), for instance) we should document current behavior when it exists.

We should recommend against specifying specific rule IDs in nosemgrep comments because we do not guarantee that rule IDs are stable over time. Rule IDs can also change as analyzers are transitioned.

(See also Add a SAST configuration option to disable comm... (#439291) for those who don't want this behavior because it allows findings to be bypassed through the codebase rather than in Vulnerability Management.)

Related work

A similar option in Category:Secret Detection is documented as such:

In some instances, you might want to ignore a secret. For example, you may have a fake secret in an example or a test suite. In these instances, you want to ignore the secret, instead of having it reported as a vulnerability.

To ignore a secret, add gitleaks:allow as a comment to the line that contains the secret.

For example:

"A personal token for GitLab will look like glpat-JUST20LETTERSANDNUMB" #gitleaks:allow

https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/index.html#ignore-secrets

For this use case I'd rather suggest that people use Vulnerability Management to dismiss the finding; consider disabling the rule if it's never valid; or adjust the scanned file paths using SAST_EXCLUDED_PATHS before they start doing this type of finding-by-finding comment annotation.

Edited by Connor Gilbert