CERT-In SBOM requirements: what the Version 2.0 guidelines ask for

CERT-In's Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM (Version 2.0, 9 July 2025) are India's reference for software transparency. This guide sets out what they ask of consumers, developers and integrators.

What CERT-In published

CERT-In, India's national Computer Emergency Response Team, published Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0, dated 9 July 2025 ^[1]. It extends CERT-In's earlier SBOM guidance to four further bills of materials: cryptographic (CBOM), quantum (QBOM), AI (AIBOM) and hardware (HBOM) ^[2][3]. The document covers SBOM concepts, the ecosystem, preparation, processes, vulnerability tracking and recommendations, followed by chapters on each additional BOM type ^[1].

Who it applies to

The guidelines are aimed particularly at government, the public sector, essential-services organisations and organisations in the software export and services industry ^[1]. They describe three roles:

• Software consumers must ask for a complete SBOM, map it to their internal SBOM, include it in vulnerability management and update it when patches are applied.
• Software developers must ensure a correct and complete SBOM is supplied and issue VEX and CSAF advisories.
• System integrators and resellers distribute products with complete SBOMs and include accurate SBOMs in deliverables.

Law-firm commentary describes the guidelines as non-mandatory but strongly recommended ^[2]. Sector regulators can make SBOMs binding: SEBI's CSCRF requires them for regulated entities' core and critical software ^[4].

Procurement recommendations

Recommendation 7.1.1 asks government, public-sector and essential-services organisations to include SBOM requirements in all software and solution procurement. Recommendation 7.1.2 states that "all software supplied to the government; public sector & essential services organizations/departments must be accompanied by a complete SBOM" ^[1]. See SBOM procurement requirements for contract language.

The 21 baseline fields

CERT-In lists 21 baseline SBOM fields: Component Name, Component Version, Component Description, Component Supplier, Component License, Component Origin, Component Dependencies, Vulnerabilities, Patch Status, Release Date, End-of-Life (EOL) Date, Criticality, Usage Restrictions, Checksums or Hashes, Comments or Notes, Author of SBOM Data, Timestamp, Executable Property, Archive Property, Structured Property and Unique Identifier ^[1]. The unique identifier follows the Package URL pattern. Each field is explained, with examples and sources, in CERT-In SBOM 21 fields explained.

Levels, classifications and formats

Because recommendation 7.1.2 asks for a complete SBOM, a top-level list of direct dependencies will not meet it. State the level and classification whenever you share an SBOM.

Versioning, storage and sharing

CERT-In recommends a separate SBOM for each software version, updated only to add component information or correct errors, and workflows to update SBOMs as components change ^[1]. SBOM data should be stored and transmitted securely with encryption and access controls, and shared documents should be digitally signed. Suggested sharing channels include secure file-sharing platforms, API integration, collaboration tools and industry repositories ^[1].

VEX and CSAF

When a vulnerability is discovered, suppliers should publish a VEX document with one of four statuses (not affected, affected, fixed, under investigation), followed by a CSAF advisory giving details, affected versions, severity and mitigation ^[1][5]. See SBOM vs VEX.

Implementation roadmap

CERT-In describes three phases ^[1]: Start (critical assets, format, minimum requirements, storage, tooling, procurement), Progress (Package URL identifiers, mapping supplier SBOMs, SSDLC integration, configuration management) and Advance (vulnerability tracking, incident response, periodic review). CERT-In's July 2025 audit policy guidelines also list SBOM auditing within audit scope ^[6].

Checklist

1. Map which applications and suppliers fall under the guidelines or a sector regulator.
2. Add SBOM, VEX and, where relevant, CBOM, AIBOM and HBOM clauses to procurement templates.
3. Generate SBOMs in CI/CD in SPDX or CycloneDX and validate against the 21 fields.
4. Enrich time-sensitive fields continuously: vulnerabilities, patch status, EOL, criticality.
5. Establish VEX and CSAF processes for software you supply.
6. Keep timestamped evidence: SBOM versions, validation results, VEX decisions and owners.

How IntelliXBOM helps

IntelliXBOM validates SBOMs against the CERT-In field list, flags missing or stale fields, keeps version history and diffs, and records VEX decisions. It maps the inventory, including CBOM, QBOM, AIBOM and HBOM, to framework controls and produces timestamped evidence. It helps organisations address the guidelines; it does not certify compliance.

This article summarises public guidance for information only and is not legal advice; refer to the current official documents before acting.