What is SCAL-P?

SCAL-P (Secure Chain Assurance Layer for Packages) is a security CLI that wraps npm, pnpm, yarn, and bun to enforce policy, verify integrity, and score trust — before packages hit your node_modules.

Think of it as a guard for your dependency graph: you define rules, SCAL-P enforces them every time someone runs npm install (or pnpm, yarn, bun). No SaaS, no API keys, no remote calls — it runs entirely on your machine or CI.

At a glance:

The core idea: make every dependency auditable, traceable, and controllable by policy. No implicit trust.

How it works

Every package manager follows the same basic flow: resolve dependencies, download tarballs, unpack into node_modules, execute lifecycle scripts. The problem is that execution and installation happen before you can inspect what's coming.

SCAL-P inserts itself into that flow at two points:

The wrapper pattern works like this:

# Instead of:
npm install express

# You run:
scalp install express

Under the hood, scalp install resolves the tree, evaluates policy, then delegates the actual download and unpack to npm install. If policy passes, it runs and hashes the result. If policy fails, you get a clear violation report and nothing is installed.

SCAL-P also ships a scalp ci command designed for CI pipelines that bundles all steps — resolve, evaluate, block, install, audit, report — into a single command with one exit code.

Why this exists

The npm ecosystem has over 2 million packages. That scale created a massive attack surface. Supply chain attacks via malicious packages became a critical vector — and they keep getting worse:

• debug + chalk (Sep 2025) — 18+ packages compromised including debug, chalk, ansi-styles, supports-color, strip-ansi. Combined impact: over 2 billion weekly downloads. Phishing attack on the maintainer bypassed TOTP. Payload targeted cryptocurrency wallets and Web3 transaction interception. [Cycode]
• Axios (Mar 2026) — one of the worst attacks of 2026. Compromised maintainer account published versions 1.14.1 and 0.30.4 tagged as latest. Axios has 100M+ weekly downloads. Payload: a phantom dependency (plain-crypto-js) delivering a cross-platform RAT. Stayed live for ~3 hours. [Huntress] [Elastic]
• node-ipc (May 2026) — three malicious versions (9.1.6, 9.2.3, 12.0.1) published from a compromised maintainer account. 10M+ weekly downloads. 80KB obfuscated payload in the main bundle stealing cloud and CI/CD credentials via DNS exfiltration. [Snyk] [Hacker News]
• Shai-Hulud (2025–2026) — self-replicating worm that steals npm/GitHub tokens and automatically publishes malicious versions to every package the token can access. Multiple waves ("The Third Coming", "Mini Shai-Hulud"). Uses Sigstore, OIDC abuse, and CI/CD persistence. [Palo Alto Unit42]
• Mini Shai-Hulud (May 2026) — ongoing worm campaign by TeamPCP. Compromised accounts publish 300+ malicious versions in 22 minutes. Targets include @antv/*, TanStack, SAP ecosystem, Mistral. Obfuscated Bun script steals AWS, GitHub, Kubernetes, npm tokens, and SSH keys, exfiltrates via C2 and GitHub repos, injects malicious CI/CD workflows, and self-propagates. [StepSecurity]

Existing tools address parts of the problem but leave gaps:

How SCAL-P fixes it

SCAL-P reverses the default trust model. Modern package managers execute code before you can verify what you're getting. SCAL-P flips the order:

Threat coverage

Design principles

• Zero external dependencies — only the Go standard library. Easy to build, audit, and vendor.
• Don't break the user — no policy file means allow + warn. SCAL-P shouldn't block your deploy because you forgot a config file.
• Audit-first — every event is logged before any decision is made.
• Passthrough by default, guarded by choice — scalp install without flags is transparent. --guarded activates enforcement.
• Offline-first — network is a cache amplifier, not a requirement. Trust scores degrade gracefully.
• Separate lockfile — SCAL-P locks installed content, not tarballs. Different purpose from package-lock.json.

When to use SCAL-P

• You maintain an open source project with many dependents — SCAL-P catches compromised maintainer accounts and protestware before they reach your users.
• Your CI pipeline installs dependencies on every deploy — scalp ci prevents a malicious PR dependency from reaching production.
• You ship a binary or CLI tool — scalp verify lets you checksum your releases and lets consumers verify them.
• You publish npm packages in a multi-team org — policy rules prevent any team from pulling in unapproved dependencies.
• You operate in a regulated environment — the append-only audit log gives you a verifiable record of every install decision.

When NOT to use SCAL-P

• You need zero overhead in local development — same as any security tool. Run scalp install without --guarded for transparent passthrough, or skip it entirely in dev.
• Your project has no lockfile or policy — SCAL-P works fine (allow + warn by default), but you'll get the most value with a policy configured.
• You already use a different lockfile format — SCAL-P's .scalp/lockfile.json is complementary to package-lock.json, not a replacement.

What's next?