Protecting your Supabase projects from npm supply chain attacks

Summary

The post explains why npm supply-chain attacks matter to Supabase projects: Edge Functions, the Supabase CLI, and packages including supabase-js, @supabase/ssr, and @supabase/server all depend on npm. Attackers can compromise maintainers, register typosquats, or exploit build pipelines; once malicious code reaches node_modules, lifecycle scripts may read environment variables, cloud metadata, tokens, kubeconfig, and SSH keys. The proposed defense is layered: upgrade to pnpm 11, increase minimumReleaseAge to several days, pin sensitive dependency versions, commit and review lockfiles, disable or allowlist install scripts, verify package names, and pin GitHub Actions to full commit SHAs. Supabase is publishing a canonical security guide, hardening its GitHub Actions, adding secret-handling warnings to API documentation, and coordinating communications; the post also recommends rotating credentials after a potentially compromised install and using scanners as supplementary defense.

Takeaways

1. 1

   pnpm 11 sets a 24-hour minimumReleaseAge by default; the post recommends raising it to three to seven days because many malicious packages are detected and removed within 24 to 48 hours.

2. 2

   Lifecycle scripts such as preinstall, install, and postinstall can execute malicious package code during installation. The post recommends disabling them where possible or using pnpm's Allow Builds model to allowlist required packages.

3. 3

   A pull_request_target workflow that checks out pull-request code can run attacker-controlled code with access to repository secrets and caches. The post recommends using pull_request for workflows that touch pull-request code and reserving pull_request_target for trusted, no-checkout operations.