feat(tools): route OSV and CVE.org adapter recipes through vetted-ops sandbox dispatcher

[Kaap10]

What should happen

Read-only HTTP query recipes in tools/osv/tool.md and tools/cve-org/tool.md should execute via a closed catalogue through tools/vetted-ops (or a dedicated safe HTTP read dispatcher) rather than bare curl commands in Bash.

Why

As raised by @potiuk in #1297, the framework's recommended security posture (docs/setup/secure-agent-setup.md) explicitly denies Bash(curl *) to ensure network egress does not bypass sandbox proxies, enforced by tools/sandbox-lint. Consequently, adopters running under this recommended baseline encounter refused commands when executing the bare curl ... | jq recipes currently documented in tools/osv/ and tools/cve-org/.

Because both adapters perform exclusively read-only, unauthenticated lookups with a strictly closed parameter set (advisory IDs, package names + ecosystems + versions, commit SHAs), they possess the exact properties vetted-ops was designed to exploit: "a closed catalogue whose parameters can never become commands or flags".

Unifying both adapters under this dispatcher eliminates the deny-versus-adapter-recipes inconsistency across the entire security cross-referencing surface and allows adopters to run them safely with a single allow-entry rather than wildcard network rules.

Which layer

Tool / bridge (tools/<system>/)

Boundary conditions (optional)

• Dual Adapter Scope: As recommended during review, tools/osv/ and tools/cve-org/ should be addressed together in the same change to keep the cross-reference surface coherent.
• Dispatcher Backend: tools/vetted-ops currently delegates exclusively to gh. This requires either teaching the dispatcher a lightweight, non-gh HTTP read backend or providing a stdlib-only dispatcher helper under the tools.
• Downstream Compatibility: Output JSON structures should remain identical so existing downstream jq consumers and triage pipelines continue functioning without churn.

Out of scope (optional)

• Writing, allocating, or publishing CVE records (mutating CNA actions remain strictly governed under tools/cve-tool-vulnogram).
• Introducing new external network dependencies or third-party Python libraries.

References (optional)

• PR feat(tools/osv): query OSV.dev for vulnerability cross-references during security triage (#311) #1297 discussion: feat(tools/osv): query OSV.dev for vulnerability cross-references during security triage (#311) #1297 (comment)
• Precedent tool: tools/cve-org/tool.md
• Sandbox baseline: docs/setup/secure-agent-setup.md

[Kaap10]

Planning to pick this up. I've read through the vetted-ops dispatcher (ops.py, cli.py, config.py) and mapped out the change surface. Two viable approaches; wanted to align on direction before writing code.

Option A — Extend vetted-ops with a stdlib HTTP read backend.
Teach the dispatcher a second execution path alongside gh: operations with backend="http-read" use urllib.request (stdlib-only, no new dependencies) instead of subprocess.run(["gh", ...]). The five read-only operations (4 OSV, 1 CVE.org) register as closed shapes in ops.py with typed parameter validators, exactly like the existing forge operations. URLs are built from templates in the builder — parameters can never become URL path components they weren't designed for.

This is the path your review comment described as "the better home if you want the single-allow-entry property" — one allow on vetted-op-read covers both forge reads and security-data reads.

urllib.request honours HTTP_PROXY/HTTPS_PROXY, so the egress-gateway proxy is obeyed without any additional wiring. Both api.osv.dev and cveawg.mitre.org are already on the allowlist (your fixup in #1297 added the former).

Option B — Standalone stdlib dispatcher under tools/osv/.
Same closed-catalogue shape, but a separate Python package rather than an extension of vetted-ops. Keeps vetted-ops pure-gh (the argv[0] == "gh" invariant stays unconditional). Downside: a second dispatcher to allowlist and maintain.

Leaning toward Option A based on your review, but this touches core infrastructure, so confirming before I start. Happy to go either way.

[potiuk]

Nice !

[potiuk]

Option A — Extend vetted-ops with a stdlib HTTP read backend.

That one is better.