npm install && pray

Hello, Node Congress. Thank you so much for having me. I'm Jo Franchetti and I'm a DevRel at Deno, and I'm going to dive right in and let's talk about some scary stuff.

There's a ritual that every JavaScript developer knows. You're building something, you need to pass dates or validate an email or format a currency. So you do what any reasonable person does. You open up your terminal and you type npm install, and you pick a package with a few million weekly downloads and a friendly readme. You trust it. You ship it.

And for a long time, that worked great. And our ecosystem grew because of that trust, because someone could publish a utility at 2 a.m. and by morning developers on the other side of the world were using it already in production. And that openness is genuinely beautiful. It's why JavaScript became what it is. But we need to talk about what that trust costs us now.

In September of 2025, researchers at Reversing Labs identified something that hadn't been seen before in the npm ecosystem. It was a self-replicating worm, and they called it shyhoo lewd after the sandworm from June, which is pretty fitting because once it got into the ecosystem, it was very hard to stop. And here's what it did. It started with a single malicious package. In this case, it was rxnt authentication. And once a developer installed it, the malware would scan their environment for npm credentials. Then it used those credentials to publish a malicious version of other packages that that developer maintained or had access to. It was literally viral.

Each new victim became a new vector for attack. By the time it was contained, over 500 npm packages have been compromised. Then there was a second wave, shyhoo lewd 2.0, which hit in November and compromised 796 more packages. And that represented over 20 million weekly downloads. And what was the malware actually stealing? Well, anything that it could find. It was looking for environment variables, AWS and GCP tokens, GitHub credentials, npm auth tokens. And it did all of this silently over HTTP in the background while your app ran perfectly.

You would never know. And a month earlier, in September 2025, a different attack hit even harder. You've maybe heard of the chalk or debug packages, two of the most downloaded packages in the entire npm ecosystem. And a very prolific maintainer managed both of these along with 16 other widely used packages. Combined, they had more than 2 billion weekly downloads.

What the attackers did is they registered the domain npmjs.help. And then three days after registering it, they sent the maintainer an email from support at npmjs.help. And they were impersonating npm support. The email was convincing enough to get the maintainer to enter their credentials into a fake login page. And with those credentials, the attackers then had full publishing rights to all 18 of their packages.

So let's take a moment to understand the mechanics because that's important for what we're going to talk about next. Supply chain attacks in the npm ecosystem work because of a combination of factors. First are implicit trust in version ranges. We all do it. Most npm files, our package.json files, use a hat or a tilde in front of the version numbers. That means that when a maintainer pushes, say, 2.1.1 to fix a bug, your CI is going to automatically pull it in. There's no review. You don't get any approval. It just lands in production.

There's no review. You don't get any approval. It just lands in production. The second attack surface is the maintainer themselves, not the code. The chalk attack didn't require finding a vulnerability in chalk's code, it required finding a vulnerability in a human being. Specifically, their tendency to trust an email that looks official and be too busy and tired to really check properly. If you compromise the person, you can potentially compromise all of their packages.

Thirdly, the malware doesn't need to be obvious. A few lines of code that run at install time with a post-install script or code that only activates when specific environment variables are present or code that quietly spawns a subprocess, these can all pass a casual code review. This is where I would like to introduce something, but I also want to be careful about how I frame it because I don't want this to sound like a sales pitch. This is about design decisions that have real consequences.

So by default, Node.js gives every package that you install the same permissions as your user account. When you run npm install and say a post-install script fires, that script can read your .ssh directory. It can make HTTP requests. It can write to your file system. It can spawn processes. Deno takes a slightly different approach. By default, a Deno program doesn't have access to sensitive APIs without explicit permissions. So in Deno, we have allowenv to give access to env variables, allownet to allow access to the Internet, allowread to give read access to the file system, allowwrite, which allows you to write to the file system, and allowrun, which allows you to spawn subprocesses. And crucially, you can scope these.

So we could do something like allowenv equals database URL, which means that the process can only read that database URL environment variable and nothing else. Or we could do something like allownet equals api.stripe.com, which means the process can reach Stripe and nowhere else.

And there is one more layer worth understanding. I mentioned earlier the post-install problem. So when you run npm install, npm executes any lifecycle scripts that the package declares pre-install, install, or post-install. And that's how Shai Walood ran its payload. The attacker didn't require you to import the package. It ran the moment you installed it.

Deno doesn't have install scripts. There's no post-install hook. When Deno downloads a package, it caches it and then it stops. No code is run. And that's an intentional design decision. It's not an omission. And pnpm has taken a similar position recently. Newer versions require you to explicitly allow packages to run build scripts via an only built dependencies allow list.

