grafana/mimir: technical due diligence, read from its repository

1 of 22 `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.

1 model weight files are stored in git itself, not in LFS, DVC or a model hub. Every clone carries them, the history keeps every version for good, and nothing records which run or data produced them.

go.mod declares 98 direct dependencies. Each one is a maintenance obligation, a supply-chain surface and a potential licence question that transfers with the asset. The count says nothing about whether any given dependency was a good choice; it says how many such choices a buyer inherits.

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.

3 of 620 locked dependencies match 3 published advisories in OSV, 1 of them rated high or critical. A lockfile says which version is installed, not whether the flawed code is reachable from this product, so each needs a look. Most are fixed by an upgrade, and the advisory names the version. This lockfile pins development tools alongside what ships and does not say which is which, so some of these may never reach a user.

pkg/usagestats/reporter.go sends to stats.grafana.org, and operations/mimir/mimir-flags-defaults.json leaves reporting on as shipped. Every installation reports to the vendor unless its operator turns this off. For a buyer running it inside their own product, that is an outbound data flow to a third party: ask what is sent, how often, and whether the buyer's customers were told.

Both probes call the same endpoint. When a dependency slows down, the liveness probe fails with the readiness probe, so the platform restarts pods that only needed taking out of rotation, and a partial outage becomes a full one. Liveness should ask whether the process is alive; readiness whether it can serve.