Free tool
SBOM CERT-In field checker
Drop in your SBOM and see, field by field, how much of CERT-In's 21-field list it already covers and which components have the most gaps.
Runs in your browser. Nothing is uploaded.
| # | CERT-In field | Coverage | Components | Derivable |
|---|
Components with the most gaps
| Component | Version | Fields missing |
|---|
SBOMReady fills the gaps for you from lockfiles, OSV and package registries, and writes a completed CycloneDX SBOM in CERT-In's format.
What CERT-In asks for in an SBOM
A software bill of materials (SBOM) lists the components inside a piece of software: libraries, frameworks, packages and their versions. CERT-In's Technical Guidelines on SBOM, QBOM and CBOM, AIBOM and HBOM (version 2.0, July 2025) set out 21 data fields an SBOM should carry, from the basics like name, version and supplier to fields most tools never fill, such as patch status, end-of-life date, criticality, usage restrictions and whether a component is executable or an archive.
Government departments, public sector undertakings and banks in India increasingly ask suppliers for SBOMs in this shape. An SBOM straight out of a generator usually covers fewer than half of the fields.
How this checker works
It reads a CycloneDX or SPDX 2.x JSON SBOM in your browser and maps each of the 21 fields to where it lives in that format: for example the purl or CPE for the unique identifier, the licenses array for the licence, and the dependencies section for component dependencies. Fields with no native slot in CycloneDX are read from properties named certin:<field>, such as certin:criticality or certin:eol_date, which is how SBOMReady writes them. The field list and the mapping are the same ones our SBOMReady product uses.
For each field you get the share of components that have it. The Derivable column shows missing values that can be filled from information already in the SBOM, such as the origin of a package from a public registry.
The 21 fields, briefly
- Identity: component name, version, description, supplier, unique identifier (purl or CPE) and checksums.
- Legal: licence and usage restrictions such as export controls.
- Security: known vulnerabilities, patch status, release date, end-of-life date and criticality.
- Structure: dependencies, origin (open-source, proprietary or third-party), and the executable, archive and structured properties.
- About the SBOM itself: the author of the SBOM data and the timestamp, plus comments.
How to close the gaps
Start with what your build already knows. Generate the SBOM from lockfiles rather than from installed folders, so versions and purls are exact. Add hashes in the build. Pull licences and descriptions from package registries, and vulnerabilities from OSV or your scanner. The remaining fields, such as criticality and end-of-life, need a decision from your team: record them once per component and reuse them.
Large SBOMs are fine: the file is processed in a background thread in your browser, so the page stays responsive even with tens of megabytes of JSON.
FAQ
Questions
Which SBOM formats are supported?
CycloneDX JSON (any 1.x version) and SPDX 2.x JSON. XML and tag-value files aren't supported here; convert them to JSON first.
Is my SBOM uploaded anywhere?
No. The file is read and checked entirely in your browser and never leaves your device.
Why are some fields almost always empty?
Fields such as patch status, end-of-life date, criticality and usage restrictions have no standard place in most generators' output. They need data from outside the build or a decision from your team.
Do I need all 21 fields for every component?
CERT-In lists them as the data fields an SBOM should contain. Buyers differ in how strictly they check, but full coverage of the identity, licence and vulnerability fields is the usual minimum.
Where do certin: properties come from?
They're how SBOMReady stores fields that CycloneDX has no native slot for. Any tool can write them as component properties.
How large a file can it check?
Files of 20 MB and more are processed in a background thread. Above 100 MB, split the SBOM or use SBOMReady on the command line.