How unknown software vulnerabilities may lead to financial fraud?

By Martin Callinan, Founder, Source Code Control

According to a Forrester Research report, modern software includes up to 80% third-party components and libraries, mostly open source licensed. Very few software companies track what components their developers are using and related information such as version numbers, potentially allowing vulnerable code to enter the supply chain during software development which may be exploited by bad actors when the solution is delivered to customers.

For both consumers and providers of financial services, keeping pace with the ever-changing technology landscape had never been as challenging as today. With the rise of financial services technology (fintech) solutions, the consumer does not need to visit a bank branch to avail of these services every time. Similarly, financial institutions no longer need to set up a wide network of physical outlets to provide these services. Consumers can now access their account details and carry out transactions with just a few clicks of the mouse or taps on the smartphone. From internet banking to mobile banking, digital wallets, UPI and payment gateways, technology solutions have made the delivery of financial services considerably easy.

But this increased convenience does not come without its share of threats and risks.

To understand this better, we need to look at how the software that enable these services are developed. All software development today, including those for fintech services, involves the use of third-party components, libraries and frameworks. These are typically open source software licensed. Very few software companies keep a track of version numbers of these third-party components, which they use for development of software and applications. Because of this lack of tracking if there are vulnerabilities they will enter the supply chain resulting in end customers using software that potentially could put them at risk and expose the organization supply the technology to legal and reputational damage.

Take for example the Equifax breach of 2017 which exposed the personal information of at least 147 million Americans and had a financial impact of over $4 billion. This was caused by hackers who exploited two out-of-date libraries in Apache Struts, a popular open source web framework. Graeme Payne, the company’s senior vice-president and CIO for global corporate platforms, later said: “…at the time that the breach was announced, I wasn’t even aware that we were running Apache Struts in the particular environment”.

Supply chain attacks like Kaseya and SolarWinds can be created by adding malicious code to components used by developers. These codes could then enter the code base for later exploitation. As recently as July 2021 a modified library on popular code sharing site NPM was found to include malicious software which steal’s users’ save passwords from browsers.

The scale of the problem, its impact and safeguards
Because of the increase in breaches caused by lack of management of third party libraries, government and industry bodies around the world are creating regulations to force software companies adopt secure software development frameworks. For example, in the finance sector the Payment Card Industry (PCI) has introduced the PCI Secure Software Lifecycle (SLC) Standard and Program, providing “a baseline of security requirements with corresponding assessment procedures and guidance to help software vendors design, develop, and maintain secure software throughout the software lifecycle”. These standards mandate tracking of open source software components for vulnerabilities and have a strategy for remediating. Any software vendor that has to be PCI-compliant has to adhere to this standard.

It requires software companies to manage the use of components and libraries in their development to build trust among customers. It says, among other things: “The organisation shall ensure that the program participants are aware of the open source policy; relevant open source objectives; their contribution to the effectiveness of the program; and the implications of not following the program’s requirements.”

The US White House recently issued an executive order on ‘Improving the Nation’s Cybersecurity’ which states that all software should include a software bill of materials (SBOM). Akin to the list of ingredients we see on food packaging, the SBOM is an inventory of all third-party components that have been used in a software solution.

Who needs to do what?

Software companies:
Organisations developing software solutions should implement secure software development lifecycle management which includes tracking of all third-party components used. This will help protect against vulnerable components and libraries with known vulnerabilities entering the software development supply chain.

Financial institutions: Banks and other financial institutions buying software solutions or commissioning a third party organisation to develop solutions on their behalf should include measurements and benchmarks to ensure the software developed is safe and secure, thereby protecting their customers. Service Levels should be mandated for the remediation of vulnerable code.

Software vulnerabilitiesSource Code Control
Comments (0)
Add Comment