Evaluating CodeRabbit? Same review, plus real test runs. See why

Security testing

The recurring assessment between your annual pentests.

Attack chains run against your preview on every pull request, from flows it has already tested, with two real accounts. Not a replacement for a human-signed pentest, and it does not pretend to be.

Get startedBook a demo
Customer story

12 people, 5 days → 2 people, half a day

the QA sprint before every release

A twelve-person QA team ran a five-day sprint before every release. With Qodex running complex API and API security scenarios, two people finish it in half a day.

Sushant SauravCTO, Matchbook
Read the Matchbook case study
The assessment

How Qodex tests your security

It starts from the authenticated flows it has already run, not a cold crawl. Everything it reports was executed against your preview, so a finding is a path that worked, not a score that might.

Product view. Example data.

Security

qodex · security · GET /v1/orgs/{org}/billing
Agentbilling-api
▼Sub-agent: probe billing endpointRunning

Walking the OWASP API Top-10 against the live endpoint. Starting with object-level authorization: I will request another org as an Org A admin and check for a leak, then sweep auth and rate limiting before I file.

Read endpoint contract
GET /v1/orgs/{org}/billing · org-scoped resource
Sent request as Org A admin -> 200
token=<org_A_admin> · org param = org_8842
Expected 403 (cross-tenant)
no org-scope check on the billing resource
Confirmed BOLA
read another org billing · mrr 41200 leaked
Checked broken auth -> 401 ok
unauthenticated request correctly rejected
Checked rate limiting -> retry_after present
429 after 60 req/min · retry_after = 30s
Filed finding F-2048
CRITICAL · CVSS 8.6 · against pull/1473
Saved regression scenario TS-058
caught on every PR from now on
Thinking...
FindingF-2048
CRITICALCVSS 8.6·Access control

Broken object-level authorization (BOLA)

EndpointGET /v1/orgs/{orgB}/billing
Evidence
Status 200 · expected 403
{
  "org_id": "org_8842",
  "plan": "scale",
  "mrr": 41200
}
$41,200 billing returned for the wrong org. The signed-in admin does not belong to org_8842.
finding F-2048 · pull/1473 · detected 0.8s into run
Summary
  • Tested the billing endpoint against the OWASP API Top-10.
  • Confirmed 1 critical: cross-tenant read (BOLA).
  • Filed finding F-2048 against pull/1473.
  • Saved regression scenario TS-058 so this is caught on every PR.
Checks run
10 / 10
Critical
1
Auth · rate-limit
OK
  • 2real accounts, real roles
  • 6chains executed per run
  • OWASPclass coverage on every pull request
  1. Step 01

    Learns the app from flows it already ran

    The starting map is the authenticated API and UI flows Qodex has already tested for you, not a crawl of whatever a bot can reach.

  2. Step 02

    Threat-models from observed behaviour

    What it saw the app do becomes what it tries to abuse: a token that works on one route is tried on the routes it should not.

  3. Step 03

    Two real accounts, real roles

    An owner and a member, in two organizations you control, so IDOR and privilege escalation are tested the way they happen.

  4. Step 04

    Executes the chain, entry point to impact

    Each chain is run end to end against the preview. A step that fails ends the chain; a chain that reaches impact is the finding.

  5. Step 05

    A pass means the attack was blocked

    Assertions are inverted on purpose. Relaxing one cannot turn a failure green, so the number you see cannot be gamed.

  6. Step 06

    Scanners set the floor, judgment above them

    semgrep, gitleaks and osv-scanner catch the known vulnerabilities first. Qodex owns the layer above: what an attacker does with them.

Runs on every pull request against its preview, on demand, on a schedule, from CI or a webhook. Nothing to install and no runner in your pipeline.

What it finds

One example chain.

Four steps from a public signup form to every other customer's invoices, each one executed against the preview, and the one fix that breaks it.

Criticalchain 2 of 6 · cross-tenant exposure

Cross-tenant read · executed, not inferred

  1. 1Entry point

    Self-serve signup, no approval, no email domain check.

  2. 2Foothold

    Session token is accepted on any organization’s routes.

  3. 3Pivot

    Sequential organization ids enumerate every tenant.

  4. 4Impact

    Invoices, contact records, and export jobs of every other customer.

One fix breaks the chain

Resolve the organization from the session, not the path parameter, in the shared route guard.

2 accounts · roles: owner, member · 6 chains executed

Example chain. Real ones link to the pull request that opened them.

