Files
dev-workflows/skills/safedeps/SKILL.md
T
evandrodevbr c17192c9fe feat: vendorizar as 10 skills do pilar de seguranca em skills/
Copia local (nao fork, nao submodule) de safedeps, sca-audit,
secrets-scan, code-review-security, api-security-review,
web-security-review, cve-triage, patch-prioritization,
dependency-scanning e hermaguard -- commit exato de origem e licenca
de cada uma em skills/NOTICE.md. Elimina o passo de clone externo
pro pilar de seguranca do wf-security-review: git clone deste repo
ja traz tudo funcional.

Corrige tambem o comando de instalacao pro Claude Code nos dois
READMEs e no docs/SKILLS.md: Claude Code exige um diretorio por
skill (skills/<nome>/SKILL.md), nao aceita os .md soltos que o
comando antigo copiava -- confirmado testando a instalacao real.
2026-08-24 00:32:20 -03:00

2.6 KiB

name, description
name description
safedeps Grounds dependency decisions in live OSV.dev vulnerability data instead of a model's frozen training-cutoff knowledge. Trigger whenever you are about to add a dependency, bump/upgrade a package version, choose between package versions, answer "is <package> safe / vulnerable", or review a manifest or lockfile (requirements.txt, package.json, package-lock.json, go.mod) for security issues. Also trigger on requests like "check my dependencies for vulnerabilities" or "what version of X should I use".

safedeps

Your training data has a cutoff. CVEs published after it are invisible to you, and a vulnerable package version doesn't error at runtime -- it just runs, quietly exploitable. Don't guess. Ask OSV.dev.

When to run this

Before you write a version number into a manifest, or when asked to review one, run the checker and use its real output instead of your own recollection of which versions are safe.

python3 <skill_dir>/../../check_deps.py <package>@<version>:<ecosystem>
python3 <skill_dir>/../../check_deps.py path/to/requirements.txt

(<skill_dir> is this file's directory; the script lives at the repo/plugin root as check_deps.py. Ecosystems: npm, PyPI, Go, crates.io, Maven, etc. -- omit :ecosystem and it defaults to npm.)

The script prints one of two things per package, straight from OSV.dev:

OK    npm:[email protected] -- no known advisories
VULN  npm:[email protected] -- 2 advisory(ies):
  - CVE-2026-4800 [HIGH] lodash vulnerable to Code Injection via `_.template` imports key names
      fix: upgrade to 4.18.0

What to do with the output

  1. If a package you're about to add/bump shows VULN, do not use that version. Use the version named in fix: instead (or newer).
  2. If no fixed version is listed, tell the user there's an open advisory with no patch yet -- let them decide.
  3. Always surface the advisory IDs and severities to the user; don't silently swap versions without saying why.
  4. If the script reports OSV.dev is unreachable, say so plainly and fall back to your own knowledge with a caveat that it may be stale -- don't pretend you checked.

Examples

Adding a dependency: user asks to add flask to a Python project. Run check_deps.py [email protected]:PyPI (the version you were about to pick) before writing it to requirements.txt. If it's clean, proceed. If not, check the fix: version and use that instead.

Reviewing a project: user asks "are my dependencies safe?" Run check_deps.py requirements.txt (or package.json) in their project root and report every VULN line with its fix version.