Show path to vulnerable dependency in dependency list [parent issue]
Problem to solve
As a developer checking a vulnerable component in the dependency list, I want to know what's causing the vulnerable component to be installed in my project, so that I can better assess the threat and possibly take action (remove the vulnerable component or upgrade to a fixed version).
When Dependency Scanning reports a vulnerability affecting a transient dependency, users don't know how this vulnerable and transient dependency relates to the dependencies they have declared in the dependency files of their project. It makes it difficult for them to establish whether there's a threat, or if the vulnerability can be safely ignored. Also, it makes it difficult to figure what actions are required to remove the vulnerable dependency or upgrade to a fixed versions.
Intended users
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
User experience goal
Proposal
In the dependency list, show the dependency paths between vulnerable dependencies and top-level dependencies. There are possibly many paths connecting a transient dependency to the top-level dependencies, but the UI only shows one of the shortest path, and explicitly says there might be other paths.
Due to technical limitations, dependency paths are shown only for vulnerable dependencies. The UI should make that clear, to avoid any confusion. See #227599 about showing the dependency path for all components of the dependency list, and not only the vulnerable ones.
The dependency path is displayed in the Location
column of the Dependency List table. It begins with the filename of the dependency file where the dependency has been found, followed by a top-level dependency, and possibly transient dependencies leading to the vulnerable component. If needed, it's truncated to fit into that column. When truncated, it shows the beginning of the path and the number of dependencies that have been omitted.
In order to show the dependency path in the UI, the Gemnasium analyzers (gemnasium
, gemnasium-maven
, and gemnasium-python
) build a dependency graph, and leverage this graph to extract one of the shortest path leading to a vulnerable dependency. The path is added to the Dependency Scanning report, and the Dependency Scanning report format needs to be updated to allow for that.
Technically, Gemnasium builds and queries the dependency graph using a Go library like gonum/path. See Proof of Concept: gitlab-org/security-products/analyzers/gemnasium!81 (closed)
This feature is supported for all languages and package managers Dependency Scanning currently supports, except for Go. That's because Gemnasium relies on go.sum
to support Go projects, and this file doesn't contain the information needed to build the dependency graph.
Further details
Dependency Scanning either parses the lock file the package manager generates automatically, or something equivalent when there's no lock file. The lock file lists all the project dependencies, including the transient dependencies, that is the dependencies of the dependencies. Users don't manually edit the lock file. Instead, they edit the main dependency file, and declare top-level dependencies the project explicitly uses. It's the packager manager's responsibility to build the full dependency list, and store that list into a lock file.
Most lock files give the exact relationship between the dependencies, but this information is currently ignored when parsing the files, in the Gemnasium analyzer project. As a result, this information is not available to the backend, and cannot be shown in the dependency list, in the UI.
Implementation plan
-
frontend
- Path viewer component: #229501 (closed)
- Show dependency path in the dependency list and vulnerabilities: #227326 (closed)
-
backend
- Parse and expose dependency path #229472 (closed)
- documentation
-
feature flag
- Rollout #241739 (closed)
Follow-ups
- UX Improvement - #247851 (closed) (non-blocking as follow-up)
Permissions and Security
No change.
Documentation
The documentation tells for which package managers the dependency paths are available. In particular, it says this feature is not supported for Go projects.
Availability & Testing
The dependency path is part of the generated Dependency Scanning report, and checked during QA for gemnasium
, gemnasium-maven
, and gemnasium-python
.
Also, end-to-end feature tests are needed to ensure dependency paths are presented in the UI, when the data is available - gitlab-org/quality/testcases#992 (closed)
What does success look like, and how can we measure that?
Users can see the dependency path that leads from a dependency file to a vulnerable dependency listed in the dependency list.
What is the type of buyer?
Is this a cross-stage feature?
No