Your app

Built for the way security actually breaks

  • Attack chains, not finding lists

    Executed paths from entry point to real impact, not forty CVSS rows to triage.

  • IDOR and privilege escalation with real roles

    Two accounts, two organizations, so the cross-tenant read is attempted, not assumed.

  • Cannot be gamed

    A pass means the attack was blocked. Relaxing an assertion cannot make a failure pass.

  • Scanners as the floor

    Industry-standard open-source scanners run first. Qodex is the judgment on top, not a replacement for them.

  • Runs on every pull request

    Against the preview, before the merge. Also on demand, on a schedule, from CI, or from a webhook.

What it is not

This is not a penetration test.

What it does not do
  • It does not replace a penetration test signed by a human. No compliance framework accepts an automated scan as one, and PCI DSS bars the claim in its own text.
  • It does not produce a certificate, an attestation, or a letter for your auditor.
What it fills instead
  • The other eleven months. Your pentest is one week of the year; this runs on every pull request in between.
  • The regression check on what last year’s pentest found, so a fixed chain stays fixed.
  • The first read for the next pentest: the executed chains, the accounts used, the fix that broke each one.
Add-on

And it reviews the pull request too.

The same agent that runs the chains against the preview can review the pull request that caused them: static analyzers, a full read of every changed file, a blast-radius pass, two frontier models, and live probes before a comment is posted. One finding, one thread, one fix.

See AI code review
Security

Built to be trusted with your preview.

  • Read access, nothing installed

    No agent in your application, no runner in your CI. Read access to the repository and the preview URL is all it needs.

  • Encrypted and isolated

    Data is encrypted in transit and at rest on US servers, and isolated per project.

  • Never trains on your code

    Your code, findings and chains are never used to train models.

  • Bring your own key

    Use your own model key if you prefer. Every token is logged.

Customers

What teams say on G2.

  • G2 · Enterprise
    “We now detect issues in staging instead of finding them after deployment.”

    Anshuk K.

    AI & Data Engineer

    Verified G2 review
  • G2 · Financial services
    “The no-code interface helps our whole integration team write and manage test cases, and drastically reduces the time spent on QA.”

    Rishabh V.

    AI Engineer

    Verified G2 review
  • G2 · Small business
    “It lets our small team stay confident in releases without needing a dedicated QA resource.”

    Sameer C.

    Software Engineer

    Verified G2 review
FAQ

Questions security teams ask first.

Is this a penetration test?

No. A penetration test is a human-signed engagement, and no compliance framework accepts an automated scan in its place; PCI DSS says so in its own text. Qodex is the recurring assessment between those engagements: executed attack chains on every pull request, so the eleven months between pentests are covered and the next pentest starts from what has already been tried.

What does OWASP-class coverage mean here?

The classes in the OWASP API Top 10 that matter on a real application: broken object-level authorization (BOLA and IDOR), broken authentication, injection, and function-level authorization. Each is tested as a chain against the preview with real accounts, not as a payload list fired at a URL. Known vulnerabilities in dependencies, secrets and code patterns are caught first by semgrep, gitleaks and osv-scanner.

How does it handle false positives?

By not inferring. A finding is a chain that was executed against the preview and reached its impact: the request, the response, and the step that let it through. If the attack was blocked, the chain ends and nothing is reported. Assertions are inverted, so a pass means the attack failed and relaxing an assertion cannot make a finding disappear.

How are the accounts and roles set up?

You give Qodex two real accounts in two organizations you control, typically an owner and a member, on the preview or staging environment. Cross-tenant reads, privilege escalation and function-level checks run between those two. Where the app has more roles, add them; each chain records which account it ran as.

What data does it touch?

The preview or staging environment you point it at, with the accounts you created for it. It needs read access to the repository and never writes to your source. Data is encrypted in transit and at rest on US servers, isolated per project, and never used to train models. Bring your own model key if you prefer; every token is logged.

What does a run cost?

There is no infrastructure line: nothing to install, no runner to host, no scanner seat. Runs are part of your Qodex plan, and if you bring your own model key every token is logged so you can see exactly what a run spent. See the pricing page for plans, or ask on the demo for a number for your repository count.

Something else? Get in touch

Get started

Stop merging on faith.

Install the GitHub app, point Qodex at your staging URL, and the next pull request gets tested before it merges.

Get startedBook a demo
  • Nothing to install in your app
  • No credit card
  • Scenarios you own