Platform Security Assessment 2026-08

The one-paragraph version

Someone read 32 Phenom source repositories frozen at tag audit-baseline-2026-08-04 and wrote down every place the code lets an attacker reach something. They found 184 things. Two are Critical, 26 are High, and the rest are Medium, Low or informational. Nothing was exploited and no live system was touched: this was a source read, not a penetration test. The interesting result is not the count. It is that 142 of the 184 trace back to just nine recurring habits, so the fix list is nine engineering programmes rather than 184 tickets.

The numbers

Severity split by component:

What “Inferred” means, and why it matters to you

172 of the 184 findings are marked Inferred and 12 are marked Verified. That is not a confidence problem with the finding. It means the assessor read the code path and the missing control at a specific file and line, but could not observe the running system to confirm the deployed configuration. When you pick up one of these, your first job is usually a five-minute lookup in a console, not a code change. Several findings say exactly which lookup settles them. See Open questions.

Provenance and handling

These constraints come from the source material and they are not negotiable.

What was verified is worth stating too. All 184 findings survived an adversarial falsification pass with zero false positives and zero hallucinated findings. A second independent pass argued Phenom’s side and broke none of the central claims. Both Critical findings held under repeated attack.

How these pages are laid out

What already works

Three quarters of the remediation argument is “you already own this pattern, apply it in the other places”, so the patterns are worth naming:

• The production ALB mutual-TLS origin lock. mutual_authentication { mode = "verify" } against a codified trust store, with per-hostname authenticated origin pulls. It binds the caller cryptographically. An IP allowlist was tried first and correctly rolled back. This control is what currently bounds the worst Critical finding.
• moderation_audit_log. Append-only, enforced at the data layer by AFTER triggers rather than at call sites, with a guard trigger that raises on UPDATE and DELETE for every role including admin, and a manual relationship so attribution survives user deletion.
• nest-api’s Cognito verifier. Four controls verified at line. This is the reference implementation to standardise on, which makes the “no shared security component” root cause cheaper to fix than it looks.
• The audience-separation decision in admin_sandbox/nest-api/src/auth.ts, which is deliberate, documented, and names its threat.
• dev-environment’s publish pipeline, which mints a one-hour token scoped to two named repositories, passes it as a build secret so it never lands in a layer, and pushes by digest. This is the model the other production paths should copy.
• The daily Terraform drift loop, which opens or updates a labelled issue on drift and auto-closes it when clean.

A note on the existing Drop audit page

Drop Security Audit currently reports pipeline status GREEN with all critical, high and medium findings remediated. This assessment records 22 open findings against phenom-drop, including one of the two Criticals. The two documents disagree and the disagreement has not been reconciled. Treat the Drop page as covering a narrower earlier scope until someone reconciles them, and see MGR-C01 first.