What Does a Sponsor Bank Need From a Fintech on Open Source Risk?

Your sponsor bank needs proof that you know what open source is inside the software that touches its customers, that you find and fix known vulnerabilities on a defined clock, and that you build software in a controlled way. In practice that means a current software bill of materials (SBOM) for each product, vulnerability status ranked by exploitation evidence, patch timelines you actually meet, a record of exceptions, and a way to hand all of it to the bank securely and refresh it on a schedule. The bank asks because its examiners hold it responsible for what its third parties do, so its expectations become yours.

This post explains where those expectations come from, using the federal banking agencies' own text, the FFIEC examination handbook, the FTC Safeguards Rule and PCI DSS, then turns them into an evidence pack and a refresh cadence you can run with your own tools. Product detail comes only at the end. Nothing here is legal or compliance advice; your partnership agreement and your counsel decide what you owe.

Key takeaways

• The 2023 Interagency Guidance on Third-Party Relationships says a bank's use of third parties does not reduce its own responsibility, so the bank looks through you to your software.
• The guidance names the software development life cycle, vulnerability and penetration test results, secure source code management and technology inventories as due diligence topics.
• The FTC Safeguards Rule (16 CFR 314.4) may apply to your fintech directly, with secure development, six monthly vulnerability assessments absent continuous monitoring, and service provider oversight.
• Where card data is in scope, PCI DSS 6.3.2 asks for a component inventory and 6.3.3 sets one month for critical or high security patches.
• Build the pack around SBOMs, KEV and EPSS ranked vulnerability status, patch metrics, exception records, an SSDF mapping and an access log, refreshed on a cadence and on triggers.
• Safeguard covers the software component part of this job: SBOM generation and analysis (GA), software composition analysis with vulnerability management using EPSS and CISA KEV (GA), policies and gates (GA), Portal for NDA gated, tracked SBOM sharing (GA), the compliance and GRC suite (GA), the local runner and CLI (GA), and autonomous remediation (GA, ships switched off). Trust Center is early access, the desktop app is early access (beta), and fork and patch is early access.
• Safeguard does not make you compliant with anything, does not answer for the bank's examination, and has no SOC 2 report of its own to hand to your bank.

Why your bank's examiner is really the one asking

A sponsor bank arrangement puts a regulated bank between your product and the customer. The bank holds the charter, the deposits or the card program, and the supervisory relationship. You hold the code. When an examiner reviews the bank, the examiner asks how the bank oversees you.

The interagency guidance states the principle in one sentence that every fintech compliance lead should know. Published at 88 FR 37920 by the Federal Reserve, the FDIC and the OCC, and final as of June 6, 2023, it says that a banking organization's use of third parties "does not diminish its responsibility" to operate safely and soundly and in line with the law, to the same extent as if it did the work in house.

That line explains every questionnaire you have received. If the bank would have to manage software supply chain risk for an app it built itself, it has to manage the same risk for the app you built for it, and it cannot do that without evidence from you.

OCC Bulletin 2023-17, which announced the guidance, rescinded OCC Bulletin 2013-29 and the 2020 FAQs that supplemented it, and notes that not every relationship carries the same level of risk. A sponsor bank that lets you onboard its customers, move its money or hold its customer data will usually treat you as a higher risk relationship, and higher risk means more evidence, more often. The comment summary in the notice also records that commenters raised the particular risks of fintech relationships; fintech partnerships get no special pass.

What the 2023 interagency guidance expects banks to check in a fintech partner

The guidance organizes third-party risk management into a life cycle: planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. Oversight and accountability run across all of it. Software supply chain questions show up in at least four places.

Due diligence: information security

The due diligence factor on information security is the closest the guidance comes to describing an AppSec program. It says due diligence typically involves assessing the third party's information security program and its consistency with the bank's own program. It lists controls such as multifactor authentication, end-to-end encryption and secure source code management as examples of what to consider.

It then goes further. As applicable, the bank may assess the third party's data, infrastructure and application security programs, including its software development life cycle, and the results of vulnerability and penetration tests. It also asks whether the third party keeps informed of known and emerging threats and vulnerabilities and whether it puts sustainable corrective actions in place for deficiencies found in testing.

Read that list as a fintech and you get the shape of your evidence pack. The bank wants to see how you develop software, what your testing found, and how you fixed it.

