frigadehq/trench: technical due diligence, read from its repository

The first commit carries 10,558 lines — 51% 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 65 fixes in the last 24 months, 10 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.

64 of 1,104 locked dependencies match 161 published advisories in OSV, 89 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 111 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.

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.