SBOM Generator
Generate a Software Bill of Materials from your dependency manifest — CycloneDX JSON or SPDX tag-value. Covers npm, PyPI, and Go modules. Built for the EU Cyber Resilience Act's SBOM documentation duties. Nothing is uploaded — manifests can reveal internal package names, so everything runs locally.
Supported inputs: package.json and package-lock.json (npm), requirements.txt (PyPI), and go.mod (Go modules). Direct dependencies are captured; package-lock.json additionally resolves the installed versions. Components carry pkg: PURLs so scanners and VEX tools can match them to advisories.
Why it exists: the EU Cyber Resilience Act requires an SBOM as part of product technical documentation from December 2027 — see our CRA SBOM requirements guide and the broader Cyber Resilience Act overview.
Frequently asked questions
CycloneDX or SPDX — which should I pick?
CycloneDX (JSON) is the newer format, designed for security use cases — vulnerability scanning, VEX, dependency graphs. SPDX (ISO/IEC 5962) is the license-compliance veteran. The CRA accepts either as long as the SBOM is machine-readable; pick CycloneDX unless your toolchain or customer contract asks for SPDX.
Does this cover transitive dependencies?
From package-lock.json, yes — the lock file lists everything actually installed, including transitives. From package.json, requirements.txt, or go.mod you get the declared (direct) dependencies, which is the minimum the CRA requires in the SBOM. For full transitive depth from a manifest file alone, a package resolver is needed.
Is my manifest uploaded?
No. Everything runs in your browser — dependency manifests can expose internal package names and repository paths, so nothing is sent to a server.
Is the SBOM published publicly under the CRA?
No — it forms part of the technical documentation shared with market-surveillance authorities on request, not something you publish. What is public is the CE marking and declaration of conformity.