Files
upstream-atomic-crm/.claude/rules/dependency-safety.md
upstream-mirror 93ecc1a6f8
Some checks failed
✅ Check / 🔬 ESLint (push) Failing after 21s
✅ Check / 🏷️ Typecheck (push) Failing after 11s
✅ Check / 🔎 Test (push) Failing after 11s
✅ Check / e2e-test (push) Failing after 11s
✅ Check / 🔨 Build (push) Failing after 11s
🚀 Deploy / 🚀 Deploy (doc) (push) Failing after 12s
🚀 Deploy / 🚀 Deploy (demo) (push) Failing after 12s
🚀 Deploy / 🚀 Deploy (supabase) (push) Failing after 18s
snapshot of https://github.com/marmelab/atomic-crm.git (main, 2026-09-18; blobs > 131072B omitted)
2026-09-18 01:48:50 +05:00

26 lines
1.2 KiB
Markdown

# Dependency safety
Adding a new package is a supply-chain decision, so agents never do it silently.
## Rule
- New-package installs are denied by permissions (`settings.json` -> `permissions.deny`:
`Bash(npm install *)`, `Bash(npm i *)`, `Bash(pnpm add *)`, `Bash(yarn add *)`). A
deny is ~100% respected; a CLAUDE.md rule or a post-action warning is not.
- Bare `npm install` / `pnpm install` / `yarn install` (no package argument, restoring
the lockfile) stays allowed: the literal space in the deny glob requires an argument,
so an argument-less install is not matched.
- To add a package, the human validates THAT specific package first: minimum 21 days
since publication, healthy download/maintainer count, no open advisory
(`npm audit`, Snyk).
## Third-party skills and MCP servers
- Treat a downloaded skill/plugin (marketplace or external repo) like an npm dependency:
the same audits apply (they have shipped hardcoded secrets and malicious payloads).
- Pin an MCP server's version once validated; do not let it auto-update without a fresh
human check.
Automatic blocking reduces risk, it does not remove it: a periodic security review is
still required for anything touching auth, payments, or sensitive data.