Supply-Chain Hardening

Installing or importing a dependency runs someone else's code with your privileges. Every control in this skill exists to change what that sentence permits: when the code runs, whether it runs at all, what it can do when it does, and how you find out it was hostile.

This is a content skill, not a tool: it owns the reasoning - which control, which layer, whether to allow an exception - while config files own the rules. It serves three situations: hardening a project, hardening a machine or global config, and an agent mid-task when a gate fires.

Principles

1. A dependency is code execution, not data. Adding a package grants its

publisher - and whoever compromises them - execution on your machines and CI. Vet accordingly, and extend the same reasoning to non-package dependencies: GitHub Actions, base images, MCP servers, agent skills.

1. Removing triggers is not removing capability. Blocking install scripts

stops one execution path; the code still runs on import with full privileges. Every structural control closes a trigger; attackers move to the next one. That's why layers, not any one switch.

1. Layer for defence-in-depth, and know each layer's limit. Age gates

detect nothing; scanners prevent nothing; provenance authenticates the pipeline, not the payload; runtime "permission" flags are seat belts, not boundaries. A layer whose limit you can't state is a layer you're over-trusting.

1. A gate set is not a gate enforced. Some tools' gates are advisory by

default (aube falls back to an older version unless minimumReleaseAgeStrict = true; pnpm's built-in default gate is non-strict, though explicitly configuring the gate flips strict on). After configuring any gate, verify it fails closed - try to install something that should be refused. When a broader control masks a narrower one, that verification is unavailable: the narrow gate has nothing to refuse, so it stays silent locally and fires on the first machine without the mask. Reproducing it means turning the broad control off, which is a de-protection, not a check - assert the missing decision statically instead (read the config, run no install).

1. The agent proposes; the user decides; something boring verifies.

Allowlisting, bypassing, and weakening are the user's security decisions. Enforcement belongs in config, hooks, and CI - never in anyone's memory.

1. Every exception is scoped, reasoned, and has an exit criterion. An

exception without an expiry condition is a permanent hole with a historical excuse. See [references/exceptions.md](references/exceptions.md).

When to use this skill

• New project or machine → walk the five-layer stack below; per-tool keys

and drop-in blocks in [references/ecosystems.md](references/ecosystems.md).

• Hardening incrementally → audit the existing setup against the stack;

the usual gaps are a non-strict gate, an uncovered frozen-install path, and no detective layer.

• A gate fired mid-task → jump to "When a gate fires" below. Never bypass

globally to keep a task moving.

• Unfamiliar or agent-suggested package → verify before installing (see

"Slopsquatting").

• Scanner hit or suspected compromise →

[references/incident-response.md](references/incident-response.md).

• "Should we buy a scanner/firewall product?" →

[references/evaluating-dependencies.md](references/evaluating-dependencies.md).

Scope fence: if the task adds no dependency and touches no package-manager or CI config, this skill has nothing to add - do the task without narrating supply-chain considerations.

Trigger vs capability

ignore-scripts removes a trigger, not a capability. Reason about which execution triggers an ecosystem exposes, because closing one does nothing for the others:

The load-time column is why "scripts are disabled, we're safe" is false, and why the detective layer and containment exist. Runtime containment: real boundaries are containers/VMs with no egress; Node's --permission is, per its own docs, a seat belt and not a security boundary (known gaps: node:sqlite filesystem access, no worker-thread inheritance, pre-init flag escapes).

The five-layer stack

Layer 5 is not optional garnish: malware campaigns have shipped with valid SLSA provenance (a compromised pipeline signs its own malware), and the large majority of malicious packages are pulled by registries without ever receiving a CVE - so neither provenance nor CVE feeds substitute for MAL-* matching. Provenance ≠ safety.

Slopsquatting

Agents hallucinate plausible package names; attackers register them. Before installing anything unfamiliar - especially a name suggested by an agent or LLM output - verify existence, purpose match, age, downloads, and repository; a brand-new low-download package answering exactly a niche need is the attack shape. A strict age gate refuses brand-new names as a side effect; low-download-threshold checks (aube) encode the same defence.

Age-gate units: never copy a number between tools

The same 4-day policy is spelled in days (npm), minutes (pnpm, aube, Yarn), seconds (bun), duration strings (mise, uv), and ISO-8601 or minutes (P4D/5760 - pip, Deno; Deno rejects 4d). Copying a literal between configs silently changes the policy by orders of magnitude. Full table and per-tool keys: [references/ecosystems.md](references/ecosystems.md).

When one policy value is hand-spelled across several configs, enforce agreement mechanically - a drift-guard pre-commit checker (one constant, one file+regex+unit row per config, normalise, fail on drift). The mechanical-enforcement skill owns that checker pattern.

When a gate fires mid-task

The most common agent-facing situation: an install refused, a build script blocked, a provenance or trust-policy failure. The gate firing is the system working - the burden of proof is on the bypass.

1. Identify which control fired and what it's protecting against. Read

the error, not just past it (ERRPNPMIGNORED_BUILDS = script blocking; "no mature version" = age gate; trust/provenance = downgrade check).

1. Decide whether a bypass is even wanted. Often the right move is to

wait out the quarantine, pick an older version, or drop the dependency.

1. Ask the user. The security decision is theirs - never auto-bypass,

however small the exception seems. Present the narrowest option and what it trades away.

1. Allowlist narrowly: per-package allowBuilds/approve-scripts/

scoped exclude - never a global disable, never ignore-scripts=false, never removing the gate. Project-level is not the narrow option: it is not per-package, and it re-arms scripts the per-package allowlist does not govern - the root package's own preinstall/install/ postinstall run again (silently arming repo git hooks from prepare, among other things), and every allowBuilds: { x: true } in the repo flips from inert to executing. Turning the mask off changes what runs; it is a de-protection, never a diagnostic.

1. Document scope, reason, and exit criterion in the config where the

exception lives - see [references/exceptions.md](references/exceptions.md) for the template and worked examples (publishing-bug-vs-attack, aged backports).

Hard lines: never --no-verify past a supply-chain hook; never disable a gate globally or project-wide to save a round-trip; a one-off env/flag bypass is for human-attended one-shots only (the per-tool asymmetry - which tools even offer one - is in [references/ecosystems.md](references/ecosystems.md)).

Composition with neighbouring skills

• mechanical-enforcement owns linter-shaped controls - gitleaks, zizmor

for GitHub Actions, cargo-deny licence/advisory bans, and the generic config-drift-guard checker pattern. This skill owns dependency posture: what to gate, what to scan, when to except.

• hk owns wiring: this skill says what to run (osv-scanner as update

task + CI gate + hook); hk says how to hook it.

• security-review reviews your own code for vulnerabilities; this skill

governs third-party code you adopt.

Adding a new control or ecosystem

1. Identify which layer it belongs to (quarantine / structural / containment

/ CI / detective). If it claims two, it's probably two controls.

1. Prefer structural removal over runtime mitigation, and automated detective

wiring over a manual task.

1. Record the tool's key, unit, and strictness default in

[references/ecosystems.md](references/ecosystems.md) - verify each against the live tool, not memory; units and defaults are where the traps live.

1. Note the new tool's escape hatches and exception vehicle, and whether its

gate applies on the frozen/lockfile install path.

References

evals/ holds this skill's test prompts, fixtures, and assertions - run per the writing-skills evals harness when revising. The compromised-lockfile fixture is inert grading text; never install from it.