What is a supply chain attack and how to reduce security risks

When you install a dependency for a project, you trust an entire chain of code you never wrote. A supply chain attack exploits exactly that trust: instead of attacking your site directly, the attacker compromises a library that thousands of other projects already use and waits for you to install the infected version.

The case that shows the scale of the problem

In a campaign that hit axios, a JavaScript library widely used to make HTTP requests, someone took control of the lead maintainer's npm account and published two malicious versions, about 39 minutes apart, as if they were regular releases of the project. The versions stayed online for a few hours, until npm removed them.

It was not an isolated case. ReversingLabs, a software security company, recorded an increase of about 73% in detections of malicious open source packages in 2025 compared to 2024, with more than 10,000 identified on npm alone. And in a recent campaign called Shai-Hulud, more than a hundred npm packages were compromised by code that replicated itself.

How the attack spreads

The mechanism usually follows a simple pattern:

1. The attacker steals a maintainer's credentials (phishing, social engineering, or a token leaked from another compromised service)
2. They use those credentials to publish a new version of the package, with malicious code hidden inside
3. Anyone who installs or updates the dependency gets the infected code along with it, without noticing, because the package still comes from the "official" source
4. In some cases, the malware can replicate itself: it uses the stolen tokens to find other packages from the same maintainer and infect those too, creating a chain effect

That is the core danger: from the point of view of the person installing it, it looks like a normal update. There is no warning, no alert: it is just one more version of a library you were already using.

If your site has a backend: what you can do

For anyone running applications with a server (most sites), there is no magic solution, but there are practices that reduce the risk a lot:

• Pin dependency versions (lockfiles, such as package-lock.json) instead of always pulling the latest version automatically
• Audit dependencies regularly with tools such as npm audit, Socket Security or Snyk, which monitor packages known for suspicious behavior
• Review what an update really changes before applying it in production, especially for libraries with a lot of access (authentication, file handling, network requests)
• Use trusted publishing when available: a more recent mechanism that removes the need for long-lived tokens, reducing what can be stolen
• Limit what the backend can access, following the principle of least privilege: if a compromised dependency only has access to what is strictly necessary, the potential damage is smaller

None of these practices is a total guarantee. A supply chain attack is, by nature, hard to prevent completely, because it exploits the very trust that makes the package ecosystem useful.

If your site has no backend processing files

That is the case with Kastavo. Because the tools run entirely in the browser, there is no server receiving the person's file and processing it with backend dependencies. So one specific attack vector simply does not exist here: a compromised server-side dependency has no way to reach files that never arrived at that server, because they never leave the device of the person using the tool.

This reduces exposure, but it does not remove all risk. A client-side architecture still depends on:

• Dependencies used during development and build: if a library used to build the site is compromised, the code that reaches the person's browser can be affected
• Third-party scripts loaded on the page: any external script (analytics, ads, fonts) is, in itself, a dependency you trust
• The integrity of the publishing pipeline itself: from the commit to the deploy, every step is a link that needs to be protected

That is why, even without a backend processing files, it is still worth applying the same practices from the previous section (lockfiles, auditing, least privilege) in the development and build environment.

The lesson that remains

A supply chain attack is not a problem solved by a single tool or setting: it is a category of risk that grows with the number of dependencies any modern project accumulates. The architecture of where processing happens (server or browser) changes which vectors exist, but it does not replace the basic security practices in either case.

The most useful question, when choosing a tool for a sensitive file, is not just "is it secure?" but "what exactly is it exposed to, and why?"