cilium/pwru: technical due diligence, read from its repository

1 of 2 `FROM` lines in product Dockerfiles name an image without a version, or with `latest`. Each build pulls whatever the registry serves that day, so the image that ships can change without a commit, and last month's build cannot be reproduced. Pin a version, or a digest.

11 test files against 228 source files (4.8%). This does not measure whether the tests are good, only whether enough of them exist for the codebase to be changed safely by someone who did not write it — which is exactly the situation after an acquisition.

The codebase carries 439 TODO, FIXME, HACK or XXX markers across 112,527 lines. These are the team's own notes about work they knew was unfinished. A high density is not automatically bad — it can mean an honest team — but every one of them is a decision deferred, and after an acquisition they are deferred onto someone who was not in the room.

No USER instruction switches away from root, so the process runs with full privileges inside the container. It is a one-line fix and an ordinary expectation, which is why its absence is worth asking about: it usually says more about whether anyone has reviewed the deployment than about this container specifically.

6 places in the deployment configuration run a container privileged or in the host's network, process or IPC namespace. A compromise of that container is a compromise of the machine, and most acquirers' security reviews block it. Node agents (network, storage, monitoring) are excluded.

None of 292 readable files references an instrumentation, metrics or error-reporting library. If this system is in production, nobody learns that it broke from the system itself — they learn it from a customer. That is a reliability finding before it is an observability one.

Nothing in the service carries a request or correlation id, and there is no tracing. When a customer reports a failure, the log lines that belong to their request cannot be picked out from everyone else's.