Security & responsible disclosure.

The short version: SuperPentest runs on EU infrastructure, stores every piece of evidence encrypted, never lets a credential value reach the model or the report, and enforces its scope and safety rules in code rather than trusting the model to behave. We are a small team and do not yet hold our own SOC 2 or ISO 27001 certificate; we build on certified infrastructure and are transparent about exactly what that means.

Our security posture

We run on infrastructure that is independently certified, and we are explicit that the certification belongs to the provider, not to us:

• Compute & data — Amazon Web Services, Frankfurt (eu-central-1). SOC 2, ISO 27001 and more at the infrastructure layer; your data stays in the EU.
• Edge & marketing site — Cloudflare. TLS termination, DDoS protection and a strict Content-Security-Policy on every page.
• Database — MongoDB Atlas. Encrypted at rest, access-controlled, EU region.
• Billing — Stripe. PCI-DSS Level 1; we never see or store full card data.

AWS Cloudflare MongoDB Atlas Stripe

Infrastructure and sub-processors carry their own SOC 2 / ISO 27001 / PCI-DSS certifications. The full, current sub-processor list is in our Privacy Policy and DPA.

How your evidence is handled

• Encryption. TLS in transit; encryption at rest for databases, evidence and generated artefacts.
• Secret redaction. Captured traffic is masked before it is persisted. Credential values are referenced by identity label and never placed in model context, findings or the interface.
• Auditability. An immutable record of who authorized a run, what scope applied, and who accessed the resulting evidence.
• Data residency. Evidence is stored in the EU. Transfers outside the EEA rely on an adequacy decision or the EU Standard Contractual Clauses.
• You control retention. Export reports and evidence for 30 days after termination; delete individual engagements, evidence sets and test identities at any time from your account, without asking us.

Reporting a vulnerability

We run an offensive security product, so we hold ourselves to the standard we ask of others. If you believe you have found a vulnerability in SuperPentest, report it to [email protected] with [security] in the subject line. If you would prefer an encrypted channel, say so in a first message with no technical detail and we will arrange one.

A good report lets us reproduce the issue without guessing. Please include:

• The affected URL, endpoint or component, and the date and time of your testing.
• A concise description of the issue and the impact you believe it has.
• Steps to reproduce — requests, responses and any payloads, ideally as a copy-pasteable sequence.
• Any account or identity you used, so we can correlate it with our own logs.

Please do not include third-party personal data in your report. If a proof of concept requires accessing data that is not yours, stop at the point the issue is demonstrated and describe the rest.

We publish the same contact in a machine-readable form at /.well-known/security.txt (RFC 9116).

Scope of this policy

In scope: superpentest.com and its subdomains, the SuperPentest web application and API, and the public assets served from them.

Out of scope:

• Customer environments. We test those only under a signed, written scope; they are not ours to authorize and testing them is never covered by this policy.
• Third-party services we use (for example our CDN, scheduling or analytics providers). Report those to the provider; tell us as well and we will follow up.
• Volumetric or denial-of-service testing, including stress and load generation.
• Social engineering of our team or customers, and physical attacks.
• Findings produced only by automated scanners with no demonstrated impact, missing hardening headers with no exploit path, and self-inflicted issues such as those requiring a modified client or a compromised device.

Safe harbour

If you make a good-faith effort to follow this policy, we will treat your research as authorized conduct, will not pursue or support legal action against you for it, and will work with you to understand and resolve the issue quickly.

Good faith means: you stay inside the scope above, you avoid privacy violations, data destruction and service degradation, you do not access, modify or retain data that is not yours beyond what is needed to demonstrate the issue, you do not extort or threaten disclosure, and you give us a reasonable period to fix the issue before you publish.

If a third party brings action against you for research that followed this policy, we will make clear that it was authorized.

Our response

We are a small team and we answer every report ourselves.

Stage	Target
Acknowledgement that a human has your report	Within 3 business days
Triage, severity assessment and a plan	Within 10 business days
Fix for critical and high severity	Target 30 days
Fix for medium and low severity	Target 90 days

We will tell you when the issue is fixed and we are happy to credit you publicly if you want that. We do not currently operate a paid bug bounty; if that changes, this page changes with it.

How we protect the systems we test

The product's safety properties are enforced in code, not left to the model's judgement. The same invariants that make a finding trustworthy are the ones that keep a run from doing damage.

• Authorization is deterministic. Scope, methods, budget and severity are decided by policy and code. The model cannot widen scope or authorize itself.
• Ownership is verified first. A target is confirmed as yours before any test request is sent.
• Scope is enforced at egress. Hosts outside the signed rules of engagement are blocked at the network boundary. Reconnaissance can discover an asset, but discovery never grants permission to test it — an off-scope hit is a lead, never an authorization.
• Requests are rate-limited with backoff. The engine slows down when a target shows stress, and stop conditions halt a run cleanly on your signal or ours. SuperPentest is not a load generator; bounded resilience testing is a separate, explicitly authorized add-on.
• Target output is data, never instructions. Pages, responses and callbacks may carry injection; the engine never executes them as directives.
• Secrets never leave the boundary. The agent sees identity labels, not credential values, and captured traffic is redacted before it is stored or displayed.
• Outcomes are honest. A failed or exhausted run is reported as partial or failed, never as completed, and a missing toolbox stamps the run as degraded coverage rather than passing it silently as clean.

Contact

Security reports and anything else on this page: [email protected].