Security & trust

We build a security product, so our own practices are the product.

This page describes our security commitments and current practices. It is not a certification. Where formal attestations (e.g. SOC 2, ISO 27001) are in progress or planned, we say so explicitly rather than imply we hold them.

Authorization first

Bastionize only tests targets you are authorized to test. Passive assessment requires an explicit authorization attestation that we record with your identity and a timestamp. Intrusive (active) checks require you to prove control of the target host through a DNS TXT or hosted-file token before they run. We block scanning of private, loopback, link-local, and cloud-metadata addresses outright.

Non-intrusive by design

Our checks are read-only and non-destructive. We do not exploit vulnerabilities, run denial-of-service tests, brute-force credentials, or submit authentication attempts. Detection uses benign, non-executing markers and content signatures to keep false positives — and impact — low.

Engineered against abuse (SSRF)

Because a scanner makes outbound requests on your behalf, we defend against server-side request forgery in two layers: every target is validated at resolution time, and every outbound connection is re-validated at connect time to prevent DNS-rebinding. Per-scan request budgets and per-check timeouts bound the load any assessment can generate.

Data handling

Responsible disclosure

Found a security issue in Bastionize itself? We want to hear from you. See our responsible disclosure policy and security.txt. Please do not run automated scans against our own systems without prior written authorization.

Subprocessors & compliance

We use reputable infrastructure and service providers to run Bastionize; a current subprocessor list is available on request. Formal compliance attestations and a Data Processing Addendum are available or in progress for enterprise customers — contact us.

Security contact: security@bastionize.com