Skip to content

Supply chain security

In the static world the attack does not come through your live site — it comes through the packages you install. What to do about it.

On a traditional platform like WordPress, security is mostly about defending a live server: unpatched plugins, guessed database passwords, an exploitable PHP runtime.

In the static and JavaScript world the threat is inverted. You are generally not attacked by someone hacking your production site. You are attacked through the open-source building blocks you used to make it.

What a supply chain attack is

When you run npm install you are not downloading one tool. You are downloading a nested web of thousands of sub-dependencies written by thousands of strangers.

A supply chain attack is a hacker slipping malicious code into one of those tiny, deep sub-dependencies. The moment you install that update, it executes on your machine — stealing local API keys, scraping .env files, or writing a backdoor into your project.

A firewall cannot help with this. The code is invited in. What works instead is policing it before it lands, freezing it once it is known good, and choosing architectures that keep the pile small in the first place.

Stage 1 — Before anything downloads

Choose a lean stack

Your largest vulnerability is the sheer volume of third-party code you inherit, so the first control is architectural.

Astro, 11ty, Pagefind keep the dependency chain small, and their maintainers actively police what gets pulled into the ecosystem. They also compile to static files — there is no live Node process on the web to exploit and nothing pulling unvetted dependencies at runtime.

Next.js, Strapi and similar carry sprawling dependency trees that no core team can fully audit, and they run a backend 24/7, so anything hidden in that chain stays exposed to the internet.

A cooldown gate on your machine

Most malicious packages are caught within days of publication. A cooldown means you are never the one who finds out first.

In a terminal:

nano ~/.npmrc

Add this one line:

min-release-age=7

Ctrl + O, Enter to save, Ctrl + X to exit. Check it with cat ~/.npmrc.

Nothing published in the last seven days will install on your machine.

The same rule on the build server

The global setting protects your laptop and nothing else. Vercel, Netlify and Cloudflare build on their own machines, so the rule has to travel with the repository.

In FEWD’s file explorer, right-click in the empty space, New File, named exactly .npmrc — leading dot, no extension. One line:

min-release-age=7

Commit it. Your cloud builds now wait out the same seven days.

Stage 2 — Freezing what you have

package-lock.json

If .npmrc is the bouncer, the lockfile is the vault. It records the exact version and cryptographic hash of every package in your working setup.

  • Never delete it, never gitignore it, never work around it.
  • Commit it every single time you install or update anything.
  • Read the diff. An unexpected transitive dependency appearing is exactly what you are looking for.

A cloud build that finds a lockfile installs precisely what you had, rather than resolving fresh versions on its own.

Cryptographic handshakes

Use OIDC rather than permanent tokens for cloud deployments. An OpenID Connect handshake is short-lived and self-destructs; a Personal Access Token sitting in a settings page does not.

Restrict workflow permissions to read-only in your repository settings, so that even a compromised build cannot write back into your source.

Stage 3 — After it is live

Cooldowns and lockfiles stop loud, immediate exploits. They do nothing about a sleeping vulnerability discovered in a package you used eight months ago.

That needs something watching continuously:

  • Locally — the Socket CLI wrapper, monitoring what changes as you update.
  • On your repositories — Snyk or the Socket GitHub App.

The point is that you stop having to remember. The day a researcher discloses a flaw in an old utility package, a pull request appears on the project that used it.

What FEWD does about it

FEWD Studio is built under the same rules: a seven-day release-age wait on the machines it is built on, lockfile committed with every change, npm audit after every dependency change with high and critical findings addressed before shipping, and the lockfile diff reviewed on every install.

The app itself ships with no credentials in the package. Licence activation talks to public endpoints where the licence key is the credential — there is no API key inside the application to extract.

When FEWD installs packages for you

The same ideas apply to the installs FEWD Studio runs for a project:

  • Nothing installs until you press Install, and the dialog says what will run.
  • A project with a lockfile installs the exact versions it lists.
  • Package scripts are skipped by default.
  • Without a lockfile, a 7-day wait applies, which you can skip for one install.

That is a precaution, not a guarantee, and it covers only installs FEWD runs. Responsibility for what you install remains yours. The min-release-age setting above covers the rest. See Security in FEWD Studio and Security notices explained.