One published case study so far. It is here because both halves are useful: a real finding that was verified and fixed, and a plausible high-severity claim that verification refuted.
2026-09-01 · authorized owner self-audit
The production build emitted no CSP, no X-Frame-Options, and no referrer, HSTS, or permissions policy. A local probe page on a different origin embedded the storefront and the whole interface rendered, sign-in button included.
Root cause: the application declared no header policy at all. After the fix, the browser refuses the frame itself with frame-ancestors 'none'. Ten regression assertions keep it closed.
Remote configuration values flowed into href and src with only whitespace trimming. That is the shape a scanner reports as high-severity cross-site scripting.
A local reproduction served a hostile javascript: payload. React 19 replaced it with a blocked-URL placeholder, so no script execution was achievable, and attacker control was never established because the configuration source is the operator's own API. Recorded as refuted, with the reason retained. The scheme allowlist was still added — labelled as hardening, not as a vulnerability fix.
This is one audit of one small application. It measures nothing about SecHelix in general, and it is not a Trophy Case entry: that bar requires a public project and a public fix reference, and this target is private.
Case studies are published only when the evidence survives review and the result is safe to attribute. A short honest list is the point. Full-workflow benchmark status remains NOT_MEASURED for the same reason — the one published run measures labels on a synthetic suite, not audits of real systems.
The two halves of this audit are covered in more depth elsewhere: the reasoning behind refusing the XSS candidate is in the argument for disproving your own findings, the retest that proved the header fix is security regression testing, and the category this run belongs to is described on the AppSec agent guide.