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
- Create a project with vulnerabilities in it - for instance, by cloning https://staging.gitlab.com/secure-team-test/dependency-list-test.
- Access the vulnerabilities API, e.g.,
GET https://staging.gitlab.com/api/v4/projects/4392789/vulnerabilities?pipeline_id=12642579&scope=all
. - 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
.