Overreliance on 3rd-party Libraries and Cybersecurity Black Hole

AI assistants are beneficial. They allow people to create content and write software code to achieve incredible productivity. I experimented myself, building a fully functional CMS using Python, Flask, Bootstrap and PostgreSQL without writing any code myself—only explaining the task to ChatGPT and copying and pasting the code. It took the whole weekend, and I got a CMS, a working web application that would have taken me weeks to write myself. Note that I had extremely limited knowledge of Flask before beginning the project, yet I was able to learn quickly.

I had an extensive software engineering background, and writing the requirements and understanding the output was easy. However, even pretending to be a complete beginner and writing prompts to guide me through building requirements, I could achieve similar results without spending much time.

However, in the process, one thing became clear to me — ChatGPT heavily relies on 3rd party libraries, sometimes suggesting outdated and vulnerable versions of libraries. The efficiency leads to overreliance on the 3rd party libraries. It is easy to make a logical step that as more junior developers build software with AI; there will be more code fragments that are not optimal from security and performance perspectives. Yet, overreliance on 3rd-party libraries has a not-so-much-hidden danger — using the libraries, developers give control to their authors. A library can have flaws and be used to attack the application, or the author may implement a backdoor in one of the new versions, as it happened with xz/liblzma.

The cybersecurity challenge is significant. Thousands of new tech startups launch new applications every year and receive substantial usage. Those companies accumulate vast amounts of user data, and many have access to user systems. For cost and speed, developers rely on AI, autogenerated code and 3rd party libraries, introducing more cybersecurity vulnerabilities that can be exploited.

My favorite example is the existence of an npm package is-odd. As the description says, “Returns true if the given number is odd.” Although implementing such a check in JavaScript would take one simple line of code: if(x % 2 != 0){ }

Of course, this is an exaggeration, yet it is a good illustration of how connecting a third-party library can implement even some simple functionality.

What can we do about it?

Application code should be audited and monitored for security. Extensive logging and auditing capabilities are required to understand what the users and the application are doing, what actions lead to which results, and what happens with the data received, processed and provided by the application.

Third-party libraries should come from credible sources and be reviewed, tested, and version-locked. Updates should require a backward compatibility check, successfully passing autotests and a security review.

It is essential to monitor for known vulnerabilities in the libraries used by your applications and implement patches promptly.

…

Every developer is responsible for application security. No matter how small the functionality you develop, attackers can exploit it as long as it is part of a bigger software package.