Leading Global Bank Partners with AccuKnox to Deploy SBOM Security

Why Do Indian Banks Suddenly Need an SBOM Program?

CERT-In published its first SBOM guidelines in October 2024 and replaced them in July 2025 with Technical Guidelines on SBOM, QBOM, CBOM, AIBOM and HBOM version 2.0. The scope widened from software alone to cryptography, AI models, and hardware. RBI’s own SBOM mandate for banks is expected to align with that document.

What the guidelines ask for is specific. Every component needs a version and a unique identifier, with supplier attribution. Dependency graphs must cover direct and transitive relationships. Each BOM record needs creator identity, tool provenance, a timestamp, and a data license.

The operational tasks are harder than the format. A bank has to hold continuous visibility of components across its applications, refresh the BOM when software changes, keep records available for audit, and collect and validate the SBOMs its vendors send in. That last one is the part most banks have no process for at all.

The SBOM capability checklist Indian banks are being scored against.

What the Bank Tested, and What It Scored Against

The bank ran a formal evaluation rather than a demo. Its Cyber Information Security Division scored each capability as supported, partially supported, or not supported, with proof required for every claim.

The scorecard covered five areas. BOM generation and automation came first, then ingestion and parsing of BOMs received from vendors and internal developers, then vulnerability tracking and analysis, then license compliance and policy checks, and finally version comparison and change tracking.

Ten software projects went through the pipeline in a single week. Generation ran through the knoxctl CLI, while continuous monitoring, vulnerability enrichment, alerting, and reporting ran in the AccuKnox platform.

Air-Gapped From Day One, with Support for SaaS and On-Prem

The deployment was 100% on-premises with no internet connectivity. Both halves of the workflow, generation and monitoring, ran inside the bank’s own perimeter with no outbound calls.

That constraint quietly eliminates a large part of the SBOM market. Plenty of tools generate a clean CycloneDX file and then need a cloud backend to enrich it, score it, or store it. In a public sector bank’s core environment, that backend does not exist and will not be approved.

Five BOM Types, Two Formats, One Toolchain

The bank’s form marked SBOM and CBOM mandatory, and the platform generated both automatically with proof attached. The team also demonstrated AI-BOM and HBOM validation, which matters because CERT-In v2.0 now covers AI models and hardware explicitly.

Every BOM came out in both SPDX and CycloneDX, carrying all the minimum elements CERT-In lists, with a unique identifier assigned to each component. The platform ingested, normalized, and validated the BOMs vendors sent in, and re-uploading the same file did not create duplicate records.

From Build Artefact to Runtime Enforcement

Generating a BOM is where most programs stop. The bank was more interested in what happens after generation, because a BOM sitting in a directory changes nothing about risk.

The path from CI/CD artefact, through pre-deployment verification, to runtime.

Artefacts from the code repository, container images, and packages feed a signing step that produces signed releases. The platform then handles BOM analysis, license verification, and risk prioritization. An admission controller checks the BOM before a workload deploys, so a workload without a BOM or carrying a disallowed license never reaches the cluster. Runtime enforcement holds the line after deployment, catching drift and protecting integrity against the recorded BOM.

That chain is also what moves a build platform up the SLSA levels, from signed provenance at level 2 to hermetic builds and full pipeline security at level 4.

Transitive Risk Is Where the Exposure Actually Sits

Direct dependencies are the ones teams already know about. The damage tends to arrive through the libraries your libraries pull in, which is exactly what CERT-In means by requiring full dependency graphs.

Dependency graph showing transitive relationships, outdated components, and version conflicts.

The graph view maps every hop and flags outdated packages, components shared across multiple parents, and conflicting versions of the same library. CVEs from the vulnerability databases map onto those components, prioritized by CVSS score and exploitability, and searchable by CVE identifier when an advisory lands and someone senior asks whether the bank is exposed.

License risk rides along the same graph. Unauthorized open source licenses, deprecated packages, and known vulnerable components each raise an alert.

Tracking What Changed Between Two Builds

CERT-In asks for BOMs to be refreshed when software changes, which is only useful if someone can see the difference between two versions.

Comparing two BOMs, with added, removed, and changed components.

The comparison view counts what was added, removed, changed, and left alone, then lists each component with its version movement and license change. A library that quietly moved from Apache 2.0 to a commercial license shows up here rather than in a legal review two years later.

Component-level detail, including supplier, PURL, OSSF score, and scope.

Why The Leading Bank Chose AccuKnox – Supply Chain Security, xBOM Capability, CERT-IN Compliance

The Air-Gapped Deployment Worked No internet connectivity, no cloud dependency, generation and monitoring both inside the bank’s perimeter. For a public sector bank this is a pass or fail gate before features get discussed.
One Tool Covered Generation and Monitoring A CLI produced the BOMs and the same platform handled vulnerability enrichment, alerting, and reporting, so the bank did not have to integrate a generator with a separate management backend.
Coverage Went Past SBOM CBOM was mandatory on the bank’s form and it works today, with AI-BOM and HBOM validation demonstrated alongside it. Banks buying an SBOM-only tool in 2026 will be running this evaluation again shortly.
Enforcement, Not Just Inventory Admission control blocks workloads without a valid BOM or with disallowed licenses, and runtime drift detection keeps the deployed state matching the recorded one.
Compliance Fields Mapped Themselves CERT-In minimum elements, component identifiers, supplier data, and dependency relationships were populated by the tooling rather than assembled by an analyst the week before an audit.

FAQ