docs: restructure docs for new hosting (#9799)

This commit is contained in:
Owen Rumney
2025-11-18 15:45:49 +00:00
committed by GitHub
parent f64e0daf25
commit 9da33b5aed
188 changed files with 178 additions and 3576 deletions

View File

@@ -0,0 +1,35 @@
# C/C++
Trivy supports Conan C/C++ Package Manager ([v1][conanV1] and [v2][conanV2] with limitations).
The following scanners are supported.
| Package manager | SBOM | Vulnerability | License |
|-----------------|:----:|:-------------:|:-------:|
| Conan | ✓ | ✓ | ✓[^1] |
The following table provides an outline of the features Trivy offers.
| Package manager | File | Transitive dependencies | Dev dependencies | [Dependency graph][dependency-graph] | Position |
|-----------------------|----------------|:-----------------------:|:----------------:|:------------------------------------:|:--------:|
| Conan (lockfile v1) | conan.lock[^2] | ✓ | Excluded | ✓ | ✓ |
| Conan (lockfile v2) | conan.lock[^2] | ✓ [^3] | Excluded | - | ✓ |
## Conan
In order to detect dependencies, Trivy searches for `conan.lock`[^1].
[conanV1]: https://docs.conan.io/1/index.html
[conanV2]: https://docs.conan.io/2/
### Licenses
The Conan lock file doesn't contain any license information.
To obtain licenses we parse the `conanfile.py` files from the [conan v1 cache directory][conan-v1-cache-dir] and [conan v2 cache directory][conan-v2-cache-dir].
To correctly detection licenses, ensure that the cache directory contains all dependencies used.
[conan-v1-cache-dir]: https://docs.conan.io/1/mastering/custom_cache.html
[conan-v2-cache-dir]: https://docs.conan.io/2/reference/environment.html#conan-home
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies
[^1]: The local cache should contain the dependencies used. See [licenses](#licenses).
[^2]: `conan.lock` is default name. To scan a custom filename use [file-patterns](../../configuration/skipping.md#customizing-file-handling).
[^3]: For `conan.lock` in version 2, indirect dependencies are included in analysis but not flagged explicitly in dependency tree

View File

@@ -0,0 +1,53 @@
# Dart
Trivy supports [Dart][dart].
The following scanners are supported.
| Package manager | SBOM | Vulnerability | License |
|-------------------------|:----:|:-------------:|:-------:|
| [Dart][dart-repository] | ✓ | ✓ | - |
The following table provides an outline of the features Trivy offers.
| Package manager | File | Transitive dependencies | Dev dependencies | [Dependency graph][dependency-graph] | Position | [Detection Priority][detection-priority] |
|-------------------------|--------------|:-----------------------:|:----------------:|:------------------------------------:|:--------:|:----------------------------------------:|
| [Dart][dart-repository] | pubspec.lock | ✓ | Included | ✓ | - | ✓ |
## Dart
In order to detect dependencies, Trivy searches for `pubspec.lock`.
Trivy marks indirect dependencies, but `pubspec.lock` file doesn't have options to separate root and dev transitive dependencies.
So Trivy includes all dependencies in report.
### SDK dependencies
Dart uses version `0.0.0` for SDK dependencies (e.g. Flutter).
It is not possible to accurately determine the versions of these dependencies.
Trivy just treats them as `0.0.0`.
If [--detection-priority comprehensive][detection-priority] is passed, Trivy uses the minimum version of the constraint for the SDK.
For example, in the following case, the version of `flutter` would be `3.3.0`:
```yaml
flutter:
dependency: "direct main"
description: flutter
source: sdk
version: "0.0.0"
sdks:
dart: ">=2.18.0 <3.0.0"
flutter: "^3.3.0"
```
### Dependency tree
To build `dependency tree` Trivy parses [cache directory][cache-directory]. Currently supported default directories and `PUB_CACHE` environment (absolute path only).
!!! note
Make sure the cache directory contains all the dependencies installed in your application. To download missing dependencies, use `dart pub get` command.
[dart]: https://dart.dev/
[dart-repository]: https://pub.dev/
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies
[cache-directory]: https://dart.dev/tools/pub/glossary#system-cache
[detection-priority]: ../../scanner/vulnerability.md#detection-priority

View File

@@ -0,0 +1,54 @@
# .NET
Trivy supports `.NET core` and `NuGet` package managers.
The following scanners are supported.
| Artifact | SBOM | Vulnerability | License |
|-----------|:----:|:-------------:|:-------:|
| .Net Core | ✓ | ✓ | - |
| NuGet | ✓ | ✓ | ✓ |
The following table provides an outline of the features Trivy offers.
| Package manager | File | Transitive dependencies | Dev dependencies | [Dependency graph][dependency-graph] | Position |
|:---------------:|--------------------|:-----------------------:|:----------------:|:------------------------------------:|:--------:|
| .Net Core | *.deps.json | ✓ | Excluded | ✓ | ✓ |
| NuGet | packages.config | ✓ | Excluded | - | - |
| NuGet | *Packages.props | - | Excluded | - | - |
| NuGet | packages.lock.json | ✓ | Included | ✓ | ✓ |
## *.deps.json
Trivy parses `*.deps.json` files. Trivy currently excludes dev dependencies from the report.
!!! note
Trivy only includes runtime dependencies in the report.
## packages.config
Trivy only finds dependency names and versions from `packages.config` files. To build dependency graph, it is better to use `packages.lock.json` files.
## *Packages.props
Trivy parses `*Packages.props` files. Both legacy `Packages.props` and modern `Directory.Packages.props` are supported.
### license detection
`packages.config` files don't have information about the licenses used.
Trivy uses [*.nuspec][nuspec] files from [global packages folder][global-packages] to detect licenses.
!!! note
The `licenseUrl` field is [deprecated][license-url]. Trivy doesn't parse this field and only checks the [license] field (license `expression` type only).
Currently only the default path and `NUGET_PACKAGES` environment variable are supported.
## packages.lock.json
Don't forgot to [enable][enable-lock] lock files in your project.
!!! tip
Please make sure your lock file is up-to-date after modifying dependencies.
### license detection
Same as [packages.config](#license-detection)
[enable-lock]: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#enabling-the-lock-file
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies
[nuspec]: https://learn.microsoft.com/en-us/nuget/reference/nuspec
[global-packages]: https://learn.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders
[license]: https://learn.microsoft.com/en-us/nuget/reference/nuspec#license
[license-url]: https://learn.microsoft.com/en-us/nuget/reference/nuspec#licenseurl

View File

@@ -0,0 +1,27 @@
# Elixir
Trivy supports [Hex][hex] repository for [Elixir][elixir].
The following scanners are supported.
| Package manager | SBOM | Vulnerability | License |
|-----------------| :---: | :-----------: |:-------:|
| [hex][hex] | ✓ | ✓ | - |
The following table provides an outline of the features Trivy offers.
| Package manager | File | Transitive dependencies | Dev dependencies | [Dependency graph][dependency-graph] | Position |
|-----------------|--------------|:-----------------------:|:----------------:|:------------------------------------:|:--------:|
| [hex][hex] | mix.lock[^1] | ✓ | Excluded | - | ✓ |
## Hex
In order to detect dependencies, Trivy searches for `mix.lock`[^1].
[Configure](https://hexdocs.pm/mix/Mix.Project.html#module-configuration) your project to use `mix.lock`[^1] file.
[elixir]: https://elixir-lang.org/
[hex]: https://hex.pm/
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies
[^1]: `mix.lock` is default name. To scan a custom filename use [file-patterns](../../configuration/skipping.md#customizing-file-handling)

View File

@@ -0,0 +1,133 @@
# Go
## Overview
Trivy supports two types of Go scanning, Go Modules and binaries built by Go.
The following scanners are supported.
| Artifact | SBOM | Vulnerability | License |
|----------|:----:|:-------------:|:-------------:|
| Modules | ✓ | ✓ | [](#license) |
| Binaries | ✓ | ✓ | - |
The table below provides an outline of the features Trivy offers.
| Artifact | Offline[^1] | Dev dependencies | [Dependency graph][dependency-graph] | Stdlib | [Detection Priority][detection-priority] |
|----------|:-----------:|:-----------------|:------------------------------------:|:----------------------:|:----------------------------------------:|
| Modules | ✅ | Include | [](#dependency-graph) | [](#gomod-stdlib) | [](#gomod-stdlib) |
| Binaries | ✅ | Exclude | - | [](#go-binary-stdlib) | Not needed |
!!! note
When scanning Go projects (go.mod or binaries built with Go), Trivy scans only dependencies of the project, and does not detect vulnerabilities of application itself.
For example, when scanning the Docker project (Docker's source code with go.mod or the Docker binary), Trivy might find vulnerabilities in Go modules that Docker depends on, but won't find vulnerabilities of Docker itself. Moreover, when scanning the Trivy project, which happens to use Docker, Docker's vulnerabilities might be detected as dependencies of Trivy.
## Data Sources
The data sources are listed [here](../../scanner/vulnerability.md#langpkg-data-sources).
Trivy uses Go Vulnerability Database for [standard library](https://pkg.go.dev/std) and uses GitHub Advisory Database for other Go modules.
## Go Module
Depending on Go versions, the required files are different.
| Version | Required files | Offline |
| ------- | :------------: | :-----: |
| \>=1.17 | go.mod | ✅ |
| <1.17 | go.mod, go.sum | ✅ |
In Go 1.17+ projects, Trivy uses `go.mod` for direct/indirect dependencies.
On the other hand, it uses `go.mod` for direct dependencies and `go.sum` for indirect dependencies in Go 1.16 or less.
Go 1.17+ holds actually needed indirect dependencies in `go.mod`, and it reduces false detection.
`go.sum` in Go 1.16 or less contains all indirect dependencies that are even not needed for compiling.
If you want to have better detection, please consider updating the Go version in your project.
!!! note
The Go version doesn't mean your Go tool version, but the Go version in your go.mod.
```
module github.com/aquasecurity/trivy
go 1.18
require (
github.com/CycloneDX/cyclonedx-go v0.5.0
...
)
```
To update the Go version in your project, you need to run the following command.
```
$ go mod tidy -go=1.18
```
### Main Module { #gomod-main }
Trivy scans only dependencies of the project, and does not detect vulnerabilities of the main module.
For example, when scanning the Docker project (Docker's source code with go.mod), Trivy might find vulnerabilities in Go modules that Docker depends on, but won't find vulnerabilities of Docker itself.
Moreover, when scanning the Trivy project, which happens to use Docker, Docker's vulnerabilities might be detected as dependencies of Trivy.
### Standard Library { #gomod-stdlib }
Detecting the version of Go used in the project can be tricky.
The go.mod file include hints that allows Trivy to guess the Go version but it eventually depends on the Go tool version in the build environment.
Since this strategy is not fully deterministic and accurate, it is enabled only in [--detection-priority comprehensive][detection-priority] mode.
When enabled, Trivy detects stdlib version as the minimum between the `go` and the `toolchain` directives in the `go.mod` file.
To obtain reproducible scan results Trivy doesn't check the locally installed version of `Go`.
!!! note
Trivy detects `stdlib` only for `Go` 1.21 or higher.
The version from the `go` line (for `Go` 1.20 or early) is not a minimum required version.
For details, see [this](https://go.googlesource.com/proposal/+/master/design/57001-gotoolchain.md).
It possibly produces false positives.
See [the caveat](#stdlib-vulnerabilities) for details.
### License
To identify licenses, you need to download modules to local cache beforehand, such as `go mod download`, `go mod tidy`, `go mod vendor`, etc.
If the `vendor` directory exists, Trivy uses this directory when scanning for license files.
For other cases Trivy traverses `$GOPATH/pkg/mod`dir and collects those extra information.
### Dependency Graph
Same as licenses, you need to download modules to local cache beforehand.
## Go Binary
Trivy scans Go binaries when it encounters them during scans such as container images or file systems.
When scanning binaries built by Go, Trivy finds dependencies and Go version information as [embedded in the binary by Go tool at build time](https://tip.golang.org/doc/go1.18#go-version).
```
$ trivy rootfs ./your_binary
```
!!! note
It doesn't work with UPX-compressed binaries.
### Main Module
Go binaries installed using the `go install` command contains correct (semver) version for the main module and therefore are detected by Trivy.
In other cases, Go uses the `(devel)` version[^2].
In this case, Trivy will attempt to parse any `-ldflags` as it's a common practice to pass versions this way.
If unsuccessful, the version will be empty[^3].
### Standard Library { #go-binary-stdlib }
Trivy detects the Go version used to compile the binary and detects its vulnerabilities in the standard libraries.
It possibly produces false positives.
See [the caveat](#stdlib-vulnerabilities) for details.
## Caveats
### Stdlib Vulnerabilities
Trivy does not know if or how you use stdlib functions, therefore it is possible that stdlib vulnerabilities are not applicable to your use case.
There are a few ways to mitigate this:
1. Analyze vulnerability reachability using a tool such as [govulncheck](https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck). This will ensure that reported vulnerabilities are applicable to your project.
2. Suppress non-applicable vulnerabilities using either [ignore file](../../configuration/filtering.md) for self-use or [VEX Hub](../../supply-chain/vex/repo.md) for public use.
### Empty Version
As described in the [Main Module](#gomod-main) section, the main module of Go binaries might have an empty version.
Also, dependencies replaced with local ones will have an empty version.
[^1]: It doesn't require the Internet access.
[^2]: See https://github.com/aquasecurity/trivy/issues/1837#issuecomment-1832523477
[^3]: See https://github.com/golang/go/issues/63432#issuecomment-1751610604
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies
[toolchain]: https://go.dev/doc/toolchain
[detection-priority]: ../../scanner/vulnerability.md#detection-priority

View File

@@ -0,0 +1,71 @@
# Programming Language
Trivy supports programming languages for
- [SBOM][sbom]
- [Vulnerabilities][vuln]
- [Licenses][license]
## Supported languages
The files analyzed vary depending on the target.
This is because Trivy primarily categorizes targets into two groups:
- Pre-build
- Post-build
If the target is a pre-build project, like a code repository, Trivy will analyze files used for building, such as lock files.
On the other hand, when the target is a post-build artifact, like a container image, Trivy will analyze installed package metadata like `.gemspec`, binary files, and so on.
| Language | File | Image[^4] | Rootfs[^5] | Filesystem[^6] | Repository[^7] |
|----------------------|--------------------------------------------------------------------------------------------|:---------:|:----------:|:--------------:|:--------------:|
| [Ruby](ruby.md) | Gemfile.lock | - | - | ✅ | ✅ |
| | gemspec | ✅ | ✅ | - | - |
| [Python](python.md) | Pipfile.lock | - | - | ✅ | ✅ |
| | poetry.lock | - | - | ✅ | ✅ |
| | uv.lock | - | - | ✅ | ✅ |
| | requirements.txt | - | - | ✅ | ✅ |
| | egg package[^1] | ✅ | ✅ | - | - |
| | wheel package[^2] | ✅ | ✅ | - | - |
| [PHP](php.md) | composer.lock | - | - | ✅ | ✅ |
| | installed.json | ✅ | ✅ | - | - |
| [Node.js](nodejs.md) | package-lock.json | - | - | ✅ | ✅ |
| | yarn.lock | - | - | ✅ | ✅ |
| | pnpm-lock.yaml | - | - | ✅ | ✅ |
| | bun.lock | - | - | ✅ | ✅ |
| | package.json | ✅ | ✅ | - | - |
| [.NET](dotnet.md) | packages.lock.json | ✅ | ✅ | ✅ | ✅ |
| | packages.config | ✅ | ✅ | ✅ | ✅ |
| | .deps.json | ✅ | ✅ | ✅ | ✅ |
| | *Packages.props[^9] | ✅ | ✅ | ✅ | ✅ |
| [Java](java.md) | JAR/WAR/PAR/EAR[^3] | ✅ | ✅ | - | - |
| | pom.xml | - | - | ✅ | ✅ |
| | *gradle.lockfile | - | - | ✅ | ✅ |
| | *.sbt.lock | - | - | ✅ | ✅ |
| [Go](golang.md) | Binaries built by Go | ✅ | ✅ | - | - |
| | go.mod | - | - | ✅ | ✅ |
| [Rust](rust.md) | Cargo.lock | ✅ | ✅ | ✅ | ✅ |
| | Binaries built with [cargo-auditable](https://github.com/rust-secure-code/cargo-auditable) | ✅ | ✅ | - | - |
| [C/C++](c.md) | conan.lock | - | - | ✅ | ✅ |
| [Elixir](elixir.md) | mix.lock[^8] | - | - | ✅ | ✅ |
| [Dart](dart.md) | pubspec.lock | - | - | ✅ | ✅ |
| [Swift](swift.md) | Podfile.lock | - | - | ✅ | ✅ |
| | Package.resolved | - | - | ✅ | ✅ |
| [Julia](julia.md) | Manifest.toml | ✅ | ✅ | ✅ | ✅ |
The path of these files does not matter.
Example: [Dockerfile](https://github.com/aquasecurity/trivy-ci-test/blob/main/Dockerfile)
[sbom]: ../../supply-chain/sbom.md
[vuln]: ../../scanner/vulnerability.md
[license]: ../../scanner/license.md
[^1]: `*.egg-info`, `*.egg-info/PKG-INFO`, `*.egg` and `EGG-INFO/PKG-INFO`
[^2]: `.dist-info/METADATA`
[^3]: `*.jar`, `*.war`, `*.par` and `*.ear`
[^4]: ✅ means "enabled" and `-` means "disabled" in the image scanning
[^5]: ✅ means "enabled" and `-` means "disabled" in the rootfs scanning
[^6]: ✅ means "enabled" and `-` means "disabled" in the filesystem scanning
[^7]: ✅ means "enabled" and `-` means "disabled" in the git repository scanning
[^8]: To scan a filename other than the default filename use [file-patterns](../../configuration/skipping.md#customizing-file-handling)
[^9]: `Directory.Packages.props` and legacy `Packages.props` file names are supported

View File

@@ -0,0 +1,140 @@
# Java
Trivy supports four types of Java scanning: `JAR/WAR/PAR/EAR`, `pom.xml`, `*gradle.lockfile` and `*.sbt.lock` files.
Each artifact supports the following scanners:
| Artifact | SBOM | Vulnerability | License |
|------------------|:----:|:-------------:|:-------:|
| JAR/WAR/PAR/EAR | ✓ | ✓ | - |
| pom.xml | ✓ | ✓ | ✓ |
| *gradle.lockfile | ✓ | ✓ | ✓ |
| *.sbt.lock | ✓ | ✓ | - |
The following table provides an outline of the features Trivy offers.
| Artifact | Internet access | Dev dependencies | [Dependency graph][dependency-graph] | Position | [Detection Priority][detection-priority] |
|------------------|:---------------------:|:----------------------:|:------------------------------------:|:--------:|:----------------------------------------:|
| JAR/WAR/PAR/EAR | Trivy Java DB | Include | - | - | Not needed |
| pom.xml | Maven repository [^1] | Exclude | ✓ | ✓[^7] | - |
| *gradle.lockfile | - | [Exclude](#gradlelock) | ✓ | ✓ | Not needed |
| *.sbt.lock | - | Exclude | - | ✓ | Not needed |
These may be enabled or disabled depending on the target.
See [here](./index.md) for the detail.
## JAR/WAR/PAR/EAR
To find information about your JAR[^2] file, Trivy parses `pom.properties` and `MANIFEST.MF` files in your JAR[^2] file and takes required properties[^3].
If those files don't exist or don't contain enough information - Trivy will try to find this JAR[^2] file in [trivy-java-db](https://github.com/aquasecurity/trivy-java-db).
The Java DB will be automatically downloaded/updated when any JAR[^2] file is found.
It is stored in [the cache directory](../../configuration/cache.md#cache-directory).
!!! warning "EXPERIMENTAL"
Finding JARs in `trivy-java-db` is an experimental function.
Base JAR[^2] may contain inner JARs[^2] within itself.
To find information about these JARs[^2], the same logic is used as for the base JAR[^2].
`table` format only contains the name of root JAR[^2] . To get the full path to inner JARs[^2] use the `json` format.
## pom.xml
Trivy parses your `pom.xml` file and tries to find files with dependencies from these local locations.
- project directory[^4]
- relativePath field[^5]
- local repository directory[^6].
### remote repositories
If your machine doesn't have the necessary files - Trivy tries to find the information about these dependencies in the remote repositories:
- [repositories from pom files][maven-pom-repos]
- [maven central repository][maven-central]
Trivy reproduces Maven's repository selection and priority:
- for snapshot artifacts:
- check only snapshot repositories from pom files (if exists)
- for other artifacts:
- check release repositories from pom files (if exists)
- check [maven central][maven-central]
!!! Note
Trivy only takes information about packages. We don't take a list of vulnerabilities for packages from the `maven repository`.
Information about data sources for Java you can see [here](../../scanner/vulnerability.md#langpkg-data-sources).
You can disable connecting to the maven repository with the `--offline-scan` flag.
The `--offline-scan` flag does not affect the Trivy database.
The vulnerability database will be downloaded anyway.
!!! Warning
Trivy may skip some dependencies (that were not found on your local machine) when the `--offline-scan` flag is passed.
### supported scopes
Trivy only scans `import`, `compile`, `runtime` and empty [maven scopes][maven-scopes]. Other scopes and `Optional` dependencies are not currently being analyzed.
### empty dependency version
There are cases when Trivy cannot determine the version of dependencies:
- Unable to determine the version from the parent because the parent is not reachable;
- The dependency uses a [hard requirement][version-requirement] with more than one version.
In these cases, Trivy uses an empty version for the dependency.
!!! Warning
Trivy doesn't detect child dependencies for dependencies without a version.
### maven-invoker-plugin
Typically, the integration tests directory (`**/[src|target]/it/*/pom.xml`) of [maven-invoker-plugin][maven-invoker-plugin] doesn't contain actual `pom.xml` files and should be skipped to avoid noise.
Trivy marks dependencies from these files as the development dependencies and skip them by default.
If you need to show them, use the `--include-dev-deps` flag.
## Gradle.lock
`gradle.lock` files only contain information about used dependencies.
!!!note
All necessary files are checked locally. Gradle file scanning doesn't require internet access.
By default, Trivy doesn't report development dependencies.
Use the `--include-dev-deps` flag to include them in the results.
### Dependency-tree
!!! warning "EXPERIMENTAL"
This feature might change without preserving backwards compatibility.
Trivy finds child dependencies from `*.pom` files in the cache[^8] directory.
But there is no reliable way to determine direct dependencies (even using other files).
Therefore, we mark all dependencies as indirect to use logic to guess direct dependencies and build a dependency tree.
### Licenses
Trivy also can detect licenses for dependencies.
Make sure that you have cache[^8] directory to find licenses from `*.pom` dependency files.
## SBT
`build.sbt.lock` files only contain information about used dependencies. This requires a lockfile generated using the
[sbt-dependency-lock][sbt-dependency-lock] plugin.
!!!note
All necessary files are checked locally. SBT file scanning doesn't require internet access.
[^1]: Uses maven repository to get information about dependencies. Internet access required.
[^2]: It means `*.jar`, `*.war`, `*.par` and `*.ear` file
[^3]: `ArtifactID`, `GroupID` and `Version`
[^4]: e.g. when parent pom.xml file has `../pom.xml` path
[^5]: When you use dependency path in `relativePath` field in pom.xml file
[^6]: `/Users/<username>/.m2/repository` (for Linux and Mac) and `C:/Users/<username>/.m2/repository` (for Windows) by default
[^7]: To avoid confusion, Trivy only finds locations for direct dependencies from the base pom.xml file.
[^8]: The supported directories are `$GRADLE_USER_HOME/caches` and `$HOME/.gradle/caches` (`%HOMEPATH%\.gradle\caches` for Windows).
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies
[maven-invoker-plugin]: https://maven.apache.org/plugins/maven-invoker-plugin/usage.html
[maven-central]: https://repo.maven.apache.org/maven2/
[maven-pom-repos]: https://maven.apache.org/settings.html#repositories
[maven-scopes]: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
[sbt-dependency-lock]: https://stringbean.github.io/sbt-dependency-lock
[detection-priority]: ../../scanner/vulnerability.md#detection-priority
[version-requirement]: https://maven.apache.org/pom.html#dependency-version-requirement-specification

View File

@@ -0,0 +1,30 @@
# Julia
## Features
Trivy supports [Pkg.jl](https://pkgdocs.julialang.org/v1/), which is the Julia package manager.
The following scanners are supported.
| Package manager | SBOM | Vulnerability | License |
|-----------------|:----:|:-------------:|:-------:|
| Pkg.jl | ✓ | - | - |
The following table provides an outline of the features Trivy offers.
| Package manager | File | Transitive dependencies | Dev dependencies | License | Dependency graph | Position |
| --------------- | ------------- | :---------------------: | :--------------- | :-----: | :--------------: | :------: |
| Pkg.jl | Manifest.toml | ✅ | Excluded[^1] | - | ✅ | ✅ |
### Pkg.jl
Trivy searches for `Manifest.toml` to detect dependencies.
Trivy also supports dependency trees; however, to display an accurate tree, it needs to know whether each package is a direct dependency of the project.
Since this information is not included in `Manifest.toml`, Trivy parses `Project.toml`, which should be located next to `Project.toml`.
If you want to see the dependency tree, please ensure that `Project.toml` is present.
Scanning `Manifest.toml` and `Project.toml` together also removes developer dependencies.
Dependency extensions are currently ignored.
[^1]: When you scan `Manifest.toml` and `Project.toml` together.

View File

@@ -0,0 +1,97 @@
# Node.js
Trivy supports four types of Node.js package managers: `npm`, `Yarn`, `pnpm` and `Bun`[^1].
The following scanners are supported.
| Artifact | SBOM | Vulnerability | License |
|----------|:----:|:-------------:|:-------:|
| npm | ✓ | ✓ | ✓ |
| Yarn | ✓ | ✓ | ✓ |
| pnpm | ✓ | ✓ | ✓ |
| Bun | ✓ | ✓ | ✓ |
The following table provides an outline of the features Trivy offers.
| Package manager | File | Transitive dependencies | Dev dependencies | [Dependency graph][dependency-graph] | Position |
|:---------------:|-------------------|:-----------------------:|:---------------------------------:|:------------------------------------:|:--------:|
| npm | package-lock.json | ✓ | [Excluded](#npm) | ✓ | ✓ |
| Yarn | yarn.lock | ✓ | [Excluded](#yarn) | ✓ | ✓ |
| pnpm | pnpm-lock.yaml | ✓ | [Excluded](#lock-file-v9-version) | ✓ | - |
| Bun | bun.lock | ✓ | [Excluded](#bun) | ✓ | ✓ |
In addition, Trivy scans installed packages with `package.json`.
| File | Dependency graph | Position | License |
|--------------|:----------------:|:--------:|:-------:|
| package.json | - | - | ✅ |
These may be enabled or disabled depending on the target.
See [here](./index.md) for the detail.
## Package managers
Trivy parses your files generated by package managers in filesystem/repository scanning.
!!! tip
Please make sure your lock file is up-to-date after modifying `package.json`.
### npm
Trivy parses `package-lock.json`.
To identify licenses, you need to download dependencies to `node_modules` beforehand.
Trivy analyzes `node_modules` for licenses.
By default, Trivy doesn't report development dependencies. Use the `--include-dev-deps` flag to include them.
### Yarn
Trivy parses `yarn.lock`.
Trivy also analyzes additional files to gather more information about the detected dependencies.
- package.json
- node_modules/**
#### Package relationships
`yarn.lock` files don't contain information about package relationships, such as direct or indirect dependencies.
To enrich this information, Trivy parses the `package.json` file located next to the `yarn.lock` file as well as workspace `package.json` files.
By default, Trivy doesn't report development dependencies.
Use the `--include-dev-deps` flag to include them in the results.
#### Development dependencies
`yarn.lock` files don't contain information about package groups, such as production and development dependencies.
To identify dev dependencies and support [aliases][yarn-aliases], Trivy parses the `package.json` file located next to the `yarn.lock` file as well as workspace `package.json` files.
#### Licenses
Trivy analyzes the `.yarn` directory (for Yarn 2+) or the `node_modules` directory (for Yarn Classic) located next to the `yarn.lock` file to detect licenses.
### pnpm
Trivy parses `pnpm-lock.yaml`, then finds production dependencies and builds a [tree][dependency-graph] of dependencies with vulnerabilities.
To identify licenses, you need to download dependencies to `node_modules` beforehand. Trivy analyzes `node_modules` for licenses.
#### lock file v9 version
Trivy supports `Dev` field for `pnpm-lock.yaml` v9 or later. Use the `--include-dev-deps` flag to include the developer's dependencies in the result.
### Bun
Trivy also supports scanning `bun.lock` file generated by [Bun](https://bun.sh/blog/bun-lock-text-lockfile).
You can use Bun v1.2 which uses this file as default or use `bun install --save-text-lockfile` in Bun v1.1.39 to generate it.
For previous Bun versions you can use the command `bun install -y` to generate a Yarn-compatible `yarn.lock` and then scan it with Trivy.
#### Development dependencies
`bun.lock` contains information about package groups, such as production and development dependencies. By default, Trivy doesn't report development dependencies. Use the `--include-dev-deps` flag to include them.
!!! note
`bun.lockb` is not supported.
## Packages
Trivy parses the manifest files of installed packages in container image scanning and so on.
### package.json
Trivy searches for `package.json` files under `node_modules` and identifies installed packages.
It only extracts package names, versions and licenses for those packages.
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies
[pnpm-lockfile-v6]: https://github.com/pnpm/spec/blob/fd3238639af86c09b7032cc942bab3438b497036/lockfile/6.0.md
[yarn-aliases]: https://classic.yarnpkg.com/lang/en/docs/cli/add/#toc-yarn-add-alias
[^1]: [yarn.lock](#bun) must be generated

View File

@@ -0,0 +1,30 @@
# PHP
Trivy supports [Composer][composer], which is a tool for dependency management in PHP.
The following scanners are supported.
| Package manager | SBOM | Vulnerability | License |
|-----------------|:----:|:-------------:|:-------:|
| Composer | ✓ | ✓ | ✓ |
The following table provides an outline of the features Trivy offers.
| Package manager | File | Transitive dependencies | Dev dependencies | [Dependency graph][dependency-graph] | Position |
|-----------------|----------------|:-----------------------:|:----------------:|:------------------------------------:|:--------:|
| Composer | composer.lock | ✓ | Excluded | ✓ | ✓ |
| Composer | installed.json | ✓ | Excluded | - | ✓ |
## composer.lock
In order to detect dependencies, Trivy searches for `composer.lock`.
Trivy also supports dependency trees; however, to display an accurate tree, it needs to know whether each package is a direct dependency of the project.
Since this information is not included in `composer.lock`, Trivy parses `composer.json`, which should be located next to `composer.lock`.
If you want to see the dependency tree, please ensure that `composer.json` is present.
## installed.json
Trivy also supports dependency detection for `installed.json` files. By default, you can find this file at `path_to_app/vendor/composer/installed.json`.
[composer]: https://getcomposer.org/
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies

View File

@@ -0,0 +1,156 @@
# Python
Trivy supports three types of Python package managers: `pip`, `Pipenv` and `Poetry`.
The following scanners are supported for package managers.
| Package manager | SBOM | Vulnerability | License |
|-----------------|:----:|:-------------:|:-------:|
| pip | ✓ | ✓ | ✓ |
| Pipenv | ✓ | ✓ | - |
| Poetry | ✓ | ✓ | - |
| uv | ✓ | ✓ | - |
In addition, Trivy supports three formats of Python packages: `egg`, `wheel` and `conda`.
The following scanners are supported for Python packages.
| Packaging | SBOM | Vulnerability | License |
|-----------|:----:|:-------------:|:-------:|
| Egg | ✓ | ✓ | ✓ |
| Wheel | ✓ | ✓ | ✓ |
| Conda | ✓ | - | - |
The following table provides an outline of the features Trivy offers.
| Package manager | File | Transitive dependencies | Dev dependencies | [Dependency graph][dependency-graph] | Position | [Detection Priority][detection-priority] |
|-----------------|------------------|:-----------------------:|:----------------:|:------------------------------------:|:--------:|:----------------------------------------:|
| pip | requirements.txt | - | Include | - | ✓ | ✓ |
| Pipenv | Pipfile.lock | ✓ | Include | - | ✓ | Not needed |
| Poetry | poetry.lock | ✓ | [Exclude](#poetry) | ✓ | - | Not needed |
| uv | uv.lock | ✓ | [Exclude](#uv) | ✓ | - | Not needed | |
| Packaging | Dependency graph |
| --------- | :--------------: |
| Egg | ✓ |
| Wheel | ✓ |
These may be enabled or disabled depending on the target.
See [here](./index.md) for the detail.
## Package managers
Trivy parses your files generated by package managers in filesystem/repository scanning.
### pip
#### Dependency detection
By default, Trivy only parses [version specifiers](https://packaging.python.org/en/latest/specifications/version-specifiers/#id5) with `==` comparison operator and without `.*`.
Using the [--detection-priority comprehensive][detection-priority] option ensures that the tool establishes a minimum version, which is particularly useful in scenarios where identifying the exact version is challenging.
In such case Trivy parses specifiers `>=`,`~=` and a trailing `.*`.
```
keyring >= 4.1.1 # Minimum version 4.1.1
Mopidy-Dirble ~= 1.1 # Minimum version 1.1
python-gitlab==2.0.* # Minimum version 2.0.0
```
Also, there is a way to convert unsupported version specifiers - use either the `pip-compile` tool (which doesn't install the packages)
or call `pip freeze` from the virtual environment where the requirements are already installed.
```bash
$ cat requirements.txt
boto3~=1.24.60
click>=8.0
json-fix==0.5.*
$ pip install -r requirements.txt
...
$ pip freeze > requirements.txt
$ cat requirements.txt
boto3==1.24.96
botocore==1.27.96
click==8.1.7
jmespath==1.0.1
json-fix==0.5.2
python-dateutil==2.8.2
s3transfer==0.6.2
setuptools==69.0.2
six==1.16.0
urllib3==1.26.18
wheel==0.42.0
```
`requirements.txt` files usually contain only the direct dependencies and not contain the transitive dependencies.
Therefore, Trivy scans only for the direct dependencies with `requirements.txt`.
To detect transitive dependencies as well, you need to generate `requirements.txt` that contains them.
Like described above, tou can do it with `pip freeze` or `pip-compile`.
```zsh
$ cat requirements.txt # it will only find `requests@2.28.2`.
requests==2.28.2
$ pip install -r requirements.txt
...
$ pip freeze > requirements.txt
$ cat requirements.txt # it will also find the transitive dependencies of `requests@2.28.2`.
certifi==2022.12.7
charset-normalizer==3.1.0
idna==3.4
PyJWT==2.1.0
requests==2.28.2
urllib3==1.26.15
```
`pip freeze` also helps to resolve [extras](https://packaging.python.org/en/latest/tutorials/installing-packages/#installing-extras)(optional) dependencies (like `package[extras]=0.0.0`).
`requirements.txt` files don't contain information about dependencies used for development.
Trivy could detect vulnerabilities on the development packages, which not affect your production environment.
#### License detection
`requirements.txt` files don't contain information about licenses.
Therefore, Trivy checks `METADATA` files from `lib/site-packages` directory.
Trivy uses 3 ways to detect `site-packages` directory:
- Checks `VIRTUAL_ENV` environment variable.
- Detects path to `python`[^1] binary and checks `../lib/pythonX.Y/site-packages` directory.
- Detects path to `python`[^1] binary and checks `../../lib/site-packages` directory.
### Pipenv
Trivy parses `Pipfile.lock`.
`Pipfile.lock` files don't contain information about dependencies used for development.
Trivy could detect vulnerabilities on the development packages, which not affect your production environment.
License detection is not supported for `Pipenv`.
### Poetry
Trivy uses `poetry.lock` to identify dependencies and find vulnerabilities.
To build the correct dependency graph, `pyproject.toml` also needs to be present next to `poetry.lock`.
License detection is not supported for `Poetry`.
By default, Trivy doesn't report development dependencies. Use the `--include-dev-deps` flag to include them.
### uv
Trivy uses `uv.lock` to identify dependencies and find vulnerabilities.
License detection is not supported for `uv`.
By default, Trivy doesn't report development dependencies. Use the `--include-dev-deps` flag to include them.
## Packaging
Trivy parses the manifest files of installed packages in container image scanning and so on.
See [here](https://packaging.python.org/en/latest/discussions/package-formats/) for the detail.
### Egg
Trivy looks for `*.egg-info`, `*.egg-info/METADATA`, `*.egg-info/PKG-INFO`, `*.egg` and `EGG-INFO/PKG-INFO` to identify Python packages.
### Wheel
Trivy looks for `.dist-info/METADATA` to identify Python packages.
[^1]: Trivy checks `python`, `python3`, `python2` and `python.exe` file names.
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies
[detection-priority]: ../../scanner/vulnerability.md#detection-priority

View File

@@ -0,0 +1,30 @@
# Ruby
Trivy supports [Bundler][bundler] and [RubyGems][rubygems].
The following scanners are supported for Bundler and RubyGems.
| Package manager | SBOM | Vulnerability | License |
|-----------------|:----:|:-------------:|:-------:|
| Bundler | ✓ | ✓ | - |
| RubyGems | ✓ | ✓ | ✓ |
The following table provides an outline of the features Trivy offers.
| Package manager | File | Transitive dependencies | Dev dependencies | [Dependency graph][dependency-graph] | Position |
|-----------------|--------------|:-----------------------:|:-----------------|:------------------------------------:|:--------:|
| Bundler | Gemfile.lock | ✓ | Included | ✓ | ✓ |
| RubyGems | .gemspec | - | Included | - | - |
### Bundler
Trivy searches for `Gemfile.lock` to detect dependencies.
### RubyGems
`.gemspec` files doesn't contains transitive dependencies. You need to scan each `.gemspec` file separately.
[bundler]: https://bundler.io
[rubygems]: https://rubygems.org/
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies

View File

@@ -0,0 +1,44 @@
# Rust
Trivy supports [Cargo](https://doc.rust-lang.org/stable/cargo/), which is the Rust package manager.
The following scanners are supported for Cargo.
| Package manager | SBOM | Vulnerability | License |
| --------------- | :---: | :-----------: | :-----: |
| Cargo | ✓ | ✓ | - |
In addition, it supports binaries built with [cargo-auditable](https://github.com/rust-secure-code/cargo-auditable).
| Artifact | SBOM | Vulnerability | License |
| -------- | :---: | :-----------: | :-----: |
| Binaries | ✓ | ✓ | - |
## Features
The following table provides an outline of the features Trivy offers.
| Package manager | File | Transitive dependencies | Dev dependencies | [Dependency graph][dependency-graph] | Position |
|-----------------|------------|:-----------------------:|:-----------------|:------------------------------------:|:--------:|
| Cargo | Cargo.lock | ✓ | Excluded[^1] | ✓ | ✓ |
| Artifact | Transitive dependencies | Dev dependencies | Dependency graph | Position |
| -------- | :---------------------: | :--------------- | :--------------: | :------: |
| Binaries | ✓ | Excluded | - | - |
### Cargo
Trivy searches for `Cargo.lock` to detect dependencies.
Trivy also supports dependency trees; however, to display an accurate tree, it needs to know whether each package is a direct dependency of the project.
Since this information is not included in `Cargo.lock`, Trivy parses `Cargo.toml`, which should be located next to `Cargo.lock`.
If you want to see the dependency tree, please ensure that `Cargo.toml` is present.
Scan `Cargo.lock` and `Cargo.toml` together also removes developer dependencies.
### Binaries
Trivy scans binaries built with [cargo-auditable](https://github.com/rust-secure-code/cargo-auditable).
If such a binary exists, Trivy will identify it as being built with cargo-audit and scan it.
[^1]: When you scan Cargo.lock and Cargo.toml together.
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies

View File

@@ -0,0 +1,44 @@
# Swift
Trivy supports [CocoaPods][cocoapods] and [Swift][swift] package managers.
The following scanners are supported.
| Package manager | SBOM | Vulnerability | License |
|-----------------|:----:|:-------------:|:-------:|
| Swift | ✓ | ✓ | - |
| CocoaPods | ✓ | ✓ | - |
The following table provides an outline of the features Trivy offers.
| Package manager | File | Transitive dependencies | Dev dependencies | [Dependency graph][dependency-graph] | Position |
|:---------------:|------------------|:-----------------------:|:----------------:|:------------------------------------:|:--------:|
| Swift | Package.resolved | ✓ | Included | - | ✓ |
| CocoaPods | Podfile.lock | ✓ | Included | ✓ | - |
These may be enabled or disabled depending on the target.
See [here](./index.md) for the detail.
## Swift
Trivy parses [Package.resolved][package-resolved] file to find dependencies.
Don't forget to update (`swift package update` command) this file before scanning.
## CocoaPods
CocoaPods uses package names in `PodFile.lock`, but [GitHub Advisory Database (GHSA)][ghsa] Trivy relies on uses Git URLs.
We parse [the CocoaPods Specs][cocoapods-specs] to match package names and links.
!!! note "Limitation"
Since [GHSA][ghsa] holds only Git URLs, such as github.com/apple/swift-nio,
Trivy can't identify affected submodules, and detect all submodules maintained by the same URL.
For example, [SwiftNIOHTTP1][niohttp1] and [SwiftNIOWebSocket][niowebsocket] both are maintained under `github.com/apple/swift-nio`,
and Trivy detect CVE-2022-3215 for both of them, even though only [SwiftNIOHTTP1][niohttp1] is actually affected.
[cocoapods]: https://cocoapods.org/
[cocoapods-specs]: https://github.com/CocoaPods/Specs
[ghsa]: https://github.com/advisories?query=type%3Areviewed+ecosystem%3Aswift
[swift]: https://www.swift.org/package-manager/
[package-resolved]: https://github.com/apple/swift-package-manager/blob/4a42f2519e3f7b8a731c5ed89b47ed577df8f86c/Documentation/Usage.md#resolving-versions-packageresolved-file
[dependency-graph]: ../../configuration/reporting.md#show-origins-of-vulnerable-dependencies
[niohttp1]: https://cocoapods.org/pods/SwiftNIOHTTP1
[niowebsocket]: https://cocoapods.org/pods/SwiftNIOWebSocket