illacloud/illa-builder: technical due diligence, read from its repository

22 test files against 1,938 source files (1.1%). 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.

apps/builder/package.json declares 133 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 473 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.

There is no disclosure policy, no automated dependency updates, no named code owners and no pre-commit configuration. None of these is load-bearing on its own. Their collective absence says that security posture here is whatever the current team happens to remember to do, which is not a posture that survives the team changing.

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.

68 of 1,780 locked dependencies match 156 published advisories in OSV, 74 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.

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.