Find the vulnerabilities that actually exist
Parlix reads your repository the way an attacker would: it traces real data flows, audits them against your actual stack, and verifies every single finding before it reaches you. No rule packs. No wall of maybes.
Connects to GitHub and GitLab · Your code is never used for training
Your scanner cried wolf, so nobody reads it any more
Pattern-based tools flag the shape of a bug and leave the judgement to you. The result is a queue thousands long, where the handful of genuine issues are indistinguishable from the noise — so the queue gets ignored, and the real finding sits in it until someone else discovers it first.
Parlix inverts that. A finding has to survive validation, verification and chaining before you ever see it. What lands in your workspace is a short list that is worth your morning.
Thousands
of unreviewed alerts in a typical legacy scanner queue
Weeks
between a bug being introduced and a human reading the alert
Verified only
Parlix discards anything it cannot reproduce. A finding you can't act on is worse than no finding at all — it costs the same attention and returns nothing.
Built to be trusted, not just run
Everything below exists to raise one number: the share of reported findings that turn out to be real.
Data flows, not pattern matches
Parlix reconstructs the paths untrusted input actually takes through your application — across files, frameworks and service boundaries — then reasons about each one. No regex, no rule packs to maintain.
Every finding is verified
A candidate vulnerability is not a report. Each one goes through a dedicated verification pass that has to reconstruct the exploit path before the finding is ever shown to you.
Chained, not isolated
Real breaches are two medium bugs stapled together. Parlix chains verified findings into full attack paths, so you see the privilege escalation, not just the two ingredients.
Understands your stack
A stack-inspection pass learns your frameworks, ORMs, auth middleware and sanitisers first, so the audit knows which sinks are already safe and which of your helpers are the dangerous ones.
Tunable depth and cost
Choose scan depth, reasoning level, model per stage, parallelism and a flow budget. Run a fast pass on every branch and the deep one nightly.
Fits the way you ship
Connect GitHub or GitLab once. Scans run against real commits, results land in your workspace, and scan reports go out by email to the people who own the code.
Eight stages between your commit and a finding
Each stage narrows the field. By the time something reaches your inbox it has been reconstructed, contextualised, validated, reproduced and ranked.
- 01
Clone
The repository is fetched at the exact commit you asked for and cached by codebase hash, so an unchanged tree is never paid for twice.
- 02
Flow extraction
Entry points are enumerated and every reachable data flow from an untrusted source to a sensitive sink is reconstructed.
- 03
Stack inspection
Frameworks, ORMs, auth layers and existing sanitisers are identified so later stages judge your code by your stack, not a generic model of one.
- 04
Security audit
Each flow is audited in context against the behaviour of the stack around it.
- 05
Flow validation
Flows that were mis-reconstructed or are unreachable in practice get dropped here, before they can waste a reviewer.
- 06
Vulnerability search
Surviving flows are probed for concrete, exploitable weaknesses rather than categories of risk.
- 07
Verification
Every candidate has to be independently reproduced. Anything that cannot be is discarded rather than reported as "possible".
- 08
Chaining
Verified findings are composed into multi-step attack paths, ranked by what they actually let an attacker reach.
Connect once, scan every commit after
Link GitHub or GitLab from your workspace settings and Parlix can reach the repositories you choose — nothing more. Scan results are written back to your workspace, and finished reports can be emailed to the people who own the code.
- GitHub and GitLab, cloud or self-managed
- Per-repository access, revocable at any time
- Results routed to configurable sinks
- Email scan reports, per user
GitHub
OAuth app install, scoped to the repos you pick.
GitLab
Cloud or self-managed instances.
Sinks
Send verified findings where your team already works, instead of asking everyone to check one more dashboard.
A security tool has to hold itself to the standard
Workspaces and roles
Every project lives in a workspace. Granular permissions cover who can read, create, update, stop, pause and delete scans — and who can manage members.
Your code stays yours
Repositories are cloned for the duration of a scan and never used to train models. Access is scoped per repository and revocable from your settings at any time.
Predictable by design
Flow budgets, parallelism limits, severity filters and per-stage model selection mean a scan's cost and duration are set by you, not discovered afterwards.
Latest writing
What a scan actually costs, and how to control it
Scan depth, reasoning level, flow budgets and per-stage model selection are the four knobs that decide what a Parlix run costs. Here's how to set them.
Verifying a vulnerability before reporting it
A candidate finding and a vulnerability are different objects. Here's the verification stage that separates them, and why it deletes more than it keeps.
Why most security scanners get ignored
Every team has a scanner. Almost no team reads its output. The problem isn't discipline — it's that precision below a certain threshold makes a tool worse than useless.
See what Parlix finds in your codebase
Point it at one repository. We'll walk you through every finding, including how it was verified — and what it discarded on the way.