Security & Vulnerability Disclosure
Last updated: June 5, 2026. Effective: June 5, 2026.
We take security of clinical software seriously and welcome reports from security researchers, healthcare IT teams, and users. This page summarizes our security posture and tells you how to report a vulnerability responsibly.
Report a vulnerability
Primary contact: security@pphrisk.com
Please include the following in your report so we can act quickly:
- A clear description of the vulnerability and its potential impact
- Steps to reproduce (proof-of-concept code or HTTP requests welcome)
- The affected URL, page, or component
- The browser, operating system, and any relevant timing
- Your name and a public handle if you would like to be credited (optional)
Encrypted submission: if you require encryption, request our PGP key at the email above and we will respond with the current key.
Our commitment to researchers
We commit to:
- Acknowledge your report within 3 business days
- Provide an initial triage and severity assessment within 7 business days
- Keep you updated on remediation progress
- Not pursue legal action against researchers who act in good faith within the scope below
- Credit you publicly (if you wish) after the issue is resolved
Scope
In scope:
- pphrisk.com and any sub-path under it
- Authentication and session handling (Supabase Auth, magic link, OTP)
- SMART-on-FHIR launch flow (launch.html, OAuth handshake, scope handling)
- Team-feed and compliance-report data access (row-level security, email whitelist)
- Stored XSS, server-side request forgery, IDOR, and similar web vulnerabilities
Out of scope:
- Third-party services we depend on but do not operate (Vercel, Supabase, Resend, Cloudflare, jsDelivr CDN, Google Fonts) — please report directly to them
- Reports based solely on automated scanner output without proof of exploitability
- Denial-of-service attacks against the production infrastructure (do not run these)
- Social engineering of Epigenuity employees
- Physical security
- Reports about email best-practices that do not result in spoofing or interception (SPF, DKIM, DMARC tightening is welcome but is not by itself a vulnerability)
Safe-harbor rules
Acting in good faith means:
- You only access data you own or have explicit permission to test against
- You do not exfiltrate, retain, or share data beyond the minimum needed to demonstrate the issue
- You do not degrade service for other users
- You give us a reasonable opportunity to remediate (default 90 days) before public disclosure
- You comply with all applicable laws, including the Computer Fraud and Abuse Act and HIPAA
Security posture
| Domain | Posture |
|---|---|
| Transport encryption | TLS 1.3 enforced at edge (Vercel CDN). HSTS preload-eligible. No mixed content. |
| Authentication | Passwordless: Supabase Auth issues a one-time 6–10 digit code via email. No plaintext passwords are stored. Sessions are JWT-based and time-bound. |
| SMART-on-FHIR launch | OAuth 2.0 Authorization Code with PKCE. Public client (no client secret). Read-only patient-scoped scopes. No offline_access. Token stored only in browser sessionStorage; destroyed on tab close. |
| Database access | Postgres on Supabase with Row Level Security enabled on every team table. Access gated by an institutional email-domain whitelist evaluated server-side at policy time. |
| PHI storage | None. Patient name, MRN, date of birth, address, and phone are never transmitted to or stored on Epigenuity-controlled infrastructure. See the Privacy Policy. |
| De-identified data storage | Encrypted at rest (Supabase standard). Bound to team email domain. Soft-delete via archived_at; hard-delete on request. |
| Logging | Vercel edge access logs retained 30 days. Supabase auth/PostgREST logs retained per Supabase defaults. No PHI in logs because no PHI is processed server-side. |
| Dependencies | Minimal third-party JS: Tailwind CDN, Supabase JS SDK, fhirclient (SMART). All loaded over HTTPS. Subresource Integrity to be added in next maintenance window. |
| Backups | Supabase daily automated backups, 7-day retention; longer retention available on paid plan as we scale. |
| Account separation | Single-tenant Supabase project today; multi-tenant isolation via RLS and a planned per-tenant schema once usage warrants. |
| Patch management | Dependency updates reviewed weekly; security updates applied within 7 days of CVE publication. |
| SOC 2 | SOC 2 Type II report in progress; estimated completion Q1 2027. Available under NDA after that. |
Architecture summary
For technical reviewers, the SMART-on-FHIR architecture is documented in SMART_DEPLOY.md. Key invariants:
- The SMART access token never leaves the user's browser
- FHIR data flows directly from the EHR's FHIR endpoint to the user's browser — Epigenuity infrastructure is not in the data path
- Risk-factor matching happens client-side in
smart-prefill.js; the mapping rules are auditable in source - Optional team-feed and compliance-report records contain only de-identified metadata (bed label, framework, risk-factor IDs, tier, timestamp) and require an authenticated user with a whitelisted institutional email
Reporting a privacy incident
If you believe Epigenuity has handled personal information in a manner that violates our Privacy Policy, contact privacy@pphrisk.com. For HIPAA-related concerns, contact hipaa@pphrisk.com.
Hall of fame
We thank researchers who have responsibly disclosed issues to us. (List currently empty — be the first.)
PPHrisk is a product of Epigenuity LLC.