AI-generated code security · self-hosted

Find the vulnerabilities your AI ships and prove which are exploitable.

AI assistants write more of your code every day, and the flaws ship with it. BreachLens scans that code — plus your containers, cloud, and running apps — then runs controlled exploitation to confirm what an attacker could actually reach. Every confirmed finding ships with reproducible evidence — often a runnable command — that replays the attack. It runs on your infrastructure, with your own AI model — the proof never leaves your network.

Book a technical demo Read the docs

No agents phoning home No data leaves your network Bring your own AI model

A real BreachLens finding marked CONFIRMED — the function-level reachability panel traces the exact call path (server.js:126 → marked.setOptions()) to the vulnerable function, with the one-step fix (marked 0.3.5 → 0.3.9) and all seven subissue CVEs.

01Proof, not alerts

A finding you can't reproduce is a guess.

Every other scanner ends at a ranked list. BreachLens takes each candidate finding and attempts the exploit under authorization, in an isolated environment. Only findings it can actually reproduce earn the CONFIRMED badge. So your team debates the fix, not whether the bug is real. Here's the entire mechanism, start to finish:

Detected

A scanner flags a candidate

A scanner surfaces a possible issue in code, a container, cloud config, or a running app.

Attempted

Controlled exploitation

BreachLens tries to exploit it against your authorized target, in an isolated environment — recording the attempt where it's browser-driven.

Confirmed

Evidence attached

If it works, the finding ships with the evidence URL and the attack — plus a reproducible curl and a replay where available.

See it prove an exploit on your stack Read the docs

02Coverage

One self-hosted platform. The whole scanner stack.

Consolidate the point tools instead of stitching them together — code, cloud, and runtime in one engine, one data model, one place your team works.

Find

Every major scanner class, in one deployment.

SASTStatic analysis for injection & insecure patterns
SCAVulnerable & outdated dependencies
SECRHardcoded credentials, keys & tokens
IaCTerraform / K8s / cloud misconfig
CTNRImage OS & dependency CVEs
DASTDynamic testing of running apps & APIs
PENTAuthorized, controlled exploitation
CLDCSPM for AWS · Azure · GCP · GitHub
AIRed-team for LLM apps, agents & MCP

Prove

Evidence, not just alerts.

· Proof of exploit — reproducible evidence that replays the attack end to end.
· Recorded replay — capture an authenticated journey and drive testing through the flows that matter.
· Kills false positives — proves it to your team, and to auditors, with evidence instead of a CVSS score.

Prioritize

Cross-tier attack paths, scored by real reach.

· Attack paths — links code, container, cloud & pentest findings into one chain across an application.
· AI verdict per chain — a narrative plus a likely-real / mixed-signal / likely-noise judgment.
· Function-level reachability — is the vulnerable dependency actually called? Across supported language ecosystems.

Fix

Turn findings into reviewed pull requests.

· AI auto-fix — drafts the patch and opens a PR/MR for your team to review.
· Bring your own model — Anthropic, OpenAI, Gemini, or fully local Ollama.
· Nothing auto-merges — a human is always in the approval seat; no code leaves your environment.

Report & govern

Audit-ready output procurement asks for.

· Compliance reports — auto-mapped to OWASP Top 10, API, LLM & CI/CD.
· SBOM + signing — CycloneDX / SPDX with verifiable digital signatures.
· Preventive → corrective — shift-left gates, the scanner set, and the fix loop in one place.

Runtime & posture

Coverage past build time, into newer attack surfaces.

· Kubernetes posture — CIS-style cluster & RBAC assessment.
· Runtime sensors — bundled eBPF host & workload detection.
· MCP & LLM red-team — probe agents & models for prompt injection and exfiltration.

03Correlation

Five tiers, one attack path, one verdict.

A SAST bug, a vulnerable dependency, an exposed container, a proven exploit, and a runtime signal aren't five tickets — they're one attack path. BreachLens links them across an application boundary and lets AI judge whether it's real.

breachlens · attack-paths

