<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Release notes You can now view the dependency paths of the dependencies identified in your project on the Dependency List and in the security widget of your merge request. This will help you see vulnerable dependencies are part of your project (which dependency you added that it was a dependency of) and it will help you triage the finding and decide if there is a threat. ## Notes See https://gitlab.com/groups/gitlab-org/-/epics/3858 for **Post-MVC** issues. ## Problem to solve As a developer checking a vulnerable component, 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. ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ### User experience goal When seeing the user interface reference a dependency, the person can identify where that depedenency came from. ### Implementation plan 1. Discovery: https://gitlab.com/gitlab-org/gitlab/-/issues/198034 1. Prerequisite: Add vulnerable dependency path to Dependency Scanning report format https://gitlab.com/gitlab-org/gitlab/-/issues/229469 1. Show dependency path to vulnerable dependency // Generate dependency path in Gemnasium (in parallel) Show the dependency path (3 consecutive issues): 1. Show path in the dependency list https://gitlab.com/gitlab-org/gitlab/-/issues/227620 1. Show path in the vulnerability page (Security Dashboard) https://gitlab.com/gitlab-org/gitlab/-/issues/219093 1. Show path in the vulnerability modal (Merge Request) https://gitlab.com/gitlab-org/gitlab/-/issues/219095 Generate dependency path in Gemnasium: 1. Make Gemnasium report one dependency path per vulnerable dependency, when the lock file parser provides the dependency graph 1. `Report vulnerable dependency paths for XYZ` (1 issue per package manager, excluding Go) ### Permissions and Security No change. ### Documentation The [documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html) 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. ### 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. ### What is the type of buyer? ~"GitLab Ultimate" ### Is this a cross-stage feature? No ### Links / references https://gitlab.com/gitlab-org/gitlab/-/issues/198034