Open source security is critical for financial institutions

Open source is everywhere. Over 90% of organisations in the UK use open source components in their software, including the financial sector. FINOS’ 2022 State of Open Source in Financial Services report made it clear in particular just how rapidly open source software is proliferating in the sector. However, recent cyberattacks demonstrate the risk these companies run of losing billions of pounds if they don’t manage their software supply chains.

In December 2021, a critical vulnerability was discovered in the Java logging component Log4j, present in a plethora of applications across every sector. It sparked a scramble to patch any software using the component following 800,000 attacks in just 72 hours across nearly every sector.

Thankfully, the financial sector was quick to act, but the door is still open for bad actors to find and exploit other vulnerabilities. The FINOS report itself states that more work needs to be done to secure open source software. This becomes even more apparent when you look at data showing a 742% average yearly rise in software supply chain attacks over each of the past three years. It’s never been more important for the financial sector to be diligent about its software composition.

The lurking danger of poor visibility

To illustrate why FINOS’ recommendation should not be taken lightly, organisations cross-industry have typically displayed shockingly poor software hygiene. Case in point, to this day, 30-40% of Log4j downloads are of the unpatched version. And more widely, roughly 96% of the time an open source component gets downloaded, there’s a newer, safer version available. This is happening because consumers of open source components are making bad decisions about when they should update their software, and which versions they should update to (spoiler: the latest version isn’t always the best).

If banks and financial institutions don’t gain better visibility of the components they’re downloading, the potential damage from a breach via a ransomware or DDoS attack could be catastrophic. The implications would be felt worldwide, and the costs eye watering. According to IBM, data breaches cost UK enterprises an average of $3.88 million per breach–not to mention the potential lawsuits, loss of customers and their data, and damage to brand reputation.

I’ve worked with institutions in the sector that operate globally across time zones, whose developer teams are saddled with conducting manual security evaluations of all open source components in the software they’re developing, across different development environments. The size of these institutions also increases the pressure for results - time is money, so the risk of oversight is even greater.

So what does the financial sector need to do in the face of potential breaches?

How organisations can proactively shore up open source security

The first and perhaps most crucial step in shoring up open source security is gaining visibility, but cultural differences and team silos often obstruct this.

For better software resiliency, financial organisations must overcome this siloed culture that often makes it difficult to standardise and formalise policies across different departments for adopting software. Granted, there have been some encouraging pledges and new memberships from financial institutions within the Open Source Security Foundation (OpenSSF) to foster cross-industry collaboration and understanding surrounding open source. But the finance industry still lacks a unified approach to open source adoption and security.

While we should encourage more cross-industry collaboration through partnerships with foundations such as the OpenSSF, finance organisations also need to turn to some humble yet effective solutions for software visibility, such as Software Bill of Materials (SBOMs). Similar to a bill of materials for a car, an SBOM provides a complete record of all the open source components in a piece of software, and it can be used by IT professionals to help mitigate attacks and reduce the time it takes to remediate flaws.

Keeping software up-to-date must also be mandatory, not optional. Across the industry, only 25% of components are actively updated when observing commercial engineering teams. On a micro-level, 69% of all upgrade decisions are suboptimal. It’s generally best to upgrade when necessary on a proactive, consistent basis before there’s a problem, instead of a reactive basis involving unplanned work triggered by a published security concern like Log4j. It’s safer, saves cost and time, and helps developers focus on creative software development, improving morale and value.

To be clear, this is just the start. While an SBOM is certainly helpful, it’s no silver bullet. An ingredient list doesn’t do much good if you don’t know where the ingredients came from, or if it’s been tainted. The use of AI, dependency firewalls, and other tools for software composition analysis, will enable IT teams who might be struggling under the workload of maintaining software security. These tools will allow teams to stay agile, flag potential vulnerabilities and plug any liabilities in software that may have been missed through human error - and guidance for these tools exists for free from the Linux Foundation and OpenSSF.

It’s worth noting the government has a role to play here as well, and the UK government has shown promise here with its recent call for views on software resilience for businesses. If nothing else, as it looks towards additional measures to regulate the finance sector’s critical third parties, it should ensure that any guidance or regulation it’s putting out surrounding open source software is extremely clear and similar in prescriptiveness to GDPR. 

Until significant emphasis is put on improving open source practices at a national level, the government is unlikely to deliver on its objectives to improve cyber resilience. This will not only benefit the financial sector, but every sector affected by open source vulnerabilities. Mandating the use of SBOMs would go a long way towards improving software hygiene.

One thing’s clear. Open source adoption isn’t slowing down across banks and financial services, and 2023 will likely introduce new supply chain attacks. As the sector continues to take advantage of open source’s many benefits, organisations must manage software supply chains in a thoughtful, architected way so they can react swiftly and methodically when a new incident does occur.