So you're opting in rather than opting out. And npm does have an opt-out. We've got the npm install minus minus ignore scripts flag. But it's not on by default. It's not surfaced prominently and it can break packages that legitimately need to compile native extensions. And honestly, most teams just don't use it.

Say you've got a package that executes malicious code at runtime. Code that runs when you import it, when you call one of its functions, when it registers a side effect or on module load. That is completely unaffected by the ignore scripts flag. The malware just moves from install time to run time. The worm is still going to run, it's just going to wait until your application is running.

And tools that catch this kind of thing are called SAST and DAST scanners. So we've got our static and dynamic analysis tools that look for suspicious patterns in our dependency code. And they run on a CI schedule or on a PR. That gap between adding a package and the next CI scan is where runtime attacks live. And that's exactly where DNO's permission enforcement matters the most.

They don't run the moment a developer adds a package and types node index.js to run something locally. That gap between adding a package and the next CI scan is where runtime attacks live. And that's exactly where DNO's permission enforcement matters the most.

So let's actually take a look at a little demo and take a look at what happens when you try to do what ShyWooLoo did. So let's take a look at a little script down here. So let's say we've got this script here. It's going to try and read your environment and make an outbound HTTP request exactly what the worm's payload was doing. And if I try and run this with DNO, so if I do dno run worm.ts, it doesn't actually run. The first thing that happens is I get a prompt asking whether or not I want to give those permissions. It stops immediately before a single byte is sent. And then I can double check what this code is doing and make sure that it's doing what I want it to be doing and what I thought it should be doing.

Now, I want to be precise about what this protects against and what it doesn't. DNO's permission system is a great defense against code that tries to do bad things at the system level. But it's kind of old news. You've all seen it before. And it doesn't solve every problem that we're facing. You might have known this was coming. Ryan Dahl, the creator of Node and DNO, tweeted recently that the era of humans writing code is over. And of course, AI coding assistants are genuinely useful. I use them. I assume you use them. They speed up boilerplate. They're good at explaining unfamiliar code. They catch bugs that I'd certainly miss. And, you know, I'm not going to sit here and tell you to stop using them.

But they can introduce us to a whole new category of problems. And it's related to everything that I just talked about. It's about the code that you didn't write. That you don't fully control doing things that you don't intend it to do.

So let's take a look at another real-world example. In early 2025, researchers at Truffle Security ran an analysis of the Common Crawl dataset, which is just a massive public snapshot of the web. And what they found was quite alarming. Nearly 12,000 live valid secrets were embedded in that training data. That's things like AWS keys, API keys, Slack tokens, GitHub credentials.

And these weren't just secrets that had been rotated out. These were live and working and are still working right now, some of them. There's a few things going on here. AI projects move very fast. And when we move fast, our security practices tend to lag behind. AI coding assistants can sometimes suggest bad patterns that hard-code our credentials directly into the code.

And separately and interestingly, Wiz.io found that 65% of companies on the Forbes AI 50 list have leaked verified secrets on GitHub. 65%. Even the companies that are building the AI tools have the same problem that everybody else has. So why does this keep happening? Well, it isn't random. It's a structural problem.

In 2025, GitHub Copilot was assigned a cybersecurity vulnerability. This was CVE-2025-53773, if you want to look it up. The theory of this vulnerability was that an attacker could potentially embed prompt injection instructions in a repository via comments in the code. The prompt would cause Copilot to modify the user's setting files and enable unsafe execution modes when a developer asked Copilot to summarize or work with that code. This is a form of indirect prompt injection. The attack surface isn't your own code anymore. It's any code or copy that your AI assistant looks at.

Researchers have shown that injecting as few as 250 malicious documents into pre-training data can successfully backdoor an LLM with a 90% attack success rate. You wouldn't even know that the model was compromised. It would behave normally except when specific conditions are met. AI-generated code, of course, makes mistakes. Not necessarily malicious mistakes, just wrong code. A script that was supposed to clean up temporary files can delete the wrong directory.

This is a form of indirect prompt injection. The attack surface isn't your own code anymore. It's any code or copy that your AI assistant looks at. And not only that, I don't know if you've heard of this idea of model poisoning. It is still somewhat experimental, but actually quite real. Researchers have shown that injecting as few as 250 malicious documents into pre-training data can successfully backdoor an LLM with a 90% attack success rate. You wouldn't even know that the model was compromised. It would behave normally except when specific conditions are met.

So let's set the scary stuff aside for a moment and talk about the boring, everyday risk, because honestly, that's what's more likely to get you. AI-generated code, of course, makes mistakes. Not necessarily malicious mistakes, just wrong code. A script that was supposed to clean up temporary files can delete the wrong directory. A file sync utility can overwrite the source instead of the destination. A data migration script can run on the wrong database. These aren't exotic failure modes. They're just normal failure modes of software written by someone who doesn't fully understand your environment, which is kind of exactly what AI-written code is.

