Each generator reads a different input: Maven and Gradle use resolved dependency graphs, npm uses its dependency tree or lockfile, the Python tool reads environments, lockfiles or requirements, and the Go tool evaluates modules and build constraints. Knowing the input tells you what the SBOM can and cannot show.
The cheat sheet
This is based on the open source CycloneDX generators' own documentation.
| Build system | Generator input | Key setting to check |
|---|---|---|
| Maven | Direct and transitive dependencies of the project, by scope | Scope flags, goal choice (module, aggregate, package) |
| Gradle | Resolvable configurations of each project | includeConfigs, skipConfigs, aggregate or direct task |
| npm | npm's dependency tree, from installed packages or the lockfile only | omit, lockfile only mode, workspaces |
| Python | Virtual environment, Poetry, Pipenv or requirements file | Which subcommand, which environment |
| Go | Modules and, in app mode, packages that compile for a target | Environment constraints, app or mod |
Notice what is absent from every row: the running system. All of these describe a build or an install, not production.
What each input implies
Maven. The Maven plugin README says it produces a BOM containing the aggregate of all direct and transitive dependencies of the project. The scopes you include decide whether provided and test dependencies show up.
Gradle. The README says a direct SBOM scans every resolvable configuration by default. That includes test and tooling configurations unless you narrow it.
npm. The dedicated tool uses npm's own listing of the tree and may read package.json files inside node_modules as an extra source when that listing has problems. Lockfile only mode drops metadata that lives in dependency manifests.
Python. The tool reads what is installed in an environment, or what a manifest and lockfile say. An environment includes whatever was installed, wanted or not.
Go. App mode includes only modules the application depends on, with build constraints evaluated, while mod mode includes the aggregate of modules required by all packages in the module.
The trust check for each
- Count the components and compare to the lockfile or dependency report you already trust.
- Pick three dependencies you know about and confirm names and versions.
- Look for things that should not be there: test libraries in a shipped file, the generator itself.
- Look for things that should be there but are not: a shaded jar, a vendored library, a native library.
- Read the root component and confirm name, version and type.
Step 4 is where input limits show. A dependency copied into the repository or bundled into a jar is not a resolved dependency, so no generator reading resolution data will list it by name.
What none of them see
- Code copied into your repository by hand.
- Libraries loaded at runtime from outside the dependency system.
- Operating system packages and base images, unless you also scan the container.
- Anything installed in production after the build.
For those, add another source such as a container image scan, and treat the build SBOM as one layer of the full picture.
Choosing a combined approach
Most products need more than one SBOM source: one from the build for the application dependencies, one from the image for the system layer. Merging or linking them is a separate task. The point of the cheat sheet is to remind you which layer each file speaks for.
Try it yourself
Click through it at your own pace, or open it full screen. Compare what an image scan finds with what a build generator reads, and note the layers that only the image shows.
Safeguard's SBOM and dependency scanning covers manifests and lockfiles, and the free scan lets you try your own repository.
Quick check
Does a build SBOM describe production?
No. It describes what the build resolved. Production can differ, so compare with an image or runtime view.
Which input is most reliable?
No input wins everywhere. Pick the one that matches what you ship, then verify against a source you trust.
Sources
- CycloneDX Maven plugin README
- CycloneDX Gradle plugin README
- CycloneDX npm tool README
- CycloneDX Python tool README
- CycloneDX gomod README
Last reviewed: 19 October 2026.
