Security Disclosure

We welcome reports from security researchers and we would much rather hear about a flaw from you than read about it later. If you are acting in good faith under this policy we will not pursue legal action against you, we will work with you on a fix, and we will credit you if you want to be credited.

This policy is published by [Legal entity name] and covers the Vendorisk.ai application and its API. It is not a permission slip for testing anything else.

In scope for testing and reporting:

• The Vendorisk.ai web application and any of its public routes and API handlers.
• Authentication and session handling: the email magic-link sign-in flow, the auth callback, session cookie handling and refresh, and sign-out.
• Authorisation and tenancy: any path by which one workspace can read or write another workspace's data, or a member can act above their role. Findings here are the ones we care about most.
• The team-invitation flow, including invite-token handling and acceptance.
• Billing flows and the Stripe webhook handler - for example webhook signature handling, or a way to grant a plan or credits without paying.
• Injection, server-side request forgery, cross-site scripting, content-security-policy bypass, and prompt injection that causes the application to leak data or take a privileged action rather than merely producing rude output.
• Exposure of secrets or of the privileged service key in anything reachable by a client.

Email [Security contact email]. If you want to encrypt, our public key fingerprint is [PGP key fingerprint]. Please do not open a public issue, post the finding on social media, or use the general or sales addresses on the contact page for a security matter.

What to include

• The affected URL, route or API endpoint.
• A concise description of the vulnerability class and the impact you can actually demonstrate.
• Reproduction steps, a proof of concept, and any request or response excerpts. Please redact other people's data.
• Whether you accessed, retained or copied any data that is not yours, and confirmation that you have since deleted it.
• How you would like to be credited, or that you prefer not to be.

Please keep the finding confidential until we have shipped a fix or agreed a disclosure date with you.

The following are out of scope. Reports limited to these will be closed without a fix, though we will still read them.

• Findings about vendors profiled in Vendorisk.ai dossiers. Those are unrelated third-party companies. If you have found a vulnerability in a company that a Vendorisk.ai dossier describes, report it to that company under its own disclosure policy - not to us. We will not act as an intermediary, and we cannot authorise testing against anyone else's systems.
• Disagreement with the content of an assessment. An incorrect risk tier or an unsupported claim is a factual dispute, not a vulnerability. Use the dispute route on the contact page.
• Denial of service, volumetric or stress testing, resource-exhaustion attacks, and anything that degrades service for other users.
• Social engineering, phishing or physical attacks against our staff, our users, our contractors or our suppliers.
• Attacks requiring a compromised email account, a rooted device, or an already-privileged position obtained outside this policy.
• Findings in our third-party providers' own infrastructure - report those to the provider. We will happily act on a finding in our configuration of a provider.
• Missing hardening headers, cookie flags, TLS configuration preferences, SPF/DMARC observations or automated-scanner output with no demonstrated impact; self-XSS; clickjacking on pages with no sensitive action; missing rate limits on endpoints that do not perform sensitive work; version-disclosure and best-practice findings.
• Prompt injection whose only consequence is that the model produces wrong, biased or offensive dossier text.
• The limitations we already document in section 12 - we know, they are on the roadmap, and reporting them tells us nothing new.

If you make a good-faith effort to comply with this policy during your research, we will consider your research authorised, we will not initiate or support legal action against you in connection with it, and if a third party brings action against you we will make it known that your activity was authorised under this policy.

Good faith means: you stay within the scope above; you use only your own test accounts and data; you stop as soon as you have demonstrated the issue rather than pivoting further into the system; you do not access, modify, exfiltrate or retain data belonging to anyone else, and you delete anything you encountered inadvertently and tell us; you do not degrade the service or interfere with other users; you do not demand payment in exchange for withholding a report; and you give us a reasonable opportunity to fix the issue before disclosing it.

This safe harbour is ours to give and covers only claims we could bring ourselves. It cannot bind third parties, and it does not authorise you to test the infrastructure of our providers or of the vendors described in our dossiers.

