Software supply chain attacks continue to challenge financial institutions. Many teams now operate large application stacks built with open-source libraries, vendor software and internal code. Without clarity on these components, it becomes difficult to manage exposure effectively.
Regulators such as RBI, SEBI and CERT-In now require organisations to maintain clear, accurate SBOMs in recognised standard SBOM formats. The format selection matters as much as the content it captures. A PDF export, regardless of how complete the underlying data is, will not satisfy an automated audit workflow.
This guide explains the SBOM formats accepted by India’s three primary regulators, what each format is suited for, the mandatory fields each regulator expects and how to ensure your SBOM programme is genuinely audit-ready.
SBOM Formats Recognised by RBI, SEBI and CERT-In
India’s regulators do not prescribe a single format. They expect globally recognised, machine-readable standards. Two formats meet this bar: CycloneDX and SPDX (Software Package Data Exchange).
1. CycloneDX: The Security-First SBOM Format
CycloneDX was designed for automation. It uses JSON and XML serialisations and has a compact schema built around component identity, transitive dependency graphs and vulnerability metadata. Its native support for VEX (Vulnerability Exploitability eXchange) makes it particularly well-suited for organisations that want SBOM data to feed directly into vulnerability management workflows.
For most RBI and CERT-In aligned environments, CycloneDX is the practical default. It integrates cleanly into CI/CD pipelines and supports the extended BOM taxonomy – CBOM (Cryptographic Bill of Materials), HBOM (Hardware BOM) and ML-BOM – that CERT-In’s expanded guidelines reference. The current active specification is CycloneDX 1.7 (released October 2025), though many tools still generate 1.5 or 1.6 output by default. Verify the specVersion field in any tool output before treating it as audit-ready.
2. SPDX: The Compliance and Audit-Ready SBOM Format
SPDX is an ISO/IEC-backed standard with a detailed model for licence identifiers, copyright statements and provenance. Where CycloneDX prioritises security and automation, SPDX prioritises legal and compliance documentation. Its rich licensing vocabulary makes it the preferred format for supplier audits and cross-organisation licence governance.
SPDX 3.0 (published 2024) introduced an element-based model that is more powerful for complex supply chains, though many tools still produce SPDX 2.3 output. For most BFSI compliance purposes, SPDX 2.3 remains fully valid.
Which format to use
In practice, most organisations adopt both. CycloneDX handles build-time automation and vulnerability workflows. SPDX handles compliance reporting and supplier-facing documentation.
A format comparison answers what an SBOM contains. It does not answer whether a known CVE is exploitable in a specific deployment. That answer comes from VEX. A VEX document accompanies an SBOM and states, for each known vulnerability, whether it is affected, not affected, under investigation or fixed, in machine-readable form.
CERT-In’s guidelines reference this chain explicitly: SBOMs should integrate with VEX and CSAF (Common Security Advisory Format) advisories for rapid vulnerability status updates, not just raw CVE lists. CycloneDX has native VEX support built into its specification, which is one practical reason to favour it for security-focused workflows.
For a detailed format-by-format breakdown including conversion trade-offs, see our guide: Guide to SBOM Standards and Formats: CycloneDX, SPDX, VEX.
Mandatory SBOM Fields CERT-In, SEBI, RBI Require You to Capture
Each regulator defines a specific set of mandatory SBOM fields that go beyond simply listing components. The fields cover:
- Component identity
- Dependency relationships
- Licence obligations
- Cryptographic integrity
- Vulnerability status and
- Lifecycle data
Plus, the generation method for each field determines how much of this your tooling can automate versus what requires manual enrichment. Most raw SBOMs produced by scanning tools are incomplete against these standards; enrichment is not optional, it is where compliance is won or lost.
Generating an SBOM is only half the work. Field mapping is where most organisations discover the gap, matching what their tooling produces against what each regulator specifically requires.
CERT-In mandates 21 fields, SEBI mandates 9, and RBI adopts CERT-In’s baseline in full. Raw SBOMs from scanning tools rarely satisfy all of these out of the box; missing fields, incomplete metadata and unstated licence obligations are the most common audit findings.
The table below shows what each regulator expects and where the coverage focus lies.
| Regulator | Fields required | Focus area | Full reference |
| CERT-In | 21 fields | Component identity, dependencies, vulnerabilities, lifecycle and integrity hashes | See all 21 fields → |
| SEBI | 9 fields | Governance, licence, encryption, access control and error handling | See all 9 fields → |
| RBI | Adopts CERT-In’s 21 fields | Same as CERT-In baseline — partial SBOMs will not meet inspection expectations | RBI SBOM compliance guide → |
How to operationally comply with SBOM requirements
Selecting the right format and mapping your fields is the starting point. Operationalising SBOM compliance, from scoping applications to automating generation, enriching vendor SBOMs and building governance workflows requires a structured, repeatable process.
For the complete step-by-step operating model, see our SBOM Generation Checklist aligned with RBI, SEBI and CERT-In Guidelines.
Conclusion
SBOM compliance is now a mandatory, continuously tested obligation across India’s financial ecosystem. The SEBI deadline has passed. The RBI’s 2026 Directions are in force. CERT-In’s technical guidelines define the field-level baseline that both regulators rely on.
Selecting the right SBOM format is the first practical decision. Ensuring your chosen format covers all required regulatory fields without manual gaps is where most programmes stumble.
Speak with our experts to understand exactly which formats, fields and governance controls apply to your regulatory profile. Also, find out how our SBOM solutions can help you understand your current programme may fall short before an auditor finds it first. Connect today.
FAQs
Which SBOM formats do regulators accept?
Regulators recognise CycloneDX and SPDX as the two primary machine-readable formats. CycloneDX suits security and vulnerability workflows, including native VEX support. SPDX supports strong licence governance and provenance documentation. CERT-In allows both, but expects complete and consistent field coverage regardless of which format is used. SWID is no longer considered an SBOM format under current regulatory and international guidance.
Do vendors need to share SBOMs regularly?
Yes. RBI’s CSITE Advisory and 2026 Cybersecurity Directions are explicit: vendors must provide SBOMs and allow audit rights. Updated SBOMs are expected whenever critical patches, security fixes or major version changes are released. This enables regulated entities to track component drift, validate integrity and respond rapidly when a dependency becomes vulnerable.
Does an SBOM detect unknown vulnerabilities?
Not directly. An SBOM records known components and versions, which enables rapid response when a new vulnerability is disclosed. The value is speed – security teams know exactly where an affected dependency sits across the application estate, without manual triage. Pairing SBOM with VEX adds a further layer by confirming whether a known vulnerability is exploitable in a specific deployment context.
How often should teams refresh SBOMs?
SBOMs should be regenerated at every build, release or vendor update. SEBI expects organisations to define and document their update cadence. Stale SBOMs consistently surface as audit gaps during regulatory reviews and undermine the broader compliance posture they are meant to support.
