Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Compliance›CERT-In SBOM/CBOM Guidelines
India · CERT-In v2.0 (09 Jul 2025)

CERT-In SBOM, CBOM, QBOM, AIBOM & HBOM

Technical Guidelines v2.0 — what each bill of materials must contain and how to produce it

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.

Talk to our advisory team Read the v2.0 guidelines on cert-in.org.in
At a glance
09 Jul 2025Version 2.0 published (v1.0 Oct 2024)
5 BOM typesSBOM, CBOM, QBOM, AIBOM, HBOM
6 SBOM classesDesign, Source, Build, Analyzed, Deployed, Runtime
Table 5defines SBOM minimum elements
CERT-In Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM — Version 2.0
Why this matters

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).

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.

How O3 helps

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.

1 · Find it first

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.

2 · Catch it live

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.

3 · Fix it fast

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.

Risk-based prioritisation

From alert flood to a short list

KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.

Raw findings in dependency tree~12,400
Vulnerable & version-matched~4,700
Reachable in your code~1,360
KEV / high-EPSS · act now~370

Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.

SBOM minimum elements

How to build an SBOM that meets CERT-In's minimum elements

Table 5 of v2.0 lists the data fields every SBOM must carry. A compliant SBOM is machine-readable and complete down to transitive dependencies, not a hand-maintained spreadsheet.

CERT-In v2.0 Table 5§3 SBOM
Capture, per component: name, version, a unique identifier (PURL or CPE), supplier or author, and the dependency relationship including top-level and transitive dependencies (Table 5).
Record a cryptographic hash and a timestamp for each component so the SBOM is verifiable and point-in-time.
Document license information for every component and flag any 'known unknowns' where completeness cannot be established.
Emit in a standard machine-readable format such as CycloneDX or SPDX, and regenerate on every build rather than editing by hand.
Where O3 helps

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.

SDLC SBOM classes

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.

CERT-In v2.0 §3.2SCA tooling
Map your pipeline to the six classes: Design, Source, Build, Analyzed, Deployed and Runtime SBOMs (§3.2).
Generate Source and Build SBOMs inside CI using Software Composition Analysis (SCA) tooling, which the guidelines explicitly endorse for generation and vulnerability detection.
Produce an Analyzed SBOM by running SCA and vulnerability analysis against the build output, and a Deployed SBOM reflecting what actually runs in production.
Capture a Runtime SBOM from the live environment so loaded components, not just declared ones, are inventoried.
Where O3 helps

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.

Vulnerability tracking

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.

CERT-In v2.0 §6VEXCSAF
For each known vulnerability affecting an SBOM component, publish a VEX statement declaring whether the product is affected, not affected, fixed or under investigation (§6).
Issue machine-readable advisories in CSAF format so downstream consumers can ingest your security posture automatically.
Prioritise exploitable issues: combine reachability with EPSS exploit-probability and CISA KEV known-exploited status before declaring something affected.
Aim to publish VEX promptly after disclosure; the v2.0 Log4j example illustrates advisory publication within roughly a week.
Where O3 helps

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.

CBOM, QBOM & PQC

How to inventory cryptography and prepare for post-quantum migration

Section 8 extends the BOM model to cryptography. A CBOM inventories cryptographic assets; a QBOM and the associated migration strategy address quantum readiness.

CERT-In v2.0 §8CBOMQBOM
Build a CBOM cataloguing cryptographic assets in use: algorithms, key lengths, certificates, protocols and where each is used (§8).
Assess crypto-agility: identify quantum-vulnerable algorithms such as RSA and ECC and the systems that depend on them.
Define a Post-Quantum Cryptography (PQC) transition plan that sequences migration to quantum-resistant algorithms and tracks progress through the QBOM.
Re-scan after changes so the CBOM/QBOM stays current as libraries and certificates rotate.
Where O3 helps

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.

AIBOM

How to produce an AIBOM for AI systems

Section 9 introduces the AI Bill of Materials, inventorying the components used to build, train and deploy AI models so AI supply-chain risk is visible.

CERT-In v2.0 §9AIBOM
Inventory the hardware behind the model: GPUs, accelerators and servers used for training and inference (§9).
List the software components: model name and version, ML frameworks and libraries.
Record datasets and training data sources so provenance and licensing of data are documented.
Keep the AIBOM versioned alongside the model so retraining and model updates are reflected.
Where O3 helps

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.

HBOM & provenance

How to cover hardware and component provenance

Section 10 defines the Hardware Bill of Materials, and the guidelines emphasise provenance to detect compromised suppliers across the chain.

