### Overview This epic covers the following: - Introduction of a new dependency scanning CI/CD component. Leverages the customization options of the components, and versioning capabilities. - Removal of build support. Graph export detection capabilities only. - Support for dependency graphs in CycloneDX artifacts produced when given a supported graph export format There are three iterations within this body of work: 1. Establishment of the dependency graph contract. We'll always have a dependencies section in the produced CycloneDX artifacts even if they are all listed as direct dependencies. 1. Improving the accuracy of the graph. Dependencies will be properly mapped in the dependencies section of the CycloneDX. 1. ~Dependency group cataloging. We'll detect the groups for which a dependency belongs to, and share that information in the CycloneDX.~ This has been moved to https://gitlab.com/groups/gitlab-org/-/epics/14831+, and is now out of scope of this issue. ### Problem to solve Developers use the ~"dependency list" to reference the components in use by their applications. This list also serves to inform users of what is causing the vulnerable component to be installed in their project. This allows them to perform a more targeted thread assessment and can often lead to them taking an action to remediate the vulnerable component. Currently ~"SCA:Dependency Scanning" supports generating a dependency graph for the following package managers: Sbt, NuGet, and Yarn. We need to extend this functionality to other package managers. ### 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) ### Proposal **Extend dependency graph support** to other package managers, beyond Sbt, NuGet, and Yarn. (The vulnerable package, introduced package, short path `details` fields are immediately available for any package manager for which the analyzer builds an internal dependency graph.) 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 https://gitlab.com/gitlab-org/gitlab/-/issues/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 dependency scanning analyzer builds a dependency graph, and leverage this graph to extract one of the shortest path leading to a vulnerable dependency. ### 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 [analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/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. ### Documentation Document how to enable dependency graph results. 1. Some lock files have this information built in 1. Some projects will require setting up a job to export the dependency graph as part of a build step. ### Availability & Testing ### Available Tier ~"GitLab Ultimate" ### 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. ### Is this a cross-stage feature? No ### Status _The following comment contains the latest status update._ * https://gitlab.com/groups/gitlab-org/-/epics/7288#note_2202017049 * https://gitlab.com/groups/gitlab-org/-/epics/7288#note_2166904475