repo-cve-exploitability

Assess whether the CVEs recorded against repo are exploitable in this repository's own code, not just present in its dependency graph. Combine Seizu's graph data (what was found) with the repository source read through the external GitHub MCP tools (whether it matters).

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

• repo — the repository fullname, owner/name.
• cve_ids — comma-separated; when empty, assess the highest-severity open findings.
• max_cves — how many findings to assess when cve_ids is empty.
• severity — the severity filter to pass through to the graph.
• ref — branch, tag, or commit SHA to inspect; empty means the default branch.

Tool arguments — use exactly these field names:

• github_security__repo_risk_summary: org, repos, exclude_forks, include_archived
• github_security__repo_dependencies: repos, packages, manifest, org, limit
• github_security__sync_freshness: org
• github_security__top_vulnerabilities: org, repos, state, severity, limit, exclude_forks, include_archived
• cve_analysis__get_cve: cve_id
• ext__github__get_file_contents: owner, repo, path, ref (path / lists the repository root; a path ending in / lists that directory)
• ext__github__search_code: query (GitHub code-search syntax, e.g. repo:owner/name path:*.py "import yaml"), perPage
• ext__github__list_commits: owner, repo, sha, path, perPage
• ext__github__get_commit: owner, repo, sha
• ext__github__list_branches: owner, repo
• ext__github__list_tags: owner, repo
• ext__github__get_latest_release: owner, repo 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. Resolve it in step 1 and use the fullname the graph returns for every later call, splitting that on / into owner and repo for the ext__github__* calls.

Stage 1 — establish the findings:

1. Resolve the repository first. 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, and do not delegate to a sandbox to fetch it — the graph and the GitHub MCP tools are the only sources for this assessment.
2. Call github_security__sync_freshness with the resolved org. State the newest sync timestamp and warn that the finding list may be stale or incomplete if it 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, and limit=100. repos filters in the query, before ranking and the limit, so every row that comes back is already this repository's — never re-run it org-wide and filter the rows yourself, and never call it more than once with the same arguments. An empty result here means the graph records no matching findings for this repository.
4. If cve_ids is non-empty, restrict the working set to those CVE/GHSA identifiers and say so when one of them has no matching row in the graph. Otherwise take the top max_cves rows by severity, then EPSS, then CVSS.
5. Do not call cve_analysis__get_cve for each finding. github_security__top_vulnerabilities already returns severity, CVSS, EPSS, the advisory summary, the CVE and GHSA ids, the patched version and the vulnerable range — everything the assessment needs. Call cve_analysis__get_cve only for a CVE whose advisory came back empty, and at most three times in a run: in this graph its description is usually null, so a per-CVE sweep costs a call each and returns what you already had.
6. If no findings remain, stop and report that — do not go looking for vulnerabilities in the code that the graph did not report.