A BreachLens attack path — a critical multi-vector RCE chain combining SQL injection, reflected XSS, an OpenSSL CVE in the container image, and confirmed live exploitation, scored 774 across 129 hops, carrying a proof-of-exploit badge and an AI verdict of Likely Real at 82 percent, laid out as a step-by-step attack story across the web, image, and runtime tiers.

A real cross-tier chain · proof-of-exploit confirmed · AI verdict: likely real · 82%

04Deployment & data residency

Runs on your infrastructure. Nothing leaves it.

All that proof — the findings, the attack paths, the exploit evidence — is generated where your systems live and stays there. No SaaS tenant, no third party in your trust boundary: the one thing a cloud-hosted pentest agent structurally can't offer.

Self-hosted is the default path, not an upsell. A single Docker Compose stack on your own cluster — the same install everyone gets.
Runs offline and network-restricted. Your code, findings, and AI inference stay in your network — AI runs locally via Ollama. Scanner vulnerability feeds and rules update from public sources; offline mirroring is available on request.
No third party in your trust boundary. No external account to be approved for, no prompts or findings sent to anyone else's cloud — bring your own model or run it fully local. The exploit evidence stays under your control.
Fits your pipeline. GitHub & GitLab CI templates, a standalone CLI, webhooks, and a documented API — least-privilege scopes, disclosed.

What leaves your network

Source codenothing

Scan results & findingsnothing

Exploit evidence & replaysnothing

Telemetry (default)none

AI inferenceyour model, or fully local

05See the evidence yourself

Don't take our word for it. See the proof.

Other vendors open with a wall of Fortune-500 logos. We can't — we're new. So instead of borrowed trust we hand you the earned kind: open docs, a real sample report, and a live run against a deliberately-vulnerable target. Verify it yourself before you ever talk to us.

Live walkthrough

We run BreachLens against a deliberately-vulnerable target and walk you through the findings, attack paths, and a proof-of-exploit replay — live.

book a demo

Docs & API reference

The real install guide, CLI, and interactive API playground — versioned, with a changelog. No form to read it.

docs.breachlens.app

Sample report

A sanitized compliance + proof-of-exploit report — the exact artifact your auditors and procurement will see.

request a copy

06Straight answers

The questions a security team actually asks.

Does our code or data ever leave our network?

No. BreachLens is self-hosted and runs on infrastructure you control. Source, findings, and exploit evidence stay in your boundary, and there's no telemetry phoning home by default. In an offline deployment, AI is served by a local model and your data stays put; the scanner vulnerability feeds update from public sources, with offline mirroring available on request. See the deployment docs.

Is it really self-hostable, or is that a SaaS checkbox?

Self-hosted is the default and only install path — a single Docker Compose stack you stand up on your own cluster. It isn't an enterprise upsell gated behind a bigger contract; it's what everyone runs.

Is the “proof of exploit” real, or a dressed-up severity score?

Real. A finding is only marked CONFIRMED when BreachLens actually reproduced the exploit against your authorized target. The evidence includes the evidence URL and the request that worked — and, where one can be generated, a runnable curl you can run yourself against a lab target and watch work. It is not a heuristic confidence number.

How does it fit our pipeline and tools?

GitHub and GitLab CI templates, a standalone @breachlens/cli for any runner, webhooks, and a documented REST API. Auto-fix opens PRs/MRs in your SCM; reports export to the formats procurement expects. Integration scopes are least-privilege and disclosed in the docs.

Is it safe to grant authenticated / pentest access?

Straight answer: authenticated scan and pentest access is operator-trust — gated by an explicit authorized/controlled flag, RBAC, and license tier, not a cryptographic ownership proof. Exploitation only runs against targets you mark authorized, on infrastructure you host. We'd rather state the limit plainly than let you find it during an eval.

Who's behind this — and what about compliance?

A founder-led, engineering-first team — your demo is a call with the person who built it, not an SDR. A security.txt disclosure channel, a public docs changelog, and the self-hosted architecture are all published. SOC 2 is planned, not in progress — we won't imply an audit status we don't have.