vulnerability report for a buggy file refers to a SHA reference and pipeline, but neither have the buggy file
Summary
During a customer call, incorrect behavior for vulnerabilities was identified by a customer. They're a SAAS customer, the issue is on GitLab.com, and shows on 14.3.0-pre f4ac01d6663
.
GitLab team members can find out more about the call in the ticket though there's very limited information about this issue.
- A report entry appears in
/-/security/vulnerabilities
in a group.- Tool: Dependency Scanning
- Scanner: Gemnasium
- Opening the report shows there's an issue with a file in a project.
- a pipeline is shown:
- Under Location, a file is shown, the path in the link is to a specific Git SHA
- That SHA is a merge commit,
556
.
- That SHA is a merge commit,
- Clicking through to that file redirects to the repository root, with an informative warning that
"<file>" does not exist in "<commit SHA>"
-
The file has been deleted from
master
at some point, so for the default branch, this vuln is resolved. -
The pipeline
355647870
ran off the back of merge request7
-
The MR was opened for a branch with a single commit.
0f1
-
Only one pipeline ran for that merge request.
-
The MR shows no other activity - no forced pushes, no additional pushes etc.
-
There's two SHAs associated with the pipeline:
- the commit on the branch
0f1
- the merge commit generated when the MR was accepted
3d8
- the commit on the branch
-
The SHA
556
on the file link in the vuln report does not match either commit (0f1
or3f8
)- ISSUE
1️⃣ the SHA link on the report has come from somewhere else, not the specified pipeline.
- ISSUE
-
The branch and MR associated with the pipeline flagged on the vuln report don't appear to have had this file on it. When clicking through to the file in the commit
0f1
and then browsing the repo at that commit, the file is not present. -
the file link is for a merge commit
556
.- browsing the repo for commit
556
shows the file not present
- browsing the repo for commit
-
looking at MR
9
which generated556
- there's a lot of commits, but the merge request was only opened against one HEAD commit,
e64
- the repo for commit
e64
does not contain the file either. - one pipeline
356709829
is shown as running against this MR.
- there's a lot of commits, but the merge request was only opened against one HEAD commit,
Issue 9
(embedded in the file link) and a pipeline for MR 7
.
Neither branches associated with the MRs have this file on it, therefore a pipeline run against both HEAD commits should not return this vulnerability.
There is a third pipeline. When clicking on the merge commit for sha 556
(the one in the file link) this shows pipeline 358250409
. This pipeline does not show on MR 9
.
This pipeline has been run automatically or manually against master
and shows as running against commit 556
. this pipeline failed, but it failed at the build stage. This seems to be irrelevant to this issue.
Steps to reproduce
Unknown
Example Project
This has been observed on a private customer project on GitLab.com.
As noted above, all avenues from the vulnerability report (MR 7
, MR 9
and its commit sha 556
) are dead-ends for explaining why the report exists.
What is the current bug behavior?
Vulnerability reports are generated referring to the wrong pipeline AND the wrong file SHA.
What is the expected correct behavior?
Vulnerability reports link back to the correct pipeline and Git SHA.
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)