saleor/storefront: technical due diligence, read from its repository

Across 5.2 years of history there is not one tag. There may still be a deployment process, but this repository holds no record of what shipped when — which is the record a buyer needs to reconstruct an incident or a regression after the fact.

39 of 995 locked dependencies match 90 published advisories in OSV, 58 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 root licence changed 1 time(s). The latest terms restrict what users, hosts or a buyer may do in ways the earlier ones did not. Code taken under the old terms stays under them, so both matter in diligence.

None of 1,022 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.