Purpose

Reduce supply-chain risk without treating scanner output as automatically exploitable.

When to activate

Dependencies are added/updated or a security review includes third-party packages.

When not to activate

The task is unrelated to dependency state and no manifest/lockfile changed.

Preconditions

• Read applicable repository instructions before edits.
• Preserve unrelated working-tree changes and establish a baseline when the workflow can modify code.
• Identify which tools and environments are actually available; do not claim unavailable checks ran.

Required inputs

• Manifests and lockfiles
• Runtime/deployment context
• Available advisory/scanner data

Workflow

1. Enumerate direct dependency deltas and identify their package source and resolved versions.
2. Run the repository's vulnerability/advisory tooling when available and record database freshness.
3. Prioritize direct reachable/runtime findings over unrelated dev/transitive noise, while still recording all findings.
4. Check suspicious naming, unexpected registry sources, install scripts, abandoned packages, and unnecessary additions.
5. For upgrades, verify the target version exists, resolves the advisory, and remains API/runtime compatible.
6. Prefer removal or existing dependencies when the new package adds little value.
7. Run tests/build after any remediation.

Relevant tools

Package manager, advisory scanner, registry metadata, lockfile diff.

Safety restrictions

Do not run package install scripts solely to inspect a suspicious package; inspect metadata/source first.

Validation

• Scanner/advisory output is captured with versions and timestamp/source.
• A remediation is verified against both advisory state and application tests.
• Unresolved findings retain severity and rationale rather than disappearing from the report.

Expected output

• Dependency delta
• Findings with provenance
• Remediation and compatibility evidence
• Accepted/unresolved risks

Failure handling

If advisory access is unavailable, perform local provenance/manifest checks and explicitly mark vulnerability freshness unverified.

Completion criteria

The skill is complete only when every applicable validation item above has observed evidence or is explicitly marked not executed with the concrete blocker. Do not replace missing evidence with confidence language.

Research mapping

This skill was selected from research problems: P018, P052. See research/vibe-coding-problems.md and research/problem-evidence.csv in the Vibe Coding Skills repository.