fix(audit): keep the row when the actor id is not a UUID

[42-v]

fix(audit): keep the row when the actor id is not a UUID

Merging this publishes nothing. vault42 releases are cut by pushing the annotated tag.

The defect

user_id and client_id are UUID in the schema (001:156-157) and string in the model, and three call sites pass a value the caller chose: the submitted client_id on a failed client auth, and the asserted subject on /mint and on a service document.

A non-UUID there does not produce a row with an odd value in it. pgx refuses the encode and there is no row at all — and the caller discards the error, correctly, because auditing must never block authentication.

So the events most worth having are the ones most likely to vanish:

• A credential spray sends client_id=admin, not a UUID. That is precisely the case the comment above auditClientAuthFailure says the audit exists to catch. The trail records only the attackers who already knew a valid client UUID.
• Every /mint event with a non-UUID subject. That row is the compensating control docs/security.md AR-16 names for a by-design subject-forgery oracle it otherwise accepts.
• Service document events, which spec.md §7.8 says are filed under user_id so an Art. 15 export finds them.

The fix, and why it moved

actorColumns blanks an id the column cannot hold and moves the claimed value into metadata, which is JSONB and takes any string. The row lands, and it still records who the caller said they were.

It sits in the postgres repository, not in audit.Logger. I wrote it in the logger first and four packages went red — that was the answer, not an inconvenience:

• The constraint belongs to the column, and only this package knows the column.
• Normalising in the logger changes the shape of every AuditEntry in the process to satisfy a rule that applies at one boundary.
• It would have left every mock repository accepting what the real one rejects — which is how this survived in the first place.

Verification

Pure function, no container needed:

go test ./internal/repository/postgres/ -run TestActorColumns    PASS

covering: a valid uuid left alone, an uppercase uuid accepted, a spray's admin, a legacy mint subject, both-bad, no-dashes, one-char-short, nil metadata, and that the caller's map is never mutated (a batch retry must not accumulate keys).

Mechanism against a real PostgreSQL — the INSERT driven straight at the column to prove it still refuses "admin", then through the repository to prove the row now lands with the value readable at metadata->>'actor_client_id_raw'.

Honest caveat: container-backed tests are intermittent in my environment — RequireContainerRuntime probes with a 4s timeout and a cold podman often misses it, so that test skipped on one run and executed on another. CI is authoritative for it. Everything else here ran locally: internal/audit, internal/middleware, internal/handler, tests/spec all ok, go vet and gofmt clean.

One existing test moved with it

TestAuditRepo_RefusedCommitLosesTheBatchLoudly used UserID: "u-1". With a non-uuid actor the entry now carries a metadata map, which that harness cannot encode, so the batch would fail before reaching the commit and the test would pass for the wrong reason. It uses a real uuid now, because it is a test about a refused COMMIT and nothing else.

Provenance

From the research + adversarial-hunt workflow, where it was named "the one thing to ship". Its argument is worth repeating: the product's differentiator is that its evidence is falsifiable — 456 requirements, a named test per Met row, CI failing when a Met row names a test that does not exist. This was a control that is documented, unit-tested, believed by the register, and silently absent at runtime for exactly the inputs an attacker sends.