Responsible Disclosure Policy
If you've found a security vulnerability in pentes.io, we want to hear about it. This policy describes the scope, our commitments to you, what we ask of you, and how we coordinate disclosure. We honor good-faith security research and won't take legal action against you when you stay inside the boundaries below.
Where to send it
- Email: security@pentes.io
- PGP: available on request — email us first and we'll send a fingerprint and key over a side channel.
- We monitor this inbox; acknowledgement comes from a real person, not an autoresponder.
What's in scope
pentes.ioand all subdomains we operate (the marketing site, the SPA at/#/*, the API atapi.pentes.io).- The scan worker control surface (the way we accept and authorize a scan, not the open-source scanners themselves).
- The triage pipeline (LLM input/output contract, prompt-injection vectors from SARIF inputs).
- Authentication and account management (Google Sign-In flow, password reset, session handling, MFA).
- Billing endpoints (Stripe integration points, quota enforcement, plan changes).
What's out of scope
Reports in these categories will be acknowledged but typically marked informational:
- Vulnerabilities in third-party services (Google, Stripe, Cloudflare, Anthropic, Hetzner) — report those to the vendor; we'll happily forward the relevant context.
- Findings from automated scanners with no demonstrated impact.
- Self-XSS, clickjacking on pages that don't carry sensitive actions, missing best-practice headers without an exploit path.
- Denial-of-service or volumetric attacks against our infrastructure — please don't test these; describe the theoretical vector in text instead.
- Social-engineering attempts against pentes.io staff or customers.
- Physical security of our infrastructure providers' data centers.
- Public information disclosure that is intentional (e.g. our public sitemap, llms.txt, marketing copy).
Out-of-scope reports that include a novel insight we hadn't considered are still useful — please send them.
Rules of engagement
To stay in safe harbor:
- Test only against your own pentes.io account, or against accounts you have written authorization to test.
- Do not attempt to access, modify, exfiltrate, or destroy other customers' data. If you stumble into another tenant's data while exploring, stop immediately, redact what you saw from your report, and tell us.
- Do not run automated scans against pentes.io infrastructure — we are a scanning service; you'll waste your time fighting our rate limiter. A targeted proof-of-concept is what we want.
- Do not perform actions that would degrade service for other customers (rate-limit bypasses, resource exhaustion, billing fraud).
- Give us a reasonable window to fix the issue before public disclosure — see "Coordinated disclosure" below.
Our commitments to you (safe harbor)
- We will not pursue legal action, file complaints with your employer, or contact law enforcement about your research, provided you follow the rules above in good faith.
- We will acknowledge your report within 72 hours.
- We will give you a status update at least every 14 days until the issue is resolved or formally closed.
- We will credit you in our security changelog (with your consent) once the fix has shipped.
- We will not require an NDA as a precondition for receiving your report. Once we acknowledge, we may ask you to coordinate the timing of public disclosure.
Coordinated disclosure
Our default coordinated-disclosure window is 90 days from the date we acknowledge your report. Inside that window:
- If we ship a fix earlier, you are free to publish at any point after the fix is live.
- If we ship a fix later than 90 days, we will tell you why and propose an extension; we will not invoke legal escalation if you publish anyway.
- For actively-exploited issues we may ask for a shorter coordinated window; we will explain the reason and the user impact in writing.
Rewards
We do not yet run a formal bug bounty program. We will send you a thank-you (and pentes.io swag where logistically possible) for valid reports, and we will credit you publicly. When we open a formal program with monetary rewards, prior disclosing researchers will be invited first.
What to include in a report
- A clear description of the vulnerability and where it lives (URL, endpoint, parameter).
- The steps a maintainer needs to reproduce it (curl one-liner, screenshot, proof-of-concept).
- Your assessment of impact (data accessible, user actions enabled, etc.).
- Any suggestions for remediation (optional but appreciated).
- Whether and how you want to be credited.
Hall of fame
Researchers who have responsibly disclosed issues to us will be listed here. (Currently empty — be the first.)