We put a lot of trust in others for the sake of convenience. You might, for example, eat in a restaurant or order takeout because it saves you having to cook, and from needing to cultivate the expert skills to prepare a certain delicious meal. Alternatively, you may cook at home, but buy your produce from the local supermarket, meaning that you do not need to grow or otherwise produce it yourself. At every level, you’re gaining convenience, but also making yourself vulnerable by placing your trust in a third party.
Software is no different. Many coders and software engineers will rely on open-source libraries and third-party code to augment their software instead of writing everything from scratch. If a third-party library is freely available to use, it means that developers can save time by using it instead of building their own version to offer the functionality that library might provide. Rather, they can spend more time building and testing the original functions of a particular app. Because not every coder is a master of every area or discipline they might encounter, third-party options let them incorporate code that works instead of having to figure it out for themselves.
However, third-party code isn’t some magic cure-all. It comes with tradeoffs that can, in some cases, cause more trouble than they’re worth — made even more so in a world of ever-more stringent data regulations such as Europe’s GDPR.
Third-party vulnerabilities
One negative involves possible dependencies meaning that, if you rely heavily on a third-party library, any code is tied up with that library. Changing libraries can be problematic. If you use too many libraries, it can result in dependency conflicts.
For many, however, the biggest problem involves possible vulnerabilities. Open-source libraries and code are often targeted by hackers or other bad actors. This can open up the threat of so-called software supply chain attacks, in which hackers manipulate third-party software component code as a means by which to compromise whichever “downstream” applications might use them. This code manipulation frequently involves seizing upon a so-called zero-day vulnerability to inject malicious code or malware which are then spread to customers who expose their own IT networks in the process. The results can be some GDPR-worrying data breaches.
Think of it like a thief who is able to break one particular brand of lock which happens to have been installed in every house on a street. By compromising that single unit, they are then able to gain access to every home that lock is used to protect.
Supply chain attacks on the rise
In recent years, there have been no shortage of examples of damaging supply chain attacks. For example, at the end of 2020 it was reported that hackers had broken into the systems belonging to U.S. tech company SolarWinds, which provides networking monitoring services to a wide selection of the largest American companies and governmental agencies. By inserting malicious code into widely used SolarWinds software, which was then distributed to customers as software updates, SolarWinds clients unknowingly created backdoors into their IT systems.
In another supply chain attack, file-sharing company Accellion was the target of a supply chain attack in which a vulnerability in its file-transfer program was seized upon by bad actors as a way to hack worldwide networks. By April 2021, the number of companies that had been victims of this attack had reached 100 and continued climbing.
Yet another supply chain attack, this time involving Microsoft Exchange, and the exploitation of several zero-day vulnerabilities to carry out email exfiltration from corporate Microsoft Exchange servers. One other recent supply chain attack involved the widely used code coverage tool Codecov, which was the victim of its own supply chain attack.
Good application security
Managing application security risk is a “must” for all enterprises. In an ideal world, all software would be built from the ground-up with no reliance on other parties, thereby defending against possible supply chain attacks. That is not always possible, however.
But that does not mean that there aren’t steps you can take to protect yourself. For starters, properly evaluating the security policies of suppliers can reduce the possibility of being the victim of an attack. So, too, can regular audits, in which you ascertain how interconnected you are with suppliers and how a possible breach could therefore impact you and your sensitive data.
One other very important step involves the deployment of tools for monitoring for suspicious or otherwise unusual activity that could signify that you are the victim of a cyber attack. As an important safeguarding measure, a Web Application Firewall (WAF) is able to identify potential attacks taking place and block them. WAFs can be utilized to block exploitation of vulnerable libraries and dependencies.
Supply chain attacks appear to be ramping up in a big way. But by taking the right precautions you can minimize the risk of being a victim of one of these attacks. Doing so is a highly advisable step to take.