- Key insight: CISA's update requires vendors to list every component in software, including borrowed code buried several layers down.
- Expert quote: Asked whether a large vendor could produce a software bill of materials meeting all 17 fields with tools that exist now, New York University professor Justin Cappos answered in a word: "No."
- Forward look: The new elements will show up in the questionnaires banks send vendors before they show up in contracts, according to Cornerstone Advisors. FIS, Fiserv and Jack Henry did not respond to questions about whether they supply SBOMs to clients who ask.
Overview bullets generated by AI with editorial review.
The federal government told software buyers this week to ask their vendors for a complete list of what is inside the products they run. Banks are among the buyers, and the researchers who study how those lists get made say a buyer cannot trust all of what comes back.
The Cybersecurity and Infrastructure Security Agency, or CISA, published the
This is the first major update for the standard since the National Telecommunications and Information Administration set
A software bill of materials, usually called an SBOM, is essentially a highly detailed nutrition label for software; it inventories the components inside. Much of what a vendor ships is code it did not write, and an SBOM is the list of that borrowed material.
As an example: MongoDB
The Wednesday document updates and replaces that 2021 baseline rather than starting over. CISA added 10 data fields to the seven the earlier standard required, bringing the total to 17.
Together, these data fields cover the name, version, producer and license of each software component, a cryptographic fingerprint of the code, and a set of details about the inventory itself.
The guidance now also asks for every component in a piece of software rather than the top layer alone. That translates to software buyers gaining information about what software components a threat actor could exploit to break in.
The elements "do not create new requirements," according to the guidance, and
The new SBOM standard instead serves banks by setting a federal benchmark that they can put on the table when negotiating with a vendor — leverage that can win them greater visibility into the software they're buying.
That matters because
But, the new SBOM standard is not a panacea for banks. Two academics who study how these inventories get built told American Banker that a bank would not be able to trust the data it gets back.
What a bank gets when it asks for the ingredients
Today, banks are not getting component-level inventories from the companies that run their core systems, said Brad Mason, a managing director at Cornerstone Advisors, which advises banks on core system selection and vendor contract negotiation.
Banks instead get an inventory one level up. Core contracts name the "applications, modules, services, interfaces, environments, or product families" a bank is buying and generally stop there, Mason told American Banker.
They usually do not "go down to open-source libraries, software dependencies, component versions, or detailed internal functionality," he said.
A bank that asks for these components rarely gets them.
Providers answer with questionnaires, security summaries, attestations and SOC reports, which are third-party audits of a vendor's controls, Mason said. Some offer "limited disclosure tied to a specific vulnerability, audit, regulator request."
Vendors resist writing component detail into a contract because ordinary product changes and retirements "can otherwise become contract issues," he said.
FIS, Fiserv and Jack Henry ran the core systems for
None of the three responded to questions about whether they provide SBOMs to clients who ask.
What banks should ask for instead
CISA's new requirements will show up first in the questionnaires banks send vendors rather than in the contracts they sign, Mason said. Over time, he expects banks to write the inventory requests into contracts.
For a community bank, the useful demand is not all 17 fields, he said. It is vulnerability management obligations, incident notification, remediation commitments and audit rights.
A full inventory "is only useful if the bank can ingest it, monitor it, compare it against vulnerability data, and follow up on remediation," Mason said, and many community banks have neither the staff nor the tooling.
Larger institutions that do have both can seek audit rights, documentation review rights and clearer definitions of what a product actually does, Mason said.
Turtles all the way down
The 2021 baseline only required a software bill of material to disclose the so-called top-level dependencies — what code the software borrowed. Going deeper was encouraged rather than required, since depth beyond the outer layer "may not be easily available," that document read.
Contrast top-level dependencies with transitive dependencies, which look at what the borrowed code borrows, what that code borrows and so on down the line.
The 2026 document replaces that element with one called Coverage, under which an SBOM "should include information for all components that make up the target software, including transitive dependencies." There is "no minimum depth," according to the guidance.
Following that chain matters, because Log4j was a common transitive dependency when it broke in 2021. Log4j is a small piece of free code that keeps a record of what a program does, and thousands of products have borrowed it.
When
A recipient "should be able to conclude that a newly reported vulnerability does not affect them if the SBOM does not list the component associated with the vulnerability," the Wednesday guidance reads — the check that nobody could run when Log4j broke.
The banks' own council said the data was unreliable
The Financial Services Sector Coordinating Council
Dependency relationships, which describe how components rely on one another, "often produce incomplete or inconsistent mappings" that "may obscure rather than clarify risk," the letter said.
It also requested tool names be optional; these identify the software that generated the inventory. That field "does not provide meaningful benefit," according to the council.
The council's members include the American Bankers Association, the Independent Community Bankers of America and America's Credit Unions. Debbie Guild, the council's chair and PNC's head of technology, signed the letter. CISA required both anyway.
Read more:
Should a bank ever be liable when a customer gets scammed ?OpenAI models' Hugging Face breach is a red flag for bankers The top-performing banks with $2B to $10B of assets in 2025
FIS also sits on the council, according to a
A vendor helping shape what its customers ask of vendors is a conflict on its face, but it is also what a sector coordinating council does, since its positions get negotiated among members that buy and sell from one another.
Nothing in the letter records which member shaped which recommendation.
The FSSCC did not respond to a request for comment.
The tools are guessing, and they disagree
The council's objection to required dependency relationships is "somewhat true and somewhat misleading," according to Justin Cappos, a professor at New York University's Tandon School of Engineering who runs its Secure Systems Lab.
Today's generators combine two techniques, he told American Banker, and "neither is very accurate because they're really approaching the problem with very incomplete information."
The unreliable mappings the council complained about are a symptom of that, in his account, rather than a reason to drop the field.
Building an SBOM is like writing the ingredients list for a pie, Cappos said. Scanning the finished software is "trying to write down the ingredients list for a pie after it is baked, based upon its smell."
Reading the dependency lists that come packaged with the code is using the recipe, "which sounds a bit more reasonable, but consider that often different ingredients get substituted in the kitchen," Cappos said.
When his lab ran the two most popular generators against the same program, the lists differed by about 30%, according to Cappos.
Asked whether a large vendor could produce an SBOM meeting all 17 fields with tools that exist now, he answered in a word: "No."
Cappos is working on one attempt at a fix.
Santiago Torres-Arias, an assistant professor at Purdue University who works on the same problem, said the opposite when asked about whether a vendor would be able to generate all 17 fields.
"Unfortunately, yes," he told American Banker. "It's not very hard to fill some 'reasonable' values in the fields required, but it is impossible to assess whether proper due diligence was done when filling those in."
In other words, a vendor could hand a bank a document with all 17 fields filled in, but nobody (the vendor included) could say whether the values were right.
The seemingly contradictory answers from Torres-Arias and Cappos actually land in the same place; they both suggest that a bank cannot tell what it is holding.
The one place an SBOM mandate has actually taken hold is medical devices. Makers of internet-connected devices have had to file one with the Food and Drug Administration since March 2023, under a law that points at the same 2021 baseline CISA just replaced.
Torres-Arias said he heard one theme from practitioners after that deadline passed: "Everybody was to produce 'an SBOM', and not necessarily a 'useful SBOM.'"
CISA said the tools had caught up. They haven't
For its part, CISA says the technology to produce inventories at depth already exists.
The agency explained its Wednesday guidance changes in an appendix, where it said the top-level-only rule from 2021 "reflected the capabilities of SBOM tooling at the time rather than the depth of information needed to make informed security decisions."
Adding transitive dependencies to the requirements became possible because "the advances in SBOM tooling since 2021 make specifying this breadth of software component information feasible," according to the appendix.
CISA did not immediately respond to a request to reconcile these claims with those of Torres-Arias and Cappos.
American Banker reviewed 23 published SBOMs, including documents from MongoDB, Red Hat and the Python Software Foundation, along with sample files that the two main SBOM formats, SPDX and CycloneDX, publish to demonstrate their own specifications.
None carried filled-in data for all 17 fields, and no document published for a real product got past 12. The highest score, 15, went to a test file the CycloneDX project wrote to exercise every field in its own format.
Every document reviewed was published before Wednesday, so the count measures what the tools available to a vendor today actually produce. (A field counted as present only when every component in the document carried it.)
The companies that run bank core systems publish no SBOMs at all, so there was nothing of theirs to score.
What would help, Torres-Arias said, is not more required fields but a document that can admit what it does not know.
"If an SBOM could express uncertainty, people would be better equipped to handle and reason about risk," he said.
