SBOM Generator

Generate an SPDX or CycloneDX SBOM from a manifest or lockfile

Paste a package.json, package-lock.json, requirements.txt, go.mod, pom.xml or one of five other dependency files — or upload it — and get back a software bill of materials in CycloneDX or SPDX. Both standards are supported, in two serialisations each, so whichever format your customer, auditor or scanner asked for is one dropdown away. The file format is detected automatically from the filename or the content, so in practice you paste and read the result.

Everything runs in your browser. The manifest is parsed, the components are assembled and the document is serialised locally; nothing is uploaded and no registry is contacted. For a file that lists every internal package name in your product, that is not a small detail.

What an SBOM is for

An SBOM is an inventory of the third-party components inside a piece of software. The argument for having one is best made by the mornings after a Log4Shell or an xz-utils backdoor, when the only question that matters is “are we running it, and where?”. Organisations with a current SBOM per artefact answer that with a query. Organisations without one answer it by asking every team to go and look, which takes days they do not have.

The regulatory pressure follows the same logic. US Executive Order 14028 pushed SBOMs into federal software procurement, NTIA published the minimum elements a bill of materials has to carry, and the EU Cyber Resilience Act now requires manufacturers of products with digital elements to identify and document the components they ship. The practical consequence for most teams is that an SBOM has quietly become a contractual deliverable — something a customer’s security questionnaire asks for by name, in a named format.

SPDX or CycloneDX? The difference that matters

There are two mainstream standards and they were built for different jobs. Both are widely supported and neither is going away, which is why this tool emits both.

In practice: if the request came from legal, procurement or an open-source compliance programme, they almost certainly want SPDX — its licence fields are richer and its tag-value serialisation is the one humans read. If it came from a security team, a scanner or a vulnerability-management platform, they want CycloneDX, because the tooling around VEX and vulnerability exchange grew up there. If nobody specified, CycloneDX JSON is the safer default for a modern pipeline; it is what most scanners ingest without configuration.

Both are convertible to a degree, but conversion is lossy in the areas each format was designed for, so generating natively in the format you actually need beats round-tripping.

What goes into the document

For each dependency the tool records the component name, the version, the ecosystem, whether it is a runtime or development dependency, a package URL, and a licence where one is available. The package URL (purl) is the part that does the real work: pkg:npm/express@4.18.2, pkg:pypi/requests@2.31.0, pkg:golang/github.com/gin-gonic/gin@1.9.1. It is an unambiguous, ecosystem-aware identifier, and it is what lets a downstream scanner match your component against a vulnerability database without guessing. Both output formats carry it — CycloneDX in the component’s purl field, SPDX as an ExternalRef of type purl.

SPDX output is emitted with a generated document namespace UUID, a creation timestamp, a DESCRIBES relationship per package, and NOASSERTION in the fields the tool genuinely cannot determine from a manifest — download location, copyright text, and licence where the source file does not state one. CycloneDX output carries a urn:uuid serial number, a metadata block naming the tool, and the top-level application component when the manifest declares a project name and version. NOASSERTION is not a defect; it is the correct value, and inventing a licence would make the document worse.

Supported inputs

Detection works from the filename when you upload, and from the content when you paste — a lockfileVersion key marks a package-lock, a _meta key marks a Pipfile.lock, and so on. Dependencies are grouped by scope, so development and optional dependencies are labelled rather than silently mixed in with the ones you actually ship.

Manifest or lockfile? Use the lockfile

This is the choice that decides whether your SBOM is useful, and it is worth being blunt about it.

• A manifest lists what you asked for. package.json says ^4.18.0. The tool strips the range operator and records 4.18.0, which is the floor of the range, not necessarily what is installed. And package.json carries no licence information about your dependencies at all, so every licence comes out as NOASSERTION.
• A lockfile lists what you got. package-lock.json pins exact resolved versions and, for most packages, records the declared licence — so this is the one input where the licence breakdown is populated from real data rather than left unasserted.
• A manifest lists direct dependencies only. The transitive tree is where the interesting vulnerabilities live; Log4Shell reached most of its victims transitively. A lockfile includes them.

If you feed it a package.json you will get a valid, well-formed SBOM of your direct dependencies with unasserted licences. That is fine for a quick inventory and it is not what you should send a customer. Paste the lockfile.

Reading the output before you ship it

Alongside the generated document, the results are broken out into a few views. The dependency tree is searchable, which is the fastest way to answer “do we have X anywhere”. The licence view groups components as permissive, copyleft, proprietary or unknown — the copyleft bucket is the one to read first if you distribute a binary, because AGPL and GPL obligations on shipped software are the ones that generate legal conversations. Anything the tool cannot classify lands in unknown rather than being guessed at.

There is also a vulnerability view, and it is important to understand exactly how small it is: it checks component names against a short built-in list of well-known advisories (lodash, axios, minimist, requests, urllib3, flask, django, rails and a handful of others) using a simplified version comparison. It is an illustration, not a scanner. It does not query the NVD, OSV or GitHub Advisories, it has no network access at all, and “no known vulnerabilities detected” here means nothing beyond “nothing matched a very short list”. The correct workflow is to generate the SBOM here and feed it to a real scanner — that is what the format is for, and it is why the vulnerability data is deliberately not written into the CycloneDX or SPDX output.

Honest limits

• No hashes. The generated documents do not include component checksums. A manifest does not contain them and the tool makes no network calls to fetch them. If your recipient requires hashes as part of NTIA minimum elements, generate from a build-time tool that has the artefacts on disk.
• Declared, not resolved. Everything comes from the file you pasted. A manifest-derived SBOM reflects intent; only a lockfile reflects a real dependency graph, and neither reflects what is actually inside a built container image.
• One ecosystem per run. A polyglot repository needs a pass per manifest, and merging the results is a manual step.
• Licence text is not verified. Where a licence is recorded it is the string the package declared. Declared licences are wrong often enough that compliance programmes scan the source rather than trusting the metadata.

Within those limits the output is standards-conformant and ready to hand over: CycloneDX 1.5 as JSON or XML, SPDX 2.3 as JSON or tag-value, plus a CSV of the component table for the spreadsheet somebody inevitably asks for. Each downloads with the conventional extension — .cdx.json, .cdx.xml, .spdx.json, .spdx — so tooling that sniffs filenames recognises it without renaming.

Common questions

• Is my dependency file uploaded anywhere? No. Parsing and generation happen entirely in the browser, and no package registry is queried. Nothing about your dependency graph leaves the machine.
• Which format should I send if the request just said “an SBOM”? CycloneDX JSON. It is the format most security tooling ingests without configuration. If the request came from legal rather than security, send SPDX.
• Why are all my licences NOASSERTION? You almost certainly pasted a manifest rather than a lockfile. package-lock.json is the input that carries declared licence data; a plain package.json does not contain it.
• Why are the versions missing their ^ and ~? Range operators are stripped so the document holds a concrete version string, which is what both standards expect. That resolved version is the range floor, not the installed version — another reason to use the lockfile.
• Can I use the output for a customer questionnaire? The document is well-formed for both standards. Check whether the questionnaire demands component hashes or supplier fields, which a manifest cannot supply.

Where this fits in a real process

An SBOM generated by hand once, for a questionnaire, is a compliance artefact and nothing more. The version that earns its keep is generated per build, stored with the artefact it describes, and re-scanned when new advisories land — so that the next time a component everybody depends on turns out to be compromised, the answer to “are we affected” is a lookup rather than a fire drill. Use this tool to produce the document you need right now, to see what the two formats actually look like side by side before choosing one, or to check what your dependency file will yield before wiring generation into CI.