An SBOM for CERT-In: the 21 minimum elements, explained, and how to check yours

A software bill of materials, or SBOM, is a machine-readable list of every component inside a piece of software: each library, its version, who supplies it and under what licence. Its use is simple. When the next Log4Shell is announced, an organisation with SBOMs finds out in minutes which of its systems are affected. One without them spends the week asking vendors.

CERT-In’s Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, version 2.0 of 9 July 2025, say what an SBOM has to contain to be useful for that. Table 5 lists 21 minimum elements. The guidelines are mandatory for government, public-sector and essential-services organisations and for software exporters, and sector regulators have been folding SBOMs into their own rules. For everyone else they are the benchmark a large customer will hold you to.

1 · The 21 elements, grouped

In CERT-In’s table they come in one list. Grouped by what they are for, they are easier to fill:

• What the component is: Component Name, Component Version, Component Description, Component Supplier, Component Origin, Unique Identifier.
• Proof it is that component: Checksums or Hashes, and the Executable, Archive and Structured properties, which say what kind of file it is.
• How it fits: Component Dependencies.
• What you may do with it: Component License, Usage Restrictions.
• How safe and how current it is: Vulnerabilities, Patch Status, Release Date, End-of-Life (EOL) Date, Criticality.
• About the SBOM itself: Author of SBOM Data, Timestamp, Comments or Notes.

Six of them carry most of the weight: name, version, supplier, licence, hashes and the unique identifier (usually a package URL, or purl). Those are what let a scanner match a component to a vulnerability. An SBOM missing them for a third of its components is a list of names, not a bill of materials.

2 · CycloneDX or SPDX

CERT-In accepts both. CycloneDX, from OWASP, was built for security use and carries vulnerabilities and dependencies naturally. SPDX, from the Linux Foundation, grew out of licence compliance and is an ISO standard. Either is fine; pick the one your build tools write well, write it as JSON, and stay with it, because a consistent format matters more to whoever reads it than which format it is.

3 · Generating one from the build

An SBOM written by hand is out of date by the next release. Generate it in the build, from what actually ships. Three common open-source generators:

syft dir:. -o cyclonedx-json=sbom.json
trivy fs --format cyclonedx --output sbom.json .
cdxgen -o sbom.json

Most language ecosystems also have their own: the CycloneDX plugins for Maven and Gradle, and for npm. Run the generator on the built artefact or the container image where you can, rather than only on the source tree, so that what is listed is what is delivered.

4 · The half a generator will not fill

Run any of those, put the result through a validator, and the same fields come back empty. Generators read package manifests. They cannot know:

• End-of-life dates for each component, which have to come from each project’s support policy.
• Criticality: how much of your product depends on the component, which is your judgement, not the package’s.
• Patch status and vulnerabilities as of the day you issue it, which come from a vulnerability scan of the SBOM, not from the SBOM.
• Usage restrictions, such as export controls or licence terms beyond the licence name.
• Supplier, which many generators leave blank for open-source packages.

That half is a process rather than a command: a short enrichment step after generation, owned by someone, re-run each release. CERT-In’s practices section asks for exactly that: an SBOM refreshed with every release and every change to a component, with known unknowns marked as unknown rather than left out.

5 · Checking yours

Our free SBOM check reads a CycloneDX or SPDX file in JSON and shows which of the 21 elements it fills and for how many components, which components are on CISA’s list of exploited flaws or past their end of life, and licence and duplicate problems. It runs in your browser; the file is never uploaded.

If the scan behind the SBOM gives you a long list of findings, the scan prioritiser sorts them into today, this week and this month.

Questions people ask