Spike: Verify security report comparison logic between Threat Insights and Security Policies after consolidation
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
Currently, ~"group::threat 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
- ~"group::threat 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
refandshawith that reference pipeline for each security orchestration CI pipeline source.
-
Using the child pipelines
- ~"group::threat 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
- ~"group::threat insights" is using the security report artifacts produced by the security jobs. ~"group::threat insights" has an issue to start using the
Security::Findingrecords. -
groupsecurity policies is using the
Security::Findingrecords stored in the database.
- ~"group::threat insights" is using the security report artifacts produced by the security jobs. ~"group::threat 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.