The Indian Computer Emergency Response Team (“CERT-In”), under the Ministry of Electronics and Information Technology, issued version 2.0 of its Technical Guidelines on Software Bill of Materials (SBOM) and related frameworks such as Quantum BOM (QBOM), Cryptographic BOM (CBOM), Artificial Intelligence BOM (AIBOM), and Hardware BOM (HBOM) on July 9, 2025 (“Guidelines”). The Guidelines are a seminal step towards enhancing cybersecurity, transparency, and accountability in software supply chains across government, essential service providers, and software-exporting entities.
Overview of the Framework
The Guidelines covers five Bills of Materials (“BOMs”) including Software (“SBOM”), Quantum (“QBOM”), Cryptographic (“CBOM”), Artificial Intelligence (“AIBOM”), and Hardware (“HBOM”), laying down detailed technical and governance requirements for each.
Legal professionals advising clients in software development, AI deployment, systems integration, or software procurement must now ensure BOM-related compliance is embedded into corporate governance frameworks, technology contracts, and risk management protocols.
| Types of BOM | Core Focus | Regulatory Objective |
| SBOM | Software components, dependencies, and versions | Supply chain transparency, vulnerability and license compliance tracking |
| CBOM | Cryptographic keys, algorithms, and protocols | Post-quantum readiness, cryptographic hygiene |
| QBOM | Quantum-resilient systems and assets | Transition plan to quantum-safe infrastructure |
| AIBOM | AI models, datasets, and environments | Model integrity, security, performance, and compliance |
| HBOM | Hardware components/subsystems | Identity and origin tracking, firmware vulnerabilities and patching |
SBOM
A SBOM is a structured inventory, listing all components including libraries, modules, dependencies constituting a software product. CERT-In underscores the SBOM’s role in reducing risks posed by vulnerable third-party code, malicious insertions, and unmonitored updates. The Guidelines suggest SBOM adoption across for software consumers (e.g., public utilities, banks), developers (custom solution providers) and system integrators/resellers (value-added software service providers). They require SBOMs to be maintained throughout the software lifecycle from design and development to deployment and runtime.
SBOMs have now taken on the role of quasi-legal artifacts in public procurement and enterprise software life cycles. They are recommended not just to support cybersecurity readiness, but also to fulfill regulatory audits, contractual verification and incident response obligations. The Guidelines recommend including SBOM obligations within software acquisition contracts, ensuring that the components, licenses, origin, and hash identifiers for all artifacts are disclosed, updated, and auditable.
AIBOM
AIBOM refers to a registry of all AI-related components including datasets, algorithms, models, training pipelines, and inferencing mechanisms employed within an AI system. Given the opacity of AI systems, AIBOM ensures traceability, auditability, and liability demarcation. AIBOM recommends inclusion of model architecture and version, training data sources and licenses, pre-processing scripts and security patches and compliance status among others.
It aims to benefit in enhanced audit trails for AI decision-making, clearer delineation of third-party vs. proprietary IP and facilitation of risk assessments and human-in-the-loop mechanisms.
QBOM and CBOM
QBOM details quantum-related components, supporting a proactive stance on quantum-safe cryptography and readiness for post-quantum risks.
CBOM documents cryptographic assets (algorithms, keys, protocols, certificates), providing traceability, compliance support, and risk management for cryptography-dependent systems.
HBOM
HBOM identifies all hardware elements, sub-components, source details, and maintenance parameters, forming the basis for supply chain security, counterfeit detection, and device-level risk analysis.
Legal Implications and Compliance Requirements
The Guidelines suggest all government, public sector, and essential services organizations to demand SBOMs, CBOMs, QBOMs, AIBOMs, or HBOMs (as applicable) in procurement, development, or deployment of relevant products or services. They should also ensure that externally acquired software and AI solutions are accompanied by complete and accurate BOMs.
Additionally, each BOM must record an array of baseline metadata:
- SBOM/AIBOM: Name, version, description, supplier, license, origin, dependencies, vulnerabilities, patch status, criticality, usage restrictions, unique identifiers, etc.
- CBOM/QBOM: Asset types (algorithm/key/protocol/certificate), versioning, OID, usage, state, license, hardware/software dependencies, vulnerabilities, and attestations.
- HBOM: Product/model name, technical specifications, manufacturing details, serial numbers, compliance, supplier information, and test results.
The Guidelines officially recognized BOM formats such as SPDX and CycloneDX. It further outlines automation and machine-readability to be strongly encouraged for BOM generation, vulnerability tracking, and compliance reporting. Any identified vulnerabilities in software, cryptographic, AI, or hardware systems must trigger issuance of a Vulnerability Exploitability Exchange document and subsequent advisory (CSAF-compliant), outlining impact and remediation status.
In order to increase security and compliance best practices, the Guidelines also put in place:
- Supply Chain Due Diligence: It require full BOM transparency from vendors and include contractual provisions mandating timely updates for patches or new vulnerabilities.
- Contractual Architecture: It stipulates secure storage, restricted access, encryption, and version control for BOM data.
- Integration with Incident Response: BOM data must be embedded in organizational vulnerability, incident, and asset management workflows.
- Audit and Review: Regular audits of BOM processes are recommended to maintain accuracy and organizational readiness.
- Confidentiality and Access Control: Sensitive BOM elements should be segregated as public/private and protected by defined access tiers (e.g., RBAC).
Impact on Software Contracts
Legal advisors must ensure clients’ contracts, procurement documents, and AI project governance policies require the creation, maintenance, and verification of detailed BOMs, reflecting all components that could affect security, compliance, or liability exposure. The Guidelines recommend continuous monitoring and proactive risk mitigation. Accordingly, legal professionals must align their advisory as to incident response, audit, and regulatory reporting.
The guidelines recommend detailed tracking of software component licenses through SBOMs, including open-source elements, and require accurate license identification using SPDX or similar standards. Consequently, software contracts must explicitly address license compatibility, ownership attribution, and downstream usage rights to avoid intellectual property infringement and mitigate legal risks.
Software contracts should be drafted in a way to insert warranty clauses ensuring that software and AI vendors deliver updated and accurate SBOMs/AIBOMs in vendor contracts. Having precise representations and warranties backed by indemnity in software contracts regarding the accuracy and completeness of the SBOM including disclosures about known vulnerabilities and license compliance will be essential. Vendors may be required to warrant that all components are legally sourced, free from undisclosed security risks, and that SBOMs are kept current and accurate.
The dispute resolution clause should include specific Alternate Dispute Resolution clauses to resolve disputes arising out of SBOM or AIBOM through technical arbitration bodies or CERT-In panels. The contract should identify whether faulty BOMs, missing security disclosures, or outdated vulnerabilities fall under breach, negligence, or force majeure clauses.
Contracts concerning AI system development, deployment, or integration should be updated to require supplier AIBOMs with the prescribed minimum elements, certifications, and ongoing updates. The contracts should assign responsibility (by role or department) for generation, consumption, and validation of AIBOMs, and secure handling of private/sensitive AI system information. Contractual language must include an established audit rights and reporting obligations to ensure periodic review of BOM-related disclosures and address intellectual property protection, confidentiality, and data integrity relating to BOM documentation and record-keeping.
Conclusion
The CERT-In Guidelines mark a pioneering advance in Indian supply chain risk, security, and legal compliance strategy. SBOMs and AIBOMs are no longer optional checklists but binding operational tools with legal weight, regulatory teeth, and contractual enforceability.
For legal professionals particularly those advising clients deploying or developing AI, cryptographic, or complex software and hardware systems, the Guidelines necessitate a significant recalibration of contract drafting, risk allocation, and internal compliance advice. Comprehensive and regularly updated BOMs should now be considered a fundamental component of all technology-related procurement, development, and risk management arrangements.
