repo-cve-reachability

Decide whether each of these CVEs is reachable in the code of repo, not merely present in its dependency graph.

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

• repo — use the resolved owner/name fullname from the findings step.
• findings — when this is empty, the CVEs to review are the ones the findings review produced, which you already have in this step's context. Use those. An empty value here is normal and is not a reason to stop.
• ref — branch, tag, or commit SHA; empty means the default branch.
• max_cves — the most advisories to assess. Treat it as a hard cap: rank by severity, then EPSS, assess that many, and say which you did not reach and why.

Tool arguments — use exactly these field names:

• 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
• github_security__repo_dependencies: repos, packages, manifest, org, limit Split repo on / into owner and repo for every ext__github__* call.

Check the owner before you read anything. repo may carry an owner that nobody verified — a plan step or a requester can put the upstream project's org on a name that the graph holds under a different one. The findings step resolved the real fullname; if what you were given disagrees with it, use the resolved one and say so in the output. If neither the findings step nor github_security__repo_risk_summary (with org="" and the bare name) can place this repository in the graph, stop and report that — do not read a repository the graph has no record of. Reading the upstream project instead of the scanned fork produces verdicts about a codebase nobody asked about, and they look correct.

Do this work in the sandbox. sandbox__delegate reads tool results with far larger bounds than you have — tens of thousands of rows and megabytes against your 100 rows and 200KB — and anything oversized is written to a file under /home/user/seizu_results/ and returned as a receipt the sub-agent parses with run_python. Reading a large lockfile or sweeping many search hits is exactly that shape of work, and doing it in your own context is what exhausts the run.

How to delegate:

• Name every tool the task needs in the delegation's tools argument: ext__github__get_file_contents, ext__github__search_code, ext__github__list_commits, github_security__repo_dependencies. Naming them is what binds them. A delegation that omits tools leaves the sub-agent hunting for capability it has not been given, and it will spend the budget failing to find it.
• Pass the finding list as the delegation's input_data, and ask for a per-CVE verdict with cited path:line evidence.
• The sub-agent reaches GitHub through those tools, not the network — the sandbox has no outbound internet access, so curl/urllib against api.github.com or raw.githubusercontent.com always fails. If a delegation reports network errors it took the wrong route; re-issue it with the tools named.
• Have it list the tree and search the code. Never hand it a guessed list of candidate filenames to probe.
• Ask for independent lookups together, not one at a time. Each round trip to the sub-agent costs a model call, and the searches for different advisories do not depend on each other: issue every ext__github__search_code for the current batch of advisories in one turn, then read every hit site that came back in the next. Only work that genuinely needs a previous result — reading a file the search just located, or following a commit a diff pointed to — has to wait for it.

What to establish for each CVE:

1. Fix the ref. When ref is empty, call ext__github__list_branches once to find the default branch and use it for every later call.
2. Locate the vulnerable API. Search with ext__github__search_code scoped to repo: + the fullname for imports/requires of the package and, more importantly, calls into the specific function, class, or configuration flag the advisory names. Read the hit sites with ext__github__get_file_contents — search results alone are not evidence of reachability.
3. Trace untrusted input. Does attacker-controlled data (HTTP bodies, query params, uploaded files, webhook payloads, CI inputs from forks) flow into that call? Read the surrounding handler or entrypoint rather than guessing from the file name.
4. Look for mitigations: input validation or allowlists, the feature disabled by default, a non-privileged context, a pinned safe version elsewhere.
5. Check whether it is already fixed but not yet re-synced: ext__github__list_commits on the manifest or lockfile path, and ext__github__get_commit for a promising SHA.
6. ext__github__search_code only indexes the default branch and can lag. If a search returns nothing, say so and fall back to directory listings before concluding the package is unused.
7. A package with no direct import may still arrive through another dependency. Ask ext__deps__depsdev_find_dependency_path (system, name, version, target) whether the intermediate pulls it in, and ext__deps__depsdev_get_requirements for the range it declares. Never state a version pin or compatibility range from memory — the security graph records installed versions, not declared requirements, and the sandbox has no network to check them. If those tools cannot answer, say the relationship is undetermined rather than asserting one.
8. A transitive dependency's code still runs. No direct import means the repository does not call the package itself; it does not mean the vulnerable code is unused, because the intermediate that pulls it in is calling it. Name that intermediate (step 7), then establish whether the repository's use of the intermediate reaches what the advisory names: which of the intermediate's entry points this repository calls, and whether the advisory's function, feature or flag sits underneath them. Read the intermediate's source with ext__github__get_file_contents when you can identify its repository. What settles it is evidence about the intermediate: a cited call site in its source, or its own documentation stating it does not use the affected feature. Evidence about this repository cannot settle it, because this repository is not the caller. The absence of a direct import is what makes the package transitive — it is the precondition for this step, never its answer. Where you cannot get evidence about the intermediate, that is Undetermined.