deepfence/threatmapper: technical due diligence, read from its repository

The first commit carries 1,663,624 lines — 41% of every line ever added. Whatever happened before that commit happened somewhere this repository cannot show you, so the early history is not available as evidence of how the system was designed.

Of 55 fixes in the last 24 months, 4 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.

Strings shaped like credentials appear only where fakes are usual: test fixtures, examples, documentation, placeholders and local stacks. They are almost always fakes. Ask someone to confirm that none of them works anywhere, because a real key in a development file is still a real key.

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.

56 of 1,577 locked dependencies match 152 published advisories in OSV, 77 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.

10 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.

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.

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.