Vulnerabilities API always gives empty blob_path

Summary

The vulnerabilities API seems to always return empty blob_path properties on the vulnerabilities in its response, whereas it should not be empty (at least, not in all cases).

The blob_path is used by consuming applications (e.g., pipeline Security Dashboard) to generate a link to the exact file which contains the vulnerability.

Steps to reproduce

1. Create a project with vulnerabilities in it - for instance, by cloning https://staging.gitlab.com/secure-team-test/dependency-list-test.
2. Access the vulnerabilities API, e.g., GET https://staging.gitlab.com/api/v4/projects/4392789/vulnerabilities?pipeline_id=12642579&scope=all.
3. Observe that all returned vulnerabilities have "blob_path": ""

Example Project

https://staging.gitlab.com/secure-team-test/dependency-list-test

What is the current bug behavior?

blob_path is the empty string on all vulnerabilities.

What is the expected correct behavior?

blob_path is actually a path, when appropriate (always?)

Relevant logs and/or screenshots

Output of GET https://staging.gitlab.com/api/v4/projects/4392789/vulnerabilities?pipeline_id=12642579&scope=all at the time of writing: vulnerabilities.json

Previous discussion

rossfuhrman  5 days ago
I'm guessing it has to do with the sha not being present
https://gitlab.com/gitlab-org/gitlab-ee/blob/master/ee/app/presenters/vulnerabilities/occurrence_presenter.rb#L8-9

rossfuhrman  5 days ago
I haven't traced it all the way down, but the code in question may be calling for_pipelines, where calling for_pipelines_with_sha would include the sha which would populate the blob_path https://gitlab.com/gitlab-org/gitlab-ee/blob/master/ee/app/models/vulnerabilities/occurrence.rb#L90

markrian  4 days ago
Does sha here refer to the commit sha the pipeline was run against? If so, why would there ever be a pipeline without one? (edited)

rossfuhrman  4 days ago
Yes. You are correct, there should never be a pipeline without a sha (as far as I know). This is more a limitation of the queries we are running, and by default the queries for the vulnerabilities do not join into the pipeline in a way that brings back the sha

rossfuhrman  4 days ago
I'm thinking when the code in question was written, there was no need to access the sha, so for_pipelines was used. Or, it's possible it was written before for_pipelines_with_sha existed.

Current Understanding of Problem

This how we initialize occurrences for the API: https://gitlab.com/gitlab-org/gitlab-ee/blob/a43ada893cbdcca81b47dfbf1a7adb0797b028ce/ee/app/finders/security/pipeline_vulnerabilities_finder.rb#L47

We were relying on this to expose sha. It is not exposed on occurrence otherwise. https://gitlab.com/gitlab-org/gitlab-ee/blob/a43ada893cbdcca81b47dfbf1a7adb0797b028ce/ee/app/models/vulnerabilities/occurrence.rb#L92-96

In the context of ee/app/finders/security/pipeline_vulnerabilities_finder.rb, pipeline.security_reports.commit_hash should get us the sha we need to build the blob_path. We need to change the code so that occurrences returned here have this exposed in order for the API to provide the blob_path.