scottblodgett/sweetwater: technical due diligence, read from its repository

5 test files against 58 source files (8.6%). 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.

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.

3 of 86 locked dependencies match 9 published advisories in OSV, 4 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.

None of 144 readable files references an instrumentation, metrics or error-reporting library. If this system is in production, nobody learns that it broke from the system itself — they learn it from a customer. That is a reliability finding before it is an observability one.