Comprehensive Guide To Bill Of Materials Frameworks (Version 2.0)

The Indian Computer Emergency Response Team ("CERT-In") has issued the updated version of the Technical Guidelines on SBOM, QBOM, CBOM, AIBOM, and HBOM (Version 2.0) Dated July 9, 2025, ("Guidelines"). The Guidelines are voluntary yet structured framework for managing these systems through Bills of Materials ("BOM"). These detailed inventories list the components of software, hardware, or AI systems, helping businesses identify risks, comply with regulations, and enhance efficiency. This note introduces the Software Bill of Materials ("SBOM"), Quantum and Cryptographic Bill of Materials ("QBOM and CBOM"), Artificial Intelligence Bill of Materials ("AIBOM"), and Hardware Bill of Materials ("HBOM"), offering a detailed yet accessible overview of their purpose and strategic value for businesses new to these concepts.

Given the increasing regulatory emphasis on supply chain transparency and cybersecurity assurance, it is imperative for various businesses across sectors to understand the practical implications of these Guidelines and consider integrating BOM practices into their governance and compliance frameworks.

Before exploring the specific BOM types, it is important to understand the risks they are designed to mitigate. Software products are composed of many different components, some of which might come from third party sources. These third-party components and dependencies can have vulnerabilities, which attackers can exploit, leading to security incident or breaches. Key threats include attackers inserting malicious code, vulnerabilities in outdated components, and breaches by compromised suppliers.

These issues can lead to data breaches, operational disruptions, and reputational damage. These threats can be countered by maintaining visibility & transparency on software components used for building or developing the software. SBOM helps organizations know exactly what components are in their software or assets, making it easier to identify and fix vulnerabilities. By using SBOMs, entities can improve their software security and protect against potential threats.

BOM Frameworks: Core Components

These risks can be countered by maintaining visibility and transparency regarding the software components used in building or developing software. A Software Bill of Materials (SBOM) helps organizations know exactly what components are in their software or assets, making it easier to identify and fix vulnerabilities. By using SBOMs, entities can enhance software security and protect against potential threats.

1. SBOM: SBOM is like a recipe for software, listing all components, such as open-source libraries, proprietary code, and their dependencies, including details like component names, versions, suppliers, and licenses. For example, a company's data analytics tool might include an SBOM listing Apache Tomcat (a free, open-source software tool used to run web applications built with Java), ensuring no hidden vulnerabilities exist. SBOMs enable businesses to detect security flaws, comply with licensing terms (e.g., avoiding legal issues from open-source software), and integrate with tools for automated vulnerability scans, ensuring safer and more reliable software.
2. QBOM and CBOM: QBOM classifies quantum computing assets, such as quantum algorithms and security protocols designed to resist quantum attacks, which could soon compromise traditional encryption. CBOM tracks cryptographic components, like encryption keys, certificates, and protocols (e.g., TLS configurations), with metadata on versioning, usage, and expiration. For instance, a bank might use a CBOM to document encryption methods securing customer data. Together, QBOM and CBOM prepare businesses for quantum advancements, ensure compliance with security standards, and protect sensitive data against emerging threats.
3. AIBOM: An AIBOM documents AI system components, including machine learning models, training datasets, algorithms, and dependencies, with details like model versions, retraining activities, and data sources. For example, an AI chatbot's AIBOM would list its model, training data, and third-party libraries, ensuring transparency. AIBOMs support reproducibility of AI results, compliance with regulations (e.g., in healthcare or government), and accountability by tracking model lineage and vulnerabilities.
4. HBOM: It is a detailed inventory of physical hardware components, such as servers, routers, embedded chips, and firmware, including specifics like component identifiers, suppliers, and versions. For example, an HBOM for a data center would list each server's processor and firmware, helping prevent supply chain attacks (e.g., counterfeit chips). HBOMs support traceability, lifecycle management (e.g., upgrades, decommissioning), and compliance with procurement regulations, ensuring secure and efficient hardware operations.
5. The Guidelines provide "Minimum Elements" for each BOM to ensure a standardised, machine-readable structure that enables consistent sharing and processing across the supply chain. The relevant information relating to the minimum elements is set out on the reference page numbers of the said Guidelines mentioned below:
   
   1. Minimum Elements of SBOM (Page 21)
   2. Minimum Elements of QBOM & CBOM (Page 44)
   3. Minimum Elements of AIBOM (Page 54)
   4. Minimum Elements of HBOM (Page 60)

1. Strategic Business Benefits

1. Enhanced Cybersecurity: Maintaining updated BOMs enables organizations to:
   
   • Identify and isolate vulnerable components during cybersecurity incidents.
   • Support automated patch management and vulnerability scanning.
   • Prevent recurrence of past incidents, such as the Log4j (open-source Java-based logging library developed by the Apache Software Foundation) exploit, by maintaining real-time component traceability.
2. Regulatory Compliance: Standardized formats like Software Package Data eXchange ("SPDX") and CycloneDX align with global standards. Early adoption enables:
   
   • Demonstration of reasonable security practices.
   • Readiness for sectoral audits or disclosures under applicable data protection or IT laws.
3. Operational Efficiency: Integrating BOM practices into development and procurement lifecycles facilitates:
   
   • Improved inventory control and asset lifecycle management.
   • Reduction in costs associated with manual audits, software licensing disputes, and delayed incident response.
   • Streamlined vendor onboarding and offboarding processes.
4. Proactive Risk Management CERT-In encourages integration with:
   
   • Vulnerability Exploitability eXchange ("VEX") for real-time risk classification and prioritization.
   • Common Security Advisory Framework ("CSAF") for standardized vulnerability advisories.
   • These integrations allow businesses to adopt a risk-based response posture rather than relying solely on exhaustive patching strategies.
5. Strengthened Vendor Accountability: Mandating BOM disclosures from vendors fosters transparency regarding third-party dependencies and strengthens contractual protections. It also enables more robust evaluation of vendor security posture and product integrity.

2. Implementation Roadmap

To leverage these Guidelines effectively, businesses should adopt a phased approach (START, PROGRESS, ADVANCE; Page 14 of the said Guidelines):

The Technical Guidelines on SBOM, QBOM, CBOM, AIBOM, and HBOM provide a strategic blueprint for businesses to secure their supply chains, ensure compliance, and enhance efficiency. By adopting these frameworks, organizations can mitigate risks, streamline operations, and position themselves as trusted leaders in a competitive digital landscape.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.