Dependency and supply-chain security - lockfiles and reproducible installs, version pinning, vulnerability auditing, minimizing and vetting third-party packages, vendoring obscure code instead of fragile remote dependencies, and SBOM/provenance. Use when adding, upgrading, removing, or auditing dependencies, or editing package manifests, lockfiles, or build/CI dependency steps.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Dependency and supply-chain security - lockfiles and reproducible installs, version pinning, vulnerability auditing, minimizing and vetting third-party packages, vendoring obscure code instead of fragile remote dependencies, and SBOM/provenance. Use when adding, upgrading, removing, or auditing dependencies, or editing package manifests, lockfiles, or build/CI dependency steps.
Dependency & Supply-Chain Policy
Activation Scope
Apply whenever a dependency is added, upgraded, removed, or audited, and when editing package manifests, lockfiles, or CI/build steps that fetch dependencies.
This skill owns third-party dependency and supply-chain risk. Runtime application security is owned by security-policy; commit/PR mechanics by git-policy.
Add Dependencies Deliberately
Prefer the standard library or existing project utilities before adding a dependency.
Justify every new dependency: real need, active maintenance, healthy adoption, compatible license, and acceptable transitive footprint.
Avoid trivial micro-packages that add supply-chain surface for little value; a small amount of owned code can beat a risky dependency.
Watch for typosquatting and confusable names; verify the exact package name, owner, and repository before installing.
Pin & Reproduce
Always commit the lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, etc.); it is the source of truth for what actually installs.
Use reproducible, locked installs in CI and release (e.g. npm ci, not npm install), so builds are deterministic.
Pin versions deliberately; avoid loose ranges for anything security-sensitive. Upgrade intentionally, not implicitly.
Keep one package manager per project; do not mix lockfiles from different managers.
No Fragile Remote Dependencies
Do not depend on code fetched from arbitrary remote URLs or CDNs at build or runtime (aligns with ciphera-style-policy).
For obscure or unmaintained libraries, vendor the needed code into the project (with attribution and license) instead of taking a live dependency, so the supply chain stays under your control.
Pin and verify any external artifact you must fetch (checksums/integrity hashes); never trust mutable remote sources.
Audit & Patch
Run a vulnerability audit (npm audit, pip-audit, osv-scanner, or equivalent) as part of CI; fail the build on high/critical advisories.
Triage findings promptly: patch, upgrade, or document an accepted risk with justification and an expiry; do not silently ignore.
Keep dependencies reasonably current; large version gaps make security patches harder to adopt.
Prefer automated dependency-update tooling (Dependabot/Renovate) with CI gating so updates are reviewed and tested, not blind-merged.
Provenance & SBOM
For enterprise/release builds, generate an SBOM (e.g. CycloneDX or SPDX) so shipped components are inventoried and auditable.
Prefer packages and registries that support provenance/signing; verify integrity where the ecosystem allows.
Review licenses for compatibility and obligations before shipping; treat license compliance as a release gate.
Verification (Make It Mechanical)
Enforce these rules deterministically in CI: locked install, audit gate, license check, and (for releases) SBOM generation.
A dependency change is not done until the audit and license gates pass; a failing gate blocks merge.
