fix(skills): vendor the support files the vendored skills point at
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.
This commit is contained in:
Evandro Fonseca Junior committed
1 parent
eba8bb1d94
commit
bb3fe21766
20 files changed
+4156
-11
No files matched your search
@@ -0,0 +1,140 @@
|
||||
# Play: Software Composition Analysis Audit
|
||||
|
||||
Scan project dependencies for known vulnerabilities (CVEs), produce severity-ranked findings with remediation guidance.
|
||||
|
||||
## Trigger Conditions
|
||||
|
||||
Use this skill when:
|
||||
- Reviewing a project's dependency files (package.json, requirements.txt, go.mod, pom.xml, Gemfile, Cargo.toml, etc.)
|
||||
- A user asks to check for vulnerable dependencies
|
||||
- Performing a pre-deployment security review
|
||||
- Triaging a Dependabot/Renovate alert
|
||||
|
||||
## Inputs
|
||||
|
||||
- Project root directory (must contain dependency manifests and/or lockfiles)
|
||||
- (Optional) Severity threshold — minimum severity to report (default: MEDIUM)
|
||||
- (Optional) Ignore list — CVEs to suppress (with documented justification)
|
||||
|
||||
## Procedure
|
||||
|
||||
### 1. Identify Dependency Manifests
|
||||
|
||||
Scan for all dependency files in the project:
|
||||
|
||||
| Ecosystem | Manifest | Lockfile |
|
||||
|-----------|----------|----------|
|
||||
| Node.js | package.json | package-lock.json, yarn.lock, pnpm-lock.yaml |
|
||||
| Python | requirements.txt, setup.py, pyproject.toml | Pipfile.lock, poetry.lock |
|
||||
| Go | go.mod | go.sum |
|
||||
| Java/Kotlin | pom.xml, build.gradle | gradle.lockfile |
|
||||
| Ruby | Gemfile | Gemfile.lock |
|
||||
| Rust | Cargo.toml | Cargo.lock |
|
||||
| .NET | *.csproj, packages.config | packages.lock.json |
|
||||
| PHP | composer.json | composer.lock |
|
||||
|
||||
Prefer lockfiles over manifests — they capture the exact resolved versions including transitive dependencies.
|
||||
|
||||
### 2. Run Vulnerability Scan
|
||||
|
||||
Use available tools in order of preference:
|
||||
|
||||
1. **osv-scanner** (recommended — uses OSV.dev database, covers all ecosystems):
|
||||
```bash
|
||||
osv-scanner --lockfile=<lockfile_path> --format=json
|
||||
```
|
||||
|
||||
2. **npm audit** (Node.js projects):
|
||||
```bash
|
||||
npm audit --json
|
||||
```
|
||||
|
||||
3. **pip-audit** (Python projects):
|
||||
```bash
|
||||
pip-audit -r requirements.txt --format=json
|
||||
```
|
||||
|
||||
4. **govulncheck** (Go projects):
|
||||
```bash
|
||||
govulncheck ./...
|
||||
```
|
||||
|
||||
5. **trivy** (multi-ecosystem, container images too):
|
||||
```bash
|
||||
trivy fs --format json --scanners vuln <project_path>
|
||||
```
|
||||
|
||||
If no scanner is installed, **stop and ask the user to install one** rather than attempting manual analysis. Even small projects have 50+ dependencies — manually cross-referencing versions against CVE databases is not cost-effective. Recommend:
|
||||
```bash
|
||||
# Fastest to install, covers all ecosystems
|
||||
brew install osv-scanner # or: npm install -g osv-scanner
|
||||
# Node.js projects already have this
|
||||
npm audit --json
|
||||
```
|
||||
|
||||
For manual triage of individual packages, use the [OSV.dev vulnerability database](https://osv.dev/list) to search by package name or CVE.
|
||||
|
||||
### 3. Analyze Results
|
||||
|
||||
For each vulnerability found:
|
||||
|
||||
1. **Determine reachability**: Is the vulnerable code path actually used by this project?
|
||||
- Check import statements and usage patterns
|
||||
- A vulnerability in an unused function of a dependency is lower priority
|
||||
2. **Check exploitability context**: Is the vulnerability exploitable in this deployment?
|
||||
- A client-side library vuln in a server-only project may not apply
|
||||
- A DoS vulnerability may be less critical for internal tools
|
||||
3. **Identify fix availability**: Is there a patched version?
|
||||
- Check if upgrading is a minor/patch bump (low risk) or major bump (breaking changes)
|
||||
- Check if the fix is in a direct dependency or requires bumping a transitive dep
|
||||
|
||||
### 4. Produce Findings
|
||||
|
||||
For each confirmed vulnerability, generate a finding with:
|
||||
- CVE/GHSA identifier
|
||||
- Affected package and version
|
||||
- Fixed version (if available)
|
||||
- CVSS score and severity
|
||||
- Whether the vulnerable code path is reachable
|
||||
- Upgrade command to fix
|
||||
|
||||
### 5. Generate Dependency Health Summary
|
||||
|
||||
Beyond CVEs, flag:
|
||||
- **Unmaintained packages**: No commits in 2+ years, archived repos
|
||||
- **Typosquatting risk**: Package names that are suspiciously similar to popular packages
|
||||
- **License concerns**: Packages with no license or unexpected license changes
|
||||
- **Pinning issues**: Using ranges (^, ~) instead of exact versions in production lockfiles
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## SCA Audit: [Project Name]
|
||||
|
||||
### Scan Summary
|
||||
- **Ecosystems**: [Node.js, Python, etc.]
|
||||
- **Total dependencies**: [N direct, M transitive]
|
||||
- **Scanner used**: [tool name and version]
|
||||
- **Vulnerabilities found**: [X critical, Y high, Z medium, W low]
|
||||
|
||||
### Critical & High Findings
|
||||
[Standard finding template for each, sorted by severity]
|
||||
|
||||
### Medium & Low Findings
|
||||
[Condensed table format]
|
||||
| Package | Version | CVE | Severity | Fixed In | Reachable? |
|
||||
|---------|---------|-----|----------|----------|------------|
|
||||
|
||||
### Dependency Health
|
||||
[Flags for unmaintained, license, pinning issues]
|
||||
|
||||
### Remediation Commands
|
||||
[Exact commands to fix — e.g., `npm install package@version`]
|
||||
```
|
||||
|
||||
## OWASP References
|
||||
|
||||
- **A06:2021** — Vulnerable and Outdated Components
|
||||
- OWASP Dependency-Check
|
||||
- OWASP Software Component Verification Standard (SCVS)
|
||||
- OWASP Cheat Sheet: Vulnerable Dependency Management
|
||||
@@ -0,0 +1,48 @@
|
||||
# Finding Template
|
||||
|
||||
Use this structure for all security findings produced by skills.
|
||||
|
||||
```markdown
|
||||
### [SEVERITY] Title
|
||||
|
||||
- **ID**: NDC-YYYY-NNN (auto-incrementing)
|
||||
- **CWE**: CWE-XXX (if applicable)
|
||||
- **CVE**: CVE-YYYY-NNNNN (if applicable)
|
||||
- **OpenCRE**: [CRE-ID](https://www.opencre.org/cre/CRE-ID) — requirement name (see data/opencre/)
|
||||
- **OWASP Ref**: Top 10 A01, ASVS V4.1.1, MASVS-STORAGE-1, MASWE-0001, MASTG-TEST-0200, LLM01, etc.
|
||||
- **Location**: file_path:line_number or component name
|
||||
- **Impact**: What an attacker can achieve (1-2 sentences)
|
||||
- **Evidence**: Code snippet, command output, or proof-of-concept
|
||||
- **Remediation**: Specific fix with code example
|
||||
- **Confidence**: HIGH | MEDIUM | LOW (how certain is this finding)
|
||||
```
|
||||
|
||||
### Resolving OpenCRE Links
|
||||
|
||||
When you have a CWE, look up its OpenCRE mapping via the API:
|
||||
|
||||
```
|
||||
GET https://www.opencre.org/rest/v1/standard/CWE/sectionid/{cwe-number}
|
||||
```
|
||||
|
||||
This returns the CRE ID and linked standards (ASVS, WSTG, NIST 800-53, cheat sheets). Include the CRE link in findings to give readers one-click access to all related standards and remediation guidance.
|
||||
|
||||
Common mappings are pre-populated in `data/opencre/README.md`.
|
||||
|
||||
## Severity Definitions
|
||||
|
||||
| Severity | CVSS Range | Criteria |
|
||||
|----------|-----------|----------|
|
||||
| CRITICAL | 9.0-10.0 | Remote code execution, full system compromise, mass data breach |
|
||||
| HIGH | 7.0-8.9 | Privilege escalation, significant data exposure, auth bypass |
|
||||
| MEDIUM | 4.0-6.9 | Limited data exposure, requires user interaction or specific conditions |
|
||||
| LOW | 0.1-3.9 | Information disclosure, minor misconfigurations |
|
||||
| INFORMATIONAL | N/A | Best practice recommendations, defense-in-depth suggestions |
|
||||
|
||||
## Confidence Levels
|
||||
|
||||
| Level | Meaning |
|
||||
|-------|---------|
|
||||
| HIGH | Confirmed via code path analysis, PoC, or tool output |
|
||||
| MEDIUM | Strong indicators but not fully confirmed — needs manual verification |
|
||||
| LOW | Heuristic match or pattern-based — may be false positive |
|
||||
Reference in new issue
Block a user