[Feature flag] Enable vulnerability_signatures_dedup_by_type

Summary

This issue is to safely roll out a bug fix related to Advanced Vulnerability Tracking that led to a too coarse vulnerability deduplication. The fix includes the signature name into the comparison so that we do not deduplicated unrelated findings anymore as illustrated in Semgrep-based SAST reports does not report all ... (#469038 - closed) • Julian Thome • 17.11.

Owners

Most appropriate Slack channel to reach out to: #g_ast-static-analysis
Best individual to reach out to: @julianthome @gitlab-org/secure/static-analysis

Expectations

What are we expecting to happen?

Semgrep-based SAST reports does not report all ... (#469038 - closed) • Julian Thome • 17.11 should be fixed.

The fix will lead to a refinement of vulnerabilities (increased number) as opposed to coarsening where not related vulnerabilities were deduplicated before. Hence, there will be a potential increase in vulnerabilities if collisions are no longer occurring. This could manifest in 3 ways:

A. We will likely see an increase in vulnerability_signatures immediately upon disabling deduplication. Other than additional load it should be a no-op as we don't use anything but the highest priority.
B. We could see an increase in vulnerabilities that have been deduped previously due to collisions.
C. We could see a significant churn in detected vulnerabilities if signatures are misaligning (drift between identical "no longer detected" and "newly detected" vulnerabilities).

What can go wrong and how would we detect it?

Our preliminary data analyses 1, 2 did not indicate that we'll see a huge spike in findings.

However, we should look for cases where large amounts of vulnerabilities may get reintroduced or where the vulnerability deduplication fails.

see this comment

Note: Please make sure to run the chatops commands in the Slack channel that gets impacted by the command.

Phase 1: Rollout on non-production environments

Verify the MR with the feature flag is merged to master and has been deployed to non-production environments with /chatops run auto_deploy status 85b4da33382f1fed06921e62780e89c081e49afb (Slack link) (Slack link)
Create test project and test behaviour with FF disabled deduplication works as expected
Enable the feature flag for test project /chatops run feature set --project=testgroup1562213/testproject2 vulnerability_signatures_dedup_by_type true --staging
Test behaviour on test project with FF enabled; deduplication works as expected
Enable the feature globally on non-production environments with /chatops run feature set vulnerability_signatures_dedup_by_type true --dev --pre --staging --staging-ref (Slack link)

When deploying the feature to staging we should verify that with vulnerability_signatures_dedup_by_type disabled, we see the behaviour described in Rails Backend: Vulnerability fingerprints are c... (#470170 - closed) • Julian Thome • 17.11 • On track and with https://gitlab.com/gitlab-org/gitlab/-/issues/470170 we should see all the vulnerabilities that are reported by the scanner.

Phase 2: Dogfooding

For visibility, all /chatops commands that target production must be executed in the #production Slack channel and cross-posted (with the command results) to the responsible team's Slack channel.

Ensure that the feature MRs have been deployed to both production and canary with /chatops run auto_deploy status 85b4da33382f1fed06921e62780e89c081e49afb (Slack link)
Notify the groupstatic analysis about the enabled FF (Slack link)
/chatops run feature set --project=gitlab-org/security-products/analyzers/bandit,gitlab-org/security-products/analyzers/brakeman,gitlab-org/security-products/analyzers/eslint,gitlab-org/security-products/analyzers/flawfinder,gitlab-org/security-products/analyzers/gitlab-advanced-sast,gitlab-org/security-products/analyzers/gosec,gitlab-org/security-products/analyzers/kics,gitlab-org/security-products/analyzers/kubesec,gitlab-org/security-products/analyzers/mobsf,gitlab-org/security-products/analyzers/nodejs-scan,gitlab-org/security-products/analyzers/phpcs-security-audit,gitlab-org/security-products/analyzers/pmd-apex,gitlab-org/security-products/analyzers/security-code-scan,gitlab-org/security-products/analyzers/semgrep,gitlab-org/security-products/analyzers/sobelow,gitlab-org/security-products/analyzers/spotbugs vulnerability_signatures_dedup_by_type true (Slack link) (2025-03-26)
Wait for at least three days so that we have enough time monitoring the impact with regards to A,B and C
/chatops run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss vulnerability_signatures_dedup_by_type true (Slack link) (2025-03-31)
Wait for at least three days so that we have enough time monitoring the impact with regards to A,B and C
Verify that the feature works for the specific actors.

Phase 3: Global Rollout

Preparation before global rollout

Set a milestone to this rollout issue to signal for enabling and removing the feature flag when it is stable.
Check if the feature flag change needs to be accompanied with a change management issue. Change Management issue
Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production. If a different developer will be covering, or an exception is needed, please inform the oncall SRE by using the @sre-oncall Slack alias.
~~Ensure that documentation exists for the feature, and the version history text has been updated.~~
E~~nsure that any breaking changes have been announced following the release post process to ensure GitLab customers are aware.~~
Notify the #support_gitlab-com Slack channel and your team channel (more guidance when this is necessary in the dev docs (Slack link)

Global rollout on production

For visibility, all /chatops commands that target production must be executed in the #production Slack channel and cross-posted (with the command results) to the responsible team's Slack channel.

Rollback Steps

This feature can be disabled on production by running the following Chatops command:

/chatops run feature set vulnerability_signatures_dedup_by_type false

Disable the feature flag on non-production environments:

/chatops run feature set vulnerability_signatures_dedup_by_type false --dev --pre --staging --staging-ref

Delete feature flag from all environments:

/chatops run feature delete vulnerability_signatures_dedup_by_type --dev --pre --staging --staging-ref --production

Once this issue is completed we incrementally rollout TC with disabled internal deduplication in tracking calculator.

Feature flag cleanup

We created a dedicated (follow-up) FF cleanup issue here: [Feature flag] Cleanup vulnerability_signatures... (#534898 - closed) • Adam Cohen • 18.3 • On track.

Edited Apr 10, 2025 by Julian Thome