Supply Chain Security

---
name: supply-chain-security
description: "Vet dependencies before they enter the build: typosquats, dependency confusion, malicious packages, known vulnerabilities, unlocked resolution, risky install and build hooks, EOL embedded runtimes, and the authenticity and freshness of your own release channel. Use when adding or upgrading a dependency, reviewing package manifests or lockfiles, configuring package sources or internal namespaces, or publishing a package or application update."
---

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/supply-chain-security/SKILL.md. -->

# Supply Chain Security

Vet dependencies before they enter the build: typosquats, dependency confusion, malicious packages, known vulnerabilities, unlocked resolution, risky install and build hooks, EOL embedded runtimes, and the authenticity and freshness of your own release channel. Use when adding or upgrading a dependency, reviewing package manifests or lockfiles, configuring package sources or internal namespaces, or publishing a package or application update.

## 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.

## NEVER

- Bypass the ecosystem's artifact-integrity verification. Disabling audit (`npm config set audit false`) or reproducibility (`--no-package-lock`) is neither.
- Use unfrozen resolution in CI or production when the project has a committed lockfile.
- Let an internal-only package identifier resolve from an untrusted public source.
- Treat popularity, package age, name similarity, or the mere presence of a signature as sufficient evidence that a dependency is trustworthy.
- Execute unreviewed dependency install or build hooks in a privileged build environment.
- Ship an unsupported or known-unpatched embedded runtime.
- Allow broadly authorized release publishing, or execute an update that has not passed authenticity and freshness checks.

## KNOWN FALSE POSITIVES

- Maintained forks with distinct names, once repository and maintainer identity are verified.
- A new release of an established package is not a newly created package identity.
- Internal packages absent from public registries, where the organization controls source routing.
- Audited build hooks executed in an isolated, least-privileged builder.
- A supported and patched embedded runtime, bundled deliberately.
- Verified auto-update: the finding is an unauthenticated, stale, downgradeable or otherwise untrusted update path, not the presence of auto-update.

## Reference files

Read these only when the task calls for them.

- `references/ecosystem-controls.md`
- `references/verifying-findings.md`