Consolidate malware detection feature flags

What does this MR do and why?

Malware detection was spread across 6 feature flags owned by 2 groups, which made it difficult to roll the feature out in a coordinated way.

4 of those flags are replaced by 2, scoped by domain:

• vulnerability_malware_detection gates the vulnerability report and details page across both the frontend and the backend.
• dependency_malware_detection controls only the malware badge on the dependency list frontend, and takes effect only once stacked MR !249418 (merged) merges. It does not gate the dependency GraphQL malware field or malware filter — those stay behind their own wip flags (dependency_malware_field_project and malicious_packages_dependency_list_filtering), which this MR leaves untouched.

Some notes:

• Keeping them separate means the vulnerability report can be enabled without also turning on dependency UI whose backend is not ready. It also scopes vulnerability_malware_detection and dependency_malware_detection to a group.
• sscs_malware_detection is removed. Malicious vulnerability management ships to all Ultimate customers rather than as an add-on, so malware_status_for no longer needs the add-on check and no longer returns nil for a package it has checked and found clean.
• The two dependency backend flags are left as they are until the Elasticsearch filtering APIs are finished.

References

gitlab-org#18456 (comment 3652929251)

Screenshots or screen recordings

No visual changes

How to set up and validate locally

1. Make sure you have a project (like https://gitlab.com/gitlab-org/govern/threat-insights-demos/verification-projects/bala-test-group/malicious-badge-demo) containing at least one vulnerability whose identifier starts with GLAM-, since that prefix is what marks a finding as malware. You can use an existing seeded environment, or update one vulnerability's identifier so it starts with GLAM-.

2. Enable the flags at http://gdk.test:3000/rails/features/vulnerability_malware_detection and http://gdk.test:3000/rails/features/dependency_malware_detection. Toggling each flag fully on is sufficient for basic verification. To verify group scoping instead of a global toggle, add an actor on the flag page using the format Group:<id> for a group or subgroup, or Project:<id> for a single project. The check passes if the flag is enabled for the top-level group, for the subgroup itself, or for the individual project actor.

3. Keep in mind that this MR alone produces no visible UI change, because the frontend still reads the old flag name until the stacked follow-up MR (!249418 (merged)) merges.

4. Use GraphQL explorer at http://gdk.test:3000/-/graphql-explorer and run the following query, substituting your project's path.

   query {
     project(fullPath: "your-group/your-project") {
       vulnerabilities(malware: true) {
         nodes { title malware }
       }
     }
   }

5. With the flag enabled, confirm that only the GLAM- vulnerability is returned and that its malware field is true.

6. With the flag disabled,

   1. confirm that the query is rejected with the error "The malware filter is not available.",
   2. and that querying the malware field without the filter returns null.

7. On the project vulnerability report page, open the browser console and evaluate gon.features.vulnerabilityMalwareDetection. It should be true when the flag is enabled for the root group, the subgroup, or the project actor, and false otherwise. On a dependency list page, check the equivalent key, gon.features.dependencyMalwareDetection.

8. To confirm scoping works correctly, enable the flag only for a subgroup actor and verify that both the GraphQL filter and the gon value are on for a project inside that subgroup, and off for an unrelated project.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related MRs

Since !249418 (merged) renames the frontend feature-flag checks to the new names and removes the malicious_package_detection flag definition, and this MR is the backend counterpart stacked underneath it, this MR keeps the malicious_package_detection definition in place for now. The frontend still checks that flag here, and deleting the definition would leave those checks pointing at nothing.