This page is maintained by HuntBug Inc. to answer common security and privacy questions about the HuntBug platform. It describes controls that are live in the product today and our staged plan toward SOC 2 readiness. It is not a certification, an audit report, or independent verification.
Security on HuntBug is shared: our hosting providers secure the underlying infrastructure, HuntBug secures the application and how report data is handled, and customers are responsible for their own account hygiene — strong credentials, two-factor enrolment, and who they grant program access to.
Everything below is implemented and visible in the product.
Email/password and Google sign-in, with TOTP two-factor available for researchers and company accounts. Sensitive account changes require a recent, step-up authenticated session.
Row-level access rules on every data table. Researchers see only their own reports; company members see only programs assigned to their organisation; staff actions are role-gated.
Report bodies, attachments and thread messages are private to the reporter, the assigned triage staff and the owning company. Email notifications are content-free — they never include message text.
Notes marked internal are filtered server-side and are never delivered to the reporting researcher.
Payout details, KYC and tax submissions are stored encrypted with per-record initialisation vectors; only masked identifiers are shown in the UI.
Proof-of-concept files live in a private bucket, are scoped to the uploader's path, and are served only through short-lived signed URLs.
Privileged actions — bans, forced status transitions, program access changes — are written to an append-only audit log that cannot be edited or deleted from the app.
HuntBug runs its own disclosure channel at /responsible-disclosure and publishes a security.txt.
Roadmap phases describe intent and are subject to change. Target dates are shared under NDA during procurement rather than published here.