Home › Free tools › SBOM check
Drop in the software bill of materials for your product. It checks the 21 data fields CERT-In’s SBOM guidelines ask for, flags components attackers are known to use, licences that need a look, and duplicates, then says what to fix first. Read in your browser.
SBOM check1 Summary
2 The checks
3 What this could not check
Fields checked against CERT-In’s Technical Guidelines on SBOM (version 2.0), Table 5. Read in your browser; the file was never sent to us. Guidance, not an audit or a vulnerability scan; see the terms.
An SBOM is generated from the code or the built image, not written by hand. Free, open-source generators do it in one command.
What happens to it: it is read in your browser and dropped once the report is drawn. Nothing is uploaded, and our copy of your details carries only the format and the counts, never a component name.
The questions people search for before they run the check.
A software bill of materials: a machine-readable list of every component inside a piece of software, with its version, supplier, licence and a unique identifier. It lets anyone check, in minutes, whether a newly announced flaw such as Log4Shell affects the software.
CERT-In's Technical Guidelines on SBOM (version 2.0, July 2025) list 21 minimum data fields, among them component name, version, supplier, licence, origin, dependencies, vulnerabilities, patch status, end-of-life date, hashes, the author and timestamp, and a unique identifier. This check shows how many of them your SBOM fills.
CycloneDX and SPDX, in JSON, the two formats CERT-In's guidelines name. If your generator writes XML or SPDX tag-value, ask it for JSON instead; most can.
No. It flags a short, dated list of notorious components, such as old Log4j, Spring and OpenSSL versions, but a full check needs a vulnerability scanner fed with the SBOM. This check is about whether the SBOM is complete enough for that scanner, and for CERT-In.
No. It is read in your browser and dropped once the report is drawn. If you ask for the report, we keep your details and a one-line summary with the format and the counts, never a component name.
An SBOM generated with every release, the fields customers and regulators ask for, and vulnerability scanning fed from it, so the next Log4Shell is a search, not a scramble.