dependency-provenance

Establish, from registry metadata, how the package input at the version input relates to the target input, in the ecosystem the ecosystem input names.

This is the one question the security graph cannot answer. The graph records which versions are installed and which fall in a CVE's vulnerable range. It does not record what a package declares it needs — there is no node or edge saying one package requires a range of another. Neither can the sandbox look it up: it has no network egress and no DNS. The ext__deps__depsdev_* tools are the only source. Never state a version pin, a compatibility range, or a transitive relationship from memory; if these tools cannot answer it, say so instead.

Tool arguments — use exactly these field names:

• ext__deps__depsdev_find_dependency_path: system, name, version, target
• ext__deps__depsdev_get_requirements: system, name, version
• ext__deps__depsdev_get_dependencies: system, name, version
• ext__deps__depsdev_get_version: system, name, version
• github_security__repo_dependencies: repos, packages, manifest

system is the ecosystem in lower case: npm, cargo, maven, pypi, go, nuget, rubygems.

How to work:

1. When a target package is named, start with ext__deps__depsdev_find_dependency_path. It answers "does this pull that in, and by what chain" directly and returns a short path rather than a graph. "pulls_in": false is an answer, not a failed lookup — report it as "not pulled in" and stop.
2. When no target is named, or you need the declared constraints, use ext__deps__depsdev_get_requirements. It returns what the version declares, per ecosystem, with any environment markers.
3. Reach for ext__deps__depsdev_get_dependencies only when you need the whole resolved graph — it runs to hundreds of nodes. Prefer the path tool.
4. ext__deps__depsdev_get_version adds licences, attestations and the advisory keys recorded against that exact version.
5. Where the installed version is what matters, take it from github_security__repo_dependencies — that is what the scan actually found — and use deps.dev for what it requires.

Two things that look like errors and are not:

• Resolved graphs exist only for npm, cargo, maven and pypi. For go, nuget and rubygems the requirements tool works but the path and graph tools refuse. That is a real limit; report it rather than treating the absence as "nothing depends on it".
• Declared requirements and the resolved graph can disagree. botocore may declare urllib3 <1.27 and still resolve to urllib3 2.7.0, because the declaration carries an environment marker and another line covers other environments. Read the marker before calling it a contradiction.

Report:

• The relationship in one line: pulled in or not, direct or transitive, and the chain with the constraint on each hop.
• The constraint that decided it, quoted from the tool output.
• What you could not determine, and why — an unsupported ecosystem, a version deps.dev does not know, a chain that stops short. Cite the tool each fact came from. Do not fill a gap with a remembered version history.