India SBOM compliance
The one map to CERT-In, SEBI CSCRF and RBI software-supply-chain rules — who they cover, what they mandate, and the deadlines
Published Last reviewed
India now has three overlapping software-supply-chain regimes, and which ones apply depends on who you are. CERT-In's Technical Guidelines make a Software Bill of Materials the baseline expectation for government, public-sector and software-export entities. SEBI's CSCRF mandates SBOM for its regulated entities (exchanges, brokers, AMCs). RBI's IT-governance and cyber-resilience directions push the same expectations into banks and NBFCs. On top of that sits CERT-In's mandatory 6-hour incident-reporting duty under Section 70B of the IT Act.
This page is the map: which framework applies to you, what each one actually requires, the deadlines that matter, and where they overlap so one SBOM programme can satisfy several. Each framework links to a deep-dive.
One supply-chain programme, three overlapping Indian mandates
The frameworks were written by different regulators for different sectors, but they converge on the same core demand: know what your software is made of, track its vulnerabilities, and be able to prove it. A machine-readable SBOM — increasingly a whole xBOM family (SBOM, CBOM, QBOM, AIBOM, HBOM) under CERT-In v2.0 — is the artefact that satisfies all three.
The practical win is consolidation: an SBOM programme built to CERT-In's minimum elements, with VEX/CSAF vulnerability status and reachability-based prioritisation, covers most of what SEBI CSCRF and RBI expect too. Build it once, map it to each regulator's control language, and you avoid running three parallel compliance efforts.
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.
Which Indian SBOM rules apply to you: CERT-In, SEBI or RBI
Start here — the regime you must meet depends on your sector.
O3 produces the SBOM (and CBOM/AIBOM) once, tracks reachable vulnerabilities against it, and maps the same evidence to each regulator's controls — so one programme answers CERT-In, SEBI and RBI.
Required SBOM fields under CERT-In, SEBI and RBI guidelines
Different words, same substance. These three demands recur across all the Indian frameworks.
O3's reachability analysis converts a raw SBOM into a prioritised, VEX-ready view — which CVEs are actually reachable in your code — which is exactly the signal these frameworks want and scanners can't give.
SBOM compliance deadlines for CERT-In, SEBI CSCRF and RBI
Compliance is time-boxed. Track the go-live dates per regime.
O3 gives you a continuously-current SBOM + vulnerability posture, so you can produce evidence on the regulator's timeline instead of scrambling before an audit.
How to build an SBOM that meets CERT-In's minimum elements
Table 5 of the v2.0 Guidelines defines three minimum elements, not one: Data Fields, Automation Support, and Practices and Processes. The Data Fields element alone lists 21 attributes for every component, which is more than most generated SBOMs carry by default.
O3 emits CycloneDX with component identifiers, transitive dependency graphs, licenses and hashes, enriched from deps.dev, so the Table 5 data fields are populated automatically rather than hand-completed before an audit.
How to meet the SEBI CSCRF field-level SBOM mandate
CSCRF is the first Indian regulation to put SBOM attributes into the text of the rule itself. It applies across five regulated-entity tiers, and the obligations scale with the tier.
O3 keeps the SBOM current for every in-scope system and tracks which listed CVEs are actually reachable, so the "Identify" and "Protect" evidence is continuous rather than a point-in-time snapshot.
How to satisfy RBI's secure-SDLC and third-party risk expectations
RBI does not publish a standalone "SBOM circular". The requirement arrives through IT governance, secure SDLC and outsourcing/third-party risk controls that together demand you know and can evidence what your software is made of.
O3 produces the component inventory plus malicious-dependency detection (typosquats, malicious post-install scripts, compromised maintainers) for supplier-delivered code, which is the evidence third-party-risk controls actually ask for.
Incident reporting timelines: CERT-In 6 hours, SEBI and RBI
This is the obligation with the least tolerance for improvisation, and it applies far beyond the sector-specific regimes.
A current SBOM shortens the hardest step of an incident report — establishing whether a newly-disclosed component is present anywhere in your estate, and where.
How to extend the programme to CBOM, QBOM, AIBOM and HBOM
CERT-In v2.0 is the reason "xBOM" is now the Indian baseline rather than SBOM alone. Each additional bill of materials answers a question an SBOM structurally cannot.
O3 generates SBOM, CBOM, QBOM and AIBOM from the same scan, so extending coverage to the xBOM family is a configuration change rather than a second programme.
The three regimes, side by side
All 27 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.
| Requirement area | Ref | How teams meet it |
|---|---|---|
| SBOM mandate | CERT-In v2.0 · SEBI CSCRF · RBI | Machine-readable inventory of software components; CERT-In defines the minimum elements. |
| Extended xBOM | CERT-In v2.0 | CBOM (crypto), QBOM (quantum readiness), AIBOM (AI), HBOM (hardware) beyond the classic SBOM. |
| Vulnerability status | CERT-In §6 | Communicate via VEX and CSAF, not raw scan output. |
| VAPT / security testing | SEBI CSCRF · RBI | SEBI: via CERT-In-empanelled auditors. RBI: secure SDLC + VAPT. |
| Incident reporting | CERT-In Sec 70B | Report listed incidents within 6 hours of noticing; 180-day log retention. |
| Third-party / supply-chain risk | RBI · SEBI | Assess and monitor suppliers and outsourced software. |
| Applicability | sector-specific | Gov/PSU/exporters → CERT-In; SEBI REs → CSCRF; banks/NBFCs → RBI; all → 70B reporting. |
| SBOM minimum elements | CERT-In Table 5 | Three elements: Data Fields (21 attributes per component), Automation Support, Practices and Processes. |
| Machine-readable format | CERT-In Table 5 | CycloneDX or SPDX. A spreadsheet does not satisfy Automation Support. |
| SBOM class per SDLC stage | CERT-In §3.2 | Design, Source, Build, Analyzed, Deployed and Runtime SBOMs are distinct classes. |
| Known unknowns | CERT-In Table 5 | Declare where completeness cannot be established, under Practices and Processes. |
| SBOM distribution and access | CERT-In §5.3 | Define public vs private SBOM sharing and who may retrieve which. |
| License management | CERT-In §3.4 | Record licenses with SPDX identifiers and combine multi-license terms with operators. |
| CBOM / QBOM | CERT-In §8 | Inventory cryptographic assets and quantum-vulnerable algorithms for migration planning. |
| AIBOM | CERT-In §9 | Record model name, version, type, developer, licensing, dependencies and performance characteristics. |
| HBOM | CERT-In §10 | Hardware and component provenance for firmware and embedded products. |
| RE tiering | SEBI CSCRF | MII, Qualified, Mid-size, Small-size and Self-certification tiers; obligations scale with tier. |
| Framework structure | SEBI CSCRF | Organised around six NIST CSF functions: Govern, Identify, Protect, Detect, Respond, Recover. |
| Empanelled auditors | SEBI CSCRF | VAPT must be carried out by CERT-In-empanelled auditors. |
| Scope of SBOM | SEBI CSCRF | Critical systems: in-house software, third-party COTS and SaaS. |
| Board accountability | RBI/2023-24/107 | IT governance is a board-level obligation, not an IT-department one. |
| Secure SDLC | RBI IT Gov MD | Dependency review, change management and testing gates before release. |
| Digital payment controls | RBI/2020-21/74 | Additional control set for payment operators. |
| Cyber Security Framework | DBS.CO/CSITE/BC.11/33.01.001/2015-16 | The baseline cyber framework for banks. |
| Log retention | CERT-In Directions | Retain ICT logs 180 days within India, available to CERT-In on request. |
| Clock synchronisation | CERT-In Directions | Synchronise to NPL or NIC time sources so incident timelines reconcile. |
| Vulnerability prioritisation | shared | Reachability plus KEV/EPSS turns a raw component list into the findings that need action. |
Run one SBOM programme, satisfy all three
O3 generates the SBOM/CBOM/AIBOM, ranks vulnerabilities by real reachability, keeps a VEX-ready status, and maps the evidence to CERT-In, SEBI and RBI controls — so India compliance is one workflow, not three.
Frameworks are linked individually belowSee O3 Security in Action
See why security and engineering leaders trust O3
to secure their entire software supply chain.