Evandro Fonseca Junior
bb3fe21766
The vendored SKILL.md files were byte-identical to upstream, but the playbooks, templates and schemas they reference were left behind in the original repos, so a loading skill pointed at a file that does not exist anywhere in this repository. Vendored 1:1 into each skill directory (so they survive `cp -r skills/* ~/.hermes/skills/`): - plays/ for api-security-review, code-review-security, sca-audit, secrets-scan, web-security-review (OWASP/secure-agent-playbook) - templates/finding.md for the four OWASP skills that cite it - schemas/finding.schema.json for cve-triage, patch-prioritization, dependency-scanning (UnitOneAI/SecuritySkills) - docs/sarif-output.md, docs/fixer-policy.md and docs/normalized-json-output.md for dependency-scanning Path fixes, the only edit to vendored text: - the three UnitOneAI skills referenced ../../../schemas/ and ../../../docs/ which assumed upstream's skills/<category>/<skill>/ depth; this repo is flat, so the links now resolve inside the skill directory - safedeps told the agent to run <skill_dir>/../../check_deps.py while the script is vendored next to SKILL.md; corrected to <skill_dir>/check_deps.py and documented the script's exit codes (1 = finding, not a crash) - NOTICE.md records the new files, the path edits, and the remaining known gaps (hermaguard's kensei-pipeline references, the ASVS dataset citations, and hermaguard being behind upstream) Verified: every backticked path in every SKILL.md now resolves; check_deps.py runs from the installed location and returns live OSV.dev data ([email protected] -> 2 advisories); hermaguard's 46 tests still pass.
70 lines
2.9 KiB
Markdown
70 lines
2.9 KiB
Markdown
---
|
|
name: safedeps
|
|
description: >
|
|
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.
|
|
|
|
```bash
|
|
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 is vendored next to this
|
|
file, 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
|
|
|
|
Exit code is `0` when every package is clean, `1` when at least one advisory
|
|
was found, and `2` when OSV.dev was unreachable -- `1` is a finding, not a
|
|
crash. (The manifest mode only accepts files named `requirements.txt`,
|
|
`package.json`, `package-lock.json` or `go.mod`.)
|
|
|
|
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.
|