w-okada/voice-changer: technical due diligence, read from its repository

2 test files against 300 source files (0.7%). 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.

602 of 1,516 subjects are either under twelve characters or one of the standard placeholders — wip, fix, update. The history is therefore not usable for reconstructing why a decision was taken, which is the main thing an inheriting engineer needs it for. It says nothing about code quality and a great deal about how much context transfers with the asset.

The lockfile last changed 941 days before the newest commit, and 70 commits have landed since. Every security fix published upstream in that time is absent until someone updates it, and the longer the gap the larger and riskier that update becomes.

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.

10 of 220 locked dependencies match 43 published advisories in OSV, 21 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.

package.json declares ISC. LICENSE contains the text of MIT. Package managers and downstream users read the first; auditors and acquirers read the second. One of them is wrong, and until it is settled the terms this code is offered under are genuinely ambiguous.

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.