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.

ScanDrix for Monorepos

Directory-level rules, path filters, and per-service configuration for monorepo reviews.

Monorepos need different rules per package. ScanDrix resolves configuration hierarchically so one repository can carry many policies.

Strategy

Directory-level settings

Scope rules to services/payments/**, apps/web/**, etc.

Linked repositories

Give Drixy cross-repo contract context for PRs that span services.

Per-directory rules

Extend scandrix.yml with directory-scoped rule activation:

yaml

version: 1
project: "platform-monorepo"

rules:
  - rule: "no-hardcoded-secrets"
    severity: "critical"

directories:
  - path: "services/payments/**"
    rules:
      - rule: "enforce-parameterized-sql"
        severity: "critical"
      - rule: "tenant-isolation-guard"
        severity: "critical"
  - path: "apps/web/**"
    rules:
      - rule: "unbounded-goroutine-spawn"
        severity: "info"      # Go-specific rule, irrelevant here
  - path: "packages/ui/**"
    ignore_paths:
      - "**/*.stories.tsx"    # visual tests are not review targets

Resolution: organization → repository → directory (deepest match wins per rule ID).

Keep ignore paths honest

yaml

ignore_paths:
  - "**/generated/**"
  - "**/*.pb.go"
  - "**/dist/**"
  - "**/node_modules/**"

Generated code inflates review time and noise. If a directory is owned by humans, don't ignore it — use severity: info to demote noise instead.

Review fan-out

Large monorepo PRs (30+ files) get chunked analysis: the worker splits by top-level directory so review latency stays near single-service numbers. Status comments remain one summary per PR with file-grouped inline comments.

Cost & signal tuning

Symptom	Lever
Too many comments in one package	Downgrade that package's rules to `warning`/`info`
Same finding re-flagged after suppression	`/scandrix ignore <rule> --reason ...` (audited)
PR touches only `docs/**`	Global `ignore_paths: ["docs/**"]` or expect `Skipped`
Shared package change should warn dependents	Enable `linked context` on the package (Rules → Linked Repositories)

PreviousFAQ NextSecurity-First Review Pipeline