Cve Repo

cve-repo — Source Repository Resolver

Goal: find the repository that CONTAINS the vulnerable code at a checkable version. Not PoC repos, not advisory databases.

Step 1: Run resolver script

python3 ${CLAUDE_SKILL_DIR}/../../scripts/resolve.py $ARGUMENTS

Output: JSON array. Each record contains:

• cve_id, repo_url, repo_type (github|gitlab|bitbucket|wordpress|null)
• confidence: high | medium | low | none | closed-source | error
• source: ref-project | ghsa-api | known-mapping | desc-known-mapping | vendor-product | wp-slug | description | ref-ambiguous | known-closed-source | null
• affected_versions: version constraints from CVE data (e.g. ["<= 2.4.2", "< 2.11.0"])
• vulnerable_tag: git tag of the latest affected version (checkout target for reproduction)
• fix_commit: SHA of the patch commit (from GHSA or reference URLs)
• pre_fix_commit: parent of fix commit (alternative checkout target containing the vulnerability)
• candidates: all candidate repos found (including rejected report repos)
• needs_agent: true when script could not resolve with high/medium confidence
• hints: vendor, product, versions, description snippet (when needs_agent is true)

Script resolution layers (in order):

1. L1 ref-project: commit, PR, release, security advisory URLs → high
2. L2 ghsa-api: GHSA advisory ID → gh api → source_code_location + fix commit → high
3. L3 known-mapping: vendor/product → hardcoded table (Magento, PrestaShop, etc.) → high
4. L3b desc-known-mapping: description keywords → known repo (when vendor/product are n/a) → high
5. L4 vendor-product: vendor/product → GitHub HEAD check → medium
6. L4.5 wp-slug: product name → WordPress SVN slug → HEAD check → medium
7. L5 description: project name from description → GitHub HEAD check → low

Post-resolution:

• Tag resolution: maps affected_versions → actual git tags via gh api with --paginate
• Fix commit: extracted from GHSA advisory or commit URLs in references
• Pre-fix commit: parent of fix commit via GitHub API

Report/PoC repos (containing PoC, exploit, CVE-, CVEs, vulnerability in name) are classified as ref-report and excluded. Known closed-source products (SAP Commerce Cloud, Bdtask Bhojon) return confidence: closed-source.

Step 2: Agent fallback

Process only records where needs_agent is true.

For confidence: low (ambiguous or description-inferred)

1. Review hints.description_snippet to understand the vulnerable product.
2. Search: "{hints.vendor}" "{hints.product}" site:github.com via WebSearch.
3. If WordPress plugin, also search: "{hints.product}" wordpress.org plugin.
4. Verify the found repo matches the CVE description.

For confidence: none (no repo found)

1. Search: "{hints.vendor}" "{hints.product}" source code repository via WebSearch.
2. Try platform-specific: GitHub, GitLab, Packagist, WordPress.org, SourceForge.
3. If hints.versions available, verify the repo has matching tags/releases.
4. Check if the product is closed-source (no public repo exists).

Report format for agent-resolved repos:

Mark as confidence: agent in the output. If confirmed closed-source with no public repo: report confidence: closed-source.

Step 3: Present results

For each CVE:

## {cve_id}

- **Repo**: {repo_url}
- **Type**: {repo_type}
- **Confidence**: {confidence} ({source})
- **Affected versions**: {affected_versions joined}
- **Vulnerable tag**: {vulnerable_tag} (checkout target)
- **Fix commit**: {fix_commit}
- **Pre-fix commit**: {pre_fix_commit}
- **Candidates**: {count} found

Step 4: Summary table

| CVE ID | Repo URL | Confidence | Vulnerable Tag | Fix Commit | Pre-fix Commit |