A software dependency is pretty much what its name suggests: a program that a piece of software depends on in order to function. Software dependencies are the norm with modern software. Virtually no software is written by its author completely from scratch. Instead, they are stitched together using a combination of new code and additional, existing code that has been created by others. This is why proper data security is sorely needed.
These units of code are most commonly called a “package,” although the terms “module” and “library” are also frequently used. They could vary from tools used for compiling or testing a program to adding additional features — like, for instance, the encryption capabilities for a messaging app. There are millions of packages available for the most popular programming languages, partly thanks to the thriving copyleft and open source community, as well as online code repositories such as Github. According to Github, the total number of public code repositories has long since exceeded 100 million.
Challenges and risks abound
But while the availability of these tools is a profoundly positive development for coders, it does bring about some challenges. Dependency risk is the tradeoff made whenever we put our faith in anything from people to financial systems to services to, yes, code. Reliance in the form of dependencies can save time and make possible efforts that would not be achievable on our own. However, one of the big risks associated with software dependencies involves security — and the user’s faith that the person who wrote a particular third-party line of code has properly coded, tested, debugged and maintained it.
At its root, downloading a package from the internet to use as a dependency is no different than downloading any other program. Furthermore, unlike downloading a program, such as a game or media player, that is only going to be used on your computer, in the case of a dependency you are downloading code that will be baked into a larger program. Any vulnerabilities or exploits that exist in the external, third-party code — either purposefully or accidentally — will become part of your own software. In short, library vulnerabilities can leave the applications using them vulnerable to exploitation.
Putting your organization at risk
These vulnerabilities could put organizations’ data at risk in the event of a breach. Such data breaches are, unfortunately, increasingly common in 2020. Seemingly every few months there is a new report about a large organization being hacked and putting at risk large amounts of customer data or other confidential information as a result. For instance, in 2017 the American multinational credit reporting agency Equifax suffered a huge data breach compromising the personal data of 143 million customers. These kinds of (often eminently avoidable) breaches harm companies both in terms of their reputation and also financially, compounded by the heavy fines that can be levied against companies and other organizations for failing to properly safeguard user data.
More than half of such data breaches are attributed to hacking and, in many cases, exploitation of unpatched vulnerabilities can be among the top causes of this. They can open up the risk of attacks or exploitations ranging from Cross-Site Scripting attacks to ones that prey upon broken access controls, allowing hackers to bypass typical access controls to pose as privileged users.
The scope of the open source risk profile is becoming broader all the time. The overwhelming majority of modern codebases have dependencies on open source libraries. However, while most organizations include open source code in their projects, significantly fewer take the important step of scanning the code for any vulnerabilities it might have. These, in some ways, is an extension of the way we treat dependencies in the real world. A person ordering food in a restaurant probably won’t go into the kitchen and demand to see the meal prepared from start to finish.
Know the risks and act on them
But while we might not double or triple-check the reliability of every dependency we encounter in life, some are important enough that we want to make certain they are trustworthy. Third-party code that your organization relies upon is certainly one of them. Most flaws are relatively easy to fix with the right patch or update. But the impact of not doing this can be devastating.
Patch management processes are incredibly important. Fortunately, the tools are there to help manage all the code in your supply chain. These data security systems can scan databases for vulnerabilities and misconfigurations that represent security gaps attackers could exploit. They should then be able to provide recommendations on possible remedial actions. In addition, tools like Web Application Firewalls (WAF) and Runtime Application Self-Protection (RASP) can help to detect and block attempted exploitation by hackers.
Smart processes, aided by tools such as this, mean that users can take advantage of the immense possibilities of open source libraries — without being scared away by the risks.
