The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Secure |
| Maturity | Viable |
| Content Last Reviewed | 2023-01-04 |
| Content Last Updated | 2023-01-04 |
Thanks for visiting this category direction page on Dependency Scanning at GitLab. This page belongs to the Composition Analysis group of the Secure stage and is hiring a new Product Manager. The interim Product Manager is Sam White.
The Composition Analysis Group's primary focus is moving Dependency Scanning to Complete.
We welcome feedback, bug reports, feature requests, and community contributions.
Not sure how to get started?
/label ~"devops::secure" ~"Category:Dependency Scanning" ~"group::composition analysis" ~"type::feature".
Sharing your feedback directly on GitLab.com is the best way to contribute to our direction.
We believe everyone can contribute and so if you wish to contribute here is how to get started.
Dependency Scanning is a technique that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities in those components that may affect the main application.
GitLab was named as a Challenger in the 2022 Magic Quadrant for Application Security Testing.
Applications define which package they require, and the version that is used. Dependency Scanning leverages the GitLab Advisory Database to check if any of these dependencies have known vulnerabilities, and it indicates if a package upgrade is needed.
Dependency Scanning is very dependent not only on the programming languages, but also on the package manager. You can read our user documentation to see what languages and package managers are currently supported. Different package managers have different repositories and ways to keep track of versions.
Our goal is to provide Dependency Scanning as part of the standard development process so that we are proactively identifying potential vulnerabilities and weaknesses as they are introduced, to the person who introduced them. Dependency Scanning results can be consumed in the merge request, where only new vulnerabilities, introduced by the new code, are shown. This means that Dependency Scanning is executed every time a new commit is pushed to a branch. This should allow for findings to be reviewed and resolved before having the opportunity to make it into production. Where possible we provide Automatic Remediation for a found vulnerability. For those who wish to require additional review when critical or high vulnerabilities are found, you can enable Security Approvals in Merge Requests. We include Dependency Scanning as part of Auto DevOps.
Primary: Sasha (Software Developer) wants to know when adding a dependency if it has known vulnerabilities so alternate versions or dependencies can be considered.
Secondary: Sam (Security Analyst) wants to know what dependencies have known vulnerabilities (to reduce the OWASP A9 risk - Using Components with Known Vulnerabilities), to be alerted if a new vulnerability is published for an existing component, and how behind current version the components are.
Other: Cameron (Compliance Manager), Delaney (Development Team Lead), Devon (DevOps Engineer), Sidney (Systems Administrator)
Our vision for dependency scanning is to provide the ability to scan application dependencies with as little user friction as possible.
Currently we notify developers when they add dependencies in these supported languages with known vulnerabilities in the GitLab Advisory Database, if security approvals are configured, we will require an approval for critical, high or unknown findings. A summary of all findings for a project can be found in the Security Dashboard where Security Teams can quickly check the security status of projects, and the Dependency List. For limited package managers, we are able to offer auto-remediation recommendations for the findings.
We recently added the ability to parse poetry.lock files in the 15.0 release. Additionally, in the 15.1 release, we added the ability to filter out NPM development dependencies.
For next steps, we plan to allow GitLab to continuously scan dependencies for known vulnerabilities by synchronously triggering a re-scan anytime either the project dependencies change or when the advisory database is updated. These plans can be tracked in more detail in this epic.
Once that is complete, we intend to shift our focus to add support for the latest formats, including adding support for yarn v2, yarn v3, and npm v3.
A full list of our near-term priorities is kept up-to-date on our open priorities issue.
Currently the dependency list view in GitLab is parsed from artifact files. Use of artifact files is not scalable long-term as a datastore, especially when introducing searching, grouping, filtering, and group/sub-group level dependency management. Consequently, our first priority is to store the dependency list in the database. This work is being done as part of our efforts to introduce continuous vulnerability scans.
This category is currently at Viable maturity. A plan has been created for the category to progress to Complete maturity.
### User success metrics <!–
In addition to being A9 Using Components with Known Vulnerabilities in the OWASP top 10, keeping dependencies up to date is code quality issue, and finally as the need for software bill of materials (SBoM) grows being able to list your dependencies will become a needed feature for all application developers.
Dependency Scanning is frequently bundled together with Container Scanning and License Compliance to provide an overall Software Composition Analysis (SCA) solution within the Application Security Testing (AST) market. GitLab was recently named as a Challenger in the 2021 Magic Quadrant for Application Security Testing.