Your code is fine. Your dependencies are somebody else's Monday.

Your code is fine. Your dependencies are somebody else's Monday.

Every small team audits its own code and ships somebody else's. Ten percent of your product is yours; the rest arrived through npm, PyPI, Docker Hub, and GitHub Actions — each one a stranger with access to your build. The worst incidents of recent years weren't breaches of anyone's app: event-stream, colors/faker, xz — all supply-chain events. The applications were innocent and went down anyway.

The enterprise answer is SBOM platforms and binary transparency. The small-team answer is a half-day of setup and four habits.

1. Count what you actually ship

Run npm ls --all or pip freeze and write down the number. Most teams guess low by 5x. Then add the things that aren't packages: container base images, every uses: line in your GitHub workflows (that's third-party code executing with your secrets attached), Terraform modules, vendored binaries.

Now pick the four dependencies that would end the company if compromised — usually the framework, the auth library, the deploy path, one SDK. Those four get strict rules. Everything else gets boring rules. That's the entire prioritization.

2. Shrink the chain (the highest-yield hour)

The cheapest security control in software is deletion. Run depcheck, kill the dead weight — the left-pads, the second date library, the utility belt you use three functions of. Most teams cut 20–40% of dependencies in one sitting, and every line you delete is a line that can never be compromised.

Then adopt the one-question rule for new packages: what does this do that I can't write this afternoon? A JSON parser, yes. A 40-line README from a repo with two contributors, no.

3. Lockfiles are load-bearing

Commit the lockfile for applications. Pin direct dependencies and CI actions at versions (SHAs for actions — tags move, SHAs don't). Update on a monthly treadmill so diffs stay reviewable, because the alternative is the terrifying 400-line upgrade you'll never fully review.

And install from the docs link, not from memory: reqeusts and crossenv exist because typing is a skill.

4. CI is the machine holding your secrets

Every workflow step executes third-party code. So: pin actions to full SHAs, set GITHUB_TOKEN permissions to contents: read unless a job truly needs more, require review on .github/workflows changes (a workflow edit is a repo takeover wearing a diff), and never give fork PRs secrets. The free harden-runner action egress-watches jobs, so an exfiltration attempt is a red line instead of a quiet success.

Build in CI from a clean checkout, never a laptop. Pin base images by digest and rebuild monthly — that's what makes the lockfile mean something.

When the next big one lands (it will)

• Minutes 0–10: grep your lockfiles for the package and version. No hit? Document it and move on. This step is why the inventory exists.
• Minutes 10–30: rotate the CI/deploy secrets that touched the affected path (create → deploy → verify → revoke), check egress logs against the published IoCs.
• Minutes 30–60: upgrade, rebuild from the fixed base, redeploy, and write the timeline down.

That's the whole playbook — and it's also why "we'll inventory dependencies later" is the expensive version. The inventory is what turns a terrifying ecosystem-wide CVE into a ten-minute grep.

The full checklist — dependency inventory, shrink-the-chain tactics, SHA-pinned workflows, digest-pinned bases, and the response hour — is on our ops notes site: Software Supply Chain Security Checklist.

If you want the response muscle around it, the Ops Starter Kit is $14 and gives you the fillable incident plan, severity matrix, and comms templates. The First 30 Minutes one-pager is free, and the Automation Starter Pack covers the rotation workflows. Launch week: 30% off paid kits with code HIVE-LAUNCH30.

Honest question: do you know, right now, how many packages you'd have to check if a critical CVE dropped tomorrow — or would you find out by reading lockfiles under pressure?