Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Dependency Scanning

Sec Section

   
Stage Secure
Maturity Viable
Content Last Reviewed 2021-08-30
Content Last Updated 2021-08-30

Introduction and how you can help

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 maintained by Nicole Schwartz.

The Composition Analysis Group's primary focus is GitLab-hosted First putting reliability, scalability, and security first. This will be our primary focus until FY22Q4 (November 2021).

Send Us Feedback

We welcome feedback, bug reports, feature requests, and community contributions.

Not sure how to get started?

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.

Overview

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 recently named as a Challenger in the 2021 Magic Quadrant for Application Security Testing.

Applications define which package they require, and the version that is used. Dependency Scanning leverages our Vulnerability 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.

Target Audience

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)

Challenges to address

We will be researching current user challenges in this issue and using them to validate or update our job(s) to be done as a part of completing our category maturity scorecard. Please feel free to comment!

Key features

Currently we notify developers when they add dependencies in these supported languages with known vulnerabilities in our vulnerability 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.

Strategy

See Secure 3 Year Strategy

Where we are Headed

We know that we need to keep iterating and improving on our workflow. We plan to make our setup simpler and improve usability when viewing and interacting with findings. Part of this simplicity will include allowing you to focus on what matters most, and to more easily understand what solutions could resolve multiple findings. We also will increasing the supported package managers for auto-remediation.

Roadmap

-Dependency Scanning Epic Roadmap

What's Next & Why

Dependency Scanning's maturity from Viable to Complete
Dependency Scanning's maturity begining its path from Complete to Loveable
Automatic Remediation

What is Not Planned Right Now

In order to focus on what's next, the following items are not on the immediate horizon:

We would love your comments on any of those epics to help us prioritize the above epics as we complete the items in "What's Next & Why".

Maturity Plan

This category is currently at the Viable maturity level, and our next maturity target is 2021-07-22 (see our definitions of maturity levels

User success metrics

Currently we have limited product analytics data, as a result we will be tracking number of times that our scans run.

Why is this important?

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.

Competitive Landscape

Analyst Landscape

GitLab believes that our value is in offering comprehensive DevSecOps tooling - making one tool available end to end with both Secure and Protect tightly integrated into the customers DevOps cycle. One type of offering will never be able to detect all types of vulnerabilities and concerns within a software project. Because of this, and the amount of time it takes to complete the information needed in analyst surveys, we have decided to limit our focus this year to analyst surveys which reflect our vision - DevSecOps - and not those that focus only on SCA in isolation.

GitLab was recently named as a Challenger in the 2021 Magic Quadrant for Application Security Testing.

The Dependency Scanning topic is often coupled with License Compliance in Software Composition Analysis (SCA) or considered as part of an Application Security Testing (AST) package. This is what analysts evaluate, and how it is bundled in other products. As defined in our Solutions, GitLab includes Container Scanning as part of Software Composition Analysis.

Analysts are showing interest in our automatic remediation as the key feature to make dependency scanning really actionable for users. We can invest to increase our coverage.

Top Issue(s)

I base this on popularity, so please remember to comment AND upvote issues you would like to see.

Customer Success/Sales

Issue Search customer success issues

If you don't see the customer success label on an issue yet, and you are a customer success team-member, feel free to add it!

Top user issue(s)

Issue Search customer issues

If you don't see the customer label on an issue yet, feel free to add it if you are the first customer!

Top internal customer issue(s)

Issue Search internal customer issues

If you don't see the internal customer label on an issue yet, and you are a team-member, feel free to add it!

Top Strategy Item(s)

Issue Search AST Leadership issues

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license