<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary <!-- Summarize the bug encountered concisely. --> In some cases, the bundler-audit analyzer reports a vulnerability whose fields are empty or have the default value. This happens when `bundle audit check` logs a warning message before listing the vulnerabilities or no vulnerabilities at all. The empty vulnerability looks like the following: ```json { "id": "85008fe3bf9c69f6acbc1b2f6f56b1540498ac7abcfc27f589ddd17357968c5f", "category": "dependency_scanning", "message": "Vulnerability in ", "cve": "Gemfile.lock:", "severity": "Unknown", "scanner": { "id": "bundler_audit", "name": "bundler-audit" }, "location": { "file": "Gemfile.lock", "dependency": { "package": {} } }, ``` However there are no vulnerabilities when running bundler-audit locally: ``` > /performance - update-ruby-2.7.4: bundle-audit No vulnerabilities found ``` ### Further details As of today, bundler-audit is one of the two Dependency Scanning scanners capable of scanning bundler lock files. Technically, the analyzer is a wrapper that runs `bundle audit`, processes its text output, and generate a GitLab Dependency Scanning report. There's a bug in the text parser. ### Steps to reproduce 1. Create a GitLab project with [Gemfile](/uploads/ca89dbbcbdb7df7f04909df61c91d2de/Gemfile) and [Gemfile.lock](/uploads/9ee76192a3ec71a2839dbd5672d53d13/Gemfile.lock). 1. Enable GitLab Dependency Scanning and run a CI pipeline. 1. Check the CI artifact created by the `bundler-audit_dependency-scanning` job. ### Sample project 1. Open [GPT Security report](https://gitlab.com/gitlab-org/quality/performance/-/pipelines/423504957/security) 2. Click on `Hide dismissed` and review Vulnerability. - artifact for bundler [gl-dependency-scanning-report__4_.json](/uploads/19dff3b12fef0403c8e4dd4876af5743/gl-dependency-scanning-report__4_.json) <details> <summary>Artifact - gl-dependency-scanning-report</summary> ```json { "version": "14.0.0", "vulnerabilities": [ { "id": "85008fe3bf9c69f6acbc1b2f6f56b1540498ac7abcfc27f589ddd17357968c5f", "category": "dependency_scanning", "message": "Vulnerability in ", "cve": "Gemfile.lock:", "severity": "Unknown", "scanner": { "id": "bundler_audit", "name": "bundler-audit" }, "location": { "file": "Gemfile.lock", "dependency": { "package": {} } }, "identifiers": [], "links": [ { "url": "" } ] } ], "remediations": [], "scan": { "scanner": { "id": "bundler_audit", "name": "bundler-audit", "url": "https://github.com/rubysec/bundler-audit", "vendor": { "name": "GitLab" }, "version": "0.7.0.1" }, "type": "dependency_scanning", "start_time": "2021-12-06T14:46:22", "end_time": "2021-12-06T14:46:24", "status": "success" } } ``` </details> ### What is the current *bug* behavior? <!-- Describe what actually happens. --> Dependency Scanning shows vulnerability incorrectly due to a possibly a parsing error. ### What is the expected *correct* behavior? <!-- Describe what you should see instead. --> Dependency Scanning doesn't show vulnerability if `bundler-audit` passes with `No vulnerabilities found` ### Relevant logs and/or screenshots <!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise. --> <details> <summary>Screenshot</summary>  </details> ### Output of checks This bug happens on GitLab.com #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (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`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (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) </pre> </details> ### Implementation plan - [ ] TIMEBOXED to ~1 day: investigate the problem, try to reproduce and debug/fix if possible. ### Possible fixes We should either: - Fix the parser of the text output. - Remove the warnings. - Ignore everything until there's something that looks like a vulnerability section. - Use the JSON output bundler-audit. Parsing the JSON output seems more reliable, and it's possibly less time consuming compared to making sense of a bug in the text parser.