Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Compliance›SEBI CSCRF
India · SEBI Circular 2024/113

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.

Talk to our advisory team Read the circular on SEBI.gov.in
At a glance
20 Aug 2024CSCRF circular issued
31 Aug 2025Compliance deadline for most REs
6NIST CSF functions: Govern + Identify, Protect, Detect, Respond, Recover
5 tiersRE categories: MII, Qualified, Mid, Small, Self-certification
SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for Regulated Entities
Why it matters

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.

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.

Remediation expectations

The clock by finding type

Indicative fix windows. Tightest where exposure and active exploitation meet.

CSCRF circular issued20 Aug 2024
Clarifications publishedDec 2024
Compliance deadline (most REs)31 Aug 2025
SBOM refreshEvery software change/upgrade
Software Bill of Materials

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.

SEBI CSCRF SBOM guidelinesCERT-In Technical Guidelines on SBOM v2.0
Generate a machine-readable SBOM (CycloneDX or SPDX) for every internet-facing app, client-facing service, and core backend system, not just new procurements.
Capture the mandated fields per component: license, supplier or author name, version and unique identifier, dependency relationships including transitive deps, cryptographic hash, and update frequency.
Record encryption details so the SBOM doubles as evidence of cryptographic posture across the software estate.
Regenerate the SBOM on every software change or upgrade so it stays a living artifact rather than a point-in-time snapshot.
For legacy or proprietary software where an SBOM cannot be obtained, document the gap and get board approval of a risk-mitigation plan.
Where O3 helps

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.

Vulnerability management

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.

SEBI CSCRF Protect / DetectCERT-In empanelled auditor list
Inventory critical and core systems and schedule periodic VAPT cycles aligned to your RE category.
Engage a CERT-In empanelled auditor for the formal penetration test and retain the report as audit evidence.
Run continuous internal scanning (SAST, SCA, DAST) between formal VAPT cycles so new findings are caught early.
Prioritise findings by real exploitability rather than raw CVSS, so remediation effort targets what actually matters.
Track each finding to closure with timestamps and re-test evidence to satisfy auditor review.
Where O3 helps

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.

Supply-chain integrity

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.

SEBI CSCRF SBOM guidelinesCERT-In Technical Guidelines on SBOM v2.0
Continuously match SBOM components against vulnerability feeds (OSV, NVD) so new CVEs in shipped dependencies surface automatically.
Screen dependencies for typosquats, malicious postinstall scripts, and compromised maintainers before they reach production.
Verify build provenance where suppliers provide it, reading SLSA attestations and cosign signatures to confirm artifact integrity.
Maintain VEX-style exploitability statements so you can show which SBOM vulnerabilities are not actually exploitable in your context.
Where O3 helps

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.

Detect & Respond

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.

SEBI CSCRF Detect / RespondNIST CSF
Stand up or contract a Security Operations Centre with log aggregation and monitoring across critical systems.
Define an incident response plan with roles, escalation, and reporting paths to SEBI and CERT-In within required timelines.
Instrument runtime workloads so process-level and network-level anomalies are detected, not just perimeter events.
Run tabletop exercises to validate that detection feeds response and that timelines are met.
Where O3 helps

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.

Govern & Identify

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.

SEBI CSCRF Govern / Identify
Establish a board-approved cybersecurity policy and assign a senior owner accountable for CSCRF compliance.
Maintain an asset inventory of hardware, software, and data classified by criticality.
Run periodic risk assessments and feed results into the governance cycle and audit submissions.
Document third-party and outsourcing arrangements with security obligations flowed down to vendors.
Data protection

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.

SEBI CSCRF ProtectCERT-In CBOM guidelines
Encrypt sensitive data in transit and at rest, and manage cryptographic keys under a documented policy.
Enforce least-privilege access controls and review entitlements periodically.
Scan source and configuration for hardcoded secrets and weak or missing encryption before release.
Maintain audit trails for access to sensitive systems and data.
Where O3 helps

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.

The whole framework

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.

10SBOM mandate
Software Bill of Materials fields and lifecycle
4Vulnerability & supply chain
VAPT, vuln management, dependency integrity
3Detect / Respond / Recover
SOC, incident response, resilience
6Govern / Identify / Protect
Governance, assets, data protection
Requirement area
SBOM for new software at procurementCSCRF SBOM guidelinesRequire machine-readable SBOM in contracts
SBOM for existing critical/core systemsCSCRF SBOM guidelinesGenerate SBOM for internet-facing and core apps
SBOM field: licenseCSCRF SBOM guidelinesRecord component license per dependency
SBOM field: supplier/authorCSCRF SBOM guidelinesCapture supplier name for each component
SBOM field: transitive dependenciesCSCRF SBOM guidelinesMap full dependency tree, not just direct
SBOM field: encryption detailsCSCRF SBOM guidelinesInventory cryptographic algorithms via CBOM
SBOM field: cryptographic hashesCSCRF SBOM guidelinesStore component hashes for integrity
SBOM field: update frequencyCSCRF SBOM guidelinesRecord and track component update cadence
SBOM refresh on changeCSCRF SBOM guidelinesRegenerate SBOM on every software upgrade
Legacy SBOM exceptionCSCRF SBOM guidelinesBoard-approved risk-mitigation plan documented
Periodic VAPTCSCRF Protect/DetectPenetration test critical systems on schedule
CERT-In empanelled auditorCSCRFUse empanelled auditor for formal VAPT
Vulnerability managementCSCRF ProtectContinuous SAST, SCA, exploitability ranking
Supply-chain / malicious dependencyCSCRF SBOM guidelinesScreen deps for typosquats and tampering
SOC and continuous monitoringCSCRF DetectAggregate logs, runtime and network telemetry
Incident detection and responseCSCRF RespondIR plan with SEBI/CERT-In reporting paths
Recovery and resilienceCSCRF RecoverBackups, tested restore and continuity plans
Governance and board ownershipCSCRF GovernBoard-approved policy and accountable owner
Asset identificationCSCRF IdentifyClassified inventory by criticality
Data protection and encryptionCSCRF ProtectEncrypt data, manage keys, scan secrets
Access controlCSCRF ProtectLeast-privilege with periodic entitlement review
Third-party / outsourcing riskCSCRF Govern/IdentifyFlow security obligations down to vendors
Audit and evidence retentionCSCRFRetain living artifacts for auditor review

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
FAQ

Common
questions.

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

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