Security
Overview
BreachSpider is built by an active ICS/OT vulnerability researcher. We monitor our own stack with BreachSpider -- our CVE coverage applies to the software we run. This page documents our security architecture for enterprise buyers, security teams, and researchers conducting due diligence.
Section 1 -- Infrastructure Security
Hosting
OVHcloud VPS, Ubuntu 24.04 LTS. US-East region. No data leaves the United States.
CDN and WAF
Cloudflare with DDoS protection, WAF rules, and SSL termination at edge. Orange Cloud enabled.
Network Exposure
UFW firewall with default deny -- ports 22 (SSH), 80 (HTTP redirect) and 443 (HTTPS) are open to the internet. The API listens on the local interface only.
Database
PostgreSQL 16 -- not publicly accessible: the firewall admits a single allow-listed administrative address only. The API connects with a restricted, non-superuser role, with row-level security enforced.
Section 2 -- Authentication Security
- Magic link authentication: no passwords stored or transmitted. No password database to breach.
- Session tokens: SHA-256 hashed, httponly + secure + SameSite=Strict cookies
- API keys: SHA-256 hashed at rest. Raw key shown only once at generation. Format: bs_live_ prefix for easy identification in code reviews and secret scanning.
- Session management: revocable from Account settings. View active sessions and invalidate remotely.
- TOTP/MFA: available on all accounts for additional protection of the magic link flow
- Invite-only member additions: team members cannot self-register -- only org admins can invite
Section 3 -- Data Security
- In transit: TLS 1.2+ enforced via Cloudflare. HSTS headers set.
- At rest: backups are AES-256 encrypted before they leave the server. The database volume relies on the hosting platform; BreachSpider does not add its own volume-level encryption.
- Database isolation: the API uses a restricted, non-superuser database role. Row-level security scopes the tables holding customer assets, findings, environments, tickets and Windows host data to their organization, verified by two-organization isolation tests.
- Tenant isolation: every request is scoped to the caller's organization in the application as well as in the database. Cross-tenant data access is architecturally prevented.
- Asset data: used only to match CVEs for your organization. Never used for any other purpose.
- Interactive assistant: Conversations with the interactive assistant are saved to your account's chat history so you can return to them, and you can delete a conversation at any time. Messages are processed by a third-party inference provider (Anthropic) under that provider's data-handling terms, and customer data is not used to train external models.
Section 4 -- Operational Security
- Backups: nightly automated backups, AES-256 encrypted on the server, then copied offsite to Backblaze B2 (US East, private storage with provider-side encryption).
- Backup retention: 31 days offsite; 2 days on the server
- Recovery time objective (RTO): 4 hours (target)
- Recovery point objective (RPO): 24 hours (last nightly backup)
- Monitoring: API availability, disk, memory and service health checked every 5 minutes, with email alerting
- Patching: Ubuntu unattended-upgrades enabled for OS-level security patches
- Audit logging: all privileged actions logged with organization, actor, resource, and IP address. Retention by tier: 30-365 days.
Section 5 -- Vulnerability Disclosure Policy
Responsible Disclosure
We practice what we preach. If you discover a vulnerability in BreachSpider, please report it responsibly:
- Email [email protected] with full details
- Allow 90 days for remediation before public disclosure
- We will not pursue legal action against good-faith researchers operating within scope
- We will credit researchers in release notes upon request
In scope: breachspider.com, including the API at breachspider.com/api/ and the documentation at breachspider.com/docs/
Out of scope: social engineering attacks, physical security, third-party services (Cloudflare, Stripe, OVHcloud), denial of service attacks
Machine-readable disclosure policy: /.well-known/security.txt
Section 6 -- Compliance Roadmap
Target completion: Q4 2026. Platform features designed with SOC 2 Trust Services Criteria in mind. Audit log provides evidence for CC6, CC7, CC8 controls.
Platform features designed to support CIP-007 (patch management) and CIP-010 (configuration management and vulnerability assessment) workflows.
Platform aligned with IEC 62443-2-1 patch management requirements for OT/ICS environments. BCS scoring incorporates ICS context factors.
Section 7 -- Contact
Security contact: [email protected]
Security disclosure: /.well-known/security.txt
For enterprise security questionnaires, compliance documentation requests, and NDA execution: [email protected]