What Is ScanDrix And How Does It Work?

ScanDrix is an autonomous AI-powered code review and AST security scanning platform built for modern engineering teams. It integrates into your Git providers (GitHub, GitLab, Bitbucket, Azure Repos) to automatically review pull requests, detect vulnerabilities, suggest code fixes, and enforce custom Drixy rules.

How Does ScanDrix Differ From Traditional Linters Like SonarQube?

Traditional linters analyze files in isolation using rigid regex or pattern rules, resulting in high false-positive rates and zero understanding of code intent. ScanDrix performs deep Abstract Syntax Tree (AST) analysis combined with multi-model AI reasoning, understanding whole-codebase context, taint flows, and architectural boundaries.

What Are Drixy Rules And How Do I Configure Them?

Drixy rules are customizable code review and security policies. You can define rules globally across your organization, per repository, or choose from a library of community best practices. You can also run 'Dry Run' previews to test rule modifications against real historical PRs before enforcing them.

Which Git Providers And CI/CD Tools Does ScanDrix Support?

ScanDrix supports GitHub, GitLab, Bitbucket, Azure Repos, and Forgejo out of the box. It also provides a CLI and team API keys for local developer workflows, pre-commit hooks, and custom CI/CD runners.

Does ScanDrix Train On Our Private Source Code?

No. ScanDrix never uses customer source code to train AI models. All code diffs are processed in ephemeral, isolated environments with strict zero-data-retention guarantees. For enterprise deployments, ScanDrix supports Bring Your Own Key (BYOK) and self-hosted on-premise installations.

How Fast Are ScanDrix Code Reviews On New Pull Requests?

ScanDrix is built for sub-minute reviews: an async worker architecture picks up webhook events without blocking CI pipelines. That is a design goal, not a measured guarantee — live service state is on the status page.

Can ScanDrix Suggest Inline Code Fixes?

Yes. When ScanDrix detects bugs, security vulnerabilities, or rule violations, it generates precise inline diff suggestions directly in the pull request review comments that developers can apply with a single click.

Can We Deploy ScanDrix On-Premise Or In Our Own VPC?

Yes. Enterprise customers can deploy ScanDrix in their own AWS, GCP, or Azure VPC, or in fully air-gapped on-premise environments with support for internal LLM endpoints (vLLM, Ollama) and enterprise SSO.

Review Flow

How a Drixy review runs end to end — when it triggers, when it skips, and what each status means.

This page describes the lifecycle of a single ScanDrix review, from webhook to posted comments.

Trigger conditions

A review starts when your Git provider sends a webhook for a pull request event. ScanDrix runs when:

Event	Default behavior
PR opened	Full review
New commits pushed to the PR	Incremental review of changed files
PR reopened	Full review
Review re-requested via comment or dashboard	Full review
Label `scandrix-skip` present	Skipped
Draft PR	Skipped (configurable)

Delivery is asynchronous: webhooks are ingested, queued, and processed by workers with exponential backoff and dead-letter queues. A slow worker can never block your Git provider's webhook endpoint.

Pipeline stages

Ingest — the webhook is validated (signature check), normalized, and de-duplicated with an idempotency key. Retries are safe.
Context expansion — the diff is widened with surrounding code so rules see enough context to judge intent, not just changed lines.
AST analysis — files are parsed per language (Go, TypeScript, Python, and others). Deterministic checks — SQL string concatenation, hardcoded secrets, missing tenant filters, unbounded goroutines — run on the tree.
AI reasoning — multi-model review evaluates the diff against active Drixy rules, architecture boundaries, and your rule messages. Prompts never contain raw secrets; credentials are redacted first.
Posting — findings are grouped, deduplicated, and posted as inline review comments with severity badges and patch suggestions.

Most reviews complete in under 60 seconds.

Statuses

✅ Approved — no blocking findings. Informational notes may still be present.
💬 Comments — findings posted; none at critical severity (or your configured blocking level).
🛑 Changes requested — at least one finding at or above the blocking severity.
⏭️ Skipped — trigger conditions not met (draft, skip label, path filters excluded all changes).
⚠️ Failed — analysis error (unsupported file type mix, provider API error after retries). Details are in the PR check run log.

Blocking behavior is yours to configure: choose which severities block merge per repository or organization under Settings → Merge Policies.

Incremental reviews

On subsequent pushes, only files changed in the new commits are re-analyzed — unless a change touches a shared module or config file that expands the analysis scope. Full re-reviews can be forced by commenting:

code

/scandrix review full

Failure handling

Reviews are retried up to 5 times with exponential backoff. Persistent failures land in a dead-letter queue and surface as a failed check on the PR with a link to re-run from the dashboard. Outages on your side never cause duplicate comment storms — every comment carries a stable finding ID used for de-duplication.

PreviousBring Your Own Key (BYOK)NextDrixy Rules