SEBI CSCRF SBOM Requirements: What Regulated Entities and Their Vendors Must Provide

If your company sells software to an Indian stock broker, mutual fund, depository participant or exchange, a regulator now expects your customer to hold a software bill of materials for it. SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF), issued in August 2024 and in force for most regulated entities since 31 August 2025, makes SBOMs mandatory for the software behind core and critical business operations. That includes SaaS, and it includes software the regulated entity built itself.

The framework is 205 pages, and the SBOM rules are spread across a supply chain guideline, a standard with nine required data items, the application testing section and a set of FAQs. This explainer is for security and compliance teams at SEBI-regulated entities and for the vendors who supply them. It covers what the SBOM rules require and of whom, the timeline as it actually played out, how the nine required items map to CycloneDX fields (three of them have no field at all), and a script that checks a vendor SBOM against the list.

The short answer

Under SEBI's CSCRF (circular CIR/2024/113, 20 August 2024), all regulated entities must obtain an SBOM for software used in core and critical activities: for existing critical systems, for new procurements including SaaS at the time of purchase, and for in-house applications, and must keep it updated with every upgrade. The SBOM must cover licences, supplier, all components with transitive dependencies and relationships, encryption used, component hashes, update frequency, "known unknowns", access control and error handling. Where a vendor won't provide one for legacy or proprietary software, the board, partners or proprietor must approve the gap with a documented rationale. After a series of extension and clarification circulars, compliance applied from 31 August 2025 for most entities. Market infrastructure institutions (exchanges, clearing corporations and depositories) must also make SBOMs part of vendor empanelment.

Who the SBOM rules apply to

CSCRF applies to every category of SEBI-regulated entity (RE), from stock exchanges and depositories to brokers, mutual funds, portfolio managers, investment advisers and registrars. It sorts them into five tiers by size and role: Market Infrastructure Institutions (MIIs), Qualified REs, mid-size REs, small-size REs and self-certification REs. Many controls scale with the tier.

The SBOM standard doesn't. Standard GV.SC.S5 is marked "All REs (Mandatory)". The tiers change how much else an entity must do, not whether it needs SBOMs for its critical software.

What the framework requires

The requirements sit in four places.

The supply chain guideline. SBOMs must be obtained for all new software procurements for core and critical activities, and kept updated with every upgrade or change. If an SBOM can't be obtained for legacy or proprietary systems, the entity's board, partners or proprietor must approve that, with the limitation, rationale and risk management approach recorded.

Standard GV.SC.S5. This is the operative list:

1. Obtain SBOMs for existing critical systems within six months of the framework's issue.
2. Obtain SBOMs for new critical software products and SaaS applications at the time of procurement.
3. MIIs must include SBOMs in their empanelment criteria for application software vendors.
4. Each SBOM must include, at minimum, the nine items in the table below.

Application security testing. For critical systems, the list of tests and audits all REs must carry out includes the SBOM, alongside source code review, functional audit and VAPT after major releases. For commercial software empanelled for brokers and depository participants, the exchanges and depositories must run the source code and functional audits through STQC before approving a product.

The FAQs. SEBI's FAQs of 11 June 2025, which SEBI says are guidance rather than binding interpretation, settle three common questions. SBOMs are needed for all software required for core and critical business operations, including SaaS. In-house applications need them as much as third-party software does. And when a vendor refuses, the route is the board-approved exception, not silence.

The timeline, as it happened

SEBI's list of CSCRF circulars shows nothing after 28 August 2025 as of 18 October 2026. One timing detail is worth noting: the "within six months of issue" deadline for existing critical systems was written against August 2024, and SEBI's later circulars extended the overall compliance dates without restating individual guideline deadlines. For an entity's cyber audit, the practical question is now simply whether the SBOMs exist.

The nine items, mapped to CycloneDX

SEBI doesn't name a format. Both CycloneDX and SPDX are widely used. We checked the list against the CycloneDX 1.6 schema, because it has fields for some of the less common items:

The three gaps aren't a reason to skip them. They're a reason to agree with vendors, in writing, where that information will live, so the auditor sees a complete answer even though the SBOM file isn't.

Check a vendor SBOM against the list

This script reads a CycloneDX JSON SBOM and reports, for each of the nine items, what the file covers and where the format has no field. It uses only the Python standard library:

#!/usr/bin/env python3
"""Check a CycloneDX JSON SBOM against the fields SEBI's CSCRF lists (GV.SC.S5, guideline 4).

  cscrf_sbom_check.py sbom.cdx.json [...]

Some CSCRF items have no CycloneDX field; the script says so instead of guessing.
Standard library only.
"""
import json, sys

def pct(n, d):
    return f"{n}/{d} ({100 * n // d if d else 0}%)"

