SBOM security in banking now spans air-gapped xBOM governance

At a glance

What this is: This is a banking SBOM security case study showing that xBOM governance now covers air-gapped generation, dependency analysis, and runtime enforcement.

Why it matters: It matters because identity and security teams responsible for software supply chains need governance that spans build provenance, vendor intake, and enforcement boundaries, not just file creation.

By the numbers:

• The ratio of non-human to human identities now exceeds 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read AccuKnox's analysis of SBOM security for banking and air-gapped xBOM governance

Context

Software bill of materials governance is no longer a static compliance exercise. In banking, the control problem is continuous visibility across build artefacts, vendor-supplied inventories, cryptographic components, AI models, and hardware, especially when the environment cannot rely on internet-connected backends for enrichment or storage.

That is where this case study becomes relevant to broader identity and access governance. Once vendors, developers, and internal platforms all supply machine-readable evidence into the same BOM workflow, the question shifts from whether a file exists to whether the lifecycle of those inputs, outputs, and approvals is governed well enough for audit and runtime enforcement.

Key questions

Q: How should teams govern SBOMs in air-gapped environments?

A: Teams should treat air-gapped SBOM governance as a lifecycle control, not a file export exercise. The workflow needs local generation, schema validation, provenance capture, and a way to keep the inventory current when software changes. If the process cannot operate without cloud backends, it is not suitable for restricted environments.

Q: When does BOM generation fail to reduce supply chain risk?

A: BOM generation fails when it stops at inventory creation and never feeds release gates, license checks, or runtime drift detection. In that model, the organisation knows what it built but not whether it can safely deploy or continue to run. The control gap is enforcement, not visibility alone.

Q: What do security teams get wrong about transitive dependencies?

A: They often focus on first-party code and miss the risk introduced several dependency layers down. That creates false confidence because the exploitable component may sit outside the team’s direct ownership and change without obvious review triggers. Effective governance requires graph-based dependency analysis and version comparison.

Q: Who is accountable when a BOM-backed workload deploys with unapproved components?

A: Accountability should sit with the release owner, the application owner, and the security control owner who approved the enforcement policy. If BOM checks are advisory only, failures will be treated as compliance gaps after the fact. If they are wired into admission control, accountability becomes explicit before deployment.

Technical breakdown

xBOM generation in an air-gapped environment

An xBOM program extends the software bill of materials into adjacent artefacts such as CBOM, AI-BOM, and HBOM. In an air-gapped setting, the challenge is not just producing output in SPDX or CycloneDX, but doing so without cloud dependency, duplicated records, or missing metadata. The control value comes from deterministic generation inside the perimeter, because that is what makes the inventory usable for regulated environments and repeatable audits.

Practical implication: teams need an offline generation path that produces consistent xBOM records without relying on external enrichment services.

Transitive dependency mapping and component drift

The main exposure in BOM work is usually not the direct dependency the team already knows about. It is the transitive library pulled in several hops away, plus the change that appears quietly between versions. A governed BOM process must map parent-child relationships, identify version conflicts, and preserve change history so that component drift can be evaluated before release and after deployment.

Practical implication: build controls should compare component deltas across releases and flag newly introduced transitive risk before promotion.

From inventory to enforcement with admission control

A BOM only reduces risk when it becomes an enforcement input. Admission control can use the recorded BOM to block workloads that lack required provenance, carry disallowed licenses, or diverge from approved component sets, while runtime monitoring catches drift after deployment. That closes the loop between supply chain evidence and operational control, which is why BOM governance belongs in the delivery pipeline rather than in a separate compliance archive.

Practical implication: connect BOM validation to deployment gating and runtime drift detection, not just to audit reporting.

Threat narrative

Attacker objective: The objective is to reach trusted software environments through component drift or dependency risk and create exposure that the organisation cannot easily prove or contain.

1. Entry occurs through software supply chain artefacts, where untracked components, vendor BOMs, or transitive dependencies enter the build and release process.
2. Escalation happens when those components are not validated against policy, allowing vulnerable or unapproved software to move into trusted deployment paths.
3. Impact is realised when the organisation loses visibility into what is actually running, what is licensed, and what is exposed to exploitation or audit failure.

NHI Mgmt Group analysis

