Dependency security
AppSec Skills — 15 plug-and-play Claude Code security skills that audit, harden, and fix any website or app before you ship it. OWASP Top 10, auth, API, database, frontend, backend, cloud, dependencies, secrets, and pentest-style checks — all defensive, all evidence-based.
npx -y skills add Rootx202/appsec-skills --skill dependency-securityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 23 days oldThe repository was created 23 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Dependency and supply-chain vulnerability scanner for npm, pip, composer, gradle, cargo, and other package ecosystems. Use whenever the user wants to check for known CVEs, outdated packages, or supply-chain risk in package.json, requirements.txt, composer.json, build.gradle, Cargo.toml, or similar manifest/lockfiles, for any project.
SKILL.md
2.8 KB, as published. Nobody here has run it
Dependency Security — Supply-Chain Vulnerability Scanner
A skill for auditing third-party libraries and dependencies for known vulnerabilities (CVEs) and outdated versions.
When to use this
- Request to scan
package.json,requirements.txt,composer.json,build.gradle,Cargo.toml, or a lockfile - Before deployment, to confirm no dependency carries a known-critical vulnerability
Methodology
- Read the manifest and, if present, the lockfile (more accurate for exact resolved versions).
- For each package, check (using available tools such as running an audit command, or web search when appropriate) whether that specific version has known CVEs.
- Compare current version against the latest stable release.
- Rate severity based on the actual vulnerability's real-world exploitability, not simply "the version is old."
Suggested Tools by Ecosystem
- npm:
npm audit— run it for real if the environment allows, and read its actual output rather than guessing. - pip:
pip-audit, or manual comparison against the OSV database. - composer:
composer audit - cargo:
cargo audit - If the tool or network isn't available, say so explicitly and provide analysis based on well-documented, widely known vulnerabilities for those libraries, while noting that a real audit tool run is still recommended for certainty.
Report Format Per Affected Package
Package: [name]
Current Version: [x.y.z]
CVE: [CVE ID if applicable]
Risk: Critical/High/Medium/Low
Affected Function: [where this library is actually used in the project]
Upgrade: [recommended safe version]
Breaking Changes: [does the upgrade require code changes?]
Additional Considerations
- Transitive dependencies: indirect dependencies (dependencies of dependencies) can carry vulnerabilities too — don't stop at the top level.
- Typosquatting: check for packages with names suspiciously similar to popular ones that may have been added by mistake (supply-chain risk).
- Unused packages: flag any installed dependency that isn't actually used in the code — removing it reduces attack surface.
- After upgrading, remind the user to run the test suite to confirm nothing broke.
Rules
- Never claim a vulnerability exists without grounding it in a real source (an actual audit tool result or a documented CVE) — if unsure, say so rather than asserting it.
- Stay focused on third-party dependencies; issues in the user's own code belong to
code-audit.