Protecting against supply chain attacks - full guide

Supply chain attacks are one of the biggest threats you and me as developers, web developers, can face these days. They are becoming more frequent and more serious. And I talked about that in another video, which I released earlier this week on my other channel, link below. Because this week, when I'm recording this, there the Axios library. By the way, in this video here, I'm focusing on the JavaScript ecosystem, but supply chain attacks are not exclusive to the JavaScript ecosystem. They are just particularly popular. They are for various reasons, but that's not the focus here. Therefore, in this video here, I'll share concrete steps you can and probably should take, and I'm taking, I'm doing, to protect against supply chain attacks so the next time one happens, you can keep on sleeping happily because you're not in danger. By the way, if this is helpful, check out academind.com. There, I have courses on all kinds of AI related stuff, so that might be interesting to you. So, what can you do to protect against supply It's two main layers, so to say. The first layer is that you want to reduce the danger of being affected by such an attack. The second layer is that you want to reduce the blast radius if you are affected, and both are important because you can reduce the danger, but you can't reduce it to zero. There is no 100% guarantee that you will never be affected. So, you can reduce it, but not to zero. So, therefore, this second point, if you are affected, you wanna reduce the damage the attack can do. Now, each point he- consists of a couple of steps you can ta- take, a couple of things you should consider, reducing the danger. Maybe you already heard about that. You want to set a minimum release, uh, age for any packages you add to your project. Uh, what does this mean? It means if you are using, if you're working in a web dev project using npm for managing your packages, or bun or pnpm, then some of these tools allow you to add dedicated settings that help you stay secure, so to say. For example, if you are using bun, not necessarily the bun API, not necessarily in your code, but as a package manager, which you can do instead of npm, then bun has a minimum release age setting you can add in your bunfic.toml file, which is simply a configuration file you can add to your project. And if you add this setting here and you're using bun for managing your dependencies, that's important of course, to only ever install dependencies that are at least that old. Or dependency versions, I should say, that are at- at least that old. So, that is three days in- in seconds here. So, that of course, is a huge security step up because those supply chain attacks in the past have typically been detected and remedied within a few hours. So, if you make sure that you never install package versions are younger than, let's say, three days, you're already pretty, pretty secure. If you're using pnpm as a package manager instead of bun or npm, you have a similar setting you can make. And if you are using npm, good old npm, you can actually also add a .npmrc file in your project that configures how the npm package manager works, so to say. And in there, if your npm version, I think, is at least 11.11.1, you can also add a min-release-age setting and npm should honor that and not install packages that are younger than that date or package versions. Important, you really need to set this setting this is null. The same for bun. So, by default, no minimum age is assumed. A sensible default that is enforced by bun though is that by default, it does not execute lifecycle scripts of third-party packages. Now, what is that? Well, in your package.json file, you of course typically have scripts, and you could also have scripts like post-install scripts in there, which libraries could add to define some code that should execute whenever installed, and that is how many of those supply chain attacks They add malicious code as a post-install script. Bun, by default, blocks those scripts. if you're using bun for package another big security step up because those malicious scripts shouldn't get executed. I'm saying shouldn't because bun has a default list of trusted dependencies, which actually do have their scripts executed, and you could also manage your own list here. And therefore, one thing you might wanna do to override that trusted dependencies list bun has is in your package.json file, you can add that trustedDependencies setting, which will be ignored by npm, but which will be honored by bun. And if you set this to an empty array, bun maintains to ensure that no package has their post-install and other lifecycle scripts executed. So, that's another security measure. You wanna block those package scripts. For npm, you can also get there. In the .npmrc file, you can add a ignore-scripts setting and set this to true so that if you're using npm for package management, you also don't execute those, uh, lifecycle scripts. And then there is a last point, which I read about a lot, which I think is a bit overhyped, but still worth mentioning. You have that interesting package.lock.json file or bun.lock file or other lock files in your project, depending on which package manager you're using. I have a bun.lock file, for example. These lock files get created automatically normally when you install packages through npm, then you get a package.lock file, or through bun, then you would get a bun.lock file. Now, what these files do is they lock in concrete, highly-specific package versions. By default, in your package.json file, uh-You might have dependencies like this, which says, "I want at least that version of the dependency," and major updates will not be downloaded automatically, but patch updates, for example, would. So this does not mean that I want exactly version 2.1.10 for this package, but I want at least that version. And that can be problematic. If version 11, for example, would be effective, then I would download it if I were to reinstall my dependencies, or, to push this to production and in the CI/CD process, I install my dependencies, that might install a different version than I was using locally. That is where the lock file comes in. It locks in specific versions, exactly the versions you installed locally, and therefore the lock file should be committed to version control, should be committed to GIT and GitHub, for example, so that when you're deploying this, or if you were to delete your note modules folder and you reinstall all dependencies, you download and install exactly the dependencies you were using locally. So exact, specific dependency versions are being locked in here. And that is also kind of a protection mechanism, of course, because if you have safe versions locally or before, and you now reinstall or install on another server based on the log file, you get those safe versions again. Even beyond supply chain attacks, the log file is useful, of course, because it ensures that app, you're really installing exactly the same if some patch release of some dependency you were using introduced a bug, for example, you would not have that in the deployed version. So it's good for predictability. So that is important. That reduces the danger of being affected you're not pulling in new versions early and you're blocking those scripts. And with that, you are already super, super safe. You could stop here and it would be way better than what you probably had before, but it's really important to me, 100% safe. You have no guarantee that such attacks will be caught within a few hours. It could take a week, depending on how sophisticated an attack is, depending on how popular a package is. You have no guarantee that it will only be hours. So saying that you don't want to download packages that aren't at least three days old, package versions I mean, might not always be enough. Blocking scripts also is not necessarily always enough because that's just one popular way of launching such an attack, but, of course, a more sophisticated attack could inject code into the actual package code and that code could then execute on your system. If you're building a server side application, let's say, and you're downloading, let's say, Express.js, and Express.js or some dependency of Express.js had malicious code injected, that code might be executing on your machine as you're running the development server, for example. So that is great, but it's not a 100% protection. That is why we also want to reduce the blast radius, which in general is a good idea, by the way, because things can go wrong. So what do I mean by that? I, for example, mean that you want to encrypt and hide your secrets. Now, what are secrets? Secrets are stuff like my newsletter API key in the Academind.com website source code. Uh, this is required for making newsletter By the way, great idea to sign up there to be the sales, new courses, and stuff. And, of course, that is not something I want other people to get because they could use that to manipulate my newsletter contact list, So that is a secret. That secret, that concrete key should not be stored in my code base and should also not be in my dot env file. Now, as web developers, we tend to put a lot of stuff in dot env, and I admit I also do this in my courses because it's convenient. But in theory, and not just in theory, really, to be safe, that dot env file should not contain anything you're not comfortable sharing. So I can freely share this file with you because there's nothing in there that would matter to you or that would be insecure to share, right? So that is what the s- the end goal should be. Naturally, the question then is, well, where do you then put these values that you need during development? And the answer is you wanna use a service like Doppler. And no, this video is not sponsored by them. There also are alternatives, like Inphysical, or you could build your own alternative, of course. These are services that allow you to manage your secrets in the cloud and pull them into your project, inject them into the environment as you development or production server so that they are, uh, fetched just in time, so to say. And you can, for example, use Doppler for free. You can start and use it for free if you have, like, a, a small scope just up to three users, up to 10 projects, I think. So that can then be a great way of protecting yourself. So I, for example, set up a project here in Doppler for my website. In there, you can have different environments, you can define various secrets, store the secret values there, and then you can pull them in by reusing the Doppler CLI, which you need to install. And then you can run Doppler Run development server, and that will inject those secrets just in time to make them available.So that is how you can make sure that they're not lying around on your system, in your project, or anywhere else, and therefore, if you would be affected by any attack, doesn't matter, but let's say a supply chain attack, just read your .env file and find your secret values because the values aren't in that file. And of course, it's not just secrets you might be using Those supply chain attacks scanned your entire machine. By the way, it also didn't matter if you were using Windows or Linux those attacks work with all operating systems and they were looking for all kinds of passwords or keys you might have on your system. So outside of your project, you don't just wanna hide or encrypt your secrets, you also wanna, of course, encrypt any SSH keys you have lying around on your system. Use tools or services like 1Password for managing your passwords and secrets on your system. And no, they are also not sponsoring this video. I'm just using them personally. So that, of course, are great ideas because if there is simply nothing valuable lying around on your system, there is nothing that could be stolen. Another step up here would be to use a dedicated dev environment or machine for development. So what do I mean by that? I mean that you may be using your one PC for everything. You do your banking business there, YouTube videos there, you do all the personal stuff there, develop there. And of course, there's nothing wrong with that, but have any way of doing your development work on a separate machine, a separate Mac mini or whatever, then of course, anything bad that happens there stays on that machine. So that might be worth it and you have a better separation. And, uh, for example, your tax documents machine wouldn't be, uh, accessible on your development machine. So having that separation might be, uh, worth a look. If you don't have a separate machine use it, you could look into using a virtual For example, Multipass is a free tool you can use to spin up virtual Ubuntu, uh, machines on macOS, on Windows, on Linux, and it's not the only tool. You can look into a broad variety of other virtual machine, uh, providers. You could also use Docker. It's not perfect isolation necessarily though, since it shares the host kernel. That's why a virtual machine might be But spinning up such a virtual machine might be a good idea too. For example, I got Multipass installed and I created, uh, a bunch of virtual machines there, actually one base machine, which I keep on cloning because Multipass has a clone command where you can use one base machine and clone to create a new machine based on it, to use it as a base image essentially. And if they're not running, So I only have my development machine running and I have one development virtual machine per project in my case here. And then that project, so this project you see here runs in that virtual machine. It runs in there. So if anything bad happens in there, it happens in that virtual machine And in that machine, there is nothing except for this project. Now, there are a couple of gotchas here related to using AI tools like Claude Code in there or Git, because if you want to be able to git push, for example, you need to be able to connect your, your Git account here. So I need to ha- to have my Git credentials somewhere in the virtual machine, and those could be stolen if they were stored there. The same for Claude Code. If I do install Claude Code in that machine or Codex or whatever, and I then log in in there, my session token must be stored in that virtual machine. Now, there are a couple of workarounds though. For example, I did register my virtual machine as a SSH host in my SSH config file on my system, and in there I set forward agent to yes. Now, what exactly does this do? This ensures that I can actually add certain credentials to my SSH agent, to my SSH tool, so to say here, and forwards them to the virtual machine. I don't store them in there. I don't copy them in there, but when I'm then connected to that virtual machine as I am here using VS Code remote feature where you can connect to a host via SSH, in there, I then have various, uh, keys or credentials available. Uh, this here, for example, is my GitHub SSH key, which I use for authenticating with GitHub That allows me to use git commands, and for example, push or pull from inside my terminal in VS Code in that remote machine which is connected via SSH using the credentials that are stored on my host machine. So the credentials are not copied in there, they So therefore, I don't expose them in there. Of course, if some process got access to my SSH session in there, it could still access those credentials, security layer. That is the point. By the way, if stuff like that is interesting to you that, about SSH and how I forward credentials know in the comments and I'll create a dedicated video on that. But that is one thing I'm doing. Now, when it comes to AI agents like Claude and by the way, I have an amazing Claude Code course, out, or you get my subscription to get access side note. If I wanna use Claude Code in there, I can install it and authenticate and live with the fact that my session token is stored in there, because if something bad would happen, I could always revoke my sessions from inside my Claude dashboard to, uh, kind of restrict the amount of damage that can be done. And since it's a subscription, an attacker can't do more than use up my overall subscription usage, but they can't actually hurt me beyond that So I'm fine with that. If I don't want that, I could also run Claude Code or whatever on my host machine and just tell it to connect to that virtual machine via SSH and run commands in there because it can do that. It can, of course, also run SSH commands to connect to some remote machine and run commands there. So that would be an alternative way of solving this problem. And therefore, using such a virtual machine serious security step-up. But if there's one main takeaway from this it's that you should at least take this first step because that's super easy. It's just a bunch of config files you need to edit, and that you should at least also hide and encrypt your secrets. If you do that, you're already so much more secure than with those steps implemented, 100% guarantee that things can't go wrong, but it's way, way more than you probably have right now. And the next time you see a video by me or someone else about a big supply chain attack, you can hopefully sleep easy and be relaxed about it