Sharing a supply-chain hardening pass I did on a Kubeagent CLI, partly hoping to get holes poked in the threat model. (Disclosure: I build KubeAgent — agentless K8s monitor/remediator; runs from your

kubectl

context, no in-cluster agent, no kubeconfig sent anywhere.) The npm worm wave (Shai-Hulud, then Mini Shai-Hulud across npm+PyPI) made me treat a dependency compromise as when, not if. What I landed on: Reduce likelihood • OIDC trusted publishing — killed the long-lived

NPM_TOKEN

(the exact credential those worms exfiltrate to self-propagate); releases now auth with a short-lived per-run GitHub token •

ignore-scripts=true

so dependency `postinstall`/`preinstall` hooks don’t execute on install • Every third-party GitHub Action pinned to a full commit SHA, not a moving tag (post-tj-actions/CVE-2025-30066); first-party

actions/*

on majors • Dep tree kept to 7 direct packages so an advisory is actually reviewable; lockfiles +

npm ci

only Reduce impact (the part I most want critique on) • The tool holds no cluster credential server-side — no SA token, no stored kubeconfig, no inbound path. So a poisoned dependency’s blast radius is bounded to the operator machine that already has

kubectl

, rather than a centrally-held secret an attacker can pivot through. Where I think I’m weakest: that last point bounds lateral movement but a malicious dep still runs with the operator’s local privileges — so it’s a reduction, not elimination. Am I framing that honestly, or overselling? And for those publishing CLIs from a private monorepo: provenance attestations aren’t possible (npm requires a public source repo) — how are you giving consumers verifiability without open-sourcing the backend? does this reassure you? was this even a concern for you? genuinely want the pushback. 🙏

Every third-party GitHub Action pinned to a full commit SHA, not a moving tag (post-tj-actions/CVE-2025-30066); first-party

actions/*

on majors

We took this one step further https://github.com/cloudposse/atmos/blob/main/.github/workflows/verify-sha-pinning.yml https://github.com/cloudposse/atmos/tree/main/.github/actions/verify-sha-pinning verify that the shas also match a commit within the repo

thanks a lot Erik. it makes sense to do

Also, make sure you have a cooldown on package updates; 7-14 days. Meaning don't pull down the latest version as soon as it's published. Require the version remain published for X days. Vulnerabilities tend to get discovered within < 14 days of published.

yeah we already do this. will look into stepsecurity as well.

And for those publishing CLIs from a private monorepo: provenance attestations aren’t possible (npm requires a public source repo) — how are you giving consumers verifiability without open-sourcing the backend?

It's a good question. I think it's hard to fast track this / short cut this. Having a track record, getting SOC2, and time in the market.

you’re correct but its tough as a new micro saas startup

Where I think I’m weakest: that last point bounds lateral movement but a malicious dep still runs with the operator’s local privileges — so it’s a reduction, not elimination. Am I framing that honestly, or overselling?

It's not a problem you uniquely face. It am terrified of it. Look at what just happened to microsoft/github when a developer installed a vscode plugin that was hacked.

yeah, what a shit show. it’s terrifying

you’re correct but its tough as a new micro saas startup

This is the conundrum we now face. Never has it be easier to start a company, build a product. Never has it been harder to cut through the noise and reach customers because the number of products and companies is exploding.

that’s our main challenge

the hard part about selling to engineers is (a) our natural instinct is to build (b) when in an enterprise have little influence over budget (c) competition with the new realtity: does it cost less just burning the tokens to build what we need?

yes. it’s still useful monitoring tool