Due diligence: management of information systems

The next factor asks the bank to review the third party's processes for keeping its technology and contractor inventories timely and accurate and its contractors. For a software company, the technology inventory has two layers. One is infrastructure: cloud accounts, hosts, databases. The other is the software itself, including every open source package compiled into your services. The second layer is what an SBOM documents.

Due diligence: operational resilience and subcontractors

The operational resilience factor lists, among other considerations, end of life issues with the software programming language, platform or data storage technologies a third party uses. An unmaintained framework or an abandoned library in your stack is exactly this kind of issue.

The guidance also covers reliance on subcontractors, which it defines broadly as the suppliers, service providers and other organizations a third party enlists. It asks how you select and oversee them and whether they implement effective controls. Open source maintainers are not your contractors, and nothing in the guidance says to treat them as such. But the bank's question behind the factor is the same one: what do you depend on that you do not control, and how do you watch it? Your component inventory and your vulnerability process are the honest answer for open source.

Contract terms and ongoing monitoring

In the contract negotiation section, the guidance suggests specifying the type and frequency of reports the bank receives, including security reports and control assessments. It discusses the right to audit and require remediation, timely disclosure of security breaches, and a clause stating that the third party's performance is subject to regulatory examination and oversight, with access to relevant documentation. A footnote points to the Bank Service Company Act provision, 12 U.S.C. 1867(c)(1), which is the statute behind the idea that examiners can reach services performed for a bank.

Ongoing monitoring is where the cadence comes from. The guidance says monitoring may be periodic or continuous, and that more comprehensive or frequent monitoring fits higher risk and critical activities. Among the factors it lists for monitoring are how the third party responds to changing threats, new vulnerabilities and incidents, and its reliance on subcontractors. When your bank asks for a quarterly vulnerability report or an attestation after a major disclosure, this is the text behind the request.

Which FFIEC examination handbook areas reach into a partner's software development and acquisition

The Federal Financial Institutions Examination Council publishes the IT Examination Handbook that bank examiners use. On August 29, 2024 the FFIEC issued a revised Development, Acquisition, and Maintenance (DA&M) booklet, which replaced the Development and Acquisition booklet from April 2004.

The agencies' own transmittal letters describe what changed. The Federal Reserve's SR 24-6 says the booklet covers IT project management, the system development life cycle and supply chain risk management, and stresses the importance of system and software maintenance to resilience. It also says the booklet does not impose new requirements on examined entities; it describes the principles and practices examiners review. The OCC's Bulletin 2024-26 makes the same points and adds that the revised title reflects an increased focus on development, acquisition and maintenance over the useful life of a system or component.

The FDIC's letter on the same booklet lists its applicability as FDIC supervised institutions "and their service providers". That phrase matters to a fintech. Examiners use the DA&M booklet to judge how a bank develops and acquires systems, including systems a partner builds, and the FDIC states that service providers fall within its reach.

In practice this reaches you three ways. Supply chain risk management means the examiner may ask how the bank knows what components sit in a partner's software, and your SBOM is the bank's answer. The system development life cycle focus means the bank wants defined security activities in your process, not just an annual pen test; an SSDF mapping helps. And the focus on maintenance over a component's useful life is a direct hook for open source: a version that was fine at onboarding can carry a known exploited vulnerability a year later.

One honest note on sourcing. The FFIEC's handbook site did not allow automated retrieval when this post was prepared, so the description above comes from the Federal Reserve, OCC and FDIC letters that announced the booklet. Read the booklet itself on ithandbook.ffiec.gov before quoting any section number to your bank.

Where the FTC Safeguards Rule applies to the fintech directly

The interagency guidance tells banks what to check. It does not regulate you. The FTC's Standards for Safeguarding Customer Information, 16 CFR Part 314, can. The rule applies to financial institutions within the FTC's jurisdiction under the Gramm-Leach-Bliley Act, which takes in many non-bank lenders, payment companies and other fintechs. Whether it covers your company is a legal question for counsel. If it does, several paragraphs of section 314.4 speak directly to software supply chain work.

The paragraphs that touch software

