CERT-In SBOM guidelines: what version 2.0 asks for, and how to check

If you sell software to an Indian bank, a government department or an essential services operator, sooner or later a questionnaire will ask whether your SBOM follows the CERT-In SBOM guidelines. The document it means is CERT-In's Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, version 2.0, dated 9 July 2025. It is longer and more demanding than the US baselines most SBOM tools were built for.

This post covers who the guidelines are aimed at, the 21 data fields they list as minimum elements, what they say about vulnerability status, and how to generate an SBOM and check it against those fields before a customer does.

What are the CERT-In SBOM guidelines?

CERT-In, the Indian Computer Emergency Response Team under the Ministry of Electronics and Information Technology, published an SBOM-only first version of these guidelines in 2024. Version 2.0, dated 9 July 2025, keeps the SBOM material and adds four more bills of materials: a quantum BOM (QBOM) and cryptographic BOM (CBOM), an AI BOM (AIBOM) and a hardware BOM (HBOM).

It is guidance, not a statute. The document says departments and organisations "are encouraged" to make providing an SBOM a mandatory part of software procurement and development, and recommends that government, public sector and essential services organisations put SBOM requirements into every software purchase. In practice that is how it reaches suppliers: through contracts and vendor questionnaires. Law firm Khaitan & Co reads it the same way: not mandatory across the board, but a signal of where regulation is heading, with BOM obligations best written into contracts.

Who do the guidelines apply to?

Section 2.2 names the audience: entities "especially in the Government, Public Sector, Essential Services Organizations" and organisations in software exports and software services. Within those, it describes three roles:

• Software consumers, who acquire software to run their operations.
• Software developers, who build custom software.
• System integrators and resellers, who distribute, customise and support software products.

If you build software that ends up with one of those consumers, you are the developer the SBOM is asked of. The guidelines use banks and fintech as a worked example, which is why the request often arrives through financial-sector security reviews.

What are the CERT-In SBOM minimum elements?

Like the US NTIA baseline, CERT-In splits minimum elements into data fields, automation support and practices. The difference is the data fields. Table 5 of version 2.0 lists 21:

Identity	Provenance and terms	Risk and lifecycle	SBOM metadata
Component name	Supplier	Vulnerabilities	Author of SBOM data
Version	Licence	Patch status	Timestamp
Description	Origin	Release date	Executable property
Unique identifier	Dependencies	End-of-life date	Archive property
Checksums or hashes	Usage restrictions	Criticality	Structured property
			Comments or notes

The grouping is ours; the fields are CERT-In's. For automation support it names the two formats you would expect, SPDX and CycloneDX. Practices cover frequency, depth, known unknowns, distribution, access control and the handling of mistakes.

Several of these fields are facts no scanner can know. Release date, end-of-life date and criticality describe a component's lifecycle and its importance to your product. A tool that fills them in automatically is guessing. They have to come from the producer, which is you.

What do the guidelines say about vulnerabilities and VEX?

Chapter 6 asks suppliers to publish a VEX document once a vulnerability is known, and to keep it updated. It uses the same four statuses as the CISA and OpenVEX vocabulary: not affected, affected, fixed and under investigation. It then expects a CSAF advisory to follow with the detail.

The "patch status" and "vulnerabilities" fields in the SBOM table are the hook for this. An SBOM that lists components but says nothing about their known vulnerabilities, or lists vulnerabilities with no status, is missing part of what CERT-In asks for. We explain the VEX statuses and the not_affected justifications in SBOM and VEX explained.

How do you produce and check a CERT-In SBOM?

Vulkro Core generates the SBOM from your lockfiles and checks it, on your machine:

# generate: CycloneDX 1.6 with matched advisories in the same document
vulkro sbom . --format cyclonedx > sbom.cdx.json

# add the vulnerability status per advisory
vulkro sbom . --format cyclonedx-vex > vex.cdx.json

# check any SBOM, yours or a supplier's, against the CERT-In field set
vulkro sbom --check sbom.cdx.json --profile cert-in

--profile cert-in runs the NTIA minimum-elements check first, then adds the CERT-In fields the NTIA set does not cover. Here is the output for a deliberately thin one-component CycloneDX file:

