How we secure a security product.
We build a tool that watches adversaries. That obligates us to a higher-than-usual standard for our own posture. This page describes what is actually in place today — blackpot.io is a pre-launch alpha built and run by one engineer, and we'd rather you read the honest version.
Threat model
blackpot.io is designed under the assumption that adversaries will actively probe both our infrastructure and every deployed sensor. Our threat model explicitly accounts for:
- Adversaries targeting sensors directly. Every bait port is exposed by design. A sensor compromise must not provide lateral access to the customer's network, and must not leak canary state or session content off the sensor.
- Adversaries poisoning our attribution. An attacker who understands our anonymizer signals could try to forge them (fake WebRTC leaks, spoofed TCP fingerprints). The scoring engine is designed to require corroborating signals across independent layers before a session tier is elevated.
- Unauthorised access. The console sits behind Cloudflare Access sign-in; every block pushed and every AbuseIPDB report is recorded in an audit table (
enforcement_events,abuse_reports). - Supply chain compromise. Container images are built in CI and signed with Sigstore cosign using keyless OIDC signing. Reproducible builds are on the roadmap.
Data flow: what leaves your infrastructure
For self-hosted deployments (On-Premises tier), no session content, dossier body, or canary state ever leaves your environment. The sensor does not phone home to us. Outbound integrations (Cloudflare blocking, AbuseIPDB reports, MalwareBazaar hash lookups, webhooks) are each opt-in.
For managed deployments, sensors write to a capture database we operate in the United States, reached only over a private WireGuard network (Tailscale), never over the public internet.
Encryption
- In transit: the website and console are served over TLS through Cloudflare; sensors reach the capture database over WireGuard (Tailscale).
- Backups: nightly database backups are encrypted with AES-256 before they are written, copied to a second machine, and test-restored every week.
- Sensor control: commands to sensors must carry an HMAC-SHA256 signature bound to the target sensor; sensors open no inbound control port. Ingest authentication supports key rotation with an overlap window.
- Least privilege: each sensor, the intel worker, the public live feed, and the website use separate database roles, and row-level security stops one sensor from seeing another's data.
- Signed releases: container images are signed with Sigstore cosign in CI.
Vulnerability disclosure
If you believe you've found a security issue in blackpot.io, the daemon, the optional eBPF module, the console, or any adjacent Archon Labs infrastructure, please report it directly to us. Reports are read by the engineer who wrote the code. We aim to:
- Acknowledge your report within 2 business days
- Give an initial severity assessment within 5 business days
- Agree a disclosure timeline with you before publication
- Credit you in the release notes (unless you prefer anonymity)
- Take no legal action against good-faith researchers who follow responsible disclosure and do not access customer data
Contact: [email protected] . Machine-readable disclosure policy at /.well-known/security.txt.
Incident response
If an incident affects your deployment or data, we aim to:
- Notify you within 72 hours of confirming impact, and sooner where we can
- Send a root cause and mitigation summary once it is resolved
- Walk through what happened with your security team on request
- Publish a post-mortem for any incident that affects more than one deployment
Certifications
blackpot.io does not hold SOC 2, ISO 27001 or other third-party certifications today. SOC 2 Type II readiness is on our roadmap, and we will list an attestation here only once an auditor has issued it. In the meantime we will walk your security team through the architecture and controls described on this page. Contact [email protected]. See the security engineering section on the landing page for a summary.
Security researchers welcome
We're a security company. We expect scrutiny. If you have questions about our architecture, cryptography choices, or incident-response process that this page doesn't answer, email [email protected] and we'll set up a call.