• 314.4(b) requires a written risk assessment that identifies reasonably foreseeable risks to customer information.
• 314.4(c)(2) asks you to identify and manage the data, personnel, devices, systems and facilities that serve your business, in line with their importance. A software inventory is part of knowing your systems.
• 314.4(c)(4) requires you to adopt secure development practices for in-house developed applications that transmit, access or store customer information, and procedures for evaluating, assessing or testing the security of externally developed applications you use for the same purposes.
• 314.4(d)(2) requires, for information systems, either continuous monitoring or periodic penetration testing and vulnerability assessments. Absent effective continuous monitoring, you must run penetration testing annually and vulnerability assessments, including scans designed to identify publicly known security vulnerabilities, at least every six months, and whenever there are material changes to operations or business arrangements.
• 314.4(f) requires you to oversee your own service providers: select capable ones, require safeguards by contract, and periodically assess them based on risk.
• 314.4(i) requires your Qualified Individual to report in writing, regularly and at least annually, to your board or equivalent governing body, covering the status of the program and material matters such as service provider arrangements and results of testing.
• 314.4(j) requires notice to the FTC, as soon as possible and no later than 30 days after discovery, of a notification event involving the information of at least 500 consumers.

Why this matters for the bank conversation

"Publicly known security vulnerabilities" in 314.4(d)(2) is, for the open source in your code, the CVE and advisory data that software composition analysis matches against your dependency inventory. If you already monitor dependencies continuously for the Safeguards Rule, the same records answer your bank's ongoing monitoring questions. And 314.4(f) makes you the bank in your own supply chain: a bank that sees you oversee your own vendors with the same rigor is more comfortable.

Where card data is in scope: PCI DSS requirement 6.3

If your product stores, processes or transmits cardholder data, or can affect its security, PCI DSS applies and your bank or its card program will ask for your compliance status. The current version listed in the PCI Security Standards Council document library is PCI DSS v4.0.1. The requirement wording below is quoted from the PCI SSC's v4.0 Self-Assessment Questionnaire D for service providers; check it against the v4.0.1 standard you are assessed to.

• 6.2.1 says bespoke and custom software is developed securely, based on industry standards or best practices for secure development.
• 6.3.1 says new security vulnerabilities are identified using industry recognized sources and assigned a risk ranking.
• 6.3.2 says an inventory of bespoke and custom software, and third-party software components incorporated into it, is maintained to facilitate vulnerability and patch management. The applicability note made it a best practice until 31 March 2025, after which it became required.
• 6.3.3 says system components are protected from known vulnerabilities by installing patches, with critical or high security patches installed within one month of release.
• 12.9.1 and 12.9.2 are service provider requirements: acknowledge in writing your responsibility for the account data you handle, and support customers' requests for compliance status and responsibility information.

Requirement 6.3.2 is, in effect, an SBOM requirement for the code you write, stated in PCI language. Requirement 6.3.3 gives you a hard number for the patch timeline question. Even where card data is out of scope, many banks borrow the one month figure for critical and high findings because it is a recognized benchmark.

The frameworks banks use to judge your evidence

Beyond regulation, three public documents shape what a good answer looks like.

NIST SP 800-218, the SSDF

NIST's Secure Software Development Framework, version 1.1, published in February 2022, is a set of high-level secure development practices meant to be added to any development life cycle. NIST says it also gives software purchasers and consumers a common vocabulary for talking to producers. That is exactly the bank to fintech relationship.

Three practices map cleanly onto a bank's open source questions:

• PS.3.2 calls for collecting, safeguarding, maintaining and sharing provenance data for all components of each software release, with an SBOM given as the example.
• PW.4.4 calls for verifying that acquired commercial, open source and other third-party components comply with the organization's requirements throughout their life cycles.
• RV.1.1 calls for gathering information about potential vulnerabilities in the software and the third-party components it uses, from acquirers, users and public sources.

If your bank asks "describe your secure development life cycle", a short table mapping your practices to SSDF IDs, with a pointer to the evidence for each, is a far better answer than a prose essay.

CISA's 2026 Minimum Elements for an SBOM

On July 29, 2026, CISA, the NSA, the FBI and international partners released the 2026 Minimum Elements for a Software Bill of Materials. CISA's announcement says the guidance builds on the NTIA minimum elements from 2021, adds new baseline fields including component hash, license, SBOM tool name and SBOM generation context, covers open source, AI and SaaS software, and stresses machine processable formats. Treat the 2021 NTIA list as history now. If a bank's questionnaire still cites it, answer with an SBOM that meets the 2026 baseline, which covers the older fields and more.

