NPM Dependency Supply Chain Nightmare: Billions of Downloads at Risk - Fystack Remains Unaffected

On Sep 8, 2025 The NPM account of the a popular developer qix was compromised, he is managing some of famous packages with a total of 2 billions of downloads per month chalk, strip-ansi, and color-convert.

Effect on Fystack

Fystack is not affected by the recent NPM supply chain attack. Our frontend stack is the only part of our system that relies on NPM dependencies, and we use a minimal set of packages, which significantly reduces our exposure to these types of attacks.

We also follow strict security practices:

• Thorough dependency audits: We reviewed all dependencies and confirmed none are compromised.
• Locked dependencies: All packages are pinned and locked via package-lock.json, preventing unexpected updates.
• Robust CI/CD pipeline: Our build process leverages security tools like Snyk and Socket Security, which automatically scan and block risky packages before merging.

Together, these measures provide multiple layers of defense and help minimize the risks of supply chain attacks.

Rule of Thumb for Developers

Publisher Side

When publishing to NPM, keep in mind:

• Running npm login generates a plain-text authentication token stored in ~/.npmrc.
• This token never expires by default and is not protected by any keychain or credential manager.
• Unlike Docker, NPM does not integrate with secure credential stores, meaning your token is always stored in plain text on disk.

Always treat this token as highly sensitive. Consider logging out after publishing or enabling 2FA on your NPM account to reduce risk.

As a publisher, be careful of phising and social engineering attacks.

Consumer side

1. Keep dependencies patched

• Run npm audit fix regularly to apply the latest security patches.
• Make it part of your CI/CD or local workflow to ensure vulnerabilities are caught early.

2. Inspect the dependency tree

• Use tools like npmgraph.js.orgto visualize dependency trees.
• Prefer packages with a minimal number of dependencies (e.g., react-query keeps its tree small).
• Be cautious with bloated packages (e.g., @metamask/sdk), as a large dependency tree increases your attack surface.

3. Use precise version numbers

• Always pin dependencies in package.json to exact versions (e.g., "react": "18.3.1") instead of version ranges (^1.2.3 or ~1.2.3).
• Precise versions reduce the risk of introducing untested or malicious updates.

Example with a pinned version:

{
"name": "my-package",
"version": "1.0.0",
"dependencies": {
"react": "18.3.1"
}
}

While package-lock.json (or yarn.lock) captures exact versions for reproducibility, it’s not a substitute for explicit version pinning.

• Lockfiles can be deleted, regenerated, or ignored in some workflows.
• Explicit version pinning in package.json provides a stronger baseline, while the lockfile ensures consistent installs across environments.

This way, your builds are reproducible, harder to tamper with, and easier to audit for security compliance.

At Fystack, as a wallet infrastructure company, security is not just a best practice, it’s our top priority. From dependency management to CI/CD hardening, we follow strict security standards to safeguard our systems and ensure our clients can build with confidence.