Pre-launch audit

Security posture

Before opening this demo publicly 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.

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 — write to us.

The boundary that matters

The hardening above closes the software perimeter. The claim underneath it is narrower and load-bearing: a server-recorded /apply completion cannot happen for a synthetic profile without a genuine bonded Pulse phone. Acceptance and bonding are derived from the same verification result, so a completion that was never bonded is not merely unobserved — it is unreachable through the mechanic.