CISA KEV and FIRST EPSS

Two public data sets help you and your bank agree on what "urgent" means. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of exploitation in the wild. FIRST's Exploit Prediction Scoring System publishes, every day, a probability that a published CVE will be exploited in the next 30 days. Severity says how bad a flaw could be; KEV says attackers use it; EPSS estimates how likely that is soon. Report findings by all three.

What software supply chain evidence banks ask for

Put the sources together and a pattern appears. The table below lists the evidence items that come up most often, the source behind each, and what a strong answer looks like. It is a planning aid, not a checklist from any regulator.

Two notes on the items banks argue about most. First, an SBOM on its own is a list; the bank's real question is "are you exposed to anything that matters?" Pair each SBOM with a vulnerability status report from the same scan and state the data date. Second, where a scanner flags a CVE but your code never calls the vulnerable function, say so in a structured way: a VEX statement, or at minimum a documented exception with justification, beats silently leaving it off the report.

How to share an SBOM and vulnerability status with a bank without emailing files

Email attachments are the default and the worst option. They cannot be revoked, go stale the moment they are sent, get forwarded to people you never meant to reach, and leave no record of who opened what.

A better sharing model has six properties, whatever tool you use:

1. Access control by named person or by the bank's email domain.
2. Expiry by default, so each review starts with a fresh share and a conversation about what changed.
3. NDA or terms acceptance before first view, because component inventories are sensitive.
4. Versioned, immutable copies, so you can prove later exactly what the bank saw.
5. Access logging of views and downloads with timestamps and identities.
6. Revocation the moment the relationship ends or a link leaks.

Some banks require documents in their own vendor management portal. Then keep the master copy and access record on your side and upload a dated snapshot.

How often to refresh evidence, and what triggers an out-of-cycle update

The interagency guidance leaves frequency to risk, and so should you, but you need a written cadence the bank can hold you to. Here is a cadence built from the sources above. Adjust it to your contract.

Triggers for an out-of-cycle update are just as important. Agree these with the bank in writing:

• A CVE affecting a component you ship is added to CISA KEV. Tell the bank whether you are affected, what you are doing, and when it will be fixed. Do this even if the answer is "not reachable, here is why".
• A widely reported open source incident. Banks will ask within hours. Have a one-page "affected or not" answer template ready.
• A material change. A new product line, a re-platforming, an acquisition, or a new hosting region. The guidance lists strategic and operational changes, including use of subcontractors, as things to notify the bank about.
• A missed target. If a critical finding passes its deadline, tell the bank with a plan rather than letting it surface at the next review.
• An incident. Your breach notification clause governs here, along with any FTC notice duty under 314.4(j).

A method you can run with your own tools

None of this needs a specific product. Here is a sequence a small team can run.

1. List every product the bank relies on and map each to its repositories, services and container images.
2. Generate an SBOM per product from the build in SPDX or CycloneDX, with transitive dependencies, recording the tool name and generation context.
3. Match the inventory to vulnerability data, flag KEV entries, attach EPSS scores and record the data date.
4. Write remediation targets engineering leadership will sign, for example critical and high within one month and KEV listed findings faster.
5. Put a gate in CI that fails or warns on changes that break the targets, with exceptions routed to a named approver and an expiry date.
6. Map your process to the SSDF, one row per practice, each pointing at evidence.
7. Choose a sharing channel with the six properties above and agree it with the bank.
8. Calendar the cadence, write down the triggers and assign an owner for each.
9. Run one dry review with someone outside engineering reading the pack as the bank's analyst would.

How Safeguard does this job, step by step

Safeguard covers the software component part of the evidence pack: what open source you ship, what is wrong with it, what you decided, and how you shared it. The flow below follows Safeguard's docs. Labels are as of the review date at the end of this post.

1. Connect your code, or keep it on your own machine

In the app, the Integrations page connects source control (GitHub, GitLab, Bitbucket or a generic Git URL), container registries and file uploads such as package manifests and CSAF or VEX files. That is the usual route for SBOM generation and analysis (GA).

