headroomlabs-ai/headroom: technical due diligence, read from its repository

1 of 7 `FROM` lines in product Dockerfiles name an image without a version, or with `latest`. Each build pulls whatever the registry serves that day, so the image that ships can change without a commit, and last month's build cannot be reproduced. Pin a version, or a digest.

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.

16 places in product code build SQL by formatting or joining strings rather than passing parameters, and in 12 of them a value, not a table or column name, goes into the string. Where any of those values comes from a request, it is an injection point. Each site needs a look; the fix, parameters, is small.

11 of 832 locked dependencies match 58 published advisories in OSV, 38 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.

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.