What it stores and how to report a vulnerability
Security
What CoverCheck stores, who else processes it, and how to report a vulnerability.
Reporting a vulnerability
Email hello@thecompound.tech. Include the URL, what you did, and what you saw. There is no bounty and no NDA to sign. We will confirm receipt, and we will tell you what we changed.
The same address, with a machine-readable expiry, is published at /.well-known/security.txt under RFC 9116.
Accounts
CoverCheck has user accounts. What is stored against one, and who else touches it, is below.
What is stored
- Your account: the email address you sign in with, and the organisation and communities you belong to
- The vendor certificates you upload, the requirements you set, and everything derived from reading them — this is the product
- Your vendors' and their agents' contact details, because chasing a renewal means emailing somebody
- Every chase email drafted for you, whether or not you approved it — an unsent draft is kept so the history is complete
- Anonymous usage analytics — page views and clicks. Form inputs are masked in session recordings
Who else processes data
- Stripe — takes the subscription payment and holds the card details — we never see a card number
- Supabase — authentication and the database holding your vendors, certificates and requirements
- PostHog — anonymous product analytics, proxied through this domain
- Vercel — serves this site and holds its access logs
Also true
- You sign in with your email address and a password, or with your Google or Microsoft account.
- No email is ever sent to a vendor or an agent without you approving that specific message first. Approval is per email, not a setting you turn on once.
- Your data is scoped to your organisation at the database level, not only in the interface.
- Payment pages are Stripe's own hosted checkout on a Stripe domain, so a card number is never typed on this site.
CoverCheck is built and run by Compound Labs. The declarations on this page are part of this product's own configuration and are re-checked at every deploy against the repository they describe: a product that claims to have no accounts and ships an authentication route fails the build, and so does one that takes payment without naming its payment processor here.