supply-chain-security

Supply Chain Security

Rules (for AI agents)

ALWAYS

• Verify the identity of a new dependency before adding it: registry metadata, repository URL, maintainer set, and provenance checked against the signer you expect. Name-similarity screening opens the question; it never answers it.
• Query the bundled malicious-package data before adding any dependency — check_dependency, check_typosquat and lookup_vulnerability read it, this file cannot. Match on ecosystem, normalized name and affected version range; an active match on the resolved version blocks.
• Treat package age, download volume, maintainer count and activity as risk signals, never as proof of trust. Defaults: a verified maintainer signal within 90 days of a package identity's first publication, plus a documented reason within 30 days.
• Lock the resolution graph for anything you deploy — commit the lockfile, install frozen in CI (npm ci, --frozen-lockfile, pip --require-hashes, cargo --locked). Lock what you deploy, range what you publish: a library's dependency metadata needs compatibility ranges.
• Restrict where packages resolve from, so an internal-only identifier cannot come from a public registry. Use the ecosystem's own mechanism — npm scope-to-registry, Gradle exclusiveContent, a single authoritative index for Python, which has no scope isolation at all.
• Treat install and build hooks (postinstall, setup.py and modern build backends, build.rs) as arbitrary code execution. Review them, and run dependency builds in an isolated least-privileged builder — most ecosystems ship no install sandbox.
• Triage vulnerabilities on severity, exploitability, deployment context, reachability where the tooling genuinely supports it, and fix availability together. A material vulnerability with no published fix needs mitigation or a recorded risk acceptance, not a pass.
• Never carry reachability or dev-only reasoning across to a suspected malicious package or build-time compromise. A hostile postinstall already ran in your build environment with your CI credentials, whatever production imports.
• Surface trust-boundary changes on any update regardless of version number: a maintainer or ownership change, a new or changed install hook, a source transition, a provenance regression. cicd-security owns the approval policy that acts on it.
• Track bundled runtimes and engines (Electron, CEF, Chromium, system WebView, a JRE) against upstream support windows and advisories directly. Wrapper-package scanners match the wrapper version and can report clean while the engine is unpatched.
• Protect your own release channel: restrict publish privileges, verify updates against a trusted signing identity or update framework, and reject stale or downgraded releases. A checksum served beside the artifact is not authentication.