Security

A pentest platform, engineered like one

Adopting a security scanner inverts the usual question. You're not only asking "does it work?" — you're trusting a vendor with your credentials and letting it fire attack traffic at your production environment. CarbonMantis answers that by construction.

Multi-tenant isolation

Isolation at every layer

Isolation is enforced independently at each layer, so no single mistake can collapse the boundary between tenants.

Data

Row-level tenant scoping on every table, enforced in the data layer. There is no global-query path — cross-tenant reads are architecturally impossible, and covered by integration tests.

Compute

Every scan runs as ephemeral, isolated jobs with no shared state. One tenant’s scan can’t observe or disrupt another’s.

Network

Worker egress is locked down and NAT-bounded; workers can’t reach internal systems.

Cryptography

Per-tenant key-encryption keys. One tenant’s key never decrypts another tenant’s data.

Credential protection

Per-tenant envelope encryption

For authenticated scanning we store the most sensitive data in the system — customer credentials — with envelope encryption keyed per tenant.

Each credential is encrypted with its own 256-bit data key (AES-256-GCM), wrapped by a per-tenant key-encryption key held in a cloud KMS. Plaintext keys are never persisted.
Compromising one tenant's key exposes only that tenant — the single shared application key most systems use is explicitly rejected.
Credentials are decrypted only in the control plane, only in memory, delivered to workers over a RAM-backed volume that's destroyed with the job — never written to disk, never a Kubernetes Secret.
Workers have no path to the KMS. Every decryption is audited; credentials are never displayed, and deletion is a cryptographic wipe.

Held to our own standard

The dangerous parts, contained

Isolated execution plane

Scan workers actively send attack traffic to the internet, so they run apart from everything that holds data or secrets. Egress is deny-all by default except target web ports, artifact upload, and the callback endpoint; RFC 1918 private ranges and cloud-metadata endpoints are blocked. Tool containers run non-root, read-only, with hard resource limits.

SSRF-hardened control plane

When we fetch a customer-supplied URL, a custom dialer validates the actual resolved IP at connect time — on the initial request and every redirect hop — which defeats DNS rebinding. Only public, global-unicast destinations are allowed; everything special-use is denied, and the policy fails closed. The exact bug class we report to customers, engineered out of our own stack.

Evidence minimized by design

Raw request/response bodies are never persisted. Evidence is synthesized and redacted server-side before anything is stored, through layered redaction — always-on credential scrubbing, built-in PII defaults, and your own org-specific filters — applied to every stored field.

Authentication & access

Passwords hashed with Argon2id. Short-lived RS256 JWT access tokens with rotating refresh; TOTP MFA supported. Role-based access control (Owner / Admin / Scanner / Viewer) — a Scanner can use stored credentials to run a scan but can never view them, and that use is audited.

Data handling & audit

Platform secrets live in a cloud key vault, accessed via managed identity — never env vars in production. No secrets or PII in logs. Configurable retention, and an append-only audit log of significant actions with actor, resource, IP, and timestamp.

Prove it, don't trust it

Tamper-evident, independently verifiable evidence

Every scan seals a cryptographically signed, append-only record of exactly what ran — anchored to write-once (WORM) immutable storage. You verify it yourself, offline, against a key we can't secretly swap, with an open tool. Even we can't rewrite or backdate it.

Signed execution-fact attestations plus a security audit trail, hash-chained and monotonic — insertion, truncation, rollback, and reordering are all detectable.
The verification key is pinned out-of-band (no trust-on-first-use), so a compromised API can't hand you a forged record with a matching forged key.
An independent WORM anchor proves non-equivocation — we can't show a different history to a different party, or roll the log back server-side.

See how verification works →

Stop drowning in scanner noise.

Get evidence-backed findings your team will actually act on.

Request Early Access

Be first in line when we launch · we’ll email your invite