By Tim Mackey
Fundamentally, there are four types of open source risk: licence conflicts, unpatched vulnerabilities, origin issues, and obsolete or unmaintained code. Many organizations don’t realise just how pervasive open source is within the software used throughout the enterprise.
Traditional risk identification processes, like penetration testing, don’t account for all possible risks in open source. For example, open source licence conflicts won’t lead to a cyber incident but do need to be addressed from a legal perspective. Unpatched vulnerabilities can obviously be exploited under the proper conditions, but a hidden threat is obsolete code. Unlike commercial software vendors where a vendor risk assessment identifies product support issues, with open source code the developers could simply stop writing it. Code obsolescence in an open source context implies that any issues in the code won’t be resolved by the original authors, regardless of whether there are funds to do so. Addressing these types of risk is part of the process to map out all people, processes, technology, facilities, and information supporting essential services. This means knowing what’s in your code, where it came from, who authored it, and whether they are still maintaining it.
Security and operational risks from outdated components
Security vulnerabilities often go hand in hand with unmanaged open source usage. The 2025 Open Source Security and Risk Analysis (OSSRA) report revealed that 86% of audited applications contained open source vulnerabilities and 81% contained at least one high-risk or critical vulnerability. Many of these flaws trace back to foundational and systematically important components, often with no active support.
For example, outdated versions of jQuery were implicated in 8 of the top 10 high-risk vulnerabilities identified, but few developers in 2025 are actively selecting jQuery for their applications. Instead, developers might select npm or React, which, being based on JavaScript, can include jQuery as a transitive dependency. It’s common for applications to include a mix of libraries for encryption, data processing, and web interfaces. If those libraries aren’t kept up to date, known exploits can creep in. The notorious Log4j (Log4Shell) incident in 2021 is one such example and served as a wake-up call: a single open source logging library vulnerability forced financial institutions worldwide to scramble for patches. It underscored how a single transitive dependency deep in the tech stack can create an urgent operational crisis.
Equally concerning is the prevalence of outdated or obsolete open source components. A striking 91% of codebases reviewed for the OSSRA report contained outdated open source and 90% had components that were more than 10 versions behind the current release. This ‘zombie code’ problem means many applications are built on foundations that haven’t seen updates or active maintenance in years. Even when a component is still supported, outdated component versions may lack patches for known vulnerabilities and can also suffer from stability issues that are addressed in newer versions.
For a fintech firm handling payments or sensitive customer data, running an outdated library (say, for cryptography or authentication) is an operational resilience risk: the application could fail or be compromised at the worst possible time. Regulators, such as the UK’s FCA and PRA, have stressed that the remediation of vulnerabilities should be prioritised and unpatched or obsolete open source components are prime examples of items impacting resilience. The longer unpatched code lingers, the greater the chance of an incident that could knock an important service offline, breach data, or invite regulatory scrutiny.
UK fintech: navigating regulatory expectations and Open Banking pressures
The fintech sector in the UK sits at the intersection of innovation and regulation. Initiatives such as the Payment Services Directive (PSD2) and Open Banking have accelerated the creation of new apps and services by encouraging data sharing and API integrations. Open Banking, for instance, led UK banks to expose APIs that fintech startups eagerly plug into, often using open source libraries and tools to reach their market quickly.
But with increased connectivity comes greater responsibility. Operational resilience is a key mantra of regulators: the FCA’s policy statements (such as PS21/3) and directives like the EU Digital Operational Resilience Act (DORA) are pushing firms to rigorously manage their ICT supply chains and internal software development practices. That implicitly includes open source components. A security flaw in an open source component could result in service downtime or data loss and the use of an obsolete or unsupported open source component could present an opportunity for malicious activities. Both might put a firm in breach of regulations for customer protection or data privacy.
In the financial services context, strong governance over open source isn’t just best practice, it’s a market expectation. Major banks and financial institutions conducting due diligence on fintech partners (or acquisition targets) will probe for open source risks. For an acquisition target, open source licence conflicts could directly impact the valuation they might receive. As the OSSRA report notes, knowing what open source is in your codebase is crucial for managing licence compliance and staying on top of patches. No bank wants to buy or integrate with a fintech whose software development processes don’t properly account for the risks associated with poor open source governance. In a merger or acquisition, undisclosed open source issues can even derail deals at the last minute, as legal teams discover conflicts that require expensive fixes.
Mitigating the open source risk from policy to practice
CTOs, CISOs, and compliance officers can take concrete steps to turn the open source dilemma into a strategic advantage. It starts with visibility and ends with continuous governance. Addressing the open source risk includes:
Adopt software composition analysis (SCA) tools
Automation is your friend. SCA tools scan the software your teams create, the software they include in your applications and services, and any tools or software you procure. SCA solutions identify all open source components, including deep transitive dependencies. They flag known unpatched vulnerabilities, component health, and highlight licence information for each component. By integrating SCA into your CI/CD pipelines, you’ll identify components that might introduce a security flaw or licence conflict.
Implement open source governance and policies
An internal policy should define what open source licences are acceptable in your applications and which are not. For example, many banks restrict reciprocal licences in their customer-facing code. Set up approval processes so that, before adopting a new open source component, it is vetted for security and licence compliance. This might involve establishing an Open Source Program Office (OSPO) or assigning responsibility to a compliance role that reviews third-party code usage. Training developers is key here – developers should be aware of licence obligations (e.g., attribution requirements and when to publish source code) and know how to check for them. Culture matters, too. Encourage teams to treat open source with the same rigour as proprietary code. After all, if you wouldn’t outsource a critical system to an unknown vendor without due diligence, you shouldn’t import unknown open source code without proper scrutiny.
Keep a tight rein on updates (patch, patch, patch)
Most open source vulnerabilities have patches available by the time the vulnerability is publicly disclosed. The organizations that weather incidents best are those that can quickly update or replace vulnerable components. Make routine patching of open source dependencies part of your maintenance cycle. Select an SCA tool that proactively monitors for new vulnerability disclosures – known as CVEs – rather than relying only on a continuous scanning model. Define an obsolescence policy to avoid running software that is obsolete or unsupported – a scenario alarmingly present in 90% of audited codebases. By allocating time for dependency management, you reduce the impact of patching or triggering a costly regulatory incident. Operational resilience isn’t just about infrastructure and backups; it’s about having software that won’t crumble due to neglect.
Embrace SBOMs and transparency
Modern SCA solutions can generate a comprehensive Software Bill of Materials (SBOM), essentially an inventory of your software components and their licences. This SBOM is increasingly becoming a contractual requirement in deals and partnerships; and for good reason. It provides transparency into your software supply chain. Be prepared to share generated SBOMs with your clients or regulators if requested – having the SBOM demonstrates due diligence in managing open source risks. Request SBOMs from your direct suppliers of commercial software. In the event of a new widespread vulnerability (think Log4j), a supplier’s SBOM lets you instantly answer the question “Are we affected?”.
Embracing open source, responsibly
In many sectors, fintech in particular, the future is undeniably enabled by open source – from the algorithms powering fraud detection to the frameworks enabling Open Banking APIs. The agility and innovation benefits are too compelling to forgo. However, as the OSSRA data shows, unmanaged open source use introduces multiple risks. With 66% of fintech codebases subject to potential open source licence conflicts and the majority harbouring security vulnerabilities, the industry must take action. The good news is that addressing this open source dilemma is achievable using the right tools and practices.
Organizations should view open source risk management as a core part of their software development life cycle, not an afterthought. By leveraging SCA tools, maintaining SBOMs, enforcing clear open source policies, and staying vigilant with component updates, CTOs and CISOs can transform open source from a source of uncertainty into a well-governed asset.
For fintechs, the FCA and other regulators are watching for operational resilience. Demonstrating control over the software supply chain is a key regulatory element that also enhances credibility with customers and partners.
Conclusion
The good news is that addressing open source risks is a manageable process. Start by auditing your codebase for open source components and reviewing the associated licences. Next, integrate an SCA solution capable of continuously monitoring for new vulnerabilities in open source components. Insist on SBOMs from critical software suppliers and be prepared to provide SBOMs to your key partners. Finally, create a governance model for your open source usage that minimises risk while embracing the positives open source brings to innovation. With these steps, organizations can continue to leverage the power of open source innovation without the compliance challenges and security surprises.
The author
Tim Mackey is head of software supply chain risk strategy, Black Duck