Some fintechs will not grant any outside service access to their repositories, and some sponsor banks prefer it that way. The local runner (GA), built into the Safeguard CLI (GA), runs scans on your own machine. Install and first run, exactly as the docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

safeguard

Then type /login in the interactive terminal, and start the runner with safeguard runner. For a headless setup the docs show:

# Start without the terminal UI and serve assistant turns for this workspace
safeguard runner start --workspace ./path/to/repo

# Is it running, and what is it doing
safeguard runner status

# Drain in-flight work and stop
safeguard runner stop

The docs say the runner opens only outbound HTTPS, runs the scan with its own local scan server, and uploads the result files (SBOM and findings). Source code stays on the machine. That sentence is often the one your bank's security reviewer wants in writing.

2. Generate an SBOM for each product

From the CLI, the generate SBOM docs show:

# Open the terminal, then type /login and /scan .
safeguard

# Or scan from the command line, writing results under ./output
safeguard scan --dir .

A scan from the signed in interactive terminal uploads the SBOM and findings to the platform. In the app, generation options include branch or tag, whether to include development dependencies, and a Deep Analysis option. SBOMs export in SPDX and CycloneDX. The docs say Safeguard runs daily continuous scanning of all projects, with extra triggers on push, on a schedule or on release, so the inventory stays current between bank reviews.

3. Rank vulnerabilities with KEV and EPSS

Software composition analysis and vulnerability management (GA) match the inventory against vulnerability data. The vulnerabilities docs list the data sources as the National Vulnerability Database, GitHub Security Advisories, OSV, CISA KEV, vendor security bulletins and security researcher disclosures. Each vulnerability record shows the CVE ID, CVSS score, EPSS score, whether it is actively exploited, the affected component and version, the fixed version and reachability status.

You can filter by severity, CVSS range, EPSS range, exploitable status, fix availability, reachability status and date range. That filter set is how you produce the bank's monthly view: open findings in production, split by KEV status, with EPSS and fix availability, as of a stated date. Reachability analysis and prioritization (GA) adds call path context; the docs mark some language support as Preview, so check coverage for your stack before quoting it to the bank.

4. Record decisions the way an examiner would want to read them

Two actions on a vulnerability create the decision record banks ask for. Accept Risk takes an expiration date and a business justification and goes for approval. Mark False Positive takes a justification and, where policy requires it, approval. Both leave a trail rather than a silent deletion, which is the difference between "we closed it" and "we can show why".

5. Enforce your remediation targets with policies and gates

Policies, gates and guardrails (GA) turn your written targets into controls. Per the docs, policies evaluate SBOMs and produce findings; gates are checkpoints that enforce policies in CI/CD. Policy conditions include vulnerability severity, CVSS score, EPSS score, license, component age, maintenance status and SLSA level, and there are templates such as "No Critical Vulnerabilities", "License Compliance" and "No Abandoned Packages".

Each policy's action decides what a failure does to the gate: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. The CI command in the docs is:

safeguard ci scan --wait --fail-on-gate <gate>

When a team needs an exception, the docs describe a request with the policy and finding, a business justification and an expiration date, sent to approvers, with the decision recorded in the audit trail. Compliance reporting then shows status by policy, exception history and violation trends. That report is the "secure development practice" and "exceptions" rows of your evidence table in one place.

6. Publish to Portal, then share with NDA, expiry and tracking

Portal (GA), here meaning the SBOM publish and share product rather than the free entry tier, is how the evidence reaches the bank. Publishing moves an SBOM from the scanning side into Portal and creates an immutable copy; sharing sends that copy onward as is. That distinction answers "which exact version did the bank receive?"

The sharing docs describe three methods:

1. Direct sharing to named recipients by email, with a permission level and an optional message.
2. Shareable links with an expiration date, download limit, password protection and format restrictions.
3. A customer portal with your branding and domain, where you assign SBOMs and invite the bank's users to register.

Permission levels are View (online only), Download, and Full (view, download and re-share). At the organization level you can require authentication for all shares, restrict sharing to approved domains, set default expiry and turn link sharing off. At the SBOM level you can require NDA acceptance and enable download notifications. Tracking shows who accessed which SBOMs, download history and link usage, and you can revoke a user or a link immediately. Bulk sharing sends several SBOMs at once.

7. Keep the access record

