SEBI CSCRF SBOM compliance
the only Indian regulation with a field-level Software Bill of Materials mandate
SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF), issued under circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 on 20 August 2024, is built on the five NIST CSF functions (Identify, Protect, Detect, Respond, Recover) plus Govern. It applies to every SEBI Regulated Entity, scaled by size from Market Infrastructure Institutions down to self-certifying small REs.
What sets CSCRF apart from every other Indian regulation is its explicit, field-level SBOM mandate. Regulated Entities must maintain a Software Bill of Materials for all new software at procurement and for existing critical or core systems, recording license, supplier, component inventory including transitive dependencies, encryption details, cryptographic hashes, and update frequency. The compliance deadline for most REs was 31 August 2025.
India's first regulation to put SBOM fields into law
SEBI CSCRF replaced the patchwork of earlier SEBI cyber circulars with a single, structured framework that every Regulated Entity must follow. Stock exchanges, depositories, clearing corporations, brokers, mutual funds, RTAs, KRAs, custodians, and investment advisers are all in scope. The obligations scale by RE category, so a Market Infrastructure Institution carries the full weight while a small RE can self-certify against a reduced control set.
The headline obligation is the SBOM mandate. No other Indian financial regulation names the Software Bill of Materials as a hard requirement with specific attributes. REs must capture license, supplier name, the full component inventory including transitive dependencies, encryption details, cryptographic hashes, and update frequency, and must refresh the SBOM on every software change or upgrade. Where an SBOM cannot be obtained for a legacy or proprietary system, the board must approve a documented risk-mitigation plan (CSCRF SBOM guidelines).
Beyond SBOM, CSCRF demands periodic VAPT of critical systems by CERT-In empanelled auditors, a functioning SOC, incident detection and response, and data protection, all mapped to the NIST CSF functions. Because the framework is risk-graded and audit-driven, evidence matters: REs are expected to show living artifacts, not one-off attestations.
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.
From alert flood to a short list
KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.
Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.
The clock by finding type
Indicative fix windows. Tightest where exposure and active exploitation meet.
How to build an SBOM that meets the SEBI CSCRF field mandate
CSCRF requires an SBOM for all new software at procurement and for existing critical or core systems. The minimum attributes mirror the CERT-In Technical Guidelines and go further than most teams expect.
O3 generates CycloneDX SBOMs enriched with deps.dev metadata for license, supplier, version, and transitive dependency relationships, plus cryptographic hashes, and pairs them with a CBOM that captures the encryption details CSCRF asks for. SBOMs regenerate on every scan so they stay current with each change.
How to run VAPT and vulnerability management under CSCRF
CSCRF requires periodic vulnerability assessment and penetration testing of critical systems, conducted by CERT-In empanelled auditors, with tracked remediation.
O3 supplements formal CERT-In VAPT with continuous coverage: code-property-graph SAST with source-to-sink taint, SCA against OSV, function-level reachability to confirm whether a vulnerable component is actually reachable, and agentic DAST/pentest across 50+ vulnerability classes. EPSS and KEV signals rank findings by exploitability.
How to defend the software supply chain CSCRF expects you to inventory
An SBOM is only useful if you act on it. CSCRF's emphasis on supplier and dependency data implies active monitoring for compromised or malicious components.
O3 runs malicious-dependency detection (typosquats, malicious postinstall, compromised maintainers) over the same SBOM it generates, and reads SLSA and cosign provenance to verify artifact integrity. Reachability plus EPSS/KEV produce VEX-style exploitability context for each component.
How to satisfy the SOC, detection, and incident response functions
CSCRF maps to NIST CSF Detect and Respond, requiring a SOC, continuous monitoring, and a tested incident response capability.
O3's eBPF runtime agent (kayo) builds kernel-level process trees and detects attack chains with no sidecars, and its L7 deep packet inspection (ecapture) baselines egress to flag exfiltration and DNS tunnelling. These feed the Detect function with runtime signal that complements SOC log analysis.
How to establish the governance and asset identification CSCRF requires
CSCRF adds Govern to the NIST CSF five and expects board-level ownership plus a complete view of assets and risks.
How to meet the Protect-function data security controls
CSCRF's Protect function requires safeguards around data confidentiality and integrity, including encryption and access control.
O3's secret scanning (Gitleaks-based) finds hardcoded credentials and keys in code, and its CBOM inventories cryptographic algorithms and protocols so weak or outdated encryption is visible. Key management, IAM, and data-at-rest encryption operations remain governance controls outside O3.
Every CSCRF control area and how to meet it
All 23 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.
Turn the SEBI CSCRF SBOM mandate into living evidence
CSCRF is the only Indian regulation that names SBOM fields explicitly: license, supplier, transitive dependencies, encryption details, hashes, and update frequency. O3 generates CycloneDX SBOMs and CBOMs that carry exactly those fields, screens dependencies for tampering, and adds continuous SAST, SCA, reachability, and runtime detection to support the VAPT and Detect requirements. See how O3 maps to your CSCRF obligations.
Read the circular on SEBI.gov.in- CSCRF is SEBI's Cybersecurity and Cyber Resilience Framework, issued via circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 on 20 August 2024. It applies to all SEBI Regulated Entities, including stock exchanges, depositories, clearing corporations, brokers, mutual funds, RTAs, KRAs, custodians, and investment advisers, with obligations scaled across five RE categories.
- Yes. CSCRF is the only Indian financial regulation that explicitly mandates a Software Bill of Materials. Regulated Entities must maintain SBOMs for all new software at procurement and for existing critical or core systems, recording license, supplier, transitive dependencies, encryption details, cryptographic hashes, and update frequency per the CSCRF SBOM guidelines.
- Following clarifications published in December 2024, the compliance deadline for most Regulated Entities was extended to 31 August 2025. Market Infrastructure Institutions and larger REs carry the full control set, while smaller REs follow a reduced, self-certification path.
- The mandated minimum attributes are component name, version and unique identifier, supplier or author name, dependency relationships including transitive dependencies, license, cryptographic hash, encryption details, and update frequency, plus known-unknowns. The SBOM must be regenerated on every software change or upgrade so it remains current.
- CSCRF requires periodic vulnerability assessment and penetration testing of critical systems conducted by CERT-In empanelled auditors. Many REs run continuous internal SAST, SCA, and DAST between formal VAPT cycles so new findings are caught and remediated before the next audit.
- Yes. CSCRF is structured around the NIST Cybersecurity Framework functions: Govern, Identify, Protect, Detect, Respond, and Recover. Each control area maps to one of these functions, which helps REs reuse existing NIST CSF mappings and audit evidence.
- The CERT-In Technical Guidelines on SBOM v2.0 are best-practice guidance applicable broadly, while CSCRF turns SBOM into a binding requirement for SEBI Regulated Entities. CSCRF's SBOM field list closely mirrors the CERT-In minimum elements, so meeting CERT-In's format generally satisfies the CSCRF attributes.
- A platform that generates CycloneDX SBOMs with license, supplier, transitive dependency, hash, and encryption data directly produces the artifacts CSCRF mandates. O3 adds a CBOM for encryption details, malicious-dependency screening, continuous SAST/SCA with reachability for the Protect function, and eBPF runtime plus L7 egress monitoring for Detect.
See O3 Security in Action
See why security and engineering leaders trust O3
to secure their entire software supply chain.