The Indian Computer Emergency Response Team (“CERT-In”) has issued the updated version of the “Technical Guidelines on | SBOM | QBOM & CBOM | AIBOM | HBOM” on July 09, 2025 (“Guidelines”) for maintenance of Bill of Materials (“BOM”).

A BOM is a comprehensive, structured list of all the components, materials, and instructions required to manufacture a product. These Guidelines introduce a voluntary but detailed framework for improving software supply chain transparency through the maintenance of BOM across software and now artificial intelligence (“AI”), and hardware systems.

Even though not legally binding, these Guidelines represent the intent of the Indian Government to establish a structured best practice model and ‘good to have’ measures that are likely to influence contractual standards, procurement procedures, and regulatory expectations in India and become market practice.

1. Scope of the Guidelines

The Guidelines set out five categories of BOMs, namely Software BOM (“SBOM”), Artificial Intelligence BOM (“AIBOM”), Cryptographic BOM (“CBOM”), Quantum BOM (“QBOM”), and Hardware BOM (“HBOM”). The Guidelines aim to address specific areas of supply chain risk and are applicable to organizations engaged in software exports and software services industry, technology vendors, system integrators, AI developers, hardware manufacturers and deployers, as well as public sector departments and government entities.

• SBOM: The SBOM focuses on enumerating all software components, including direct and indirect dependencies, their sources, versions, licenses, and known vulnerabilities, enabling stakeholders to mitigate risks and enhance software transparency.
• AIBOM: AIBOM mandates the disclosure of AI models, including their associated datasets, performance metrics, biases, and security features, specifically in light of growing need for transparency and accountability in AI systems, which are increasingly integrated into critical sectors such as healthcare, finance, and public services. An AIBOM helps address AI-related risks, including bias, lack of explainability, ethical use, and vulnerability to adversarial attacks.
• HBOM: HBOM extends the transparency obligations to hardware devices, including their constituent components and firmware.
• QBOM: The purpose of a QBOM is to focus on components related to quantum computing and quantum-safe cryptography. It includes quantum algorithms, security frameworks, and related technologies, enabling organizations to maintain integrity, compliance, and resilience.
• CBOM: The CBOM is an inventory of cryptographic assets which captures critical metadata such as usage patterns and expiration dates. It supports effective discovery, management, and reporting of cryptographic components, ensuring transparency and up-to-date security measures.
  2. Analysis of Key BOM Categories

While the Guidelines prescribe detailed frameworks for all BOM categories, we have limited our analysis to 3 (three) key BOM categories introduced by the Guidelines, namely the SBOM, AIBOM, and HBOM, being the most pertinent in context of the existing commercial, technological, and cybersecurity governance frameworks in India.

SBOM

• SBOM, in simple terms is a list of all the components, libraries, and modules that comprise a software, providing transparency into its composition. The SBOM framework requires organisations to generate a structured inventory of all software components included in their products or services given that different parts of a software are often outsourced. The Guidelines recommend inclusion of technical details such as the component name, version, supplier, licensing information, the software type (open source or proprietary), end-of-life timelines, as well as checksums or cryptographic hashes to ensure file integrity verification.
• The SBOM is to be prepared at various phases of the software lifecycle including design, source code, build, deployment, and operational stages. The Guidelines distinguish between various SBOM levels, ranging from a simple top-level SBOM to a complete SBOM incorporating transitive dependencies. Further, it recommends that a simpler SBOM may be made available to the public at large, for transparency purposes, while a more detailed version may be maintained for internal reference and in supply chain engagements.
• The Guidelines recommend the use of automated SBOM generation tools in standardized formats such as SPDX or CycloneDX to ensure consistency, machine-readability, and scalability. Organizations, particularly in government, public sector, and essential services, are advised to integrate SBOM creation into the secure software development lifecycle (SSDLC) and CI/CD pipelines, maintain SBOM inventories within vulnerability management workflows, and ensure regular audits and timely updates to reflect patches and end-of-life changes.

AIBOM

• An AIBOM is a list of components used in building, training, and deploying AI models. It typically includes hardware (such as servers, sensors, and GPUs), software (AI models, frameworks, and development tools), data sources, and any other essential elements required for AI implementation. These Guidelines mark an important evolution by introducing AIBOM, addressing the emergent cybersecurity and ethical risks associated with increased adoption of AI systems.
• The AIBOM framework is envisaged to have broad applicability across public sector undertakings, government departments, regulated entities, and any organisation involved in the development, integration, or deployment of AI-based systems. The fundamental rationale behind introducing AIBOM is to ensure that AI systems can be independently reviewed and assessed for fairness, accuracy, security, and accountability.
• From a composition point of view, the Guidelines enlist the minimum elements that must be included in an AIBOM. These include (i) the model name and version; (ii) model type (such as supervised, unsupervised, or reinforcement learning); (iii) intended and out of scope usage; (iv) dataset description and data source; (v) data preprocessing and augmentation techniques; (vi) training configuration and parameter details; (vii) evaluation metrics and validation benchmarks; (viii) information on model license and ownership; (ix) software and hardware dependencies; (x) security considerations including results of adversarial testing; (xi) deployment environment metadata; and (xii) unique identifiers with version control to track model lineage.
• As per the Guidelines, where available, the AIBOM should also include information on fairness and ethical use declarations, increasing the scope for accountability for entities developing and deploying AI systems. Additionally, it also recommends capturing the environmental impact of model training and deployment, disclosing any known vulnerabilities with references to security advisories, and incorporating attestations through digital signatures to verify authenticity and integrity of the AI system.
• To address industry concerns around the absence of standardisation in disclosure formats, the Guidelines recommend that AIBOMs be generated using standardised, machine-readable formats, such as the SPDX or CycloneDX., which will enable structured, automated sharing and integration of AIBOMs across organisational boundaries and within security workflows. For AI developers building systems for the government or public sector, the Guidelines require the preparation of a Vulnerability Exploitability Exchange (VEX) specific to the AI model. The VEX document is intended to communicate the exploitability status of vulnerabilities identified within AI systems, which will help organisations in prioritising their remediation efforts and facilitates improved cybersecurity posture. Additional, consumer organisations receiving AI models from vendors are not only expected to verify the completeness of the AIBOM but are also required to develop their own internal AIBOM. The internal AIBOM must also include author identification and timestamps to support audit trails and lifecycle integrity.
• AIBOMs are intended to be living documents, i.e., they should be subject to continuous updates as components evolve or vulnerabilities are discovered. They must be integrated into cybersecurity workflows, especially within vulnerability management systems. Organisations are also advised to maintain awareness of emerging risks and standards relevant to AI system governance.
• Best Practices: The best practices outlined in the Guidelines highlight the need for comprehensive component inventory, use of standardized data formats, and automation of the AIBOM generation process to ensure accuracy and efficiency. The Guidelines also encourage thorough documentation for reproducibility, prioritization of critical and high-risk models, diligent tracking of model lineage (including updates and retraining), and the establishment of workflows for continuous AIBOM updates as systems evolve.
• While the Guidelines provide a comprehensive framework for creation and maintenance of AIBOM, it falls short of prescribing ethical and governance frameworks, presumably as the same is subjective in nature. These could, however, be included in future updates when market practices are more definitive in this regard.

