When OPA's `semver.is_valid` Runs on What SemVer Rejects

On OPA v1.20.2, semver.is_valid returns true for leading-zero versions (01.2.3, 1.02.3) and empty pre-release/build sections (1.2.3-, 1.2.3+), and semver.compare compares 1.02.3 and 1.2.3 as equal.

When It Runs — Run Report #RR04 · Testing what infrastructure actually does.

Provider · Component: OPA (Open Policy Agent) · SemVer built-ins — semver.is_valid and semver.compare

Versions tested: OPA v1.20.2 (official opa_linux_amd64_static release; measured on our lab — see §2). The documentation strings and the built-in's source were checked against the live docs and the v1.20.2 source tag (2026-09-12).

Config profile: A single official opa binary; expressions evaluated with opa eval --format pretty, in both the default (non-strict) mode and --strict-builtin-errors (see §2 and §4).

Verified on: 2026-09-22 (desk sources re-checked; v1.20.2 is still the current release) · lab measured 2026-09-12 on v1.20.2.

Affects: OPA policies that use semver.is_valid or semver.compare as a version trust gate — for example "reject the supplied version unless it is valid SemVer," or "allow when declared ≥ minimum" (measured on v1.20.2).

TL;DR: OPA's docs describe semver.is_valid as validating "that the input is a valid SemVer string", but on v1.20.2 it returns true for strings the SemVer spec rejects — leading-zero numbers (01.2.3, 1.02.3) and empty pre-release/build sections (1.2.3-, 1.2.3+) — and semver.compare compares 1.02.3 and 1.2.3 as equal rather than erroring the way it does for other malformed input like 1.2.

Full report: https://whenitruns.substack.com/p/when-opas-semveris_valid-runs-on