SBOM Generator & Dependency Advisory Analyzer

About the SBOM Generator & Dependency Advisory Analyzer

A software bill of materials lists every component your product ships: its name, exact version, package URL, licence, checksum and where it sits in the dependency graph. Customers, auditors and India’s CERT-In guidelines ask for one. Open your lockfiles, a project folder or an archive of it, and this tool makes the SBOM as CycloneDX 1.6 and SPDX 2.3 (JSON and tag-value), with a check of the NTIA minimum elements and CERT-In’s baseline fields: from npm, Yarn, pnpm, pip, Poetry, uv, Pipenv, Go, Cargo, Composer, Bundler, Gradle, Maven and NuGet files, or from Maven and Gradle dependency-tree output.

Then, when you ask, it checks every exact version against OSV.dev, the open vulnerability database that gathers the GitHub, Python, Go, Rust and other advisory databases. Only each package’s ecosystem, name and version are sent. Each vulnerable package comes with its advisories, CVSS base scores, the release that fixes them and the command or override that gets you there, and malicious packages are flagged.

The SBOM, its files and the licence summary are always yours in full. The advisory report is a free preview: every count, with the first half of the vulnerable packages (up to 10); the full list, the PDF and Word report, CSV, JSON, Markdown and the CycloneDX file with advisories (VEX) unlock with a Pro pass.

Common uses

• Answering a customer’s or an auditor’s request for an SBOM, in CycloneDX or SPDX.
• Checking a release for known vulnerabilities before you ship it, with the fix for each one.
• Preparing the SBOM fields CERT-In’s guidelines list for software supplied in India.
• Recording which advisories do not affect you (VEX) so the same alerts do not come back.

Files it reads

• JavaScript: package-lock.json and npm-shrinkwrap.json (v1 to v3), yarn.lock (Yarn 1 and 2+), pnpm-lock.yaml, package.json (ranges only).
• Python: requirements.txt (also with hashes), Pipfile.lock, poetry.lock, uv.lock, pyproject.toml.
• Go: go.mod and go.sum, go mod graph and go list -m all output.
• Rust, PHP, Ruby, .NET: Cargo.lock and Cargo.toml, composer.lock and composer.json, Gemfile.lock, NuGet packages.lock.json.
• Java and Kotlin: pom.xml, mvn dependency:tree output, build.gradle(.kts), gradle.lockfile, version catalogs and gradle dependencies output.
• SBOMs: CycloneDX and SPDX files, to merge them or check them for advisories.

A manifest gives ranges, not versions: add the lockfile, or the tree output, for exact versions and the full graph.

How a version is matched to an advisory

OSV.dev answers which advisories affect each exact version. The tool then reads each advisory’s affected ranges to find the release that fixes it, comparing versions by each ecosystem’s own rules (Semantic Versioning for npm, Cargo and Go, PEP 440 for Python, Maven’s version order, RubyGems’, Composer’s and NuGet’s). Advisories that are the same vulnerability under several ids (GHSA, CVE, PYSEC …) are shown once with all their ids.

Severity is the advisory’s CVSS base score (CVSS 4.0, 3.1 or 2.0, computed with FIRST’s equations; a vector’s threat or temporal metrics do not lower it), on FIRST’s rating scale; an advisory without a vector uses GitHub’s rating.

SBOM formats and minimum elements

The CycloneDX file follows the 1.6 JSON schema and the SPDX files the 2.3 specification; both validate against their official schemas. Each component has its package URL, the checksum its lockfile records, its licence and its dependencies. The NTIA minimum elements (supplier, component name, version, other identifiers, dependency relationship, author, timestamp) and CERT-In’s 21 baseline fields are checked against what the SBOM holds, so you see which ones need your input, such as the supplier.

Limitations

• An advisory database lists what is known: a package without advisories is not proven safe, and new advisories appear daily. Check again before each release.
• A vulnerable dependency is not always exploitable in your product; record your assessment of each advisory, which the CycloneDX file with advisories carries.
• Packages from private registries, git or local paths are never sent, so they are not checked. Ranges without a lockfile are not checked either.
• Licences come from the files (npm and Composer lockfiles record them) or, when you ask, from the registries: other files do not state them.

Privacy

Looks up live data online

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot. Your files are read on your device and never uploaded. Only when you ask: the advisory check sends each package’s ecosystem, name and exact version to the public OSV.dev API, and the licence lookups send names and versions to the npm registry, PyPI or deps.dev.