A company’s biggest security hole usually isn’t in its firewall or an infrastructure flaw. It’s usually something much more mundane: blind trust in third-party code.
The Axios case is the perfect example. An essential library for making HTTP requests, with millions of weekly downloads, becomes a Trojan horse overnight. All it takes is for an attacker to hijack the maintainer’s credentials to inject malicious code into thousands of servers in a matter of minutes.
Furthermore, if your deployment system runs an install command during that window, you’ve just given that Trojan access. And the worst part is that you did it to yourself.
Digital Hoarding
The software industry, to some extent, has gotten very lazy. We’ve gotten used to importing packages to solve problems that, in some cases, could be fixed with ten lines of code.
You want to format a date or validate a form, so you install a dependency. That package depends on five others, and those five on twenty more. Ultimately, your project ends up with thousands of files in a dependencies folder written by people you don’t know, who don’t get paid to maintain that code, and whose security you cannot control.
Basically, you are leaving your business integrity in the hands of strangers coding in their free time.
The Illusion of Control
It is foolish to pay for audits if later, when deploying to production, your system downloads code from the internet blindly.
Protecting yourself against this isn’t about buying more expensive software, but about having a minimum of common sense in your architecture. No letting your production environment just download the latest version of a dependency. If your local environment worked with a specific version, production needs to run exactly that one. Leaving dynamic ranges in your configuration is telling your server to blindly trust any update released today. The lockfile should be sacred.
On the other hand, a simple utility library shouldn’t have permissions to run commands on your machine upon installation. Therefore, block third-party script execution in your deployment environments.
But the most important and even simpler rule: If a problem can be solved by writing a few lines of code, sacrifice that little bit of time and do it yourself. Do not delegate that to an external dependency. Write the damn code. Less third-party code means less attack surface.
Open Source is an indispensable tool and a great source of innovation, but don’t look at it as “free code”. If you’re going to put someone else’s code on your server, the ultimate responsibility for what happens falls on you. If you aren’t willing to audit it, you better not open the door.