The Indian Computer Emergency Response Team (‘CERT-In’) has, on July 9, 2025, released version 2 of the ‘Technical Guidelines on SBOM, QBOM & CBOM, AIBOM, HBOM’ (‘SBOM Guidelines’) detailing CERT-In’s prescriptions for maintaining various bills of materials, including Software Bill of Materials (‘SBOM’), Artificial Intelligence Bill of Materials (‘AIBOM’), Hardware Bill of Materials (‘HBOM’), Quantum Bill of Materials (‘QBOM’) and Cryptographic Bill of Materials (‘CBOM’).

A SBOM (read to include AIBOM, HBOM, QBOM and CBOM, as applicable) details the component parts comprising any software. Briefly, this includes all libraries and modules, along with a description of the software’s functionality and third-party dependencies. A SBOM ensures that organisations are aware of all codes being bought and built by their teams, allowing for an effective response to any vulnerability detected. CERT-In has chosen to include prescriptions for emerging technologies (QBOM and CBOM) in addition to SBOM, HBOM and AIBOM. The present SBOM Guidelines have not been made mandatory but seek to guide both public and private sector stakeholders on the best practices in respect of SBOMs in the context of cybersecurity measures.

The SBOM Guidelines are intended to benefit entities in the ‘public sector, Government, essential services and organisations involved in software export and software services industry.’ These organizations are encouraged to mandate the creation and provision of SBOMs as part of their software procurement and development workflows. This includes software consumers (entities that buy, license or commission software products), software developers (entities that build commercial or open-source software products) and software resellers (entities that bundle or customize existing software products).

The SBOM Guidelines identify 21 ‘minimum data fields’ that are to be tracked as part of the SBOM to enable adequate identification, which include:

i.    component name, supplier, version history and description;

ii.   license type and origin (whether open-source, proprietary or third-party);

iii.  known vulnerabilities, patch status, release date and end-of-life date;

iv.   criticality rating, usage restrictions and cryptographic checksums; and

v.    author name, timestamps and a unique identifier for the author (intended to survive supplier or branding changes).

CERT-In recommends that stakeholders:

i.    update their procurement templates to mandate provision of an SBOM in SPDX or CycloneDX format (internationally accepted machine-readable formats for efficient integration with existing security tools and asset management systems) together with ongoing Vulnerability Exploitability Exchange (‘VEX’) disclosures;

ii.   map responsibilities across the organisation’s various teams to ensure generation, validation, access and confidentiality of the SBOM (or other BOM as applicable);

iii.  select tooling which can automatically produce, store and parse SBOMs, integrating it with vulnerability scanners and patch management workflows;

iv.   train developers and contract managers on license compliance and SBOM sharing practices; and

v.    schedule periodic audits to confirm all updates are reflected promptly in the SBOM.