Portal's audit trails log SBOM activity (creation, import, changes, version changes), access activity (views, downloads, sharing events, link use, permission changes) and administrative activity. Each entry carries a timestamp in UTC, the actor, the action, the resource, the source IP, the client and the result. You can filter in the web interface and export to CSV, JSON or a formatted PDF, or send logs to a SIEM. The docs list default retention of two years for access logs and seven years for administrative and security events, configurable for enterprise customers. The audit trails page also mentions a REST API, which carries the docs banner that /v1 endpoints are not yet available, so use the web interface and exports.

8. Tie it into the rest of your compliance evidence

The compliance and GRC suite (GA) holds frameworks, controls, evidence, policies, questionnaires, risks and vendors in one place, with evidence connectors for major cloud, identity and ticketing tools and more on request. It lets you keep the supply chain evidence next to the rest of your control evidence, and your own vendor register for FTC 314.4(f) in the same system. Trust Center is early access; use Portal sharing for SBOMs today.

9. Close findings faster, under your control

Autonomous remediation (GA) can open fix pull requests for vulnerable dependencies, singly or in bulk. It ships switched off, with every category set to Manual, and the CLI asks before any command that changes something. A human approves every change, and the pull request history becomes part of your time to fix evidence.

What the bank's ask maps to

What the fintech still owns

Even with good tooling, a large part of the bank's request is yours alone.

• Your written information security program: under the FTC rule, the risk assessment, the Qualified Individual, the board report and the incident response plan.
• Incident response and notification: the contract's breach notice terms and any FTC notice under 314.4(j) need a process, a decision maker and a watched clock.
• The contract: report frequency, audit rights, notice periods and remediation terms are negotiated with the bank, and your counsel owns those words.
• Your own SOC or PCI reports, which the guidance lists among audit reports a bank may be entitled to receive. Your auditors produce them.
• Everything outside software components: access management, encryption, logging, personnel screening and business continuity.
• Judgment on risk: a tool can rank a finding, but only you can accept a risk and defend it to the bank.

What Safeguard does not do

• It does not make you compliant with the interagency guidance, the FTC Safeguards Rule, PCI DSS or any other rule, and it does not answer for your bank's examination. It produces evidence about software components that you and your bank can use.
• It has no SOC 2 report to hand to your bank. If your bank asks about your tooling vendors' audit reports, ask Safeguard directly for its current status and repeat only what Safeguard publishes.
• It covers software components, not your whole control set. Identity, network, endpoint, HR and physical controls need other evidence, even where the compliance suite stores it.
• It does not write your policies, risk assessment, board report or incident plan. It can hold and map them; you author and approve them.
• It does not interpret your partnership agreement. Questions about what the contract requires, and whether a regulation applies to you, belong with counsel.
• Trust Center and fork and patch are early access, and the desktop app is early access (beta). Do not promise a bank a capability that depends on them without checking current scope.
• The /v1 REST API is not yet available on several docs pages, including audit trails. Plan on the web interface, exports and the CLI.
• Reachability language support varies. Some languages are marked Preview in the docs. Confirm for your stack before you rely on reachability to justify an exception to the bank.

Common mistakes

Sending one SBOM at onboarding and never again. The bank's ongoing monitoring duty is continuous. A year old SBOM tells the examiner you stopped watching.

Listing direct dependencies only. Most of the code you ship arrives transitively. A shallow SBOM invites the follow up question you least want: "what else is in there?"

Reporting counts without dates. "Twelve open highs" means nothing without the data date and the age of each finding. Report first seen dates and time to fix.

Hiding exceptions. A finding you decided not to fix should appear with its justification, approver and expiry. Banks trust a documented exception more than a suspiciously clean report.

Emailing evidence. You lose version control, revocation and the access log in one click.

Answering "yes" without evidence. "Do you maintain a secure SDLC? Yes" forces a second round. Point to the SSDF mapping and the CI gate results.

Promising a patch window you cannot meet. If your release train cannot meet one month for critical and high findings today, say what you can meet and show the trend.

Forgetting your own vendors. The FTC rule asks you to oversee your service providers, and banks notice when a fintech asks for evidence it cannot itself produce.

FAQ

Does the 2023 interagency third-party guidance apply to fintechs?

