Package Manifest Projects

This guide covers generating an SBOM for a project managed by a package manager — JavaScript, Python, Go, Rust, Ruby, PHP, .NET, or Java.

Prerequisites

No package manager and no network access are required. lynkctl reads the manifests and lockfiles in your project directly.


Supported Ecosystems

Ecosystem

--provider

Detected from

JavaScript / npm

npm (alias yarn)

package.json, package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, bun.lock

Python

python

requirements.txt, Pipfile.lock, poetry.lock, pdm.lock, pylock.toml, uv.lock, pyproject.toml, setup.py

Go

go

go.mod, go.sum

Rust

cargo

Cargo.toml, Cargo.lock

Ruby

gem

Gemfile.lock, *.gemspec

PHP

php

composer.json, composer.lock

.NET

nuget (aliases dotnet, csharp)

*.csproj, packages.lock.json, packages.config, Directory.Packages.props, Directory.Build.props, *.deps.json

Java (Maven)

maven

pom.xml

Java (Gradle)

gradle

build.gradle(.kts), settings.gradle(.kts), gradle.lockfile, gradle/verification-metadata.xml


Generate an SBOM

From the project root:

lynkctl auto-detects the ecosystem from the descriptors in the directory. The examples below are all equivalent to auto-detection, shown with an explicit --provider for clarity:

Lockfiles vs Manifests

A lockfile pins the exact resolved dependency set; a manifest only declares ranges. lynkctl prefers the lockfile when one is present. When a project has only a manifest (for example a package.json with no package-lock.json), lynkctl falls back to the manifest and emits a LOCKFILE_ABSENT diagnostic — the resulting SBOM may be less precise than one built from a lockfile.

For the most accurate SBOM, commit and point lynkctl at a project that has its lockfile present.

Multi-Ecosystem Repositories

If a directory contains descriptors for more than one ecosystem — say a package.json next to a go.mod — auto-detection is ambiguous and lynkctl reports MULTI_ECOSYSTEM_DETECTED. Pass --provider to choose:

Flags

Manifest providers honour the shared flags — --no-enrich, --overrides, --evidence, --exclude-dev, --exclude-optional, --reproducible, --timestamp, --strict, --quiet, --verbose, and --output. See the Generating SBOMs flag reference.

The C/C++ build-provider flags — --include-source-files, --exclude-header-files, --include-unlinked-vendored, --deep-scan, and the --make-* / --cmake-* / --iar-* families — do not apply to manifest providers. Passing one produces a usage error (exit code 2).

Troubleshooting

If a run reports warnings or errors, rerun with -v to see the individual diagnostics and their suggested actions. See Diagnostics & Exit Codes for severity levels, exit codes, and strict mode. For help interpreting a specific diagnostic, contact Interlynk.

Last updated