We are a small team and would rather publish honest targets than impressive ones. We aim to acknowledge a report within [Acknowledgement SLA] and to complete an initial triage - reproduce, assess severity, tell you what we think - within [Triage SLA]. After that we will keep you informed at reasonable intervals until the issue is resolved, tell you when a fix ships, and agree a coordinated disclosure date with you if you want to publish.

Vendorisk.ai does not currently operate a paid bug bounty, and this policy is not an offer of payment. We offer public credit and our genuine thanks, and we would rather say that plainly than imply a reward that does not exist. If a bounty is introduced, its terms will be published on this page.

Vendorisk.ai runs as a Next.js application against a managed PostgreSQL database provided by Supabase. Tenant isolation is enforced by row-level security policies in the database itself, so an authorisation mistake in application code does not by itself hand one workspace another workspace's data. The privileged service-role key, which bypasses those policies, is used only in server-side code paths - background research jobs, invitation administration and the billing webhook - and is never exposed to the browser.

Background research runs are orchestrated by Inngest and receive only an internal job identifier. Outbound integrations are outbound only: if your workspace configures a Slack incoming webhook we post to it, and we never read from your Slack workspace. The full list of third-party processors and exactly what each one receives is in the privacy policy.

Sign-in is a one-time email magic link. Vendorisk.ai never sets, stores or verifies a password, so there is no password hash to crack, no credential-stuffing surface, and no password reset flow to abuse. The practical consequence is that your email account is your credential: protect it, and enable multi-factor authentication on it.

Sessions are held in HTTP cookies managed by the Supabase server-side auth library and refreshed as you navigate. Membership and role are checked server-side on privileged operations.

Payments are handled by Stripe. Checkout and the customer portal are Stripe-hosted, card data never touches Vendorisk.ai infrastructure, and we store only the resulting customer and subscription identifiers. Subscription state changes are applied through a signed Stripe webhook.

All provider credentials - database keys, inference and search API keys, the Stripe secret and webhook signing secret, the email API key - are supplied through environment variables and are not committed to the repository. Optional providers are genuinely optional: when a key is absent the corresponding enrichment or email step is skipped rather than failing loudly or falling back to something less safe.

The application is served over HTTPS and sets security response headers together with a Content-Security-Policy in next.config.ts, which constrains where scripts, styles and connections may come from and limits the impact of an injected script. There are no analytics, advertising or session-replay scripts in the application, which keeps the third-party script surface at effectively zero.

Request rate limiting is applied per client IP address, derived from the x-forwarded-for header, to research and API endpoints to limit abuse and runaway cost.

These are current, known weaknesses. We publish them because a vendor risk product that hides its own gaps is not worth much.

• No independent audit or certification.Vendorisk.ai holds no SOC 2 report, no ISO 27001 certificate and no third-party penetration test result. Vendorisk.ai assesses other companies' compliance posture; it has none of its own yet, and you should not infer one from the existence of this page.
• Invite links are bearer secrets until accepted. Invitation tokens are stored only as SHA-256 hashes and become single-use on first successful accept, with a 14-day expiry. Until a link is redeemed, anyone who obtains it and can sign in as the invited email can use it - do not forward invite links, and ask an admin to revoke and re-issue if one is exposed.
• Rate limiting is in-memory and per-instance. The counters live in the memory of the process that handled the request, so they reset on deploy and do not coordinate across instances. Effective protection is therefore weaker than the configured limit suggests. A shared store is the intended fix.
• No automated retention or deletion schedule. Deletion is currently performed by a human on request. There is no self-service export or account-deletion control in the product.
• No customer-visible audit log. Research runs, saved vendors and approval decisions are recorded, but there is no exportable security audit trail of administrative actions.
• Customer-supplied webhook URLs are stored as configuration. A Slack incoming webhook URL is a secret held in an integration configuration column. Rotate it on your side if you suspect exposure.

If we determine that a security incident has affected customer personal data, we will notify affected account holders and, where required, the relevant supervisory authority within [Breach notification SLA] of establishing the facts, and in any event within the periods required by applicable law. Our notification will describe what happened, what data was involved, what we have done, and what we recommend you do. We will not sit on a confirmed incident while we decide how it looks.

Reports and questions about this page: [Security contact email].