On 9 July 2025, CERT-In published version 2.0 of its Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM. The SBOM section names 21 minimum data fields per component; the AIBOM section adds a model-and-dataset inventory most Indian SaaS teams have never produced. The guidelines are advisory today, but your enterprise buyers' procurement teams started asking for both in Q3 2025. This post is the 30-day sprint we run for clients — what an AIBOM actually contains, the CycloneDX tooling that generates it, and the evidence pack you hand an auditor.
TL;DR — What does CERT-In's v2.0 actually require?
An SBOM is a machine-readable list of every software component you ship, with 21 fields each (name, supplier, version, license, known vulnerabilities, patch status, end-of-life date, checksum, and more). An AIBOM extends that to AI: the model, its training datasets, the ML frameworks, and the intended-and-prohibited use cases. Both are advisory under the guidelines, not yet mandatory law — but B2B buyers now treat them as table stakes.
Why this matters now — August 2025
CERT-In's first BOM guidelines covered SBOM only. Version 2.0, dated 9 July 2025, widened scope to five bill-of-materials types: software (SBOM), quantum (QBOM), cryptographic (CBOM), AI (AIBOM), and hardware (HBOM). The document targets the "public sector, Government, essential services and organisations involved in software export and software services industry" — which is most Indian SaaS selling to banks, government, or EU customers.
The trigger for action is not the regulator. It is the buyer. A 35-person Pune SaaS client of ours got a vendor security questionnaire from a public-sector bank in August 2025 that asked, verbatim, for "a current SBOM in CycloneDX or SPDX format and, where AI/ML is used, an AIBOM." They had neither. We built both in three weeks. The legal analyses from AZB & Partners and MediaNama both flag the same thing: advisory now, procurement-driven immediately.
What does an AIBOM look like? (The fields)
CERT-In's Table 10, "Minimum Elements of AIBOM," is the part teams have never seen before. Where an SBOM enumerates packages, an AIBOM enumerates the model and everything that shaped it. The four buckets below are the ones every AIBOM we ship has to fill.
SBOM vs AIBOM: what goes in each?
The two documents overlap on identity and license fields and diverge sharply on everything AI-specific. If you are building a RAG chatbot or a voice feature, you produce both — the SBOM for your code, the AIBOM for the model and data layer. Here is the side-by-side we hand engineering teams.
| Field | SBOM (21 fields) | AIBOM (Table 10) |
|---|---|---|
| Component name & version | Every library, module, package | The model(s) and their versions |
| Supplier / author | Package maintainer, origin | Model provider (Anthropic, OpenAI, Meta, you) |
| License | MIT, Apache-2.0, GPL, proprietary | Model license + dataset license |
| Known vulnerabilities | CVEs, patch status, EOL date | Model poisoning, prompt injection, leakage |
| Integrity | Cryptographic checksum per component | Model card hash, dataset version hash |
| Data provenance | Not applicable | Training data origin, format, limitations |
| Usage restrictions | Field present, rarely populated | Intended use + prohibited use, mandatory |
| Privacy compliance | Indirect | Dataset DPDP/licensing compliance, explicit |
The 30-day compliance sprint (copy this)
We run this as four weekly milestones. A two-engineer team clears it in 30 calendar days for a single product; multi-product orgs run it per repo. Each step has a verification you can check off before moving on.
syft dir:. -o cyclonedx-json=sbom.cdx.json on every build, or cdxgen -t js -o sbom.cdx.json for deep dependency trees. Wire it into GitHub Actions so the SBOM is a build artifact, not a one-off. Verify: a fresh build drops a dated CycloneDX file you can open.The DIY walkthrough: generate your first SBOM in 10 minutes
This runs on any machine with Docker or a code checkout. We tested these exact commands on a Node.js + Python repo in August 2025, Syft v1.27 and cdxgen v11.
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin — one binary, no runtime. Check it: syft version.syft dir:. -o cyclonedx-json=sbom.cdx.json. For a container, point at the image instead: syft myapp:latest -o cyclonedx-json=sbom.cdx.json. Open the JSON — every component now carries name, version, and a PURL identifier.grype sbom:sbom.cdx.json -o table reads your SBOM and lists CVEs with severity and fix versions. This is the "patch status" and "known vulnerabilities" the CERT-In fields ask for, generated automatically.npm install -g @cyclonedx/cdxgen, then cdxgen -t python -o aibom.cdx.json on a repo that imports ML frameworks. cdxgen detects PyTorch, transformers, and Hugging Face references and seeds the ML-BOM. You then hand-fill dataset provenance and use-case fields — the tool can't read those from code.What goes in the evidence pack?
An auditor or a buyer's security team does not want raw JSON. They want a short, dated package that proves the BOMs are current, scanned, and owned. This is the deliverable we hand over — the artifact that actually closes the procurement questionnaire.
- Current SBOM in CycloneDX 1.6 JSON, stamped with build commit hash and generation date
- AIBOM in CycloneDX ML-BOM format for every AI feature, with all four field buckets filled
- Vulnerability scan report (Grype or Dependency-Track) with severity and remediation status
- A one-page mapping of your fields to CERT-In's 21 SBOM elements and Table 10 AIBOM elements
- A named owner per component class and a refresh cadence (we recommend regenerating on every release)
- Dataset license and DPDP-compliance note for each training set, tying into your DPDP readiness audit
- Intended-use and prohibited-use statement per model, suitable for pasting into a contract annexure
When NOT to chase full CERT-In compliance yet
The guidelines are advisory, and over-engineering this is a real failure mode. We have talked two clients out of a six-week BOM program they did not need. Here is when to slow down.
Real example: a 35-person Pune SaaS, three weeks to compliant
A Pune-based B2B SaaS firm (35 staff, HR-analytics product, one ML model for attrition scoring) got a public-sector bank's vendor questionnaire in August 2025 demanding an SBOM and an AIBOM. They had clean code and zero BOM artifacts. We ran the sprint in three weeks instead of four because their stack was a single Next.js + Python monorepo.
As Manvi, who leads our QA and compliance reviews, puts it: the AIBOM is just QA applied to your model supply chain — you would not ship code you cannot trace, so do not ship a model you cannot trace either. Our AI & automation team bakes BOM generation into every delivery, and our broader web engineering practice wires Syft into CI by default.
Related reading
FAQ
Is CERT-In's SBOM/AIBOM guideline mandatory in 2025?
No. The v2.0 guidelines dated 9 July 2025 are advisory best practice, not law. They target public sector, government, essential services, and software export/services firms. The practical pressure comes from B2B buyers' security questionnaires, which began asking for SBOMs and AIBOMs in 2025.
What is the difference between an SBOM and an AIBOM?
An SBOM lists every software component you ship — libraries, packages, modules — with 21 fields each. An AIBOM extends that to AI: the model, its training datasets, ML frameworks, and the intended and prohibited use cases. If your product has an AI feature, you produce both documents.
Which format should I use, CycloneDX or SPDX?
CERT-In accepts both. We use CycloneDX 1.6 because it has native support for AI ModelCards and an ML-BOM type, so one format covers your SBOM and AIBOM. Tools like Syft and cdxgen emit CycloneDX JSON directly, and Dependency-Track ingests it.
Do I need an AIBOM if I only call an external model API like Claude or GPT-4?
Yes, a light one. The model becomes a third-party component: you record its provider, version, license, and your intended and prohibited use cases. You do not control its training data, so you cite the provider's documentation for provenance rather than authoring it yourself.
How long does it take to become compliant?
Our sprint is 30 calendar days with a two-engineer team for a single product. Generating a first SBOM takes about 10 minutes with Syft. The time goes into the AIBOM's dataset-provenance and use-case fields, the vulnerability remediation, and the evidence pack an auditor can actually read.
What tools generate an SBOM and AIBOM for free?
Syft (Anchore) and cdxgen (OWASP) are the leading free, open-source generators; both emit CycloneDX. Grype scans the resulting SBOM for CVEs, and Dependency-Track stores BOM history. cdxgen also produces an AI/ML-BOM and detects ML frameworks in your code automatically.
Does an AIBOM connect to DPDP compliance?
Directly. The AIBOM's dataset-provenance field forces you to document where training data came from and whether it meets privacy and licensing rules — which is the same evidence DPDP asks for. Building both together means you answer two compliance demands with one inventory.
Need an SBOM/AIBOM compliance pack built?
We run the full 30-day CERT-In v2.0 sprint for Indian SaaS — Syft and cdxgen in your CI, a complete AIBOM for every AI feature, a vulnerability scan, and an auditor-ready evidence pack. Fixed scope, sized to your product count. Suitable if a buyer has asked for an SBOM and you do not have one yet. No slides — just your stack and our honest take.
Book a 20-min Call
For the founder's first-person take on India's cybersecurity and regulation beat, see Vivek Kumar's writing — Softechinfra was founded by Vivek Kumar.
