Ecosystem Guides on Sonatype Open Source Community Handbook

.NET

Mon, 01 Jan 0001 00:00:00 +0000

DRAFT. Not yet run end to end. No current community Project uses .NET, so this guide is the least exercised. Source: Sonatype’s NuGet Application Analysis.

What Lifecycle reads

Sonatype’s documentation says Lifecycle scans .nupkg files and PE binaries (.dll, .exe and others), as a binary scan, and project files (.csproj, packages.config) as a manifest scan. In manifest mode “only components with an exact version specified are evaluated”, floating versions such as 3.6.* are not supported, and transitive dependencies are not included.

C/C++

Mon, 01 Jan 0001 00:00:00 +0000

DRAFT. Not yet run end to end. No current community Project uses Conan, so this guide is the least exercised. Source: Sonatype’s C/C++ Application Analysis.

What Lifecycle reads

Sonatype’s documentation says it analyses files named conanfile.txt, conanfile.py or conaninfo.txt, taking dependencies “with an exact version” from the requires and build_requires sections. It describes a scan of “a directory or subdirectories containing” those files. It does not describe a lockfile or a binary scan, and does not say that conan install is needed first.

Docker

Mon, 01 Jan 0001 00:00:00 +0000

DRAFT. Not yet run end to end. Container images are the largest scan input, and the one with the most open questions. Source: Sonatype’s Docker Image Analysis.

What Lifecycle reads

Docker is a binary ecosystem. Sonatype’s documentation describes the scan target as an image saved to a tar archive with docker save, which the CLI then accepts directly: for example docker save webgoat/webgoat-7.1:latest > webgoat-7.1.tar. It says the Sonatype CLI “relies on the Docker daemon to package the image as an archive file”.

Go

Mon, 01 Jan 0001 00:00:00 +0000

DRAFT. Not yet run end to end. Source: Sonatype’s Go Application Analysis.

What Lifecycle reads

Go is a manifest ecosystem. Lifecycle matches Go components by module path and version. Sonatype’s documentation says:

A valid go.mod is required for Go module analysis.
The recommended scan target is a go.list file generated with go list.
go.sum is also supported, but “may include dependencies that are not used by the application”, so it can report more than your build actually uses.
The Go toolchain does not need to be present when Lifecycle scans the file.

Why `go.list` and not `go.sum`

go.sum records every module version your module graph has ever needed, including ones the build does not use. go.list is produced from what the compiler would actually link, so it matches your real dependencies. The tradeoff is that producing it needs the Go toolchain and module downloads, which is why it happens in Tier 1.

Java

Mon, 01 Jan 0001 00:00:00 +0000

DRAFT. Not yet run end to end. Source: Sonatype’s Java Application Analysis. Gradle guidance is thinner than Maven, and this guide says where.

What Lifecycle reads

Java is a binary ecosystem. Sonatype’s documentation says Lifecycle scans packaged archives (.ear, .war, .jar, .zip, .tar.gz) and post-build artifacts, using Advanced Binary Fingerprinting, and that “for the best results” the post-build artifact you plan to deploy should be the scan target.

JavaScript

Mon, 01 Jan 0001 00:00:00 +0000

DRAFT. Not yet run end to end. Sources: Sonatype’s npm Application Analysis and Preparing to Run npm Application Analysis.

What Lifecycle reads

JavaScript can be scanned two ways, and the choice sets the accuracy:

Scan input	Mode	Accuracy
`package.json` plus a lockfile (`package-lock.json`, `npm-shrinkwrap.json`, `yarn.lock`, `pnpm-lock.yaml`)	Manifest matching	Good. Evaluates dependencies from metadata only.
`package.json`, the lockfile and `node_modules`	Binary (ABF)	Best. Sonatype recommends this for “the most precise results”.

Sonatype’s documentation says that when JavaScript files are included, ABF is used and the JavaScript files are the primary identification source, and that “manifest entries without corresponding JavaScript files are ignored”. package.json must come with a package-lock.json.

PHP

Mon, 01 Jan 0001 00:00:00 +0000

DRAFT. Not yet run end to end. Source: Sonatype’s PHP Application Analysis.

What Lifecycle reads

