Built and run by one person.

How do I protect my app from an npm or pip supply-chain attack?

There is no single control, because the attacks come in different shapes and each layer only covers one. Here is the stack, and what each layer does not cover.

1. Quarantine fresh releases (cooldown). Refuse to install any version published less than N days ago. This is the single most powerful defense against the compromised-maintainer class, where a trusted package gets a poisoned release. Detail here. It does not help against typosquats or old CVEs.

2. Block postinstall scripts by default, with a narrow allowlist. The postinstall is usually where the actual exfiltration happens. Detail here.

3. Pin properly, and keep it pinned: a committed lockfile, a frozen install command in CI, exact pins with no caret or tilde, and pin the package manager itself (it is what enforces everything else). Detail here. When you first pin, pin to what is running, not to latest.

4. Verify before install. Cooldown cannot save you from a typosquat you install for the first time, and AI assistants now invent package names that attackers register. Detail here.

5. Audit for known CVEs (npm audit, pip-audit) on a cadence. Exact pinning protects you from fresh malicious releases but also means you do not auto-pick-up security patches, so audits are the complement: cooldown defends against new-and-malicious, audits against old-and-known-bad. Assess whether a CVE actually affects your code path rather than running npm audit fix --force, which force-bumps transitive deps you never reviewed.

6. Self-host critical CDN assets. A compromised CDN executes in your domain's security context with access to cookies, localStorage and the DOM, and none of the above helps because there is no install step. Copy critical JS/WASM/fonts into your own public/, or use Subresource Integrity hashes if that is impractical.

Full item-by-item checklist with code: https://www.tigzig.com/security/supply.

← All Agents FAQ