Vijendra Katiyar, Co-Founder and Chief Revenue Officer, CleanStart
Fintech businesses build and operate products across payments, lending, wealth management, insurance, financial infrastructure and embedded finance. Despite their differences, they share a common dependency: software assembled from components developed and maintained across a global ecosystem. Open-source libraries, container images and third-party components often become part of critical applications without being developed or directly assessed by the organizations deploying them.
Yet these components can execute within systems responsible for financial transactions, sensitive data, risk decisions and essential business operations.
This creates a gap in technology risk management. Fintechs may have established processes for securing applications and assessing commercial vendors, but the software components underpinning those applications often receive less scrutiny. Software supply chain security must therefore be treated as an enterprise risk, not just an engineering concern.
How Software Supply Chain Risks Enter Fintech
Whenever a developer adds a library, an AI coding assistant introduces a dependency, or an engineer selects a base image, external software enters the application or platform. These decisions often happen at release speed, without direct risk-team involvement. The selected components may already contain known vulnerabilities or, in some cases, malicious functionality.
A scan of the official Redis 8.10.0 container image, conducted on August 21, 2026 using the open-source scanner Trivy (v0.74.0), found 185 known CVEs, including four critical and 47 high-severity findings. This illustrates how vulnerabilities in a widely used base image can become inherited exposure for applications built on it. In September 2025, the self-propagating Shai-Hulud worm compromised npm publishing credentials and spread malicious package versions through affected maintainers.
The campaign returned in a larger wave in November 2025. Unit 42 reported that Shai-Hulud 2.0 had produced more than 25,000 malicious GitHub repositories across approximately 350 unique users. Both waves showed how compromised publishing credentials can expose downstream users to malicious code, even when they are not the intended targets.
These examples highlight two distinct risks: vulnerabilities inherited from existing software, and malicious code introduced through trusted distribution channels. Both require controls before a vulnerability report or security incident forces a response.
Why the Current Model Leaves a Gap
Open-source risk is often treated as an engineering responsibility, managed through vulnerability scanning and patching. These controls are essential, but they typically identify problems after software has been selected, built or deployed. Vendor risk management has a separate blind spot. It assesses companies through security reviews, contracts and audit rights, but open-source libraries have no contractual relationship and may never enter that process. Their risks can remain outside enterprise risk teams’ view until a vulnerability or incident draws attention to them.
The answer is not to move responsibility away from engineering, but to connect technical controls with enterprise risk management. Risk owners need visibility into the components underpinning critical services and accountability for the risks they introduce.
Govern Components Like Third Parties
Risk teams apply three fundamental controls to third parties: maintain an inventory, assess them before onboarding, and limit unnecessary dependence. The same principles apply to software components.
Visibility: Know Every Component
A software bill of materials (SBOM) records the components present in an application or image, providing a foundation for vulnerability assessment, dependency tracking and incident response.
Regulatory expectations vary by jurisdiction and entity. In India, SEBI’s Cybersecurity and Cyber Resilience Framework includes SBOM requirements for software supporting core and critical business operations of entities within its scope. CERT-In has also published technical guidelines covering SBOMs and related software and hardware bills of materials. In the EU, DORA requires in-scope financial entities to maintain registers of their contractual arrangements with ICT third-party service providers. Though these obligations differ, they reinforce the need to understand software dependencies and manage technology risks.
Visibility must also extend to the container estate as it runs today: which images are deployed, where they run and their current vulnerability status. Teams need to prioritize findings and identify a clear remediation path, whether that means applying a fix, updating an image or replacing it with a more secure alternative.
Verification: Check Before Entry
Organizations need to verify a component’s publisher, provenance and integrity: who released it, how it was built and whether its contents match the expected artifact. These checks should happen at the point of selection, before a dependency enters the application, whether the request comes from a developer, an AI coding agent or a CI pipeline.
Moving verification to the earliest practical stage of development, an extension of the familiar “shift left” principle, means downstream security controls build on better-informed decisions.
Minimization: Reduce Unnecessary Exposure
Every component adds to the maintenance and security burden. Minimal or hardened container images strip out unnecessary shells, package managers and utilities, reducing the number of components that need to be assessed and governed. Strong software foundations combine minimal contents with builds that can be reproduced and verified. Building from source, rebuilding regularly as security fixes become available, and retaining provenance and integrity evidence can help organizations reduce unnecessary exposure and improve auditability.
Minimal images do not replace runtime protection or ongoing vulnerability management. They reduce inherited exposure and provide a more controlled foundation for applications.
Make the Compliant Path the Fast Path
Fintechs compete by shipping quickly. A security review that requires a meeting for every dependency or image becomes a queue, encouraging engineers under release pressure to work around the process.
Embedding checks into existing workflows can strengthen security without adding unnecessary approval steps. Automated dependency checks at installation, verified images in internal registries and automatically generated SBOMs help teams make better-informed choices while maintaining release speed, especially when policies are clear and approved options are readily available.
Build on Foundations You Can Verify
Customers judge fintechs by the experience they deliver. Regulators, partners and boards also need evidence of what that experience is built on. Trust depends on understanding the software foundations behind critical financial services and the risks they carry.
Software supply chain security belongs at the center of fintech risk management. Organizations need to know which software components underpin their products and platforms, verify their integrity, and govern the risks they introduce.
For fintech businesses, resilience depends not only on the services they build, but also on the software foundations they can account for, verify and maintain.
