repo-cve-findings

name	repo-cve-findings
description	Resolve a GitHub repository in the security graph and list the CVEs recorded against it, confirming from the graph's dependency data which vulnerable versions are actually installed. Produces the finding set that a reachability review then judges against the source.
allowed-tools	mcp__seizu__github_security__repo_risk_summary mcp__seizu__github_security__sync_freshness mcp__seizu__github_security__top_vulnerabilities mcp__seizu__github_security__repo_dependencies mcp__seizu__cve_analysis__get_cve

List the CVEs the security graph records against the repo input, and confirm from the graph which of them correspond to a version actually installed in that repository. Do not read repository source in this step — reachability is a separate skill.

Inputs — the values arrive in the ## Inputs block below these instructions:

• repo — the repository to review.
• cve_ids — comma-separated; empty means the highest-severity open findings.
• max_cves — how many findings to keep when cve_ids is empty.
• severity — the severity filter to pass through to the graph.

Tool arguments — use exactly these field names:

• github_security__repo_risk_summary: org, repos, exclude_forks, include_archived
• github_security__sync_freshness: org
• github_security__top_vulnerabilities: org, repos, state, severity, limit, exclude_forks, include_archived
• github_security__repo_dependencies: repos, packages, manifest, org, limit
• cve_analysis__get_cve: cve_id

The graph is the authority on which repository this is. repo may be a bare name, or carry an owner the requester assumed — never take the owner from your own knowledge of the project, because a well-known upstream org (lyft/…, netflix/…) is usually not the org that was actually scanned.

Workflow:

1. Resolve the repository. Call github_security__repo_risk_summary with org="" (empty matches every organization in the graph) and repos= the bare repository name — the part of repo after / if it has one. Take the repo fullname from the row it returns and use it from here on; say so plainly if its owner differs from what the request implied. If it returns no row, the graph holds no such repository: report that, name the closest repositories you can see, and stop. Do not go looking for the project on the internet.
2. Call github_security__sync_freshness with the resolved org. State the newest sync timestamp and qualify the findings if the data is old.
3. Call github_security__top_vulnerabilities with the resolved org, repos= the resolved fullname, state='open', severity= the severity input, include_archived=true, exclude_forks=false, limit=100. repos filters in the query, before ranking and the limit, so every row is already this repository's. Call it once.
4. Cut the working set to max_cves. If cve_ids is non-empty, keep only those CVE/GHSA identifiers and say which of them the graph has no row for. Otherwise keep the highest max_cves by severity, then EPSS, then CVSS. This is a hard cap on every section below, not a suggestion: report exactly the advisories you kept, and state how many you dropped and on what ranking. A longer table is not more useful — the reachability review reads this list and inspects source for each entry, so every extra row costs a full investigation.
5. Confirm what is installed. Call github_security__repo_dependencies once, with repos= the resolved fullname and packages= every package name from step 4 as one comma-separated list. Compare each finding's vulnerable_range and patched_version against the resolved_version returned. A row whose manifest is a lockfile (Pipfile.lock, poetry.lock, package-lock.json, go.sum, …) is the resolved truth; a row from a bare manifest with no version is only a declaration.

Output format — this is consumed by the reachability review, so keep it exact:

• Repository: resolved fullname, default branch, visibility, sync timestamp.
• Findings: a table with CVE | GHSA | package | ecosystem | severity | CVSS | EPSS | scope | manifest | vulnerable range | patched version | resolved version | installed? (yes / no / unknown).
• Not installed: findings whose resolved version is outside the vulnerable range, or where the package no longer appears — these need no reachability review, and say why.
• To review: the CVE ids whose vulnerable version is installed, ordered by severity then EPSS. This list is the input to the reachability review.
• Gaps: stale sync data, packages the graph has no dependency row for, missing resolved versions.
• Keep every claim evidence-backed. Do not state a verdict about exploitability here; that is the next skill's job.