Pre-launch audit

Security posture

Before opening this challenge we hardened the perimeter. As of June 2026:

Static analysis (Semgrep, security + OWASP rulesets) across the gate, worker, and iOS SDK — no findings.
Secret-scanning (gitleaks, full git history) across every repository — no leaks.
Dependency CVEs reviewed and patched.
Templated vulnerability + misconfiguration scan (nuclei) against the live endpoints — no findings.
The completion capability cookie is httpOnly, Secure, SameSite=Strict.
Every response carries HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, and a frame-ancestors Content-Security-Policy.

We publish this not to claim we are unbreakable, but to be precise about what we have already checked — so your time goes to the path that matters, not the ones we have already closed.

TLS and LUCKY13

The gate terminates TLS through AWS API Gateway, enforcing TLS 1.2 and 1.3 only — no SSLv2/3, no TLS 1.0/1.1.

For TLS 1.2 compatibility, AWS's managed cipher suite still offers CBC-mode ciphers, which automated scanners flag for LUCKY13 (CVE-2013-0169). LUCKY13 is a MAC-then-encrypt CBC timing attack; AWS's TLS termination processes these ciphers in constant time, which mitigates it. We chose maintained, patched, constant-time AWS-managed TLS over a hand-rolled cipher suite on purpose.

If you can turn that scanner flag into a practical decryption against this endpoint, that is itself a finding — show us.

The challenge stands unchanged

The hardening above closes the software perimeter. The payout is still the one path we have not closed by design: a server-recorded /apply completion for a synthetic profile without a genuine bonded Pulse phone. That is the door we are paying you to open.