Security
Nestuary Wellness Inc. maintains an in-house security function responsible for the security of all products and infrastructure we own and operate.
- Report to
- security@strongineering.com
Products in scope
- Strongineering iOS app — workout planning and autoregulation
- strongineering.com — marketing site and web dashboard (Firebase Hosting, Cloud Functions)
- Strongineering backend — Google Cloud Functions, Firestore, Cloud Run services
- SendPidge — anti-scam email and messaging verification service (Amazon SES, AWS)
- MailPidge — email marketing platform (Cloudflare Workers, SES)
- Strongineering AI agent — WhatsApp coaching agent (Google Cloud Run, ADK)
Vulnerability disclosure policy
If you find a vulnerability in any of the products above, tell us. We will work with you to fix it.
- Email security@strongineering.com with: the affected product, URL or app version; steps to reproduce; the impact you observed.
- We acknowledge reports within 5 business days.
- We keep you updated until the issue is resolved.
- We credit you once it is fixed, if you want.
See also: security.txt (RFC 9116).
Safe harbor
We will not pursue legal action against good-faith security research that follows this policy. Use only your own accounts, avoid other users' data, do not degrade our services, and give us reasonable time to fix an issue before you disclose it.
Out of scope
- Denial of service, spam, or social engineering of our staff
- Physical attacks and third-party services we do not control
- Reports from automated scanners without a demonstrated impact
Security updates
- October 2026 Cloud infrastructure security audit Audited Firestore security rules, Cloud Functions access controls, and Firebase Hosting headers across all services. Hardened CSP, added X-Frame-Options DENY, and tightened CORS policies.
- September 2026 AI agent sandboxing Deployed the Strongineering AI coaching agent with iframe sandbox isolation (no allow-same-origin), scoped Firestore access, and input validation on all tool calls.
- August 2026 Encrypted data blobs for proprietary content Exercise databases and strength-standard tables are now AES-encrypted at build time and decrypted at runtime in the iOS app, replacing plaintext asset bundles.
- 2024–2025 Runtime integrity checks Shipped SecurityValidator in the iOS app: detects debugging, instrumentation, and unauthorized runtime modification. Active in all production builds.
iOS binary hardening: a defense-in-depth approach
October 2026
The Strongineering iOS binary contains proprietary training algorithms, lookup tables, and encryption keys. No single defense is unbreakable — the goal is to make reverse engineering cost more than the value of what is protected.
Five layers
Metadata stripping, link-time optimization, and dead-code elimination. Removes symbol names, debug information, and unused code paths from the shipped binary.
SecurityValidator detects attached debuggers, code-injection frameworks, modified process state, and non-standard environments. Active in all production builds since 2024.
Proprietary content is AES-encrypted at build time using a whitebox cryptographic implementation. An attacker who extracts the binary sees ciphertext, not the data.
LLVM-based control-flow flattening replaces normal branching with a dispatch loop driven by opaque state. String encryption removes readable constants from the binary.
Selected functions are compiled into custom bytecode executed by an embedded interpreter. A decompiler sees only the interpreter loop and an opaque data section — the original algorithm does not appear.
Test results
We built three variants of a test function and analyzed each with an AI-assisted reverse-engineering tool:
| Protection | Algorithm recovered? | Data visible? | Effort |
|---|---|---|---|
| Unprotected | Fully recovered | Fully visible | Minutes |
| Control-flow flattening | Partially recovered | Data section unchanged | Hours |
| Code virtualization | Not recovered | Not visible in pseudocode | Days+ |
Control-flow flattening protects code but not data — lookup table values sat byte-for-byte in the binary. Code virtualization defeated automated static analysis entirely: the decompiler produced an 8-line stub with zero math. No static defense stops dynamic analysis (tracing the interpreter at runtime), which is why Layer 1 exists.