Security & AI Privacy
BleedWatch is a cybersecurity product — and we apply the same security standards to our own platform. This page details our security controls, how we use AI, and where your data lives.
Platform Security Controls
| Control | Implementation |
|---|---|
| Encryption at rest | AES-256-GCM envelope encryption. Master KEK isolated in Cloudflare Worker edge runtime. Per-record DEKs for credentials, registry API tokens, and Slack bot OAuth tokens used by alert rules. |
| Tenant isolation | Every DB query filters by tenant_id at the ORM layer. No shared caches across tenants. |
| Anti-SSRF | All user-provided URLs validated with DNS anti-rebinding. Private IPs, loopback, IMDS blocked. |
| Ephemeral secrets | Queue payloads never contain plaintext secrets — UUID references to an ephemeral store (consumed once). |
| ReDoS protection | 329 detection patterns audited with safe-regex2. Input truncated to 10 KB/line, 2 MB total. |
| Bot protection | Three layers: Caddy (attack paths), Next.js middleware (scanner UA), Fastify hooks (rate limiting). |
| Security headers | HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy — at three levels. |
| RBAC | Three-tier model (admin/client/viewer), 21+ granular permissions. |
| Audit trail | Async activity logging, 13+ event types, 90-day retention. |
| Rate limiting | Per-route Redis-backed: 5 req/min (AI), 30 req/min (standard), 200 req/min (Shield verify). |
AI & Data Privacy
Detection Pipeline
BleedWatch's detection pipeline processes code in six stages. Only one stage makes an external API call:
1. Regex Patterns → LOCAL (329 patterns, on-device)
2. FP Filter → LOCAL (rule-based false-positive removal)
3. Entropy Scoring → LOCAL (Shannon entropy calculation)
4. ONNX Classifier → LOCAL (on-device ML model, no external call)
5. Semantic AI (LLM) → EXTERNAL (truncated snippets sent to Anthropic API)
6. Dedup & Persist → LOCAL (deduplication and database storage)
What We Send to the LLM
- Only truncated code snippets flagged by stages 1-4
- Secrets are replaced with previews: first 4 characters + mask (e.g.,
sk_l****) - Never sent: full secret values, dependency graphs, client metadata, PII
No Training on Your Data
We use the Anthropic API under commercial terms. Per Anthropic's data usage policy, API inputs and outputs are not used for model training.
AI-Off Mode
Clients in regulated sectors (defense, banking) can disable LLM-based semantic validation entirely in Settings → AI Configuration.
Trade-off: Higher false-positive rate, but zero data leaves the platform. Stages 1-4 (all on-device) continue to operate normally.
On-Device ML
The first four pipeline stages use ONNX models that run entirely on BleedWatch infrastructure. No external API call is made for regex matching, false-positive filtering, entropy scoring, or initial classification.
Data Residency
| Region | Services |
|---|---|
| EU (Frankfurt) | KMS Proxy (Cloudflare Worker), encryption key management |
| EU (Falkenstein) | PostgreSQL, Redis, BullMQ workers, Scanner engine, API |
| US / EU (Anthropic API) | Semantic AI validation only — truncated snippets, no secrets |
| Global (Cloudflare CDN) | Static assets, marketing site, documentation |
All primary data storage and processing happens in the EU.
Compliance Framework Mapping
BleedWatch maps findings to industry compliance frameworks and generates audit-ready evidence packs:
| Framework | Status |
|---|---|
| SOC 2 Type II | In preparation |
| ISO 27001 | Mapped (50+ controls) |
| GDPR / RGPD | Compliant — DPA available |
| NIS2 | Mapped |
| PCI-DSS | Mapped |
| DORA | Mapped |
Continuous Security Testing
We run automated security scans against the BleedWatch platform itself on a recurring schedule. The goal is to catch regressions the moment they land, and to carry an auditable evidence trail independent of any single reviewer.
What we scan and how often
| Target | Tool | Cadence | Scope |
|---|---|---|---|
Public API surface (api.bleedwatch.com/api/v1/public/*) | Nuclei — 4,400+ curated templates | Weekly (Monday 04:00 UTC) + on-demand | Misconfiguration, CVE signatures, exposure indicators. Severity floor: medium. |
| Application dependencies | npm audit + Snyk | Every pull request | Package-level CVEs, transitive vulnerabilities. |
| Static code analysis | ESLint security rules + type-checker | Every pull request | Common anti-patterns, missing input validation, dangerous APIs. |
| Secret detection | Gitleaks | Every pull request | Accidental credential commits. |
We deliberately publish the methodology rather than the finding count from any single run. Single-run counts are a poor signal — they fluctuate with template updates and target changes, and "zero findings" can lull the reader into false confidence for scenarios the tool does not cover (zero-days, business-logic flaws, authentication bypasses).
Evidence retention
Every scan produces a SARIF 2.1.0 artifact retained for 400 days (the GitHub Actions maximum). A compact digest is also emitted to each run's Job Summary and periodically exported to a tracked CSV log in the repository, providing a multi-year audit history that outlives the artifact window.
Evidence is made available to qualifying enterprise clients under NDA as part of the SOC 2 / NIS 2 due-diligence process.
What falls outside automated scanning
Automation is a floor, not a ceiling. These categories are handled by review and testing practices, not by Nuclei-style signature scans:
- Business logic flaws — covered by code review and integration tests.
- Authentication and authorization flows — covered by per-route unit tests (for example, the Slack-bot-token regression test introduced in the alerts module).
- Zero-days and supply-chain attacks — covered by continuous dependency audit + the BleedWatch scanner running against our own builds.
- Targeted penetration testing — planned on an annual cycle once the SOC 2 Type II window opens.
Responsible Disclosure
BleedWatch scans public artifacts only — NPM packages, Docker images, public GitHub repos, PyPI packages. We never probe, exploit, or test tokens against live systems.
When we detect an exposed secret belonging to a third party, we follow responsible disclosure: the affected organization is notified, not exposed.
To report a security vulnerability in BleedWatch itself:
- Email: [email protected]
- Response SLA: acknowledgment within 24 hours
Observability & SLA
BleedWatch exposes operational metrics via OpenTelemetry (Prometheus-compatible endpoint). Enterprise clients can scrape these metrics into their own monitoring stack (Grafana, Datadog, etc.).
Key metrics exposed:
bleedwatch.api.request.duration— API response timebleedwatch.scan.duration— Scan job completion timebleedwatch.findings.total— Findings created (by severity)bleedwatch.queue.depth— Worker queue depthbleedwatch.scans.active— Active scan count
Enterprise plans include contractual SLA guarantees. See status.bleedwatch.com for real-time platform status.