How financial institutions can improve software supply chain security without impacting their business-critical systems

Every security leader at a bank, insurer, or asset manager has had a version of this conversation: Security wants to eliminate a class of vulnerabilities. Engineering explains what it would take to upgrade the platform where they live. Somebody prices out the regression testing. Somebody else raises the change-freeze calendar. The finding gets an exception, a compensating control, and a date eighteen months out on the roadmap to address it.

Nobody in that conversation is being unreasonable. Financial services carry more legacy software than almost any other industry for a few reasons: decades of accumulated infrastructure, regulatory obligations that reward stability, and applications where an hour of downtime is unacceptable. In that environment, minimizing change is risk management. Every dependency bump, every base image swap, every migration is a chance to break something that clears trades or moves money.

So the instinct to stick to the status quo has been sound. The problem is that the instinct is now being applied to the wrong problem.

Having a vulnerability backlog is no longer “fine”

For years, accepting a backlog of known vulnerabilities has been a common tradeoff financial services organizations made for stability. The vulnerabilities were known but dormant. Plus, exploitation required skill, time, cost, and incentive. The chance that any given Common Vulnerability and Exposure (CVE) in a legacy application would be weaponized against you before your next planned upgrade was low enough to simply acknowledge and move on.

Frontier models have changed this calculus drastically. Systems like Mythos can read code, find dormant weaknesses, and chain them together faster than humans can investigate and patch. The gap between “publicly known” and “practically exploitable” vulnerabilities is collapsing, and it is collapsing exactly where financial institutions have been carrying deferred risk: the software supply chain.

For the first time on record, vulnerability exploitation has overtaken phishing as the leading initial access vector for breaches in financial services. Additionally, more than half of financial services vendors carry at least one high-severity CVE. For a regulated institution, a compromised package means an operational event, a regulatory conversation, and a customer trust problem.

What this means practically: the backlog was never static, but the assumptions used to justify carrying it were. An exception signed off 18 months ago rests on an outdated threat model.

The difference between applications and the software supply chain

When a security team says “we need to modernize,” engineering leaders hear application modernization: refactor the monolith, upgrade the runtime, migrate the data layer, retest everything downstream. That is a multi-year, multi-team, capital-intensive program with real operational risk. Engineering leaders often resist this type of change — and are probably justified in doing so.

But the risk that frontier models introduce does not lie primarily in application code. It lives in the software supply chain underneath it: base images with many vulnerabilities, open source libraries pulled from public registries with no provenance, and build tooling that has never been properly inventoried. The input to the application has become exposed.

And inputs can be changed without rewriting what consumes them.

Updating those inputs is the more prudent “modernization” that many financial services organizations are reckoning with. Modernizing your software supply chain doesn’t require the same level of investment as modernizing your applications. You can change what you build from long before you change what you build.

What that looks like without a migration

Chainguard’s approach is built on securing what you build from. Hardened, minimal container images and open source libraries are continuously rebuilt so that avoidable vulnerabilities never enter the environment in the first place. Fewer components mean there’s less to scan, less to triage, and less attack surface by construction rather than by remediation.

For software that isn’t ready to be upgraded yet, Chainguard backports security fixes into the versions institutions are running today. A team on an older language runtime or framework version gets patched and trusted artifacts for that version. Compatibility is preserved, and the migration plan stays on its own schedule. 

Either way, teams using older versions reduce their exposure to vulnerabilities.

For platform teams, the operational change is smaller than expected. Most large financial institutions already run an internal golden image program to standardize the foundation for hundreds of application teams. Maintaining those images is slow and expensive. 

But when platform teams replace the upstream source of those images, they’re mirroring hardened artifacts once and distributing them as approved building blocks through the registries and pipelines teams already use. As a result, vulnerability management shifts from every application team independently researching and rebuilding base images to one platform team maintaining a trusted set. Application teams inherit the fix rather than doing the work themselves.

What’s more, every artifact includes signed Software Bills of Materials (SBOMs) and verifiable provenance, enabling teams to answer common audit questions such as “What is running?” “Where did it come from?” or “How is it maintained?” Answering these questions lets platform and security teams get back to building and maintaining their core business for their customers.

The hidden costs of not modernizing

Reframing modernization to the software supply chain is important because “maintaining the status quo” has never been the zero-risk option. It has just been the option with costs distributed widely enough to stay off the risk register.

Engineering capacity consumed by repetitive CVE triage instead of roadmap work is a real cost. Running emergency response cycles every time a new campaign targets a widely used package takes up an enormous amount of time and bandwidth. Audit findings that get harder to close each cycle cause fatigue and slow down your organization. And the entire modernization effort can grind to a halt if your team is too busy patching to actually implement new systems. All of this delayed progress means your engineering team isn’t focusing on what it exists to do: build features that generate revenue.

Set against these costs, adopting a secure software foundation is a comparatively small, reversible, well-scoped change. It touches the build, not the business logic. It can start with one platform team and a handful of images. Platform teams can improve the software foundation centrally and roll those trusted artifacts out through the registries and pipelines that other teams already use.

The timeline stays yours

The most important thing to understand about modernization for financial services organizations is that you see security benefits along the way, not just when the effort is “done.” You can massively improve security while still moving safely in your overall modernization effort by starting with the software supply chain. Over time, as more of the estate is built on trusted defaults, your overall security posture shifts from continuously reacting to vulnerabilities to not inheriting most of them in the first place. That is what secure-by-default means in practice.

Discover more about how Chainguard can help you secure your financial services organization’s software supply chain today.