Cyber Security
Bank tech vendors need to start writing nutrition labels
By
Published August 03, 2026, 6:00 a.m. EDT
|
Updated August 03, 2026, 6:03 a.m. EDT
10 Min Read
Adobe Stock
- 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
Processing Content
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 2026 Minimum Elements for a Software Bill of Materials
on Wednesday. The National Security Agency, the Federal Bureau of Investigation and 15 international partner agencies signed on
This is the first major update for the standard since the National Telecommunications and Information Administration set the baseline
in 2021
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 publishes an SBOM
for its database. It lists 54 pieces of borrowed code, among them Mozilla’s Firefox browser engine
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 no banking regulator has adopted them
. Major 2023 interagency guidance
on banks’ third-party relationships never mentions SBOMs
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 regulators hold a bank responsible
for the risk its vendors introduce, and threat actors have a history of breaking into banks through vulnerabilities in the software they buy. Recent examples include a file transfer program
, an appliance sold to guard sensitive files
and a remote access product
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-ailed 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 more than 70%
of U.S. depository institutions as of 2022, the most recent figure the Office of the Comptroller of the Currency cited in a request for information
it published last November
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 flaw
in it surfaced that December, organizations spent months
working out where they had it in an effort to patch any vulnerabilities it introduced in their systems
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 filed a comment
on the draft SBOM guidance last October asking CISA to make two of the proposed fields optional. The council carries the financial industry’s collective positions to the federal government on cybersecurity
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
- 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
Inside Upstart’s journey to get a bank charter approval
FIS also sits on the council, according to a roster
the council publishes and last updated in April 2024. That puts one of the three core providers inside the group that asked CISA to require less
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,” 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%
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. SBOMit
, a Linux Foundation project, would record what happens while a program is built, which he said would supply much of what CISA’s new fields ask for
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
Carter Pape
Technology Reporter
Carter Pape has covered cybersecurity, financial crime and emerging technology for American Banker since January 2022.Pape, reporting from… Read full bio
