<!-- Implementation issues are used break-up a large piece of work into small, discrete tasks that can move independently through the build workflow steps. They're typically used to populate a Feature Epic. Once created, an implementation issue is usually refined in order to populate and review the implementation plan and weight. Example workflow: https://about.gitlab.com/handbook/engineering/development/threat-management/planning/diagram.html#plan --> ## Why are we doing this work <!-- A brief explanation of the why, not the what or how. Assume the reader doesn't know the background and won't have time to dig-up information from comment threads. --> As discussed in this [thread](https://gitlab.com/groups/gitlab-org/-/epics/8293#note_1760788490), `dependency_files` will be removed from the security reports and there is a need of an equivalent feature from cyclonedx reports (i.e., [dependency-graph](https://cyclonedx.org/use-cases/#dependency-graph)). ## Relevant links <!-- Information that the developer might need to refer to when implementing the issue. - [Design Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>) - [Design 1](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png) - [Design 2](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png) - [Similar implementation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/<id>) --> ## Implementation plan <!-- Steps and the parts of the code that will need to get updated. The plan can also call-out responsibilities for other team members or teams and can be split into smaller MRs to simplify the code review process. e.g.: - MR 1: Part 1 - [ ] ~frontend Step 1 - [ ] ~frontend Step 2 - MR 2: Part 2 - [ ] ~backend Step 1 - [ ] ~backend Step 2 - MR 3: Part 3 - [ ] ~frontend Step 1 - [ ] ~frontend Step 2 --> - [ ] ~database Create a new `jsonb` column in `sbom_occurrences` in order to store `ancestors` in the following format: `[{name: 'name', version: '0.0.0'}]`. - [ ] ~backend Update [ancestors](https://gitlab.com/gitlab-org/gitlab/-/blob/f2fcf417378c70f14661e6184700fe74465bfbfe/ee/app/models/sbom/occurrence.rb#L138) to be based on the persisted information. - [ ] ~backend Update [occurrence_map](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/sbom/ingestion/occurrence_map.rb?ref_type=heads) and/or [occurrence_map_collection](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/sbom/ingestion/occurrence_map_collection.rb?ref_type=heads) in order to process (based on `dependsOn`) occurrences into a hash containing for fast lookup of shortest paths. See [this comment](https://gitlab.com/gitlab-org/gitlab/-/issues/441118#note_1765177985) for more details. - [ ] ~backend Update [ingestion](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/sbom/ingestion/tasks/ingest_occurrences.rb?ref_type=heads#L22-46) to ingest `ancestors`. **open question:** Should we also store this information on [sbom_sources](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/sbom/source.rb) ? ### Report examples: |Dependency scanning|CycloneDx| |--|--| |[gl-dependency-scanning-report.json](/uploads/301b94411ab3cb54c0357be1aac86e25/gl-dependency-scanning-report.json) |[gl-sbom-trivy-report.cdx.json](/uploads/d4eda3757cdb48c11252b60e0d76bd00/gl-sbom-trivy-report.cdx.json)| ### Example of the existing feature:  <!-- Workflow and other relevant labels # ~"group::" ~"Category:" ~"GitLab Ultimate" Other settings you might want to include when creating the issue. # /assign @ # /epic & --> ### Verification steps 1. FF has been enabled to [this project](https://gitlab.com/gitlab-org/govern/threat-insights-demos/verification-projects/verify-408846-group/verify-408849-project). 1. Go the project level [dependency list page](https://gitlab.com/gitlab-org/govern/threat-insights-demos/verification-projects/verify-408846-group/verify-408849-project/-/dependencies). 1. Check that there are ancestors being displayed (including popup dialog).