Air-gapped BOM governance is now a control problem, not a document problem. The bank evaluation shows that regulated environments care less about whether a BOM exists and more about whether it can be generated, validated, and enforced without internet access. That is a stronger governance model than spreadsheet-based inventory management, because it treats provenance as an operational control. Practitioners should assume offline requirements will increasingly shape xBOM design.

Transitive dependency visibility is the real pressure point in software supply chain governance. Direct components are easy to name, but the hidden exposure sits in dependencies of dependencies, version conflicts, and component changes that slip through routine reviews. This is the software analogue of shadow access paths in identity programmes: the risk lives where ownership and visibility thin out. Teams should prioritise graphs, not lists.

Lifecycle enforcement matters more than static compliance checks. A BOM that cannot gate deployment or support runtime drift detection is just an artefact for audit day. The bank’s evaluation reflects a broader market shift toward controls that connect build-time evidence to admission and runtime policy. Practitioners should treat BOM governance as part of the release security model, not a post-release reporting task.

Identity governance now extends into machine-generated trust chains. Supplier attribution, creator identity, tool provenance, and timestamps are not administrative extras. They determine whether the organisation can trust a BOM as evidence and whether downstream controls can make policy decisions from it. This is where identity, software supply chain governance, and auditability intersect most clearly. Practitioners should ensure BOM provenance is owned and reviewable, not merely collected.

Continuous component change management is the named control gap this case exposes. The bank was not just checking for one-time completeness. It was testing whether component additions, removals, license shifts, and dependency updates could be tracked over time. That is the operational reality behind modern BOM governance. Practitioners should build for change detection, because static inventories age out almost immediately.

What this signals

Continuous provenance control is becoming a baseline requirement for regulated software delivery. As BOM schemes expand from software into cryptography, AI, and hardware, teams need control points that can survive offline environments and still support auditability. The practical shift is away from static artefact storage and toward evidence that stays valid through change, release, and runtime. That aligns well with the governance expectations described in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Machine identities now appear inside the supply chain itself. Creator identity, tool provenance, and supplier attribution are not just metadata, they are control signals that determine whether artefacts can be trusted. For identity teams, this is another reminder that non-human trust chains need explicit ownership, even when the primary problem looks like application security. The boundary between software supply chain governance and NHI governance is getting thinner, not wider.

For practitioners

• Build an offline xBOM workflow Use a local generation path that can produce SBOM, CBOM, AI-BOM, and HBOM output without outbound connectivity or cloud enrichment dependencies.
• Validate transitive dependency graphs before release Require component relationship mapping, version conflict detection, and CVE enrichment before any build is promoted into a regulated environment.
• Tie BOM checks to admission control Block workloads that lack approved provenance, required schema fields, or allowed license status before they reach the cluster.
• Track component drift after deployment Compare recorded BOM state to runtime state so added, removed, or changed packages are surfaced as operational exceptions rather than audit discoveries.

Key takeaways

• This case shows that BOM governance has become a runtime security control, not a static inventory exercise.
• Transitive dependencies and component drift are where supply chain exposure tends to hide, especially in regulated environments.
• Teams that cannot enforce BOM policy before deployment will struggle to prove control after deployment.

Key terms

• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• XBOM: An expanded software inventory that goes beyond package lists to include APIs, data flows, authentication layers, internal modules, and runtime dependencies. It gives security teams the architectural context needed to decide what is reachable, sensitive, and worth prioritising.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• Admission Controller: An admission controller is a Kubernetes control that validates or changes workload requests before the cluster admits them. It acts as a deployment-time policy layer, which makes it useful for blocking unsafe images, rejecting risky configuration, and enforcing runtime standards that build-time scans may miss.

What's in the full article

AccuKnox's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact evaluation scorecard used by the bank’s Cyber Information Security Division for supported, partially supported, and unsupported capabilities.
• The on-premises deployment workflow for generating and validating SBOM and CBOM output without internet connectivity.
• The CLI and platform split between one-time BOM generation and continuous monitoring, alerting, and reporting.
• The component-level comparison behaviour that flags additions, removals, license shifts, and version changes.

👉 AccuKnox's full post covers the evaluation scorecard, air-gapped workflow, and runtime enforcement details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect lifecycle control to the broader identity responsibilities their programmes already own.