PHP is a manifest ecosystem and the documentation describes one file only: “files named composer.lock (a JSON file generated by PHP composer) will be analyzed”. It does not scan composer.json or the vendor/ directory. Sonatype recommends generating and committing composer.lock before scanning, so the Project must commit composer.lock.

Tier 1 job

 prepare-scan-input:
 name: Prepare Lifecycle scan input
 runs-on: ubuntu-latest
 permissions:
 contents: read
 steps:
 - name: Checkout
 uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
 with:
 persist-credentials: false

 - name: Gather scan input
 run: |
 mkdir scan-input
 cp composer.lock scan-input/

 - name: Upload scan input
 uses: actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9 # v7.0.2
 with:
 name: lifecycle-scan-input
 path: scan-input/
 if-no-files-found: error
 retention-days: 3

This job runs nothing from the Pull Request, and does not need composer install.

Python

Mon, 01 Jan 0001 00:00:00 +0000

DRAFT. Not yet run end to end. Source: Sonatype’s Python Application Analysis.

What Lifecycle reads

Python can be scanned from manifests or from binaries:

Scan input	Notes
`requirements.txt`	Must use `==` with a version and no wildcards. Variable ranges and environment ranges are ignored.
`poetry.lock`	Parsed automatically. For Poetry 1.5.1 and later, development dependencies are excluded when `pyproject.toml` is present and discoverable.
`Pipfile.lock`	Needs IQ CLI 2.0 or later. Only dependencies under the `default` key are parsed.
`.whl` and `.tar.gz` files	Binary scan of the actual packages.

Sonatype’s recommendation for the best results is to first create a virtual environment, resolve dependencies with pip install -r requirements.txt, and use pip download or pip wheel to gather the packages as the scan target.

R

Mon, 01 Jan 0001 00:00:00 +0000

DRAFT. Not yet run end to end, and the thinnest guide: Sonatype’s documentation for R is brief. Source: Sonatype’s R (CRAN) Application Analysis.

What Lifecycle reads

The only input Sonatype’s documentation describes is a file named cran-installed.packages, “exported via installed.packages() command in CRAN console”. It does not describe scanning DESCRIPTION, renv.lock or package tarballs. Matching is by package name and version.

That means the scan input has to be generated from an R installation that has the package’s dependencies installed. The Project’s own repository does not contain it.

Ruby

Mon, 01 Jan 0001 00:00:00 +0000

DRAFT. Not yet run end to end. Source: Sonatype’s Ruby Application Analysis.

What Lifecycle reads

Ruby is a manifest ecosystem, with a binary option. Sonatype’s documentation says it scans Gemfile.lock, .gem files and vendor/bundle. For the lockfile, “components from sections GIT, GEM and PATH and with an exact version will be analyzed”. For the best results it recommends scanning “after either installing the packages from a clean environment or storing the gems in a local cache”.

Rust

Mon, 01 Jan 0001 00:00:00 +0000

DRAFT. Not yet run end to end. Source: Sonatype’s Rust Application Analysis.

What Lifecycle reads

Rust is a manifest ecosystem, and the only file Sonatype’s documentation describes is Cargo.lock: “the Cargo coordinate-based matching feature provides the ability to scan and evaluate Rust dependencies found in the Cargo.lock file”. The name and version of each package entry are evaluated. The documentation does not mention Cargo.toml or built binaries.

Because the lockfile is the input, the Project must commit Cargo.lock. Library crates often do not. A Project that does not commit it has nothing to scan, and should either start committing it or generate it in Tier 1 with cargo generate-lockfile (which resolves to the newest versions, not the ones the Project tested against, and is therefore a weaker signal).

Ecosystem Guides on Sonatype Open Source Community Handbook

.NET

What Lifecycle reads

C/C++

What Lifecycle reads

Docker

What Lifecycle reads

Go

What Lifecycle reads

Why go.list and not go.sum

Java

What Lifecycle reads

JavaScript

What Lifecycle reads

PHP

What Lifecycle reads

Tier 1 job

Python

What Lifecycle reads

R

What Lifecycle reads

Ruby

What Lifecycle reads

Rust

What Lifecycle reads

Why `go.list` and not `go.sum`