## Summary There is an inconsistency between vulnerabilities shown in the Dependency List and those shown in the Vulnerability Report. The Dependency List is often missing many vulnerabilities that have been identified by the Dependency Scanner with SBOM. ## Workaround Run a new pipeline on the default branch ## Steps to reproduce 1. Import https://gitlab.com/gitlab-org/govern/threat-insights-demos/571526-dependency-linkage-issue into GDK 2. Run pipeline on master 3. Dependency list has no vulnerabilities 4. Vulnerability report contains items related to dependencies ## Example Test project demonstrating the issue: [https://gitlab.com/gl-demo-ultimate-odupre/shared-tests/pygoat](https://gitlab.com/gitlab-org/govern/threat-insights-demos/571526-dependency-linkage-issue) - **Vulnerability Report**: Shows 64 vulnerabilities identified by dependency scanning - **Dependency List**: Shows 0 vulnerabilities ## Expected behavior All vulnerabilities identified by the dependency scanner should appear in both: - The Vulnerability Report - The Dependency List (linked to their respective dependencies) ## Actual behavior Many vulnerabilities appear in the Vulnerability Report but are completely missing from the Dependency List, making it difficult for users to understand which dependencies are affected. ## Impact This inconsistency: - Creates confusion for security teams trying to understand their dependency vulnerabilities - Makes it difficult to prioritize dependency updates - Reduces trust in GitLab's security scanning capabilities - Impacts the user experience when managing security findings ## Additional context According to @bwill's analysis: > Vulnerabilities are linked to dependencies via the location information. If the `name`, `version`, and `file` (ex: `pipdeptree.json`) match, then the vulnerability is shown on the dependency list. This suggests there may be a mismatch in how location information is being processed between the vulnerability detection and dependency list display. ### Root cause Current workflow is as follow: 1. On pipeline completion (or when all security jobs finish) we store `Security::Scan` objects in DB and parse the content of the security reports to create `Security::Finding` records. At this moment we also parse the cycloneDX sbom report and do the DS scan "on the fly", generating an in-memory DS report and the corresponding findings, making it look as if it was coming from a regular DS security report. 2. When running on the default branch, the ingestion services are then executed. However, when we ingest the findings from a DS report **we explicitly exclude those generated by our sbom scanner**: https://gitlab.com/gitlab-org/gitlab/-/blob/a42369d9bc9ce9fa809ddb0129668e9b0043c7ba/ee/app/services/security/ingestion/finding_map_collection.rb#L44 3. When vulnerability ingestion process completes, the sbom ingestion process starts 4. When sbom ingestion completes, we fire a `Sbom::SbomIngestedEvent` event and the `Sbom::ProcessVulnerabilitiesWorker` worker will be triggered to do a DS scan and create the corresponding vulnerability records in DB. This implementation comes from the fact that we introduced DS scans of SBOM reports in the default branch first, and then later in the feature branches. Ultimately we did https://gitlab.com/gitlab-org/gitlab/-/merge_requests/180470+ to avoid ingesting findings generated at the time of report parsing and instead rely on the scan we do later, after SBOM ingestion. #### Additional problem Now the new DS analyzer emits a DS security report (Limited Availability for now) but still uses the GitLab SBOM Vulnerability Scanner (id: `gitlab-sbom-vulnerability-scanner`). This means the findings coming from the DS report generated by the DS analyzer in a CI job are simply skipped during the default branch ingestion process. This problem doesn't exist with the old Gemnasium analyzer since it uses a different scanner id in the generated DS report. ### Solution We should do the inverse: 1. Stick to the generic security ingestion process and create vulnerabilities in the default branch for all findings created during security report parsing step. This will include DS findings generated by the dynamic SBOM scan. Note that this workflow will further be limited or removed with https://gitlab.com/gitlab-org/gitlab/-/issues/546429+ 2. Remove the specific DS Scan after SBOM ingestion process done by the `Sbom::ProcessVulnerabilitiesWorker`. Since we already generate the DS report and findings during the generic report parsing logic, we don't need to wait for the SBOM ingestion and redo a DS scan then. This presents several benefits: * avoids resource wastage * ensure the DS report is the SSOT for findings reported by the CI job, if it exists * solve odd behaviors and bugs, like this bug of missing links between dependencies and vulnerabilities in the dependency list.