By Brian Fox, CTO, Sonatype
Do you know what’s inside the software your company uses? More importantly, does the C-Suite at your company?
If the 2022 State of Open Source in Financial Services report from FINOS was any indication, financial institutions should care about that question, especially because of the rampant spread of open source software across the sector. Open source is everywhere, not just in banking and finance, which has made it an attractive target for bad actors to carry out targeted cyberattacks against software supply chains. And in a sector with data this sensitive, that’s particularly concerning.
We saw a big wake-up call at the end of 2021 with the discovery of a critical vulnerability in the Java logging component log4j, impacting a ridiculous number of applications across many sectors. In just 72 hours, nearly 800,000 attacks were launched.
Now, to its credit, the financial sector responded a lot faster than others in the race to patch any and all software using this component. But log4j was one piece of software. And the real wake-up call, unfortunately, as the FINOS report itself points out, is that we’re going to see more exploits and vulnerabilities – whether it’s open source or not. We’re even starting to see a daisy chain-like tactic of software supply chains being exploited to trigger attacks on yet more software supply chains.
The data paints a stark picture – a 742% average annual increase in software supply chain attacks over the past three years. So that’s the gravity of the situation out of the way and should tell financial institutions it’s high time to carefully monitor the make-up of their software.
What can be done
Unfortunately, a lot of organisations generally speaking are shockingly unaware of what that software composition looks like, which makes it tricky to track down vulnerabilities old and new.
If we return to log4j for a moment, despite that we’re a year and a half out from that critical vulnerability’s discovery, development teams are still downloading the compromised version 30-40% of the time (https://www.sonatype.com/resources/log4j-vulnerability-resource-center) . More broadly, 96% of the time someone downloads an open source component, there’s a safer and more up-to-date alternative they could have downloaded instead. On a granular level, there are some objectively bad decisions being made here: for example, the latest version of a software component isn’t always the best version. Software upgrades should happen consistently but also only when necessary.
This isn’t necessarily born of neglect – many developer teams at financial institutions I’ve worked with around the world – many of which are massive in size – are inundated with having to manually audit all their open source components in the software they’re developing. And these are often spread across very disparate environments. Time is money, and when you only have so much time to spend on security audits, you can see where the issues arise.
The rub is that without better visibility, the potential damage in monetary and reputational terms could be catastrophic. A DDoS or ransomware attack would cost dearly, with IBM estimating that data breaches cost UK enterprises $3.88 million per incident on average. This doesn’t even account for the ripple effects of further financial losses incurred from losing customers or getting sued.
How organisations can approach bolstering their open source security
Sounds like we’re stuck between a rock and a hard place, right? Not necessarily…
Breaking down the silos that commonly exist between teams in banking and finance will be essential to nurturing the collaboration needed to standardise and formalise policies across different departments for implementing and upgrading software. Some financial institutions have made encouraging pledges to the Open Source Security Foundation to expand knowledge sharing surrounding open source. But generally speaking, the sector still needs a more universal approach to open source adoption and security.
One solution everyone in the industry has to get behind as a starting point for software visibility is implementing Software Bill of Materials (SBOM). Similar to a bill of materials issued by a car manufacturer, an SBOM shows you all the parts – in this case, open source components – that make up the whole software. Using these could help IT professionals speed up their response times to finding vulnerabilities.
I say ‘in theory’ because an SBOM doesn’t tell you where an ingredient came from, and whether that place was poisoned in the first place. And there’s also the issue of human error. Some level of automation will inevitably become more and more important – whether it’s through AI, dependency firewalls, and other tools for software composition analysis that reduce the security workload pressures on IT teams so they can focus on innovation instead. There are lots of different options on the market, in addition lots of free guidance from the likes of the Linux Foundation and OpenSSF on how to make effective use of them.
Proactively, rather than reactively, maintaining software supply chains means the sector will ultimately become safer, saving people and institutions time and money. There will be road bumps as teams initially struggle to adopt SBOMs and other tools, but the sooner this happens, the more likely it is that organisations will evade a nasty security incident that costs them and their customers a lot of money.
Can the UK government help here? It can probably do more than it realises, though we’re seeing signs they’re waking up to this fact judging from its recent call for views on software resilience for businesses. Currently, there’s simply not enough comprehensive regulation and guidance. Any regulation or legislation that does get implemented should, if anything, be as prescriptive as GDPR.
To improve open source security posture, and software hygiene more generally, we need extremely clear, uniform guidance across their board. greatly boost software hygiene. One thing’s clear. Open source is here to stay, and as more industries enjoy its innumerable benefits, they will inevitably have to grapple with the explosive rise in increasingly complex and severe software supply chain attacks. Methodical proactiveness is the key here to staying on top of the pesky incidents that lie ahead.