[recommended] cert-in: components[].supplier: 1 of 1 component(s) have no supplier: ...
[recommended] cert-in: components[].description: 1 of 1 component(s) have no description: ...
[recommended] cert-in: components[].release date: 1 of 1 component(s) have no release date: ...
[recommended] cert-in: components[].end-of-life date: 1 of 1 component(s) have no end-of-life date: ...
[recommended] cert-in: components[].criticality: 1 of 1 component(s) have no criticality: ...
[recommended] cert-in: vulnerabilities: no `vulnerabilities` array: ...
▸ t.cdx.json: 0 required field(s) missing, 6 recommended.

Each line ends with the fix (trimmed here). Two design decisions are worth knowing:

• Only the NTIA minimum decides the exit code. A missing name, version, identifier, dependency relationship, author, timestamp, hash or licence is a required gap and exits 1. The CERT-In extras are reported as recommended, because several of them are lifecycle facts only the producer can supply, and failing a build over a field no tool can honestly fill would push people to invent values.
• Lifecycle fields are read from component properties. The check looks for properties such as release-date, end-of-life and criticality on each CycloneDX component. Add them in your release process, where someone knows the answer (the values below are illustrative):

{
  "type": "library",
  "name": "lodash",
  "version": "4.17.21",
  "purl": "pkg:npm/lodash@4.17.21",
  "supplier": { "name": "OpenJS Foundation" },
  "description": "Utility functions for arrays, objects and strings",
  "properties": [
    { "name": "cert-in:release-date", "value": "2021-02-20" },
    { "name": "cert-in:end-of-life", "value": "not announced" },
    { "name": "cert-in:criticality", "value": "medium" }
  ]
}

The check is honest about its edges. The CERT-In extras apply to CycloneDX files; an SPDX document gets the NTIA check only. Origin, comments and the executable, archive and structured properties are not checked. A clean result means the fields are present, not that their values are correct.

For a reviewer who wants evidence rather than a file, vulkro compliance-pack . --framework cert-in-sbom -o cert-in-evidence/ writes a folder that maps each part of the guideline (SBOM generation, minimum fields, dependency relationships, VEX status, integrity and licensing, the CBOM and the AIBOM) to the findings and artefacts behind it, with file and line. The quantum and hardware BOMs are listed as out of scope for a source scan, rather than quietly passed.

What about the CBOM and AIBOM sections?

Version 2.0 asks for an inventory of cryptographic assets and, for AI systems, of models, datasets and frameworks. Vulkro covers the parts that live in source code: --format cbom lists weak algorithms with the file and line where each is used, and --format aibom lists AI SDKs, model identifiers, model files and MCP servers. We wrote about the second in an AI bill of materials. Neither replaces the hardware, training-data or deployment questions the guidelines also ask.

A checklist for a CERT-In SBOM request

• Generate the SBOM per release from lockfiles, in CycloneDX or SPDX.
• Give every component a unique identifier (a purl), a hash and a licence.
• Add supplier, description, release date, end-of-life date and criticality where you know them.
• Attach vulnerability status as VEX, and mark anything unanalysed as under investigation.
• Run vulkro sbom --check FILE --profile cert-in and fix every required gap before sending.
• Decide who keeps the SBOM current and how often, since frequency is one of the practices CERT-In names.

Supply chain incidents are why the guidelines exist. Our write-up of supply-chain attacks as a code problem covers the attacks an inventory helps you respond to.

Where to see it

The compliance evidence use case shows how Vulkro maps findings to controls across frameworks, and the SBOM and VEX page shows the formats. The vulkro sbom reference and the compliance-pack reference list every flag. To run the check on your own SBOM, start here.

Frequently asked questions

Are the CERT-In SBOM guidelines mandatory?

Not by themselves. They are technical guidelines that encourage government, public sector and essential services organisations to require SBOMs in procurement. Suppliers usually meet them as a contract or questionnaire requirement from those buyers.

Which version of the CERT-In SBOM guidelines is current?

Version 2.0, dated 9 July 2025. It replaced the earlier SBOM-only guidelines and widened the scope from SBOM alone to QBOM and CBOM, AIBOM and HBOM.

Does a CycloneDX SBOM satisfy the CERT-In guidelines?

The format does: CERT-In names both CycloneDX and SPDX. Whether a given file satisfies the guidelines depends on its fields. Most generated SBOMs cover identity and dependencies but lack the lifecycle fields, which is what --profile cert-in reports.

How is CERT-In different from the NTIA minimum elements?

The NTIA 2021 baseline has seven data fields. CERT-In version 2.0 lists 21, adding description, licence, origin, vulnerabilities, patch status, release and end-of-life dates, criticality, usage restrictions, hashes and several file properties. It also covers cryptographic, AI and hardware bills of materials.