Improve performance of the Vulnerability Findings computed state
Summary
The computed state of a vulnerability Finding
needs to be improved for collection queries to avoid N+1
queries. Also, memoization or reactive caching may be involved to reduce DB queries for individual model instances.
This computed state was introduced to support Resolve Vulnerability operation for the new Vulnerabilities API implemented within First-Class Vulnerabilities MVC.
Improvements
- Currently, every call to
Finding
'sstate
method results in an additional DB query forvulnerability_feedback
table - When a collection query for Findings is executed, there's currently no way to populate the
Findings
with the computed state in a single query; we have manually fetch or assign the associatedVulnerabilities
to provide the state
These performance issues need to be addressed.
Risks
- The implementation of the memoized computed state may be too complex
- The memoization of the computed state may lead to the "stale state" errors, so needs to be handled carefully
- Improvement of the collection queries for
Findings
may require moving computed state to SQL level
Involved components
-
Vulnerabilities::Occurrence
model Security::PipelineVulnerabilitiesFinder
- may be more
Implementation plan
The Security::PipelineVulnerabilitiesFinder
is parsing the report artifacts over and over again and then loading the vulnerability feedback records to determine the state of the finding. The recently introduced finder Security::FindingsFinder
can do the same thing with just one database query.
-
backend Stop using the Security::PipelineVulnerabilitiesFinder
and useSecurity::FindingsFinder
instead in following components;-
API::VulnerabilityFindings
-
Ci::CompareSecurityReportsService
-
Resolvers::PipelineSecurityReportFindingsResolver
-
-
backend Remove the Security::PipelineVulnerabilitiesFinder
class and related tests
Edited by Mehmet Emin INAC