# Protecting against supply chain attacks - full guide

## Метаданные

- **Канал:** Academind
- **YouTube:** https://www.youtube.com/watch?v=Fs6YDVJq5As
- **Дата:** 02.04.2026
- **Длительность:** 20:36
- **Просмотры:** 9,887

## Описание

Supply chain attacks are becoming more frequent. Especially in the JavaScript ecosystem. The recent axios attack (see my video: https://www.youtube.com/watch?v=CHkiSSZiWVE) is just one example.

But you can protect yourself against such attacks!

🖥️ Official Website & Courses
https://academind.com/courses/

💬 Academind Community
https://academind.com/community

👋 Social Media
https://twitter.com/maxedapps
https://twitter.com/academind_real
https://www.instagram.com/academind_real/
https://www.facebook.com/academindchannel/
https://www.linkedin.com/in/maximilian-schwarzmueller/
https://www.linkedin.com/in/manuel-lorenz-808b5185/
https://www.linkedin.com/company/academind-gmbh
https://www.linkedin.com/school/academind-pro
https://www.tiktok.com/@academind_real

## Содержание

### [0:00](https://www.youtube.com/watch?v=Fs6YDVJq5As) Segment 1 (00:00 - 05:00)

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 was a huge attack based on 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 that 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 and web development related stuff, so that may be interesting to you. So, what can you do to protect against supply chain attacks? 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 want to reduce the damage the attack can do. Now, each point consists of a couple of steps you can take a couple of things you should consider. And let's start with reducing the danger. Maybe you already heard about that. You want to set a minimum release age for any packages you add to your project. What does this mean? It means if you are using, if you're working in a web dev project and you are 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're 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 bunfig. 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, then it will make sure to only ever install dependencies that are at least that old, or dependency versions, I should say, that are at least that old. So, that is 3 days 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 that are younger than, let's say, 3 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're 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 because by default, 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 life cycle 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 that package was installed. And that is how many of those supply chain attacks work. They add

### [5:00](https://www.youtube.com/watch?v=Fs6YDVJq5As&t=300s) Segment 2 (05:00 - 10:00)

malicious code as a post install script. Bun, by default, blocks those scripts. So, if you're using bun for package management, for example, you already have 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, for one thing you might want to do to override that trusted dependencies list bun has is in your package. json file, you can add that trusted dependencies setting, which will be ignored by npm, but which will be honored by bun. And if you set this to an empty array, you should override that default list bun maintains to ensure that no package has their post install and other life cycle scripts executed. So, that's another security measure. You want to 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 life cycle 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 affected, then I would download it if I were to reinstall my dependencies. Or, for example, if I were 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, Git and GitHub, for example, so that when you're deploying this, or if you were to delete your node_modules folder and you reinstall all the 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 had saved versions locally or before, and you now reinstall or install on another server based on the lock file, you get those saved versions again. Even beyond supply chain attacks, the lock file is useful, of course, because it ensures that when you're deploying the app, you're really installing exactly the same versions you were using locally. And 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 because 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, you're not 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 3 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

### [10:00](https://www.youtube.com/watch?v=Fs6YDVJq5As&t=600s) Segment 3 (10:00 - 15:00)

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. This is required for making newsletter sign-up work. By the way, great idea to sign up there to be the first to be announced about 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, for example. 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. env file. Now, as web developers, we tend to put a lot of stuff in. 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. 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 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 want to use a service like Doppler. And no, this video is not sponsored by them. There also are alternatives like In Physical, 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 start your development or production server, so that they are 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 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, and for each environment, you can define various secrets, store the secret values there, and then you can pull them in by using the Doppler CLI, which you need to install, and then you can run Doppler run, and then your 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, attackers can't 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 in your projects. Those supply chain attacks scan your entire machine. By the way, it also did matter if you were using Windows or Linux or Mac OS. Those attacks work at 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 want to hide or encrypt your secrets, you also want, 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. I mean that you may be using your one MacBook or PC for everything. You do your banking business there, you watch YouTube videos there, you do all the personal stuff there, and you also develop there. And of course, there's nothing wrong with that, but if you 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

### [15:00](https://www.youtube.com/watch?v=Fs6YDVJq5As&t=900s) Segment 4 (15:00 - 20:00)

that may be on your personal machine wouldn't be accessible on your development machine. So, having that separation might be uh worth a look. If you don't have a separate machine or you don't want to use it, you could look into using a virtual machine. For example, Multipass is a free tool you can use to spin up virtual Ubuntu uh machines on Mac OS, on Windows, on Linux, and it's not the only tool. You can look into a broader 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 better. But spinning up such a good idea, too. For example, I got Multipass installed, and I created 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, they're not consuming resources. 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 get push, for example, you need to be able to connect your Git account here. So, I need 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 Code X or whatever, and I then log 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 keys or credentials available. 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 are stored on my host machine. 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, but it's a never security layer. That is the point. By the way, if stuff like that is interesting to you and you want to learn more about that, about SSH and how I forward credentials there and stuff like that, let me 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 Code, and by the way, I have an amazing Claude Code course, which you might want to check out, or you get my subscription to get access to all my courses, just as a side note. If I want to 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 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 is not too difficult and might be a serious security step up. But if there's one main takeaway from this video, it's

### [20:00](https://www.youtube.com/watch?v=Fs6YDVJq5As&t=1200s) Segment 5 (20:00 - 20:00)

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 you were before. And therefore, with those steps implemented, there still is not a 100% 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.

---
*Источник: https://ekstraktznaniy.ru/video/49655*