The indie founder’s 30-minute supply-chain survival kit

You're a solo founder. Your stack is Next.js + Postgres + Stripe + Resend + Vercel. Two AI assistants help you scaffold features. You ship to production from your laptop. Your node_modules directories outnumber your real customers, two to one.

You also have one Stripe account with real money flowing through it, one Postgres with real customer data in it, and one AWS account that bills you whether you're paying attention or not.

If you have 30 minutes, here's the smallest set of supply-chain hardening that meaningfully reduces your risk. Each step is independent — do as many as your patience allows.

Step 1 (5 minutes): rotate the credentials that don't expire

The single biggest indie-founder risk: long-lived API keys sitting in .env files, on developer machines, in CI environment variables. Half of them were created in 2023 and have never been touched. Each one, if leaked, is a problem that wouldn't have happened if the key was rotated quarterly.

Today, right now:

• Stripe → Dashboard → Developers → API keys → Roll your restricted keys. Use restricted keys, not full-access secret keys.
• AWS → IAM → rotate any access key older than 90 days. Convert IAM users to IAM roles where possible.
• GitHub → Personal access tokens → audit and revoke anything you don't recognize.
• npm → npm token list → revoke tokens you don't actively need; for publishing, use granular tokens scoped to specific packages.

This step protects you against the most likely supply-chain incident: a credential-stealing npm package that you installed last year while vibe coding. If it grabbed your AWS key, the question is whether that key is still valid today. If you've rotated, it isn't.

Step 2 (10 minutes): set up the install-time gate

The next-biggest risk is the install you're about to run. The fix is to put a check between your terminal and the registry.

curl -sSL get.veln.sh | bash
veln onboarding
veln wrapper on

After the shim install, every npm install, yarn add, pnpm i, pip install, uv pip, poetry add, and pipx install on your laptop routes through a local proxy that scores the package on more than twenty trust signals before download. Bad ones return 403. Your workflow doesn't change — npm install still works the same way; it just refuses the actively malicious packages.

The defaults are tuned for solo developers. You'll likely never see a false positive in normal use. When you do, you get an interactive prompt with the exact path the install tried to touch, and one keystroke approves it for the project.

Step 3 (5 minutes): lock your CI

Your laptop is target #1. Your CI is target #2 because it has the production credentials. The same gate runs in CI:

In your GitHub Actions workflow, replace npm ci with veln safe npm ci. The build refuses any package that fails the gate; the deploy doesn't happen if the install was malicious. Three lines added to your YAML.

While you're in there:

• Pin your action versions by SHA, not by @v3. (actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab, not actions/checkout@v4.)
• Use GitHub's permissions: block to limit each workflow's token scope.
• Set secrets only at the workflow level, not the repo level, when you can.

Step 4 (5 minutes): clean the graveyard

Open ~/code. Run:

find . -type d -name node_modules -mtime +180 -exec du -sh {} +

That lists every node_modules you haven't touched in 6 months. Delete them. They contain packages that have had vulnerabilities (or hijacks) disclosed since you installed them, and they're sitting there with your user's permissions to read.

Same for Python:

find . -type d \( -name '.venv' -o -name 'venv' \) -mtime +180

Disk space recovered: 5-50 GB typically. Attack surface recovered: more than you'd think.

Step 5 (5 minutes): tighten the AI assistant rules

If your AI coding tool supports a project-level rules file (most modern ones do — check your tool's documentation for the exact filename), add the following rules:

• Never run npm install without a specific version number (no @latest, no unpinned).
• Always check that suggested packages exist on npm before recommending them.
• Always check the package's first-publish date and downloads before suggesting.

A project-level rules file propagates these rules to every AI interaction in that project. The AI mostly listens. The cases where it doesn't, the gate from step 2 catches.

What this prevents

In aggregate, these five steps prevent:

• Slopsquatted packages from installing (step 2 + step 5)
• Hijacked legitimate packages from installing (step 2)
• Old credentials being useful after a leak (step 1)
• Production deploys with malicious code (step 3)
• Old graveyards being exploited (step 4)

What they don't prevent: a zero-day in a legitimate package you've used for years, a runtime attack inside your own code, a Stripe-account-level compromise (different threat model entirely). Those require different defenses.

But the recent corpus of indie-founder incidents — random crypto-stealing npm packages, leaked AWS keys from compromised dev machines, GitHub PATs grabbed via postinstall scripts — those five steps cover.

30 minutes. Once. The license cost ($4.99/mo for the gate) is less than your Vercel bill. The peace of mind is more than your Vercel bill is worth.