And it's when you run that code locally, with full permissions, that really bad things can happen, and mistakes can become not just bugs, they can become data loss. So what works and what doesn't to keep you safe? Let's compare two common solutions, Docker and the Dino permissions that I mentioned earlier. Of course, Docker containers are the gold standard answer here. We're running AI-generated code inside a container to give ourselves genuine isolation. We have a separate file system, separate network, separate process space. So if the code does something bizarre, it happens inside this little container. The problem with Docker is the setup cost.

To use Docker isolation for every AI-generated script that you want to test, you need the Docker daemon running, you need to build or pull an image, you need to manage container lifecycle. And that's a meaningful overhead when you're in the middle of a development flow and you just want to quickly validate something. And as I mentioned earlier, we've of course got Dino's permission flags as well. And these do help if you're running AI-generated code without giving it the permissions, it can't read your files or touch the network. But of course, there's a limit here. Some code is going to need permissions in order to do useful things. And if the script legitimately needs network access, you're going to have to grant it. And then we're back to trusting the code again. And Dino's permissions protect against Dino level operations. They won't protect against things like logic errors. They won't stop a script from iterating over data in the wrong order or making the wrong API call because you've already granted access.

What we really need is a fast, low overhead way to run arbitrary code in genuine isolation with a separate file system, a separate network namespace, no access to our host environment, something that can start up super fast and requires no infrastructure setup. And this is where Dino's sandbox feature comes in. The sandbox package gives you programmatic access to micro VM-based sandboxes. These aren't containers, they're full micro VMs. Every sandbox is an independent Linux micro VM, which means that each sandbox has its own strict permissions, network policies, directories, and isolated secrets, making Dino sandbox perfect for AI agents or any other dynamic workload where speed and security are paramount. They have a separate kernel, separate file system, separate network, complete isolation from the host. And the startup time is under 200 milliseconds, which is fast enough to be practical if you're using it in an AI agent loop where you're executing generated code as part of a pipeline.

Let's take a little detour to explain the two isolation layers that are in play in the Dino sandbox. Firstly, we've got our V8 isolates. These are how Dino and Node and Chrome isolate JavaScript execution contexts. Each has its own heap, its own garbage collector, no direct access to other isolates. They're lightweight and fast. And Dino deploy uses isolates to run thousands of functions on shared hardware very efficiently. Isolates are great for untrusted JavaScript code, but they are running in the same operating system process. Whereas micro VMs go a bit deeper. The Linux micro VM is a real virtual machine. It's got its own kernel, its own file system, its own networking stack. So code running inside it has no path back to your host machine. And this is the kind of isolation that you want when the stakes are a bit higher.

If you're running AI generated code that might potentially do anything. And Dino sandbox feature layers both. The JavaScript runs on the V8 isolate, and that isolate runs inside a micro VM. So you get the speed of isolate based execution with the security guarantees of hardware level virtualization.

Let's take a look at sandboxes in practice. I'm going to use the cloud API to generate some code, and then I'm going to execute it inside the Dino sandbox. So that even if cloud produces something that tries to read my file system or make unexpected network calls, it runs in complete isolation.

So the first thing that we're going to do, I have already added our Anthropic API, our Anthropic SDK, sorry, and our Dino sandbox SDK. So I'm going to start by importing them into this project. Then I'm going to create an Anthropic client and tell it to actually do something. Now we're going to get the AI generated code out of Claude's response, strip it, get the raw source code, and create a sandbox using the AI generated code.

The Anthropic SDK allows communication with the cloud, and the Dino sandbox SDK sets up a secure micro VM. Creating an Anthropic client involves specifying actions. The client automatically retrieves the Anthropic API key from the environment variables. Now, requesting Claude to generate a Dino script to fetch Bitcoin price from CoinGecko and display it as markdown code.

Extracting the generated code from Claude's response involves stripping the markdown. The next step is to create a sandbox using the AI-generated code. Implementing a hard timeout prevents code from running indefinitely. Network access is limited to api.coingecko.com to ensure security. The process output and errors are managed to catch and display them effectively.

Running the code inside the sandbox ensures isolation from the host system. The sandbox's isolated file system enhances security. Setting permissions and environment variable access for the code execution is controlled. Implementing a process timeout prevents potential infinite loops. Finally, waiting for the process to finish and displaying the results completes the secure code execution process.

So I'm going to use the await sandbox.create, and we're going to await using. The await using syntax here is a new bit of JavaScript that is automatically destroyed when the scope ends to prevent resource leaks. Taking the AI-generated code and writing it into the sandbox's isolated file system ensures no interaction with the host system. Running the code in the sandbox with restricted network access and piping output for error handling is the next step.

