Software Supply Chain Security: SBOM Rules in India

Your Software Is Mostly Someone Else's Code

A modern enterprise application is assembled far more than it is written. Open-source libraries, vendor SDKs, container base images and transitive dependencies — the packages your packages depend on — typically account for the large majority of what actually ships. That is not a problem in itself; it is how software gets built. The problem is that most organisations cannot answer a simple question quickly: when a critical vulnerability drops in a widely used library, are we running it, and where?

Indian regulators have moved from treating that as an engineering nicety to treating it as a compliance obligation. Both CERT-In and SEBI now expect regulated organisations to maintain a Software Bill of Materials (SBOM) — a machine-readable inventory of every component in a piece of software, including its suppliers, licences and nested dependencies.

What CERT-In Expects

CERT-In issued its first dedicated SBOM guidelines in 2024, and released an expanded version 2.0 in July 2025 that widened the concept well beyond software alone — adding companion bills of materials for cryptography (CBOM), quantum readiness (QBOM), AI systems (AIBOM) and hardware (HBOM).

The guidelines are aimed primarily at government agencies, public sector bodies, organisations running essential services, and software exporters. They point to the globally accepted machine-readable formats rather than inventing an Indian one — SPDX, CycloneDX and SWID — which means an SBOM you generate for an international customer is generally the same artefact you present to an Indian regulator.

The operational requirement that catches teams out is refresh cadence: an SBOM is expected to be regenerated whenever the software changes. A patch, a version bump, a swapped third-party library — each produces a new bill of materials. An SBOM generated once for an audit and never updated is, in practice, worse than none, because it creates false confidence about what is running.

What SEBI CSCRF Expects

SEBI folded SBOM obligations into its Cybersecurity and Cyber Resilience Framework (CSCRF) for Regulated Entities. The scope is broad across the securities market — stock exchanges, depositories, clearing corporations, brokers, mutual funds, RTAs, KRAs, custodians and investment advisers all fall within it, subject to the framework's own categorisation of entities.

Two details matter more than the rest. First, the requirement applies to new, existing and legacy software — not just to what you build or buy next. Second, where an SBOM genuinely cannot be obtained (a legacy platform, or a proprietary vendor that will not supply one), the expectation is not that the gap is quietly ignored: a documented risk-mitigation plan approved at board level is required instead.

The framework is also specific about content. A compliant SBOM is expected to capture the supplier name, the licence, the full component inventory including transitive dependencies, encryption and cryptographic hash details, and the update frequency. The compliance deadline for most regulated entities was 31 August 2025 and has now passed, which means SBOM maturity is squarely an audit finding rather than a roadmap item.

Where SBOM Programmes Go Wrong

• Treating it as a document, not a pipeline output. An SBOM produced by hand for an audit is stale the moment the next build ships. Generation belongs in CI/CD, attached to the build artefact.
• Stopping at direct dependencies. The components that cause incidents are usually three levels down. If your inventory does not resolve transitive dependencies, it will miss exactly the ones you need during a zero-day.
• Collecting SBOMs with nowhere to put them. Vendor-supplied SBOMs that land in an inbox and never get parsed into a searchable inventory add compliance overhead without adding a single answered question.
• Ignoring vendor and SaaS software. Scope covers what you run, not only what you write. Procurement contracts are the practical lever — an SBOM clause at renewal is far easier than a retrofit request.
• No link to vulnerability response. An inventory only pays off when a new CVE can be mapped to affected systems in minutes. If that lookup is still a manual hunt, the SBOM has not changed anything operationally.

A Practical Starting Sequence

For organisations starting late, the fastest route to defensible evidence is narrow and deep rather than broad and shallow. Begin with the systems that are actually in regulatory scope — customer-facing and market-facing applications — and generate SBOMs automatically in the build pipeline in CycloneDX or SPDX. Store them centrally so that a component can be searched across every application at once.

From there, extend outward: add SBOM clauses to vendor contracts at renewal, record a board-approved mitigation plan for each legacy system where no SBOM is obtainable, and wire the inventory into your vulnerability management process so a new advisory produces an impact list rather than a research project. Supply chain evidence sits naturally alongside the testing evidence discussed in our guides to SEBI CSCRF and VAPT and DPDP Act compliance evidence — the same auditors generally ask for both.

eNeoteric's VAPT and threat intelligence engagements include software composition analysis and SBOM review — verifying that generated inventories resolve transitive dependencies, mapping components against known vulnerabilities, and producing the artefacts auditors ask for. If you need supply chain evidence to hold up under CERT-In or SEBI CSCRF scrutiny, our compliance services and secure development lifecycle practices cover the pipeline side, and you can talk to our team about scoping an SBOM readiness assessment.