Spike: Verify security report comparison logic between Threat Insights and Security Policies after consolidation
Summary
Currently, groupthreat insights and groupsecurity policies have their own logic to compare vulnerabilities added/fixed by merge requests which can produce different results and cause confusion for the users. We want to consolidate the logic of comparing security reports for an MR to prevent that.
Given the following git commit graph;
Here are the differences between the groups;
-
Choosing the comparison base pipeline
- groupthreat insights is trying to use the latest "merge base pipeline"(pipeline 4 on the graph) if exists. If it does not exist, then it is using the latest "base pipeline"(pipeline 1 on the graph). This logic will be slightly changed by !133118 (merged).
-
groupsecurity policies is taking the latest completed pipeline for the target branch(pipeline 6 on the graph) as a reference and checking the latest completed pipelines with the same
ref
andsha
with that reference pipeline for each security orchestration CI pipeline source.
-
Using the child pipelines
- groupthreat insights is currently using the report artifacts generated by the child pipelines.
- groupsecurity policies is currently not using the report artifacts generated by the child pipelines. Here is a SPIKE for groupsecurity policies to investigate the performance impact of using the child pipelines.
-
Data source for the comparison logic
-
groupthreat insights is using the security report artifacts produced by the security jobs. groupthreat insights has an issue to start using the
Security::Finding
records. -
groupsecurity policies is using the
Security::Finding
records stored in the database.
-
groupthreat insights is using the security report artifacts produced by the security jobs. groupthreat insights has an issue to start using the
Improvements
Consolidate the logic of finding the target pipeline and the data source used, to reduce the maintenance cost and prevent inconsistent results between each group's features.