As software supply-chain risks continue to rise, regulators in India, particularly the SEBI, the RBI and the CERT-In are demanding greater transparency from organisations. They are pushing organisations to gain deeper visibility into the components that make up the software they build, deploy, or procure. This has made Software Bills of Materials (SBOMs) a key governance requirement for every regulated entity.
Understanding the required SBOM fields under SEBI, RBI and CERT-In guidelines has therefore become a critical compliance and governance need. These fields help organisations know exactly what’s inside their software, whether developed in-house or procured from third parties.
Although RBI has not published its own SBOM field list, but it has explicitly directed all Regulated Entities (REs) to follow CERT-In’s SBOM Technical Guidelines, which prescribe 21 mandatory SBOM fields. SEBI, under its Cybersecurity & Cyber Resilience Framework (CSCRF), mandates a separate minimum set of 9 SBOM fields.
In this guide, we unpack the mandatory SBOM field requirements, their differences across regulators, and practical steps to ensure compliance.
SBOM field requirements matters
SBOM field requirements matters because software transparency is the new compliance currency. Regulators want organisations to know exactly what is running inside their applications. Unknown or undocumented software components are one of the biggest sources of modern supply-chain attacks.
A well-structured SBOM helps organisations:
- Identify vulnerable libraries early,
- Validate open-source licenses,
- Respond quickly to zero-day issues,
- Maintain transparency with auditors and regulators, and
- Reduce risk from third-party and inherited components.
RBI’s position on SBOM fields
RBI, through its CSITE Advisory (Nov 25, 2024), instructs all REs to obtain SBOMs from in-house teams and vendors as per CERT-In’s prescribed guidelines. Therefore, for RBI-regulated entities, the CERT-In 21-field SBOM baseline is effectively applicable.
Lear more about RBI’s SBOM requirements in our blog: How to Meet RBI SBOM Compliance.
SEBI’s position on SBOM fields
Under SEBI’s CSCRF, regulated entities must maintain SBOM-like inventories reflecting 9 minimum fields, including licensing, supplier information, encryption, dependency mapping and integrity attributes.
In many real-world cases, the source (e.g., the codebase, a vendor-provided SBOM, or a COTS application) may not contain all fields.
In such situations, organisations can:
- Manually enrich missing fields, especially for internal or custom systems
- Use GenAI-based enrichment, where NXRadar intelligently fills missing metadata (when appropriate and permissible)
This ensures a complete and regulator-ready SBOM.
SBOM minimum fields as per CERT-In (21 fields)
Below is the complete 21-field requirement as specified in CERT-In’s SBOM Technical Guidelines:
- Component Name: Name of the software component
- Component Version: Specific version or build identifier
- Component Description: Purpose or functional summary
- Component Supplier: Vendor, developer or OSS maintainer
- Component License: MIT, Apache 2.0, GPL, proprietary, etc.
- Component Origin: Open-source, proprietary, internal, third-party
- Component Dependencies: List of libraries/packages it relies on
- Vulnerabilities: Known CVEs mapped to the component
- Patch Status: Whether patches are available or applied
- Release Date: Release date of this version
- End-of-Life (EOL) Date: Support end or EOL timeline
- Criticality: Technical/business criticality rating
- Usage Restrictions: License or vendor-imposed limits
- Checksums / Hashes: Integrity checks (SHA-256, SHA-512)
- Comments or Notes: Additional contextual information
- Author of SBOM Data: Person or system generating the SBOM
- Timestamp: When SBOM was generated
- Executable Property: Whether the component is executable
- Archive Property: Whether packaged/archived (zip/tar/etc.)
- Structured Property: Additional metadata allowed by schema
- Unique Identifier: UUID, pURL, CPE, or other unique ID
These 21 fields form the mandatory minimum for RBI-aligned compliance.
If you want to learn specifically about what CERT-In demands, head to our blog CERT-In’s SBOM Guidelines Explained.
SBOM minimum fields as per SEBI CSCRF (9 fields)
SEBI’s field list focuses on transparency, licensing clarity and operational integrity:
- License information: License type, obligations, restrictions
- Name of the supplier: Vendor or project owner
- Primary components and transitive dependencies: Full dependency graph
- Encryption used: Algorithms, key lengths, TLS version, etc.
- Cryptographic hash of the components: SHA-256/SHA-512 for integrity
- Frequency of updates: Update cadence or revision schedule
- Known unknown: Gaps in dependency coverage or incomplete data
- Access control: Who can view/update export SBOM data
- Methods for accommodating incidental errors: How mistakes or gaps are corrected and tracked
These 9 fields reflect SEBI’s emphasis on governance, transparency and operational reliability.
SEBI’s CSCRF considers software security crucial, and has released guidelines. To know the complete mandate, read our blog Understanding SBOM Requirement of SEBI CSCRF.
From fragmented to full: how to handle missing SBOM fields
In real scenarios, SBOMs received from vendors or generated from legacy code often lack several mandatory fields.
To complete them:
1. Manual Enrichment
Useful when:
- SBOM is for in-house or custom code
- Developers understand the architecture
- Licensing or classification requires human judgment
2. AI-Based Enrichment
GenAI models can:
- Infer missing metadata
- Detect likely origins
- Suggest license types
- Map hidden dependencies
- Recommend vulnerability associations
This dramatically accelerates SBOM readiness for audits.
Audit-Proofing your tech stack for RBI & SEBI
RBI and SEBI audits increasingly require proof of:
- Software composition transparency
- Third-party component visibility
- Cryptographic and licensing hygiene
- Clear dependency relationships
- Accurate vulnerability attribution
Incomplete SBOMs create compliance gaps and operational blind spots. With clear field requirements from CERT-In and SEBI, organisations now have a structured playbook for building regulator-ready SBOM inventories.
Conclusion
Indian regulators are moving firmly toward full software supply-chain transparency, and SBOMs are at the center of this shift. Understanding the mandatory SBOM fields, 21 from CERT-In and 9 from SEBI, helps organisations build the right processes, enrich missing data, and prepare for future regulations such as CBOM, AIBOM and HBOM.
With platforms like CyberNX’s NXRadar, organisations can easily generate, enrich, validate and track SBOMs across their entire application portfolio – ensuring compliance with RBI, SEBI and CERT-In guidelines while strengthening software-supply-chain security.
Contact us today, and our experts will show you how our SBOM management tool will help you with SBOM readiness and build a compliance-driven SBOM management system.
Required SBOM fields under SEBI, RBI and CERT-In Guidelines FAQs
Does RBI require a separate SBOM field list apart from CERT-In’s guidelines?
No. RBI has not published a standalone field list. Its advisory directs regulated entities to follow the CERT-In SBOM guidelines.
Must SEBI-regulated entities include all 21 CERT-In fields?
Not necessarily. SEBI’s CSCRF emphasises a minimum set of nine fields. However, adopting more comprehensive fields (e.g., from CERT-In) strengthens compliance and readiness for audits.
How often must an SBOM be updated for compliance?
Both regulators expect updates whenever the software changes (new version, patch, or component added). SEBI references update frequency as a field. CERT-In emphasises version-level SBOMs and updates on changes.
Can open-source components be excluded from the SBOM?
No. Both CERT-In and commentary interpret that all components – including open-source libraries – must be captured to ensure full supply-chain visibility.
What formats are acceptable for SBOMs under these guidelines?
While neither regulator mandates a single format, CERT-In recommends internationally recognised SBOM formats such as SPDX or CycloneDX to ensure machine-readability and consistency.
