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
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 framework applies to you
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.
The shared core: SBOM, VEX, VAPT
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.
The dates that matter
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.
The three regimes, side by side
All 7 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.
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.