Security & Trust
Last updated: October 2026
1. Security at SecurityScanner
We dogfood our own scanner on every production deploy. The inscan.space front-end, the worker at security-scanner-worker.fly.dev, and the public API are scanned weekly and re-scanned whenever the underlying stack changes. Anything we find is fixed before the next release. We publish the live score for each property via our public badge endpoint, so you can verify our posture directly:
- Strict HSTS (1-year max-age, includeSubDomains, preload-ready)
- Content Security Policy with nonce-based script execution
- X-Frame-Options DENY to prevent clickjacking
- Referrer-Policy strict-origin-when-cross-origin
- Permissions-Policy locking down camera, microphone, geolocation, and payment APIs
- Cookies marked Secure, HttpOnly, and SameSite=Lax
- All third-party dependencies tracked via OSV.dev CVE lookup
Security headers and cookie posture are also covered by our own header-checking module — same one we use to grade your sites.
2. Subprocessors
We share data with the following subprocessors to operate the service. Each one is contractually bound to protect your data and is subject to our vendor-review checklist before onboarding.
| Subprocessor | Purpose | Data shared |
|---|---|---|
| Supabase | Database hosting, row-level security, and edge functions | Account data, scans, findings, compliance reports, sessions |
| Stripe | Payment processing for paid plans | Billing details and subscription status (card data never touches our servers) |
| Anthropic | AI-powered vulnerability triage and tech-stack detection | Anonymized finding titles and descriptions (no target URLs or user data) |
| Vercel | Frontend hosting and serverless API routes | HTTP request metadata, edge logs |
| Fly.io | Backend scan worker hosting | Scan jobs, intermediate module results |
| Cloudflare | DNS for inscan.space and DDoS protection at the edge | DNS queries and HTTP request metadata |
We will notify customers at least 30 days before adding a new subprocessor that handles personal information. To request the full subprocessor list with DPA references, email security@inscan.space.
3. Responsible disclosure
We welcome coordinated vulnerability reports from security researchers. Our full policy, including scope, safe-harbour terms, and disclosure timeline, is published at /.well-known/security.txt.
Safe harbour. We will not pursue legal action against researchers who act in good faith, avoid privacy violations and service disruption, only interact with accounts they own or have explicit permission to test, and give us a reasonable window to fix before publishing details.
Response timeline. We aim to acknowledge new reports within 2 business days and provide a remediation plan within 5 business days. Critical issues are triaged same-day. You can reach the security team at security@inscan.space.
4. Certifications roadmap
We are transparent about where we are in our compliance journey. We do not claim certifications we have not earned.
- SOC 2 Type II — in progress. We have engaged an auditor; the observation window is open. We expect attestation in 2027.
- ISO 27001 — planned for Q3 2027, after SOC 2 Type II completion.
- GDPR — our privacy program is GDPR-aligned today (see Privacy Policy).
Enterprise customers who need current compliance evidence (DPA, subprocessors, security questionnaire responses) can request them through our contact form.
5. Status
Live service health, scheduled maintenance windows, and incident history are published at our status page. We subscribe to incident-response monitoring for both the Vercel front-end and the Fly.io worker; uptime metrics are calculated and posted there.
6. Data retention
We keep customer data only as long as needed to operate the service, meet legal obligations, and resolve disputes. Specific retention windows:
| Data | Retention |
|---|---|
| Account profile (email, name, OAuth provider id) | Lifetime of account; deleted within 30 days of account deletion |
| Session tokens (cookie-based auth) | 30 days from issue; rotated on each login |
| Scan results (target URL, score, findings, module progress) | Lifetime of account |
| Compliance reports (OWASP Top 10 2025 mapping) | Lifetime of account |
| Guest scan data (no account) | 30 days, then automatically purged |
| Audit log entries (admin actions, billing events) | 12 months minimum |
| Stripe billing events | 7 years (required for tax and accounting) |
7. Encryption
Encryption in transit
All public traffic is served over HTTPS with TLS 1.2+ (TLS 1.3 preferred). HSTS is enabled with includeSubDomains and a 1-year max-age. The scan worker only speaks HTTPS to target sites.
Encryption at rest
Supabase (managed Postgres on AWS) encrypts all data at rest using AES-256. Backups and snapshots inherit the same encryption.
Password hashing
User passwords are hashed with bcrypt (cost factor 12) before storage. OAuth-only accounts never store a password. We never log or transmit plaintext credentials.
Session token storage
Cookie sessions store only an opaque random token. The token's bcrypt hash lives in the database; the cookie itself cannot be reversed to recover the token.
Secrets management
API keys (Supabase service role, Anthropic, Stripe) live as platform environment variables on Vercel and Fly.io. They are never present in client bundles and never logged.
8. Audit log
Admin and privileged actions are recorded to an append-only audit log. Each entry includes the actor (authenticated user or service), the action type (e.g. scan.delete, subscription.update), a timestamp, and the target resource. Stripe billing events are mirrored into the same log via webhook.
Audit entries are retained for at least 12 months and are reviewed monthly for anomalous activity. Enterprise customers can request read-only access to their own audit trail.
9. Contact
Security questions, vulnerability reports, and compliance requests go to security@inscan.space. For privacy requests, see the Privacy Policy. For anything else, the contact form routes to the right team.