Menu

Individual skill

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.

dist/agent-skills/.agents/skills/supply-chain-security/SKILL.md

Read pinned source

Source commit eaba88102d91df65a9aa6397e8507c315c018f5e

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Instructions only
Last checked
Nov 6, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
23
Repository last updated
Aug 14, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

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