CERT-In SBOM, CBOM, QBOM, AIBOM & HBOM
Technical Guidelines v2.0 — what each bill of materials must contain and how to produce it
Published Last reviewed
On 09 July 2025 CERT-In, the national CERT under MeitY, published Version 2.0 of its Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM. It is the canonical Indian reference for software-supply-chain transparency: it defines the minimum elements of a Software Bill of Materials (Table 5), aligns SBOM generation to the SDLC (§3.2), mandates VEX and CSAF for vulnerability tracking (§6), and extends the model to cryptography (CBOM/QBOM, §8), AI systems (AIBOM, §9) and hardware (HBOM, §10).
The guidance is recommended for public-sector, government, essential-services and software-export organisations, and it makes SBOM a standard practice in software procurement. Sectoral regulators including SEBI and RBI point to it as the field-level reference for their own SBOM obligations.
India's reference standard for software-supply-chain transparency
Software supply-chain attacks reach organisations through trusted dependencies: malicious code, vulnerabilities in outdated components, and breaches via compromised suppliers. CERT-In v2.0 answers this by making a machine-readable inventory of what ships in software a baseline expectation, particularly for public-sector, government, essential-services and software-export entities.
The document is broader than a classic SBOM. It treats the bill of materials as a family: SBOM for software components, CBOM for cryptographic assets, QBOM for quantum-readiness and post-quantum migration (§8), AIBOM for AI models, frameworks and training datasets (§9), and HBOM for physical hardware (§10). Vulnerability state is communicated through VEX and CSAF rather than raw scan dumps (§6).
Each type carries its own minimum-elements table, and the lists do not overlap. An SBOM needs the 21 data fields of Table 5; a QBOM needs the 11 elements of Table 8 plus per-asset detail from Table 9; an AIBOM needs the 19 elements of Table 10; an HBOM needs the elements of Table 11, recursed into sub-components. Treating Table 5 as the universal checklist is the common error, and it leaves a supplier deliverable short in exactly the places the newer sections were written to cover.
Although the guidelines are advisory rather than statute, they have become the field-level reference that SEBI's CSCRF SBOM mandate and RBI's supply-chain expectations lean on. Adopting them now positions an organisation ahead of the sectoral rules that cite them.
Find it before attackers do. Catch it if they try. Fix it fast.
Across these requirements, O3 runs one continuous loop on your own software so issues surface, get caught, and get fixed before they become an incident.
Test like an AI-assisted attacker
An agentic pentest probes your app across 50+ vulnerability classes the way a real attacker chains them, so exploitable flaws surface in your build before someone outside finds them.
Detect and block exploitation at runtime
A kernel-level eBPF agent watches process trees and syscalls, recognises an attack sequence as it unfolds, and restricts the offending process on the spot rather than taking down the host.
Auto-patch what is reachable
Reachability ranks what genuinely matters, then autofix opens a pull request with the change, so remediation starts inside tight fix windows instead of sitting in a queue.
How to build an SBOM that meets CERT-In's minimum elements
Table 5 of v2.0 defines three minimum elements: Data Fields, Automation Support, and Practices and Processes. The Data Fields element alone lists 21 attributes to record for every component. A compliant SBOM is machine-readable and complete down to transitive dependencies, not a hand-maintained spreadsheet.
O3 generates CycloneDX SBOMs with component identifiers, transitive dependency graphs, licenses and cryptographic hashes, and enriches them with deps.dev metadata so the Table 5 fields are populated automatically.
How to generate the right SBOM at each SDLC stage
Section 3.2 defines six SBOM classes tied to the software lifecycle. Each answers a different assurance question, and producing the later classes is where most teams have gaps.
O3's SCA produces Source, Build and Analyzed SBOMs in CI, and its eBPF runtime agent observes loaded components and processes in production to support a Runtime SBOM that reflects what is actually executing.
How to track and communicate vulnerabilities with VEX and CSAF
Section 6 requires that vulnerability state be expressed through VEX (Vulnerability Exploitability eXchange) and CSAF (Common Security Advisory Framework), using the Log4j incident as a worked example.
O3's function-level reachability determines whether a vulnerable component is actually reachable, and EPSS plus KEV prioritisation drives the affected vs not-affected judgement that a VEX statement records.
How to inventory cryptography and prepare for post-quantum migration
Section 8 extends the BOM model to cryptography, and it splits the requirement in two. Table 8 sets eleven minimum elements for a QBOM, describing a quantum device or system. Table 9 sets the elements for each cryptographic asset inside it, and those differ by asset type — an algorithm is documented differently from a key, a protocol or a certificate.
O3 generates a CycloneDX CBOM of cryptographic assets and a QBOM with quantum-risk scoring, surfacing quantum-vulnerable algorithms to drive a PQC migration roadmap.
How to produce an AIBOM for AI systems
Section 9 introduces the AI Bill of Materials. Table 10 sets nineteen minimum elements, and they go well beyond a component list: the AIBOM is expected to document what the model is for, what it must not be used for, and how it performs.
O3 generates a CycloneDX AIBOM that inventories AI models, frameworks and datasets, giving teams the model and data component list the AIBOM section calls for.
How to cover hardware and component provenance
Section 10 defines the Hardware Bill of Materials. Table 11 records the product and each component beneath it, and it is explicitly recursive: where a component contains further hardware parts, those are listed with the same attributes.
O3 reads SLSA and cosign provenance and verifies signed attestations during ingestion, supporting the provenance checks the guidelines call for; it does not generate provenance itself.
How to make SBOM a standard part of procurement
The guidelines make SBOM a standard practice in software procurement and expect bills of materials to be kept current rather than produced once.
O3's SCA and malicious-dependency detection (typosquats, malicious postinstall scripts, compromised maintainers) continuously validate the components recorded in an SBOM as new risks emerge.
Every BOM type and requirement in CERT-In Technical Guidelines v2.0
All 40 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.
| Requirement area | Ref | How teams meet it |
|---|---|---|
| Component Name | Table 5 | Record the name of every component |
| Component Version | Table 5 | Capture the exact version per component |
| Component Description | Table 5 | Describe what the component does |
| Component Supplier | Table 5 | Name the supplier or originating entity |
| Component License | Table 5 | Record the license, using SPDX identifiers |
| Component Origin | Table 5 | Record where the component came from |
| Component Dependencies | Table 5 | Map top-level and transitive dependencies |
| Vulnerabilities | Table 5 | Track known CVEs affecting the component |
| Patch Status | Table 5 | State whether a fix is applied or pending |
| Release Date | Table 5 | Record the component release date |
| End-of-Life (EOL) Date | Table 5 | Flag components past vendor support |
| Criticality | Table 5 | Rate how critical the component is to the system |
| Usage Restrictions | Table 5 | Note licence or contractual limits on use |
| Checksums or Hashes | Table 5 | Store a verifiable hash per component |
| Comments or Notes | Table 5 | Carry reviewer context alongside the entry |
| Author of SBOM Data | Table 5 | Identify who produced the SBOM entry |
| Timestamp | Table 5 | Record the point in time of generation |
| Executable Property | Table 5 | Mark whether the component is executable |
| Archive Property | Table 5 | Mark whether the component is an archive |
| Structured Property | Table 5 | Mark whether the component is structured data |
| Unique Identifier | Table 5 | Assign a PURL or CPE identifier |
| Automation Support | Table 5 | Emit machine-readable SPDX or CycloneDX |
| Known Unknowns | Table 5 | Declare where completeness cannot be established (Practices and Processes) |
| SDLC SBOM classes | §3.2 | Design, Source, Build, Analyzed, Deployed, Runtime |
| SCA tooling | §3 | Use SCA for generation and detection |
| Machine-readable format | §3 | Emit CycloneDX or SPDX |
| VEX documents | §6 | Declare exploitability status per CVE |
| CSAF advisories | §6 | Publish machine-readable advisories |
| QBOM minimum elements | Table 8 | 11 elements for the quantum device or system |
| Cryptographic asset elements | Table 9 | Per asset type: algorithms, keys, protocols, certificates |
| Crypto-agility | §8 | Identify quantum-vulnerable algorithms (RSA, ECC) |
| PQC transition plan | §8 | Sequence migration, track through the QBOM |
| AIBOM minimum elements | Table 10 | 19 elements, model through attestation |
| Intended / out-of-scope usage | Table 10 | State what the model must NOT be used for |
| Model performance metrics | Table 10 | Accuracy, precision, recall, F1 |
| HBOM minimum elements | Table 11 | Product, component and recursive sub-component |
| Technology node | Table 11 | Process node for integrated circuits (7nm, 14nm) |
| Hardware VEX + CSAF | §10.4.1.5 | Vulnerability statement, then CSAF advisory |
| Provenance monitoring | Threats | Verify origin and supplier integrity |
| Procurement practice | Procurement | Require SBOM as standard deliverable |
Generate every BOM type CERT-In v2.0 asks for
O3 produces CycloneDX SBOM, CBOM, QBOM, AIBOM and HBOM, runs SCA with malicious-dependency detection, ranks exploitability with function-level reachability plus EPSS and KEV, and observes runtime components via its eBPF agent. See how it maps to CERT-In's minimum elements, SDLC SBOM classes and VEX/CSAF tracking.
Read the v2.0 guidelines on cert-in.org.inSee O3 Security in Action
See why security and engineering leaders trust O3
to secure their entire software supply chain.