From infynon-pkg
Triage and prioritize CVE findings from INFYNON package scans. Use when the user has scan results and needs to decide what to fix, defer, or handle — covers severity matrix, fix strategies, and safe version selection.
npx claudepluginhub d4rkninja/code-guardian --plugin infynon-pkgThis skill uses the workspace's default tool permissions.
> **Never run raw upgrade or install commands to fix CVEs.**
Scans project dependencies for known CVEs across npm, pip, cargo, Go, and Java ecosystems. Reports vulnerable packages with severity, affected versions, and fixes.
Scans project dependencies for CVEs and vulnerabilities across Node.js, Python, Ruby, Java, Go, Rust, PHP, and .NET ecosystems. Reports severity levels and suggests or applies fixes.
Audits project dependencies for CVEs using detected package manager, reports vulnerabilities with installed/fixed versions and exact upgrade commands. Includes auto-fix and banned-packages check.
Share bugs, ideas, or general feedback.
infynon pkgNever run raw upgrade or install commands to fix CVEs. Not
npm install <pkg>@<safe-version>, notpip install --upgrade, notcargo update, not any other raw package manager command.Every fix must go through
infynon pkg:
infynon pkg fix --auto— auto-fix all vulnerable packagesinfynon pkg scan --fix— scan and interactively fixinfynon pkg <cmd> --auto-fix— fix during installIf you find yourself about to write a raw upgrade command — STOP. Use the
infynon pkgequivalent.
You are helping the user interpret and act on CVE scan results from infynon pkg scan.
# Human-readable output
infynon pkg scan
# Machine-readable JSON (better for triage decisions)
infynon pkg scan --agent
When you see CVE findings, use this priority framework:
| Severity | CVSS | Action | Timeline |
|---|---|---|---|
| CRITICAL | 9.0–10.0 | Fix immediately — block deploy | Now |
| HIGH | 7.0–8.9 | Fix before next release | Within 24h |
| MEDIUM | 4.0–6.9 | Schedule fix in current sprint | Within 1 week |
| LOW | 0.1–3.9 | Fix at next dependency update | Next sprint |
| INFORMATIONAL | 0.0 | Review, likely ignore | Backlog |
# See what safe versions are available
infynon pkg scan --agent | jq '.vulnerabilities[] | {package, cve_id, severity, safe_version, fix_cmd}'
# Auto-fix all vulnerable packages
infynon pkg fix --auto
# Fix a specific package
infynon pkg npm install lodash@4.17.21 --strict high # npm
infynon pkg pip install requests==2.31.0 --strict high # pip
infynon pkg cargo add serde@1.0.196 --strict high # cargo
Each CVE finding includes a safe_version and fix_cmd field:
{
"package": "lodash",
"cve_id": "CVE-2021-23337",
"severity": "HIGH",
"safe_version": "4.17.21",
"fix_cmd": "npm install lodash@4.17.21"
}
Use the fix_cmd through INFYNON:
# Take the fix_cmd from the scan output, prefix with `infynon pkg`
infynon pkg npm install lodash@4.17.21 --strict high
infynon pkg fix --auto # Auto-upgrade all detected vulnerabilities
infynon pkg fix --auto --pkg-file Cargo.lock # Fix specific lock file
For each CRITICAL or HIGH CVE:
Is this package reachable from user input?
Does a safe version exist?
safe_version field in scan outputinfynon pkg search)Is this a transitive dependency?
infynon pkg why <vulnerable-package>
# Shows which of your direct deps pulls it in
Is there a breaking change in the safe version?
infynon pkg diff <package> <current-version> <safe-version>
# Shows what changed between versions
# Option 1: Check if there's a patch release that fixes only the CVE
infynon pkg diff express 4.17.0 4.18.2
# Option 2: Find an alternative package
infynon pkg search "http server" --ecosystem npm
# Option 3: Use --skip-vulnerable in CI to at least block new vulnerable installs
# while you plan the migration
infynon pkg npm install --skip-vulnerable
# Get a prioritized list: critical first, then high
infynon pkg scan --agent | jq '
.vulnerabilities
| sort_by(.severity)
| reverse
| .[] | "\(.severity) \(.package) \(.cve_id) — fix: \(.fix_cmd)"
'
Focus on:
Dev dependencies (test frameworks, linters, build tools) are generally lower risk — they never run in production. Still fix them to:
# Check if it's pulled in transitively by a different parent
infynon pkg why <package>
# Check your lock file is actually updated
infynon pkg scan --pkg-file package-lock.json
infynon pkg scan --output markdown # Markdown report
infynon pkg scan --output pdf # PDF report
infynon pkg scan --output both # Both formats
Reports include: package name, CVE ID, severity, description, affected version, safe version, fix command.
After triage, lock in your accepted risk level with CI gates:
# Block critical + high (recommended default)
infynon pkg npm install --strict high
# Only block critical (more permissive)
infynon pkg npm install --strict critical
# Block all vulnerabilities (zero tolerance)
infynon pkg npm install --strict all
infynon pkg audit # Full dependency tree with CVE annotations
infynon pkg why <package> # Trace who pulls in a package
infynon pkg outdated # Find packages with newer versions available
infynon pkg doctor # Health check: duplicates, unused, phantom deps
infynon pkg diff <pkg> <v1> <v2> # See what changed between versions