Banks, vendors stumble over new SBOM security rules

The 2026 SBOM standard, unveiled by CISA alongside 13 allied nations, marks a significant evolution from the 2021 NTIA baseline by mandating ten new minimum data fields that notably include digital signatures and component hashes. These additions enhance the ability to verify SBOM integrity and authenticity, addressing a critical gap by enabling organizations to confirm that documented components precisely match deployed software binaries. This expansion reflects a broader recognition of modern software delivery complexities, incorporating open-source software, AI systems, and SaaS into the SBOM scope to ensure comprehensive supply chain transparency.

Beyond expanding data fields, the 2026 standard shifts the operational paradigm by extending SBOM responsibilities from internal build pipelines to vendor contracts and procurement processes, especially for AI and SaaS products where binaries are often not compiled in-house. CISA frames this update as a foundational floor rather than a ceiling, anticipating that complex software types will require additional tailored elements to achieve the desired transparency. This strategic move acknowledges the evolving software ecosystem and the necessity for SBOMs to accompany services directly, ensuring that organizations receive verifiable supply chain information even when traditional build artifacts are unavailable.

A central focus of the 2026 update is the enhanced coverage and granularity of dependency information, replacing the previous 'depth' element with an unrestricted 'coverage' metric that captures all transitive dependencies. This addresses longstanding deficiencies where SBOMs failed to reflect indirect software components introduced via intermediaries, a vulnerability vector increasingly exploited in digital supply chains. By leveraging machine-readable formats like CycloneDX and SPDX, the new standard aims to improve data quality and automate vulnerability exploitability analyses, thereby supporting more granular, context-aware risk assessments that respond directly to prior industry criticisms about incomplete and inaccurate component listings.

While the 2026 SBOM standard codifies many existing best practices, some experts remain skeptical about its ability to resolve core challenges in risk management and SBOM accuracy. Jeff Williams, a noted security expert, critiques the guidance for largely documenting current tooling capabilities without integrating Vulnerability Exploitability eXchange (VEX) data or mechanisms to ensure completeness and accuracy. This critique underscores ongoing debates about the standard’s sufficiency in driving meaningful improvements in supply chain security, highlighting a tension between formalizing baseline requirements and addressing the nuanced realities of software component verification.

Banks and their technology vendors struggle to produce SBOMs that fully comply with the 2026 standard’s expanded requirements, which now include 17 data fields. Despite CISA’s guidance adding 10 new fields and updating existing ones, tooling limitations remain a significant barrier. As New York University professor Justin Cappos observed, even large vendors cannot currently generate SBOMs meeting all these criteria, highlighting a gap between regulatory expectations and practical capabilities.

The operational challenge extends beyond tooling to the quality and granularity of information banks receive from vendors. Typically, banks obtain only high-level inventories listing applications or product families, lacking detailed disclosures down to open-source libraries or component versions essential for effective supply chain risk management. Brad Mason of Cornerstone Advisors notes that vendors often resist embedding detailed component data into contracts, fearing that frequent product updates could trigger contractual disputes, which complicates transparency efforts.

Adding to these challenges, CISA’s 2026 SBOM guidance stops short of enforcing accuracy, completeness, or coverage assurance, leaving banks uncertain about the reliability of vendor-supplied SBOMs. This absence of quality assurance mechanisms undermines trust and complicates efforts to achieve true supply chain transparency. Reflecting a cautious operational rollout, Mason explains that the new requirements will first appear in vendor questionnaires before evolving into formal contractual obligations, signaling an incremental approach to adoption amid ongoing standardization hurdles.

Ensuring SBOM integrity remains a formidable challenge as partial coverage and incomplete provenance tracking undermine the reliability of software supply chain security efforts. As highlighted by experts, providing an SBOM that covers only a fraction of the components—sometimes as low as 10%—fails to meet the intent of mandatory transparency, leaving significant 'dark matter' unaccounted for. This issue is exacerbated by the widespread use of untracked sources in container images, where metadata gaps obscure critical components like WordPress despite their presence, revealing a persistent technical and standardization gap in SBOM generation and completeness.

The EU Cyber Resilience Act (CRA) exemplifies the evolving regulatory landscape that mandates not only the creation of SBOMs but also their continuous lifecycle management, demanding manufacturers demonstrate comprehensive knowledge of product composition and ongoing vulnerability management. This lifecycle approach requires constant monitoring, documentation, and risk assessment throughout a product’s supported lifetime, posing operational challenges especially for complex embedded systems with diverse software and hardware components. While the CRA accelerates SBOM adoption, it simultaneously exposes tooling and execution gaps that organizations must address to achieve meaningful supply chain security.

The rise of AI-driven development introduces unprecedented complexity and risk into SBOM accuracy, as agent-driven pipelines and large language models (LLMs) frequently hallucinate dependencies or introduce new ones without human oversight. Studies reveal that 45% of agent edits add entirely new direct dependencies, with nearly 20% of AI-generated packages being non-existent, complicating trustworthiness and traceability. To counter these risks, cryptographic attestation and build-time SBOM generation tied directly to artifact production are critical, yet current tooling often falls short in semantic completeness and integration, necessitating paired approaches combining build-native generators with container scanners to enhance vulnerability detection.

Managing the lifecycle and integrity of shim patches—modifications altering application bytecode without changing dependency metadata—poses a nuanced technical hurdle that current SBOM tooling struggles to address. Without explicit tracking mechanisms including ownership, expiry dates, and removal conditions, shim patches risk indefinite persistence in SBOMs, undermining accuracy and compliance. Organizations are forced to develop bespoke solutions such as custom scripts and policy files (e.g., shim-policy.yaml) to enforce lifecycle management, highlighting significant gaps in operationalizing SBOM standards and the urgent need for enhanced tooling to support these processes.