When SolarWinds and, later, MOVEit turned trusted software updates into breach vectors, banking regulators took notice. Today, SBOM banking regulators—chiefly the FFIEC and the OCC—are folding software bill of materials expectations into routine safety-and-soundness examinations, even though no banking statute mandates SBOMs by name. Examiners increasingly ask community banks and regional institutions the same question federal agencies have asked software vendors since Executive Order 14028 in 2021: can you tell us, component by component, what's actually running inside the software you depend on? For a $2 billion-asset bank running core processing through Fiserv, FIS, or Jack Henry, that question is hard to answer without a vendor-supplied SBOM in hand. Below, we break down what FFIEC software supply chain guidance actually says, how the OCC frames third-party risk for software vendors, and what a bank examiner will realistically ask for—plus how Safeguard closes the gap.
What Do SBOM Banking Regulators Actually Require Today?
No FFIEC or OCC rule mandates a specific SBOM format, but both agencies now expect banks to know what software components run in production and inside their vendors' products—which in practice makes an SBOM the evidence examiners want to see. The expectation traces back to Executive Order 14028 (May 12, 2021), which required federal software vendors to produce SBOMs and follow NIST's Secure Software Development Framework (SP 800-218). Banks aren't federal agencies, but their regulators sit on the same interagency bodies that track NIST and CISA guidance, and FFIEC member agencies have progressively cited the NTIA's July 2021 "Minimum Elements for a Software Bill of Materials" as the reference baseline when examiners discuss vendor software transparency. The result is a soft mandate: nothing in the Bank Secrecy Act or 12 CFR requires an SBOM by name, but an examiner scoping a technology exam in 2026 will treat the absence of any SBOM visibility as a gap in vendor management, not a neutral fact.
What Does FFIEC Software Supply Chain Guidance Actually Say?
FFIEC software supply chain guidance lives primarily in the IT Examination Handbook's "Development, Acquisition, and Maintenance" (DAM) booklet, last substantively updated in April 2024, which explicitly directs examiners to assess whether institutions understand the provenance and composition of the software they acquire, including open-source components embedded in vendor products. The booklet references secure software development practices consistent with NIST SP 800-218 and expects banks to extend the same scrutiny to purchased and hosted software that they'd apply to in-house development. Separately, the FFIEC announced in 2023 that it will sunset the Cybersecurity Assessment Tool (CAT) by August 31, 2025, pointing institutions instead toward the NIST Cybersecurity Framework 2.0—which added a dedicated "Govern" function covering supply chain risk management as a first-class category rather than a footnote. That shift matters: examiners are being trained on a framework where asking "where's your SBOM" is a standard control question, not an edge case.
How Does the OCC Frame Third-Party Risk for Software Vendors?
OCC third-party risk guidance treats software suppliers as full third-party relationships subject to lifecycle risk management, from due diligence through termination, under the Interagency Guidance on Third-Party Relationships: Risk Management issued jointly by the OCC, Federal Reserve, and FDIC on June 6, 2023 (OCC Bulletin 2023-17). That guidance replaced the OCC's 2013 Bulletin 2013-29 and explicitly widened the scope to cover subcontractors and the technology supply chain feeding a bank's critical vendors—language that didn't exist a decade earlier when most core banking contracts were negotiated. For the roughly 1,000 national banks and federal savings associations the OCC supervises, this means due diligence questionnaires increasingly include software composition and vulnerability disclosure questions, and ongoing monitoring is expected to catch newly disclosed component-level vulnerabilities (think Log4Shell in December 2021) between annual vendor reviews, not just at renewal.
What Will a Bank Examiner Actually Ask About Your SBOM?
A bank examiner SBOM conversation usually centers on three things: existence, currency, and response capability. First, examiners ask whether the institution has requested SBOMs from critical technology vendors and whether those vendors actually produced one—many still can't. Second, they ask how current that SBOM is relative to the deployed version, since a document generated at initial procurement and never refreshed tells you nothing about a patch pushed eighteen months later. Third, and most pointed after incidents like the May 2023 MOVEit Transfer breach, which compromised data at more than 2,600 organizations including several banks and credit unions through a single third-party file-transfer tool, examiners ask how quickly the institution could determine its exposure when a component-level CVE breaks. If the honest answer is "we'd call the vendor and wait," that becomes a documented finding tied to vendor management maturity, and repeated findings tend to escalate.
Do Community Banks Need SBOMs, or Just the Largest Institutions?
Asset size doesn't exempt a bank from this expectation, because concentration risk in core banking software runs through community banks just as much as through the top 20. Jack Henry serves roughly 7,500 financial institutions and Fiserv's platforms underpin services at thousands more, which means a single unpatched or malicious component in one of those platforms is a systemic event, not an isolated one—regardless of whether the bank sitting on top of it has $300 million or $30 billion in assets. FFIEC and OCC guidance is explicitly risk-based, meaning examiners scale the depth of review to the institution's complexity, but the underlying question about software transparency doesn't disappear for smaller banks; it just gets asked with less frequency and, often, less patience for "our vendor doesn't provide that."
What Happens If a Bank Can't Produce an SBOM During an Exam?
Nothing catastrophic happens on the first ask, but a documented gap in vendor software transparency typically becomes a Matter Requiring Attention (MRA) or a comparable finding tied to third-party risk management, and it stays open until the bank shows a remediation plan. The bigger exposure shows up when a gap in SBOM visibility intersects with an actual incident: if a bank couldn't identify its exposure to a widely disclosed vulnerability because it never asked vendors for component inventories, examiners read that as a control failure in incident response readiness, not just documentation hygiene, and it can factor into the institution's overall IT and management component ratings under the Uniform Financial Institutions Rating System. Institutions that treat SBOM requests as a one-time procurement checkbox rather than a maintained, living inventory tend to be the ones that get asked the same question again at the next exam cycle, with less patience the second time.
How Safeguard Helps
Safeguard closes this gap between what FFIEC and OCC examiners expect and what most banks can actually produce on demand. Instead of chasing vendors for one-off SBOM documents at procurement time, Safeguard continuously generates and ingests SBOMs across both internally developed applications and third-party software, normalizing everything into a single, examiner-ready inventory that maps components to known CVEs in real time. When a new vulnerability drops—another Log4Shell, another XZ-style backdoor—Safeguard tells you within minutes whether it touches your environment, which vendor products are affected, and what remediation status looks like, turning "we'd call the vendor and wait" into a documented, timestamped answer. Safeguard also structures its reporting around the language examiners actually use: vendor risk tiering aligned to OCC third-party risk categories, component currency tracking that satisfies FFIEC's DAM booklet expectations, and audit trails that hold up when a Matter Requiring Attention needs closing. For compliance and vendor-management teams preparing for their next technology exam, that means walking in with evidence instead of promises.