How we handle vulnerability reports (and what we'd do with yours)

We run a security company. Which means people test our product — which is exactly what we want. But "people can probe vergate.dev" is only a healthy statement if the rules are public, the response is professional, and nobody gets sued for helping. So here is our published vulnerability disclosure policy: what we promise, what's in scope, and what happens when you report.

#How to report

Email security@vergate.dev with:

1. A clear description of the issue
2. Reproduction steps (URLs, requests, payloads)
3. A proof of concept where practical
4. Impact assessment — what an attacker could do

Our security.txt is published at vergate.dev/security.txt — crawlers and security tooling will find the contact there. (We're a scanner; of course we have a security.txt. It would be embarrassing not to.)

#Our promises to you

• Acknowledgment within 48 hours. Every confirmed report gets a human reply — no autoresponders, no "we'll get back to you."
• Triage by severity on a published scale:
  • Critical — remote compromise, auth bypass, data exposure: fix target 7 days
  • High — serious but conditional impact: fix target 30 days
  • Medium / Low — hardening and hygiene: next scheduled release
• Transparency at every stage — you'll hear where the fix stands, and we coordinate disclosure timing with you before anything goes public.
• Credit — your name (or handle) in our changelog and release notes, unless you prefer anonymity. Your call.
• A token of thanks — for confirmed valid findings, 6 months of Pro. It's not a bug bounty (we're not there yet — that's a roadmap item with real budgets), but it's not nothing, and it's honest about being a token.

#Safe harbor — you can test us without fear

Good-faith security research on these targets is authorized:

• vergate.dev and everything under it (the marketing site, blog, docs)
• api.vergate.dev (the backend API)
• admin.vergate.dev (the internal ops dashboard)

We promise: no legal action, and no reporting you to authorities, for research conducted within scope and without malice. That commitment is the entire point of this policy — people who are scared to report either stay silent or publish without us, and both are worse for everyone.

The lines we ask you not to cross (standard stuff, but said out loud):

• Don't test other users' data — no accessing, modifying or exfiltrating other accounts' scans, projects or credentials.
• Don't DoS the platform — no load tests, no fuzzing to exhaustion, no resource exhaustion against shared infrastructure.
• Don't social-engineer our team — phishing our engineers isn't a vulnerability report.
• Don't destroy data — prove impact with the smallest payload that works.

#What happens to a report, end to end

1. Received — acknowledged within 48h, given a tracking reference.
2. Triaged — reproduced, severity assessed, fixed timeline agreed.
3. Fixed — changes land behind tests; you're told when.
4. Disclosed — we agree on timing; you get credit; the fix is described in the changelog with enough detail to be useful, never more than is safe.

#Why publish this at all?

Because trust is the category we sell in. We ask you to trust our scanner with your site; it's only fair that we're auditable in the same way. Our engine is open, our reports are signed, we published the story of our own scanner finding problems on our own site — and now, if you find a problem in us, here's exactly what happens next. Publish the rules, honor the rules, and the people who find things will keep finding them and telling you first. That's the whole game.