Adding a hard timeout feature is crucial to prevent potential infinite loops or malicious behaviors. The timeout mechanism ensures that the code execution process is terminated after 10 seconds, irrespective of its state. Waiting for the process to complete and displaying the results encapsulates the secure execution process. By testing the setup, the code is run in the sandbox with specific permissions and environment access to verify its behavior.

Utilizing sandboxes as full VMs provides a secure environment for generating and executing AI code. These sandboxes enable the isolation of processes, preventing unauthorized access to sensitive resources. Snapshotting the VM allows for rapid deployment and execution of multiple instances for efficient code processing. However, a challenge arises when AI-generated code requires API calls, necessitating the secure passing of API keys to maintain data security.

And then finally, I am going to wait for the process to finish, and I am going to print the results. So let's test it out, shall we? So I can do dno minus a, which is going to give all permissions. And I'm going to do minus minus m file. Which is going to give it access to the environment variables in that m file. And I'm going to say run. Oh, no. Let's get this right. No, run. Goodness, I can't type today. M file, and it is main.ts that I want to run. So what it's doing now is it is creating a sandbox, and then it's going to ask Claude to generate that code, and it's going to output it, which it has done here.

Brilliant. And sure, that wasn't super impressive to look at, but the important thing that has happened here is that even though the code was generated by an AI, and I haven't read every line of it, I haven't read any line of it, to be honest, it can only reach api.coingecko, it can't read any of my m file, it can't write to my file system, it can't call home, and if it runs for longer than 10 seconds, it's going to get killed. And yes, this is somewhat of a contrived example, but I wanted something that I could show you quickly.

And since these sandboxes are full VMs, you could, of course, install Claude directly onto a sandbox and use that to generate code, rather than what I've done here, which is generating it on my local machine. And sandboxes allow for snapshotting of your VM, so you could, in theory, install Claude, any other tools that you want, take a snapshot of the VM, and then you'd be able to spin up multiple versions of that in under 200 milliseconds, allowing for really fast code execution times for your Claude prompts and code.

But there is one more problem here that I've not spoken about yet. If you're running AI-generated code that needs to make an API call, you're going to need to pass your API key to it, and that's going to cause a problem. The code needs the credentials, but if you inject those credentials as an environment variable in your sandbox, you're back to the situation that we started with, untrusted code that can read your secrets and send them anywhere. And the great thing about this is that Deno sandboxes have a secrets option, specifically for this case.

So let's have another look at a demo. I'm going to pass that API key from my environment file to the sandbox, and I'm going to print out the API key in the sandbox logs. So let's have a look at that. So when I created my sandbox earlier, I'm going to pass it a secrets option. So in here, you can see I've given it secrets, I have passed it my Anthropic API key, which it is getting from my environment variables. And I'm saying the only thing that it's allowed to be sent to is api.anthropic.com.

And now if I echo out my API key, let's do that right at the end, and we run it again. So here we're spinning up another sandbox. Now creating another app and hopefully getting our Bitcoin price again. There we go. Okay, we got a new price this time. We got a slightly different output because we generated brand new code. And you'll notice that our API key has been replaced by a secret placeholder. The only thing that the sandbox can see is this placeholder string. And the real key is only replaced when the sandbox makes an outbound API call to an approved host.

And it's doing so through a proxy which knows about that placeholder and can swap out the real key for the placeholder. If your prompt injected code tries to exfiltrate your API key, all it gets is a useless placeholder. So let's try and bring this whole thing together.

The JavaScript ecosystem has got a supply chain problem and it is getting worse. The Chalk attacks are no longer theoretical. ShaiHuLu'd compromised hundreds of packages and millions of downloads. The Chalk attack required nothing more sophisticated than a phishing email. And the malware, when it lands, goes straight for your credentials and your environment variables.

And AI assistants, we love them. They're genuinely useful, but they're also genuinely risky. They can expose your API keys. The code that you generate can do unintended things. As prompt injection research matures, the question of whether an AI coding assistant can be turned against you is moving from theoretical to practical very quickly. But the good news is, we do have real working defenses.

Firstly, make sure you always run your code with the least privilege possible. Whatever runtime you use, give code the minimum permissions that it needs. Assume that any package you install could be malicious because one day, one of them will be. Always treat your AI generated code as if it is untrusted code. Review it. Run it in isolation, at least the first time. And don't give it the same implicit trust that you'd give to code that you wrote yourself. And finally, use sandboxing for execution that you don't control. Whether it's AI generated or user generated or just packages that you don't trust, don't run code that you don't trust on your own machine. Don't give it access to your secrets. Keep your work and your data safe.