HBOM

• The HBOM seeks to establish greater transparency in the sourcing and maintenance of hardware components. It requires documentation of hardware component names, model and part numbers, manufacturer and supplier details, country of origin, firmware versions, end-of-life dates, and known security vulnerabilities. HBOM also extends to tracking embedded software and firmware dependencies within hardware devices.
• HBOM provides an evidentiary record of supply chain integrity and can be embedded within hardware procurement contracts through disclosure covenants, representations, and warranties. Furthermore, HBOM enables organisations to demonstrate proactive risk mitigation in the event of regulatory inquiries into hardware compromise incidents, particularly in sectors governed by national security protocols.
• The Guidelines recommend that organisations regularly review and update HBOMs, especially in response to newly discovered hardware vulnerabilities, and promote integration of HBOM records into cyber incident response mechanisms.

3. Key Recommendations and Best Practices

While the applicability and nature of these recommendations may vary depending on the type of organization and its specific role in the BOM lifecycle, we have set forth below a broad summary of the key recommendations provided under these Guidelines

i. Recommendations for Government Departments and Public Sector Entities

• The Guidelines encourage government bodies, including ministries, public sector undertakings, and entities managing critical infrastructure, to incorporate BOM-related obligations within their procurement frameworks, with comprehensive component-level inventories.
• Government entities have also been encouraged to have SBOMs, AIBOMs and HBOMs in all software and products supplied to them and to institute internal mechanisms to ensure periodic updates of BOMs, especially following software updates, hardware replacements, or AI model retraining, thereby maintaining an up-to-date risk profile of their digital assets, to better prepare themselves from system vulnerabilities.
• To enhance cybersecurity governance, Government departments are further encouraged to adopt standardised BOM formats (SPDX or CycloneDX) for software and AI, to allow faster detection and mitigation of supply chain vulnerabilities.
• This therefore will be relevant for private entities who work on Government procurement projects in sectors relating to software, AI, and hardware procurement, as they may soon be subject to mandatory requirements from Government departments to follow the BOM disclosure process, across software, hardware and AI applications. The standardized formats may need to be followed, even though they may be some scope of interpretation in how private entities disclose details regarding their systems in such AIBOM forms.

  ii. Recommendations for Other Industry Participants and Technology Providers

• The Guidelines advise private sector stakeholders, particularly software developers, AI system vendors, system integrators, and hardware manufacturers to integrate BOM generation into their development pipelines and product lifecycle management processes, ensuring that SBOMs, AIBOMs, and HBOMs are prepared and updated at relevant stages of development, deployment, and maintenance.
• In addition, industry participants are encouraged to develop internal governance frameworks for BOM management. This includes implementing secure storage systems, role-based access controls (RBAC), and linking BOM inventories with vulnerability management and incident response systems, backed by regular audits and assessments to verify accuracy and completeness.
• The Guidelines recommend organizations to ensure that any BOM data is stored and transmitted securely, using encryption, access controls, and other security measures to protect sensitive information. Further, an additional layer of security is expected with the integration of multi-factor authentication (MFA).
• For AIBOM, private sector AI developers and integrators are advised to create detailed AIBOMs documenting datasets, algorithms, model performance, and known vulnerabilities, while automating AIBOM generation within AI development pipelines. They should also integrate AIBOM data with vulnerability databases, threat intelligence platforms, and CERT-In alerts to ensure real-time visibility and proactive mitigation of AI risks.
• For HBOM, hardware vendors are recommended to provide VEX and CSAF advisories when vulnerabilities are identified, and to maintain machine-readable HBOMs (CycloneDX or equivalent formats) aligned with industry standards.
• Additionally, industry associations and sector-specific bodies are advised to consider developing sectoral codes of practice on BOM adoption, enabling industry-wide consistency and facilitating ease of compliance when future regulatory standards emerge.
• Private sector organizations are encouraged to provide training and awareness programs for employees involved in the creation, management, and review of BOMs, ensuring adherence to standardized BOM practices and security protocols.
• The above protocols, in our view, may soon become market practice in the near future, with more private organizations and industry bodies encouraging a consistent disclosure practice within the industry.