What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current full ecosystem list, which changes frequently: verify against project documentation
- Governing organization and repository location: confirm the canonical project home
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
cdxgen walks a project directory, identifies which build systems and package ecosystems are present, and produces a CycloneDX software bill of materials describing what it found. The technique varies per ecosystem, and that is the point: for Maven and Gradle it can invoke the build tool to resolve the real dependency graph rather than guessing from a POM, for npm it reads lock files, for Python it handles requirements files, Poetry and Pipenv, and for Go it queries module metadata. Where a manifest alone would give an incomplete or ambiguous answer, it prefers to ask the build system. It also handles container images, operating system packages, binaries and Java archives.
Beyond the basic inventory, cdxgen populates the parts of CycloneDX that many generators leave empty: component hashes, package URLs, license data, dependency relationships showing which component pulled in which, and, with its evidence collection mode, occurrence and call-stack evidence that records where in your source a component is actually used. The output is designed to be consumed, most commonly by OWASP Dependency-Track, which ingests CycloneDX directly.
Where it fits
This runs as a build pipeline step, as part of the build that resolves dependencies, because that is when the graph is accurate. It is operated by platform or build engineers rather than a security team, and it produces an artifact rather than a verdict. cdxgen finds no vulnerabilities and blocks no builds. You need a downstream consumer: a Dependency-Track instance, an artifact store, or a contract requiring SBOM delivery. Generating SBOMs nobody ingests is wasted pipeline time.
Strengths
- Ecosystem breadth from a single tool, which avoids stitching together one generator per language.
- Resolving through build tools rather than parsing manifests produces dependency trees that reflect what actually ships.
- Emits rich CycloneDX including relationships and evidence, so downstream tooling has more than a flat component list.
- Ships as a container image and a Node package, so pipeline integration is straightforward.
Limitations
- Accuracy depends on the build succeeding in the scan environment. Projects with complex or network-dependent builds produce thinner SBOMs, and the failure is quiet.
- Breadth across many ecosystems means quality varies by ecosystem, and the less common ones get less attention.
- It is generation only. You still need a matching and policy layer, and the pairing has to be maintained separately.
Who it suits
The right choice for teams that have settled on CycloneDX and Dependency-Track and need one generator covering a polyglot estate. Less suitable if you want a single tool that both produces inventory and tells you what to fix, or if your build environments cannot reliably resolve dependencies during a scan.
Used cdxgen? Recommend it under your own name and title.
Recommend this tool