def check(path):
    bom = json.load(open(path))
    meta = bom.get("metadata", {})
    comps, stack = [], list(bom.get("components", []))
    while stack:                                   # nested components count too
        c = stack.pop()
        comps.append(c)
        stack.extend(c.get("components", []))
    libs = [c for c in comps if c.get("type") != "cryptographic-asset"]
    n = len(libs)
    deps = bom.get("dependencies", [])
    edges = sum(len(d.get("dependsOn", [])) for d in deps)
    refs_with_deps = {d.get("ref") for d in deps}
    props = {p.get("name", ""): p.get("value") for p in meta.get("properties", [])}
    rows = [
        ("a. License information", pct(sum(bool(c.get("licenses")) for c in libs), n)),
        ("b. Name of the supplier", ("SBOM supplier set; " if meta.get("supplier") else "no metadata.supplier; ")
         + "components: " + pct(sum(bool(c.get("supplier") or c.get("manufacturer")) for c in libs), n)),
        ("c. Components, transitive dependencies, relationships",
         f"{n} components, {edges} dependency edges, "
         f"{pct(sum(c.get('bom-ref') in refs_with_deps for c in libs), n)} listed in the graph"
         if deps else f"{n} components, NO dependency graph (flat list)"),
        ("d. Encryption used", f"{sum(c.get('type') == 'cryptographic-asset' or 'cryptoProperties' in c for c in comps)} "
         "cryptographic asset(s) declared"),
        ("e. Cryptographic hash of the components", pct(sum(bool(c.get("hashes")) for c in libs), n)),
        ("f. Frequency of updates", next((f"{k} = {v}" for k, v in props.items() if "update" in k.lower()),
                                         "no CycloneDX field: record it as a metadata property or in the vendor contract")),
        ("g. Known unknowns", ", ".join(sorted({c.get("aggregate", "?") for c in bom.get("compositions", [])}))
         or "no compositions: completeness not stated"),
        ("h. Access control", "no CycloneDX field: document separately"),
        ("i. Methods for accommodating occasional incidental errors", "no CycloneDX field: document separately"),
    ]
    print(f"{path}: CycloneDX {bom.get('specVersion')}, generated {meta.get('timestamp', 'unknown')}")
    for k, v in rows:
        print(f"  {k:58} {v}")
    print(f"  {'(extra) versions / package URLs':58} {pct(sum(bool(c.get('version')) for c in libs), n)} / "
          f"{pct(sum(bool(c.get('purl')) for c in libs), n)}")

if __name__ == "__main__":
    if len(sys.argv) < 2:
        sys.exit(__doc__)
    for p in sys.argv[1:]:
        check(p)

We tested it on two synthetic SBOMs for the same imaginary application, with placeholder hashes. The first is a flat list of names and versions, which is what many vendors send first. The second has licences, a supplier, hashes, a dependency graph, a declared TLS 1.3 protocol asset, an update-frequency property and a composition statement:

$ python3 cscrf_sbom_check.py vendor-minimal.cdx.json vendor-detailed.cdx.json
vendor-minimal.cdx.json: CycloneDX 1.6, generated 2026-09-30T10:00:00Z
  a. License information                                     0/3 (0%)
  b. Name of the supplier                                    no metadata.supplier; components: 0/3 (0%)
  c. Components, transitive dependencies, relationships      3 components, NO dependency graph (flat list)
  d. Encryption used                                         0 cryptographic asset(s) declared
  e. Cryptographic hash of the components                    0/3 (0%)
  f. Frequency of updates                                    no CycloneDX field: record it as a metadata property or in the vendor contract
  g. Known unknowns                                          no compositions: completeness not stated
  h. Access control                                          no CycloneDX field: document separately
  i. Methods for accommodating occasional incidental errors  no CycloneDX field: document separately
  (extra) versions / package URLs                            3/3 (100%) / 0/3 (0%)
vendor-detailed.cdx.json: CycloneDX 1.6, generated 2026-10-01T09:30:00Z
  a. License information                                     3/3 (100%)
  b. Name of the supplier                                    SBOM supplier set; components: 1/3 (33%)
  c. Components, transitive dependencies, relationships      3 components, 4 dependency edges, 3/3 (100%) listed in the graph
  d. Encryption used                                         1 cryptographic asset(s) declared
  e. Cryptographic hash of the components                    3/3 (100%)
  f. Frequency of updates                                    example:sbom:update-frequency = every release, at least monthly
  g. Known unknowns                                          incomplete_first_party_proprietary_only
  h. Access control                                          no CycloneDX field: document separately
  i. Methods for accommodating occasional incidental errors  no CycloneDX field: document separately
  (extra) versions / package URLs                            3/3 (100%) / 3/3 (100%)

The first file has names and versions and nothing else the framework asks for. The second covers six of the nine items and still needs three answered elsewhere, plus suppliers for two components. Most real vendor SBOMs land between the two.

What to do

1. Inventory core and critical software, including SaaS and in-house applications, and map each to an SBOM, a request in progress or a board-approved exception.
2. Put the nine items in your procurement terms. Ask for CycloneDX or SPDX with dependency relationships and hashes, plus written answers on update frequency, access control and error handling.
3. Require updates with every release, not one SBOM at onboarding. The framework says "kept updated with every upgrade or change".
4. Check what arrives. Run the script above, or your SBOM tooling, before filing a vendor SBOM as compliant. A flat list is unlikely to satisfy an auditor asking about relationships.
5. Document exceptions properly. The board approval needs the limitation, rationale and risk treatment, and should be revisited at renewal.
6. Vendors: get ahead of it. Market infrastructure institutions must include SBOMs in vendor empanelment, and our India supply chain update covers CERT-In's related guidance. Our post on the 2026 SBOM minimum elements covers the US baseline that many generators target.

The fair view

SEBI's approach has real strengths. It applies SBOM duties to every tier rather than only the largest firms, covers SaaS and in-house software explicitly, and gives a practical escape valve for legacy systems that puts the decision with the board instead of leaving it unrecorded. The extensions show a regulator listening to the market, and the FAQs answered the questions entities were actually asking.

The weak spot is the gap between the list and the formats. Three of the nine items have no home in the main SBOM standards, and "known unknowns" depends on a field few generators fill. Without agreed conventions, two compliant SBOMs for the same product could look very different, and auditors will have to judge them. Entities that settle the format and the side documents with their vendors now will have an easier first audit cycle than those that collect whatever files arrive.