kubeshop/monokle: technical due diligence, read from its repository

21 test files against 1,096 source files (1.9%). 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.

package.json declares 82 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.

Of 38 fixes in the last 24 months, 0 touched a test. A fix without the test that would have caught the bug can quietly come back, and the suite never learns from what went wrong.

37 of 615 locked dependencies match 144 published advisories in OSV, 88 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.

The build configuration emits source maps for production, so the original source, with its comments and structure, is downloadable by every visitor. Upload them to an error tracker and keep them off the public server instead.

Nothing references a structured logging library. Logs that are written to be read by a person are not searchable by a machine, which means incident response here is proportional to how well someone remembers the codebase rather than to what the tooling can find.

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.