Factor in cascading duo settings at the Vulnerability::Finding level
What does this MR do and why?
This change makes finding.ai_explanation_available?
and
finding.ai_resolution_available?
dependent on the
cascading duo settings
This is being done in response to a thread where it was discussed what would happen if a project:
- has SAST findings
- These findings are of duo-supported CWEs
- These projects are included in mixed-group dashboard (such as the
InstanceSecurityDashboard
I think, prior to this change, those projects would display the "resolve with duo" sparkle icon
These changes mean that AI explanation and resolution features for
vulnerability findings are now dependent on both the report
type (which must be SAST) and the duo_features_enabled
setting of
the project.
This could have side effects where we are trying to do some operations where we intend to operate on "all findings that could be duo resolved, if duo was enabled"
vulnerability_read.has_vulnerability_resolution
Filtering based on We added the has_vulnerability_resolution
column to the
vulnerability_reads
table and used it to add filtering in the
graphql API
I believe that will end up being affected by the same issue summarized above.
That fix will be tackled in a separate commit/MR
Demo
before | updating finding model |
updating vulnerability_reads
|
---|---|---|
before | finding | filter |
Here is the setup. I have the Gnuwget group that has duo enabled. It has two subgroups, GitLab Org has duo enabled. no ai enabled , well, it as duo disabled.I have the webgoat project in both subgroups. These projects both have findings that are eligible for duo resolution. Without any change, we see badges on all findings because we currently do not account for the cascading settings |
With the change to the finding model, the badge is now properly turned off for the no ai enabled project |
updating the scope on the vulnerability_reads fixes the filtering. This may require a custom index |
SQL
tbd
- explain: tbd
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
epic:&15036
related to: #496332 (closed)
related to: #496463 (closed)
Changelog: changed
EE: true