It applies to banks, not directly to fintechs. But it tells banks to assess, contract with and monitor third parties, including fintech partners, so its expectations reach you through your bank. For more, see our post on whether the 2023 interagency guidance applies to fintechs.

Do sponsor banks require an SBOM from fintech partners?

No federal banking rule names an SBOM as a required document for fintech partners. But the interagency guidance asks banks to review a third party's technology inventories and development life cycle, and PCI DSS 6.3.2 requires a component inventory where card data is in scope. An SBOM is the most direct way to answer both. See what banking regulators expect on SBOMs.

Does the FTC Safeguards Rule apply to my fintech?

It applies to financial institutions within the FTC's jurisdiction under the Gramm-Leach-Bliley Act, which can include non-bank fintechs. Whether your company is covered is a legal question for counsel. Our post on GLBA Safeguards Rule requirements for vendor risk covers the service provider side.

How often should a fintech send vulnerability reports to its partner bank?

As often as the contract says, and the guidance leaves frequency to risk. Monthly or quarterly is common for higher risk relationships, with out-of-cycle updates when a known exploited vulnerability affects your components or a material change happens.

What patch timeline will a bank expect for critical vulnerabilities?

Many banks use PCI DSS 6.3.3's one month window for critical or high security patches as a benchmark, and expect faster action on vulnerabilities in CISA's KEV catalog. Your contract sets the binding number.

Can we give the bank evidence without giving anyone access to our source code?

Yes. Generate SBOMs and findings inside your own environment and share only the results. With Safeguard, the local runner scans on your machine and uploads only the SBOM and findings.

What contract clauses should a fintech expect from a sponsor bank on security?

The interagency guidance discusses report types and frequency, right to audit and remediation, timely breach disclosure, and regulatory examination access. Our post on contract clauses banks expect from software vendors goes deeper.

What should a fintech's answer to a bank vendor security questionnaire include on open source?

An SBOM per product, vulnerability status with KEV and EPSS, patch targets and actual time to fix, exceptions with approvers, license posture and an SSDF mapping. Our retail banking vendor questionnaire playbook shows the format banks use.

Closing the gaps your bank will ask about

Every finding your bank sees in the evidence pack is a question about how fast you can make it go away. The section below describes the routes Safeguard offers for closing the gap between a published fix, or no fix at all, and your production code.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. For a fintech whose bank prefers that no outside service holds repository access, this is the route that keeps source code on your hardware while the SBOM and findings reach the platform.

Click through it at your own pace, or open it full screen.

The second demo is a real session in the Safeguard desktop app (early access, beta). The CLI session appears in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with a dependency upgrade done and tests passing. For a bank relationship, the same flow works down KEV listed findings in a repository with an engineer approving every change, which gives you a clear record for your time to fix evidence.

Click through it at your own pace, or open it full screen.

To try it on your own code, download the app and CLI at https://safeguard.sh/download and read the setup guides at https://docs.safeguard.sh/docs .

Quick check

Sources

• Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 (Federal Register metadata)
• Interagency Guidance on Third-Party Relationships, full text (GovInfo)
• OCC Bulletin 2023-17: Third-Party Relationships, Interagency Guidance on Risk Management
• Federal Reserve SR 24-6: FFIEC IT Examination Handbook, Development, Acquisition, and Maintenance
• OCC Bulletin 2024-26: FFIEC Development, Acquisition, and Maintenance booklet
• FDIC FIL: Updated FFIEC IT Examination Handbook, Development, Acquisition, and Maintenance
• 16 CFR 314.4, Elements (GovInfo, Code of Federal Regulations)
• PCI SSC Document Library
• PCI DSS v4.0 SAQ D for Service Providers (PCI SSC)
• NIST SP 800-218, Secure Software Development Framework v1.1
• NIST SP 800-218 PDF
• CISA: Updated Minimum Elements for a Software Bill of Materials (announcement, 29 July 2026)
• CISA Known Exploited Vulnerabilities Catalog
• FIRST Exploit Prediction Scoring System
• Safeguard docs: Portal Sharing
• Safeguard docs: Portal Audit Trails
• Safeguard docs: Vulnerabilities
• Safeguard docs: Policies and Gates
• Safeguard docs: Generate SBOM
• Safeguard docs: Local Runner
• Safeguard Gold Open Source

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.