Owning Your Dependencies
Before they own you!
Recently, a lot of popular pieces of software have been in the news for all the wrong reasons. NPM has been a constant source of malware since last year, GitHub is having trouble with its uptime, and Claude Code itself recently got leaked.
There are way too many supply-chain attacks going on nowadays.
What’s supply-chain?
Modern software seldom is a self-contained application. Most of the time, each piece of software has several dependencies on other software, sometimes several of them. All these pieces of software are maintained by different people, and although it has a lot of advantages in keeping things decentralised, it also exposes applications to risk when their dependencies get compromised.
As a simple example, let’s say that a developer at a small startup uses an open-source npm package called string-utils to format text in their app. They run npm install string-utils and move on.
What they don’t know is that a hacker previously identified that the original maintainer abandoned the package. The hacker claimed ownership of the repository and published a new version with one extra line of code that silently reads environment variables (like AWS_SECRET_KEY) and sends them to an external server.
The startup’s app now leaks cloud credentials every time it starts up. The developer never wrote vulnerable code. They were compromised through something they trusted.
Sounds crazy? Well, this is almost exactly how all the major supply-chain attacks happened in the past year. Supply-chain attacks are a mix of writing malicious code and sometimes social engineering. There’s a great video by Veritasium explaining things in detail, you can check it out here.
The NeoVim Relation
Much as I hate to say it, NeoVim users aren’t immune to this sort of attack. The NeoVim plugin marketplace is very innovative, thriving, and most importantly, unregulated. Sounds familiar?
I used to use plugins left-and-right, any random plugin for any small decoration or UX thing. But then I came across a statement on Reddit like “I don’t want to be fired because I wanted a different colorscheme” and that stuck with me. I thought about it for a while, then I landed on the following thought process:
Any purely aesthetic plugins, like colorscheme, autopairs, lualine, I either remove them altogether or replace them with my own home-made plugins
For plugins which are really useful like Mason, Telescope, I pin them to a specific version so that they don’t get updated. Of course, this just freezes the attack surface area, but it’s still better than allowing blind automatic updates.
First of all, I did all of it in my office laptop using Claude Code. Now, you might ask the wisdom in using something which itself got leaked due to a supply-chain attack. But I just wanted to free my office NeoVim from unnecessary dependencies, and I still had to do my actual office work, so I could not wait to learn and do it from scratch. And Claude Code is good at doing copy-paste work (this is essentially cloning the source code of the plugin locally). And not to mention, I get credits from my company for using it.
For my personal work though, I took this as a good chance to get more familiar with Lua, and also developing experience writing NeoVim plugins. Lua is an interesting language, made for embedding into other bigger programs. It has got its own garbage collector and is small enough to be learnt in one afternoon. I am still porting things over, but it has been a lot of fun writing my own plugins so far, and learning things deeply.
Conclusion
I am not sure if what I am doing is the most practical way to go about this. Just like life itself, any approach here has trade-offs and no one approach truly solves it completely. I don’t believe we can survive on no plugins, not until the NeoVim ecosystem matures even more.
Let me know what you think of this, and what you are doing to mitigate this problem in the comments.
Until later.
If you like my work, this would be a great way to show appreciation!