### Problem to solve Right now, most Dependency Scanning analyzers scan and list all project dependencies, including development and test dependencies. Users may chose to ignore vulnerabilities affecting dev. dependencies because they don't affect their production environment, and showing these vulnerabilities results in an extra noise. Users not interested in dev. dependencies should be able to exclude them, so that they can focus on production, run-time dependencies. When scanning a Gradle project, `test` dependencies are already excluded by default by the [Gemnasium Gradle plugin](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-gradle-plugin/-/blob/master/src/main/kotlin/com/gemnasium/extension/GemnasiumGradlePluginExtension.kt#L35) used by `gemnasium-maven`. The documentation doesn't say how users can add them back. The [Gemnasium Maven plugin](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-maven-plugin/-/blob/master/README.md#dump-your-projects-dependencies-to-a-json-file) provides an option to exclude dependencies belonging to the `test` scope but [gemnasium-maven](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-maven/-/blob/master/builder/maven/maven.go) doesn't expose that option, and `test` dependencies are always included. Below are the package managers and their category resolution methodologies. | Package Manager | Dependency Category Resolution | |-----------------|-----------------------------------------------------------------| | Bundler | Resolved by analyzing dependency groups in `Gemfile`. | | Composer | Resolved by analyzing lockfile's `requires-dev` section. | | Conan | TODO | | Go | Resolved at build time by excluding `_test.go` files and files filtered by architecture, build flags, and operating system. | | Gradle | Resolved by creating a dependency graph via [gemnasium-gradle-plugin](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-gradle-plugin). The plugin interfaces with the build system. | | Maven | Resolved by creating a dependency graph via [gemnasium-maven-plugin](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-maven-plugin). The plugin interfaces with the build system. | | NuGet | Resolved by referencing values in lockfile for each package. | | NPM | Resolved by referencing values in lockfile for each package. | | Pip | Resolved by referencing multiple requirements file via `-r`. For example, you store production inside of `production-requirements.txt` and dev inside of `development-requirements.txt`. | | Pipenv | Resolved by referencing values in lockfile for each package. | | Poetry | Resolved by referencing values in lockfile for each package. | | Sbt | Resolved by creating a dependency graph per configuration file. | | Setuptools | TODO | | Yarn | Resolved implicitly at install time by package manager. | ### 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) Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ ### Further details - ~backend engineering DRI: @hacks4oats Dependency Scanning relies on multiple [analyzer projects](https://gitlab.com/gitlab-org/security-products/analyzers), and currently these don't distinguish development and test dependencies. - The [retire.js analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/retire.js) installs all the npm packages prior to the scan, including dev. dependencies. - [gemnasium](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium) relies on dependency file parsers that don't propagate the environment, even when the dep. file makes a clearly makes a distinction b/w dev. dependencies and others. Currently [bundler-audit](https://github.com/rubysec/bundler-audit) doesn't allow for dependency group filter or selection, but the upstream project has [an issue for that](https://github.com/rubysec/bundler-audit/issues/195). ### Proposal As a first step, expose a CI variable users would set to make Dependency Scanning (DS) exclude development and test dependencies. The same CI variable would be shared by all DS analyzers. Contribute to upstream project if needed. As a next step, Dependency Scanning should propagate the dependency group/environment to the UI, and the UI should make it possible to filter out dev. dependencies. This is out of scope. ### Permissions and Security Same. ### Documentation To be documented in [dependency scanning doc](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html). ### Availability & Testing To be tested by introducing specific branches to the existing [tests projects](https://gitlab.com/gitlab-org/security-products/tests), to check that setting the aforementioned CI variable results in a different JSON report, where there are no vulnerabilities reported for the dev. dependencies. ### What does success look like, and how can we measure that? Users can easily exclude dev. dependencies if they chose to do so, and focus on vulnerabilities impacting their production environment. ### What is the type of buyer? ~"GitLab Ultimate" ### Links / references