Security & responsible disclosure
How we protect your data, our infrastructure, and how to report vulnerabilities safely.
Last updated: October 28, 2026
Report a vulnerability
1. Infrastructure security
All data is stored in a Supabase Postgres database with row-level security (RLS) enabled on every table. Browser clients can only access data through policies that verify ownership and role. Administrative actions are never performed directly from the browser — they go through server-side edge functions that re-verify the caller's role on every request. No client-side code has access to the service role key.
2. Credential and secret management
Payment gateway credentials (PayPal client ID, secret, webhook ID) are stored in a server-only table that is invisible to all browser roles. Only the service role can read or write credentials, and only through server-side functions. Credentials are never returned to the browser after saving — the admin interface only shows whether credentials are configured, not their values.
3. Authentication and access control
User authentication is handled by Supabase Auth with JWT-based sessions. Admin actions require a valid session token and a server-side role check on every call — a client-side role check is never trusted alone. Roles (client, staff, super_admin) are stored in the database and verified server-side. Super-admin actions like role changes and payment configuration are restricted to the super_admin role.
4. Audit logging
All administrative actions — role changes, suspension toggles, order status updates, payment configuration changes, invoice generation — are recorded in an audit log with the actor, before-state, after-state, and timestamp. The audit log is reviewed periodically and is available to super-admins for forensic review.
5. Data encryption
All connections use HTTPS/TLS. The database is encrypted at rest by Supabase. Payment credentials are stored in dedicated tables with no browser access. We do not store full card numbers or PayPal passwords — only transaction references and metadata provided by the payment processor.
6. Scan safety
Our scans are passive and external — we do not send exploit payloads, guess paths, or probe ports. We only scan the specific URL you submit, and only after you confirm ownership or authorization. Scan tools run in isolated edge functions with no access to other customers' data.
7. Team access
Access to customer data is restricted to named engineers and admin staff. No shared accounts. Engineers access customer servers only through the secure access workflow — never via credentials sent over plain email or chat. Access is revoked after work is completed.
8. Responsible disclosure
If you believe you have found a security vulnerability in Patchwise, please report it responsibly. Email us with "Security report" in the subject line. Do not publicly disclose the vulnerability until we have had a reasonable time to investigate and fix it. We acknowledge reports within 48 hours, provide a timeline for fixes, and credit responsible reporters in our advisories (with permission). We do not pursue legal action against good-faith security researchers.
9. Incident response
In the event of a security incident, we will: contain the issue, assess the scope within 24 hours, notify affected customers without undue delay, and notify supervisory authorities within 72 hours where required by law. Post-incident, we conduct a root-cause analysis and implement preventive measures. Our audit log supports forensic investigation.
10. Continuous improvement
We periodically review our security posture using automated database advisors, manual audits, and policy reviews. Access permissions are reviewed when team members join or leave. We monitor for suspicious admin activity through the audit log.