Poly Network Hack: Managing Open Source Vulnerabilities

Poly Network

On 10th August 2021, Poly Network, a cryptocurrency platform that was built to improve the interoperability between different chains, lost 610 million USD to an exploited vulnerability in the digital contracts that the Poly Network leverages on.

The Poly Network has open sourced its codes, allowing for enthusiasts and professionals alike to build on top of their ecosystem. This would also mean that any vulnerabilities found within the codes could be exploited by potential hackers.

This is one of the largest breach in the history of cryptocurrency, and possibly one of the largest breaches within the financial space in terms of stolen amount. Yet the Poly Network attack is neither new, nor comes as a surprise to people who are well-versed with open source vulnerabilities and attacks on open source. The infamous Equifax breach, Panama Papers data leak and Heartbleed bug incidents are also consequences of vulnerabilities in open source libraries being exploited by hackers.

A one-off incident?

While the Poly Network breach has focused the spotlight on security vulnerabilities within the cryptocurrency and blockchain space, the breach is indicative of a larger problem within the financial services industry.

Although digital transformation has happened in the financial services industry for the past decade, the rate of transformation has increased at an exponential rate over the past few years. The increasing acceptance and adoption of open source languages and frameworks has greatly accelerated workflows for development teams.

These open source languages and frameworks are available for everyone to see – developers and hackers alike. This gives rise to a robust ecosystem where vulnerabilities are constantly reported and patched in newer versions of these libraries. In fact, there are about 12,000 open source releases per day.

Financial Services and Open Source

As companies within the financial services industry look to provide increasingly personalised services, applications have turned into a battleground for competing companies to prove their edge over one another. To create the best applications, developers work with increasingly restrictive constraints to push more functionalities than ever. In order to meet the increasing business demands, developers use more open source in their application development than ever – it is estimated that 97% of all enterprise applications contain open source, where open source codes make up 60 – 90% of the lines of code when compiled.

The amount of open source codes within an application is mind boggling to developers, as it highlights to them that there are simply so much more codes that they do not see. In fact, the average enterprise application contains around 250+ open source dependencies, and that number is estimated to increase over the years.

Managing Open Source Vulnerabilities

As we’ve seen from the Poly Network incident, open source libraries contain vulnerabilities that can be exploited by hackers. These open source libraries and vulnerabilities can be managed effectively and efficiently with a Software Composition Analysis (SCA) tool.

In the absence of an SCA tool, the organisation needs to appoint an application manager to track all the dependencies (and their versions) that are being used by developers in the development of an application – that includes the root libraries and all transitive libraries that are being called. Once the libraries are identified, the next step is to scour the internet for vulnerability information about these library versions. If the libraries contain vulnerabilities that can be found on the National Vulnerability Database (NVD), repository commits, change logs, or bug trackers, then the application manager would need to find the correct version fixes for these vulnerabilities.

Fixing these libraries manually will introduce two problems – firstly the updated version may contain vulnerabilities of its own, and its transitive dependencies may contain new vulnerabilities. Secondly, if the vulnerable library to be fixed is itself a transitive one, then the developers do not actually know which version of the root library they should patch to, to eliminate this vulnerability brought about by a transitive dependency.

A good Software Composition Analysis tool will be able to help your development teams solve these problems effectively. A good SCA tool can also efficiently integrate with your Source Code Management tools and CI/CD pipelines to increase the level of automation when finding vulnerabilities.

The SCA tool will also have a database that tracks popular libraries across different open source languages to identify which versions contain vulnerabilities and which do not. A bonus feature of a good SCA tool would be a strong compatibility analysis engine that can help developers prioritise their remediation efforts.

Find out how Scantist can help you manage your open source components according to your organisation's needs.