CERT-In v2.0 §10provenance
Maintain an HBOM: a structured inventory of physical components and sub-components in a product or system (§10).
Establish provenance for software artifacts by capturing build origin and signing, so a component's source can be verified.
Verify supplier integrity by checking signatures and attestations against the BOM before accepting components.
Watch for compromised-supplier indicators such as unexpected component changes or unsigned artifacts.
Where O3 helps

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.

Procurement & maintenance

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.

CERT-In v2.0 procurement guidance§3
Require an SBOM as a contractual deliverable for new software acquisitions, in a standard machine-readable format.
Validate supplier-provided SBOMs against the Table 5 minimum elements before acceptance.
Regenerate and re-verify the SBOM on every software change, upgrade or patch so it never goes stale.
Run continuous SCA and malicious-dependency checks against the maintained SBOM to catch newly disclosed or compromised components.
Where O3 helps

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.

The whole framework

Every BOM type and requirement in CERT-In Technical Guidelines v2.0

All 23 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.

12SBOM
Minimum elements and SDLC classes
2Vulnerability
VEX and CSAF tracking
3Cryptography
CBOM, QBOM and PQC
4AI & Hardware
AIBOM and HBOM
2Supply chain
Provenance and procurement
Requirement area
SBOM component nameTable 5Record name of every component
SBOM versionTable 5Capture exact version per component
Unique identifierTable 5Assign PURL or CPE identifier
Supplier / authorTable 5Name component supplier or author
Dependency relationshipsTable 5Map top-level and transitive deps
License informationTable 5Document license for each component
Cryptographic hashTable 5Store verifiable hash per component
TimestampTable 5Record point-in-time of generation
Known unknownsTable 5Flag incomplete or uncertain data
SDLC SBOM classes§3.2Design, Source, Build, Analyzed, Deployed, Runtime
SCA tooling§3Use SCA for generation and detection
Machine-readable format§3Emit CycloneDX or SPDX
VEX documents§6Declare exploitability status per CVE
CSAF advisories§6Publish machine-readable advisories
CBOM§8Inventory cryptographic assets
Crypto-agility§8Identify quantum-vulnerable algorithms
QBOM / PQC transition§8Plan post-quantum migration roadmap
AIBOM hardware§9List GPUs, accelerators, servers
AIBOM software§9List models, frameworks, libraries
AIBOM datasets§9Record training data and sources
HBOM§10Inventory physical components
Provenance monitoringThreatsVerify origin and supplier integrity
Procurement practiceProcurementRequire 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.in
FAQ

Common
questions.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • They are Technical Guidelines published by CERT-In under MeitY on 09 July 2025, defining how to build a Software Bill of Materials and four related bills of materials: CBOM and QBOM for cryptography (§8), AIBOM for AI systems (§9) and HBOM for hardware (§10). Table 5 lists the SBOM minimum elements.
  • The CERT-In guidelines are advisory rather than statutory, but they make SBOM a standard practice in software procurement and are recommended for public-sector, government, essential-services and software-export entities. Sectoral regulators such as SEBI's CSCRF impose explicit SBOM mandates that reference these field-level requirements.
  • Table 5 requires, per component: name, version, a unique identifier, supplier or author, dependency relationships including transitive dependencies, license information, a cryptographic hash, a timestamp, and any 'known unknowns'. The SBOM should be machine-readable, for example in CycloneDX or SPDX.
  • Section 3.2 aligns SBOMs to the SDLC: Design, Source, Build, Analyzed, Deployed and Runtime SBOMs. Each captures a different stage, with Build and Analyzed SBOMs generated in CI using SCA tooling and a Runtime SBOM reflecting components actually loaded in production.
  • Section 6 requires vulnerability state to be communicated through VEX (Vulnerability Exploitability eXchange) statements declaring whether a product is affected, and CSAF (Common Security Advisory Framework) advisories in machine-readable form. The Log4j example shows VEX publication within roughly a week of disclosure.
  • Section 8 defines a CBOM as an inventory of cryptographic assets such as algorithms, keys and protocols, and a QBOM addressing quantum readiness. Organisations are expected to assess crypto-agility, identify quantum-vulnerable algorithms, and plan a Post-Quantum Cryptography migration.
  • Section 9 requires an AI Bill of Materials covering the components used to build, train and deploy AI models: hardware such as GPUs and servers, software including model name and frameworks, and the datasets or training data used. It makes AI supply-chain composition transparent.
  • O3 generates CycloneDX SBOM, CBOM, QBOM, AIBOM and HBOM, runs SCA with malicious-dependency detection, ranks exploitability using function-level reachability plus EPSS and KEV to inform VEX, observes runtime components via its eBPF agent, and reads SLSA and cosign provenance. Governance and policy steps remain the organisation's responsibility.

See O3 Security in Action

See why security and engineering leaders trust O3
to secure their entire software supply chain.