deps.yaml declares versions for deps we do not build

[phlax]

Title: deps.yaml declares versions for deps we do not build

Description:

bazel/deps.yaml (and api/bazel/deps.yaml) carry version/urls/sha256 for entries that are not necessarily present in any build we actually perform. A declared version is a claim about a build that may not be the one being done — for select-gated deps it is simply wrong in the configurations where the dep is not linked, and under bzlmod it can drift from what the module graph actually resolves.

These entries have historically been kept specifically for CVE scanning. That matters most for deps like the wasm runtimes, which see continual CVEs and are not monitored upstream, so any change here must not silently reduce CVE coverage.

Surfaced while working on #46875, where the legacy_all_repository_locations jq join in bazel/BUILD had to be reworked purely to reunite metadata with version data that is arguably fictional.

Two candidate directions discussed:

1. Force the deps to be present so the declared versions are real — e.g. by ensuring they load such that resolution actually pins them.
2. Accept transitive versions from the resolved module graph, and extend the CVE checker to handle named transitives, so deps.yaml carries only cpe and project metadata while versions come from what was actually built.

Constraints on any solution:

• CVE matching is version-ranged (tools/dependency/cve_matcher.jq via version.jq). Attributing a transitive's CPE to a parent entry without its own version produces meaningless matches — false negatives look identical to "clean", which is the failure mode we cannot accept for the wasm runtimes.
• Any dep carrying a cpe but lacking a resolvable version must be a hard failure in the CVE pipeline, not a skip.
• //bazel:update and //bazel:api-update write back to repository_locations.bzl via the updater rule and will need repointing at whatever becomes the version source.
• Coverage becomes a union over configurations, which ties into the reachability config work.

[optional Relevant Links:]

• [WIP] bazel/deps: Use canonical names in deps.yaml #46875
• [WIP] bazel: Switch to bzlmod #42890
• bazel/BUILD — legacy_all_repository_locations
• tools/dependency/BUILD — cpe-dependencies, cves, cves-scanned
• tools/dependency/cve_matcher.jq, tools/dependency/version.jq

[phlax]

Schema decision: tracked-but-implied deps as top-level entries

Metadata needs to cover both explicitly declared deps and deps that are only reached transitively, in a way that works for both WORKSPACE and bzlmod.

Two fields, two distinct assertions — they coexist

• implied_untracked_deps (existing, on the parent) — "this transitive exists, don't flag it as unknown, we carry no metadata for it."
• New: a top-level entry with a used_by list — "this transitive is tracked; here is its cpe, use_category, extensions. It just isn't a direct dep."

These are not two spellings of the same edge, so both stay.

Top-level rather than nested under the parent

_build_revmap in tools/dependency/validate_reachability_test.py flattens untracked → parent into a dict, so last-writer-wins:

revmap = {}
for name, meta in metadata.items():
    for untracked in meta.get("implied_untracked_deps", []):
        revmap[untracked] = name

Harmless today because the value is only a name used in error messages. Once the value carries a CPE, a nested model silently drops one parent's metadata whenever two deps imply the same transitive. Top-level entries with used_by invert the relation so multiple parents are representable rather than lossy.

It also keeps one uniform record shape: check_apparent_name_uniqueness already treats keys and apparent names as a single namespace, and a top-level tracked-implied entry participates in that unchanged. Nested entries would sit outside it and need parallel checking.

highway:
  project_name: "Highway"
  cpe: "cpe:2.3:a:google:highway:*"
  used_by:
  - v8
  use_category:
  - dataplane_ext
  extensions:
  - envoy.wasm.runtime.v8

Disjointness is a hard failure

A name is either tracked or untracked, never both. The file must not be able to express the ambiguity.

This means _resolve_dep_name needs no precedence rule between metadata keys and the revmap — the two sets are disjoint by construction, so resolution stays as-is.

Two checks, alongside check_apparent_name_uniqueness:

• a name in any implied_untracked_deps list MUST NOT be a top-level metadata key — fail naming both the key and the parent listing it, e.g. "highway is a tracked entry — remove it from v8's implied_untracked_deps"
• a name in any used_by list MUST be a top-level metadata key — catches typos, and stops used_by rotting into free text

Migration

Promoting untracked → tracked is a two-line edit: add the top-level entry, remove the name from the parent's implied_untracked_deps. Disjointness makes this atomic — the intermediate state fails — so bulk promotions land as single commits. Given the size of each edit that's the right tradeoff, and the checker message guides it.

Interaction with the hard-fail rule

Once these entries carry a cpe, the version hard-fail in this issue applies to them: they must resolve a version from the graph in at least one covered config. highway currently appears in no reachability output at all, so it would fail immediately — correct behaviour, but it means this schema change is gated on #46917 landing the config matrix.

Open: field name

used_by reads as the inverse of implied_untracked_deps, but these deps are tracked, just not direct. reached_via or tracked_via states the fact rather than a negation. Worth settling before anything is written to YAML, since renaming after migration is a much larger diff.

[phlax]

seems this might not be the case any longer (checking further)