<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>ScanDrix Engineering Blog</title>
    <link>https://blog.scandrix.dev/</link>
    <atom:link href="https://blog.scandrix.dev/feed.xml" rel="self" type="application/rss+xml" />
    <description>Deep dives on AST analysis, taint tracking, and the engineering behind reliable automated code review.</description>
    <language>en-us</language>
    <lastBuildDate>Mon, 12 Oct 2026 00:00:00 GMT</lastBuildDate>
    <generator>Next.js</generator>
    <docs>https://www.rssboard.org/rss-specification</docs>
    <item>
      <title>Top 7 OWASP Vulnerabilities Pattern-Matching Linters Miss</title>
      <link>https://blog.scandrix.dev/top-7-owasp-vulnerabilities-linters-miss/</link>
      <guid isPermaLink="true">https://blog.scandrix.dev/top-7-owasp-vulnerabilities-linters-miss/</guid>
      <pubDate>Mon, 12 Oct 2026 00:00:00 GMT</pubDate>
      <category>Security</category>
      <dc:creator>ScanDrix Engineering</dc:creator>
      <description>Single-file linters miss flaws that span file boundaries. Here are 7 critical OWASP vulnerabilities only whole-codebase taint tracking can catch.</description>
      <content:encoded><![CDATA[Security linters are great at catching local hygiene issues: hardcoded tokens on line 42, unescaped output in a template, or unparameterized queries within a single database wrapper. But real-world attackers do not attack isolated lines of code — they exploit data flow across architectural boundaries.

When untrusted input enters in an API controller, passes through three service layers, and triggers an execution sink in a database repository, single-file scanners are blind to the reachability path.

1. Cross-Service Second-Order SQL Injection

Single-file scanners search for string concatenation inside SQL statements. If a value is read from an internal cache or trusted database row before being formatted into a query, pattern matchers assume it is safe.

In modern microservices, tainted user input often enters via an asynchronous event or message queue and is executed downstream. Without cross-file taint path reachability analysis, this vulnerability remains undetected.

 

2. Server-Side Request Forgery (SSRF) with Dynamic DNS Rebinding

SSRF guards that check IP addresses using simple regex fail when user-supplied hostnames resolve to private subnet IPs (such as 169.254.169.254 in cloud environments) after DNS resolution.

A true security analysis must verify whether the network client implements deterministic socket dialer guards that validate IP addresses at connect time, rather than relying on naive URL string checks.

- Pattern linters only check if the URL string starts with http:// or https://.
- They cannot verify whether the HTTP client is configured with custom dialer controls.
- Deterministic AST analysis verifies that the round-tripper or dialer enforces private CIDR blocking.

3. Broken Object Level Authorization (BOLA / IDOR)

BOLA occurs when an endpoint accepts an entity identifier without validating that the authenticated session owns that entity. The query itself looks completely secure (using parameterized queries), but the authorization predicate is missing.

Because single-file scanners only look for syntax errors or SQL injection, they see valid parameterized SQL and produce zero alerts.

4. Prototype Pollution via Deep Merge Utilities

In TypeScript and JavaScript codebases, untrusted JSON payloads merged into configuration objects can overwrite Object.prototype. If the deep-merge helper is defined in a shared library file and called in an API route, neither file reveals the vulnerability when inspected in isolation.

 

5. Insecure Deserialization Across Interface Boundaries

When deserializing untrusted binary or JSON payloads into polymorphic interface types, malicious types can trigger arbitrary code execution during instantiation. Lint rules that match function names cannot resolve dynamic runtime implementations.

6. Path Traversal with Canonicalization Bypass

Calling path.join with user-supplied filenames without verifying that the resolved path stays within the base directory root is one of the most common file access vulnerabilities.

7. Server-Side Template Injection (SSTI)

Evaluating user-provided strings inside template engines (such as Jinja, Handlebars, or Liquid) turns simple formatting into remote code execution. Catching this requires following the string variable from HTTP request body all the way into the template compiler.]]></content:encoded>
    </item>
    <item>
      <title>How to Build an Automated AST Security Gate in GitHub Actions</title>
      <link>https://blog.scandrix.dev/how-to-build-automated-ast-security-gate-github-actions/</link>
      <guid isPermaLink="true">https://blog.scandrix.dev/how-to-build-automated-ast-security-gate-github-actions/</guid>
      <pubDate>Thu, 08 Oct 2026 00:00:00 GMT</pubDate>
      <category>Engineering</category>
      <dc:creator>ScanDrix Engineering</dc:creator>
      <description>How to configure a sub-minute deterministic AST security gate in GitHub Actions that blocks vulnerabilities before merge without slowing down CI.</description>
      <content:encoded><![CDATA[Security gates in CI/CD have a bad reputation among engineering teams. They run full-codebase scans on every commit, take 15 to 30 minutes, dump 800 false positives into a dashboard, and inevitably get disabled by team leads trying to meet sprint deadlines.

A modern security gate must satisfy three strict requirements: sub-minute execution, zero false-positive tolerance for blocking builds, and actionable inline diff suggestions that developers can commit with one click.

Diff-Cone Analysis: The Secret to Sub-Minute Turnaround

Scanning an entire 500,000-line repository on every push is wasteful. But scanning only the changed files in a git diff is dangerous because it misses cross-file reachability paths.

The solution is dependency cone analysis: parse the changed files, compute their transitive caller graph, and analyze only the impacted slice. In a typical pull request, this reduces the analysis surface from 10,000 files to fewer than 50 files.

 

Configuring Non-Blocking Dry Run Rules

When introducing a new organizational rule — such as deprecating an internal auth helper or mandating parameterized queries — never set it to block PRs immediately.

Use ScanDrix Drixy rules in Dry Run mode for 14 days. This generates informational comments on pull requests without failing the status check, allowing the team to measure rule precision on real commits before turning on enforcement.

Automated Fix Suggestions Over Static Alerts

The fastest way to get developers to fix a security finding is not an alert message linking to a 20-page CVE report. It is an inline diff patch in the pull request comment.

When developers see the exact replacement lines and can click "Commit suggestion" right from GitHub's review interface, median time-to-remediation drops from days to under 5 minutes.]]></content:encoded>
    </item>
    <item>
      <title>Why AI Reviewers Hallucinate on Cross-File Diffs (And the Fix)</title>
      <link>https://blog.scandrix.dev/why-ai-reviewers-hallucinate-cross-file-diffs/</link>
      <guid isPermaLink="true">https://blog.scandrix.dev/why-ai-reviewers-hallucinate-cross-file-diffs/</guid>
      <pubDate>Tue, 29 Sep 2026 00:00:00 GMT</pubDate>
      <category>Engineering</category>
      <dc:creator>ScanDrix Engineering</dc:creator>
      <description>Why feeding raw git diffs to LLMs causes hallucinated bugs, and how compiling full AST syntax trees gives models the ground truth they need.</description>
      <content:encoded><![CDATA[First-generation AI code review tools operate on a deceptively simple premise: take a git diff, wrap it in a prompt ("You are a senior security engineer, find all bugs in this diff"), and stream the model's output to the pull request.

Within 48 hours of enabling these tools, developers start ignoring their comments. The reviewer claims a function parameter is undefined when it is imported three lines above the diff fold. It claims an SQL query is vulnerable when the query builder sanitizes parameters by default.

The Root Cause: The Context Window Illusion

A git diff is not code; it is an edit script. It contains additions and deletions, but almost none of the semantic environment needed to interpret those changes. Types, interface implementations, base classes, and global middleware live in other files.

When an LLM is presented with incomplete context, its probabilistic training forces it to predict what might be there. If a variable is used in the diff without an obvious definition in the 10 lines of surrounding context, the model will confidently hallucinate that the variable is undeclared.

- Git diffs lack symbol tables and import definitions.
- Models cannot verify whether a function exists or how its signature is typed.
- Increasing token context windows does not solve the problem — it introduces "needle-in-a-haystack" retrieval noise.

The Fix: Ground-Truth AST Syntax Trees Before Inference

The fix is separating determinism from reasoning. In ScanDrix, every file in the repository is parsed into a concrete Abstract Syntax Tree using Tree-sitter. We build a deterministic call graph and symbol table before calling any LLM.

Instead of asking the model "Are there any bugs in this diff?", we ask verifiable, grounded questions: "Given that function sanitizeInput() was called at line 34, does untrusted param ID reach query sink on line 58?"

 

The Result: Trust Re-Established

By grounding AI reasoning in mathematical AST reachability, false positives drop dramatically. Developers stop muting review bots because every comment represents a verified dataflow path, accompanied by an actionable patch.]]></content:encoded>
    </item>
    <item>
      <title>8 Best SonarQube Alternatives for Modern Engineering Teams (2026)</title>
      <link>https://blog.scandrix.dev/best-sonarqube-alternatives-2026/</link>
      <guid isPermaLink="true">https://blog.scandrix.dev/best-sonarqube-alternatives-2026/</guid>
      <pubDate>Wed, 15 Apr 2026 00:00:00 GMT</pubDate>
      <category>Guides</category>
      <dc:creator>ScanDrix Research</dc:creator>
      <description>Tired of slow CI build times and false positives? Explore the 8 best SonarQube alternatives for code quality, security, and AI review in 2026.</description>
      <content:encoded><![CDATA[For more than a decade, SonarQube has been a fixture of enterprise CI pipelines. But modern engineering organizations face mounting friction with traditional static analysis tools: pipeline delays exceeding 15 minutes per commit, endless false positives that erode developer trust, and cumbersome Java-based plugin architectures for custom rule authoring.

In 2026, a new generation of AST-powered and AI-driven code review platforms offers sub-minute turnaround times, deep cross-file reasoning, and automated inline patches.

The 4 Core Pain Points of Traditional SonarQube Scans

Engineering leaders migrating away from SonarQube consistently cite four core blockers:

- Blocking CI pipeline slowdown: SonarQube requires heavy build-agent compute that serializes PR checks and bottlenecks rapid deployment cycles.
- High false-positive rate: Rigid regex patterns trigger warnings on safe code constructs, training developers to ignore security notifications.
- No automated fix suggestions: SonarQube tells you something is wrong, but leaves developers to manually research, draft, and test remediation code.
- Complex rule maintenance: Writing custom inspection rules requires deep knowledge of SonarQube's internal Java plugin SDK.

Top Modern SonarQube Alternatives

1. ScanDrix: Operates asynchronously via webhooks without blocking CI pipelines. Uses Tree-Sitter AST analysis to trace cross-file taint flows, enforces customizable Drixy rules, and provides inline diff fixes directly on GitHub and GitLab PRs.
2. Codacy: Offers a unified dashboard for static analysis across 40+ languages, automated code coverage tracking, and repository health grading.
3. DeepSource: Focuses on automated refactoring and Autofix pull requests for formatting, security, and bug prevention.
4. Semgrep: A developer-favorite CLI and CI tool using concise YAML syntax to find syntactic AST code patterns in seconds.
5. Snyk Code: Fast, developer-centric SAST scanner that integrates software composition analysis (SCA) with proprietary code review.
6. Code Climate Quality: Automated test coverage metrics and code maintainability grades with GitHub/GitLab integration.
7. CodeRabbit: SaaS-based AI review bot for pull request summarization.
8. SonarCloud: SonarSource's official managed SaaS version for teams seeking to avoid maintaining self-hosted SonarQube servers.

The Shift from Passive Flagging to Active Remediation

The modern standard for code quality is not generating a 100-page PDF report of theoretical issues. It is catching true architectural flaws within seconds of opening a PR and giving developers the exact, verified code changes needed to ship secure software safely.]]></content:encoded>
    </item>
    <item>
      <title>7 Best CodeRabbit Alternatives for AI Code Review in 2026 (Tested &amp; Ranked)</title>
      <link>https://blog.scandrix.dev/best-coderabbit-alternatives-2026/</link>
      <guid isPermaLink="true">https://blog.scandrix.dev/best-coderabbit-alternatives-2026/</guid>
      <pubDate>Tue, 14 Apr 2026 00:00:00 GMT</pubDate>
      <category>Product</category>
      <dc:creator>ScanDrix Research</dc:creator>
      <description>Looking for a CodeRabbit alternative? We compared the top 7 AI code review tools across AST accuracy, cross-file reasoning, VPC hosting, and pricing.</description>
      <content:encoded><![CDATA[CodeRabbit popularized automated pull request summaries by hooking LLM prompt wrappers into GitHub webhooks. However, as engineering teams scale, many encounter critical limitations: hallucinated review comments on complex cross-file diffs, high false-positive rates, lack of deterministic security guarantees, and strict SaaS-only architectures that violate corporate compliance policies.

If your team is evaluating alternatives to CodeRabbit for automated code review and pull request security, here is an objective, technical comparison of the 7 leading tools available in 2026.

Why Engineering Teams Seek CodeRabbit Alternatives

Before comparing tools, it is essential to understand where standard prompt-based review bots struggle in production environments:

- Prompt-wrapper hallucinations: Tools that pass raw git diff chunks into an LLM lack full-repository syntax trees (ASTs), frequently commenting on non-existent issues or missing real vulnerabilities across file boundaries.
- SaaS-only hosting constraints: High-growth fintech, healthcare, and enterprise organizations cannot send proprietary source code to multi-tenant third-party servers.
- Inability to enforce deterministic policies: Generic prompts cannot reliably enforce strict architectural conventions, API contracts, or zero-trust security invariants.
- Seat-based pricing creep: Rigid per-developer subscription pricing becomes prohibitively expensive across large engineering departments.

1. ScanDrix — Best Overall for Deterministic AST Security & Enterprise Self-Hosting

ScanDrix takes a radically different architectural approach than standard prompt-based reviewers. Instead of streaming text diffs directly to a model, ScanDrix compiles repository source code into deterministic Abstract Syntax Trees (ASTs) using Tree-sitter and executes cross-file taint path analysis before reasoning.

Key advantages:

- Deterministic AST validation: Zero hallucinations because AI suggestions are validated against compiler syntax trees before posting.
- Drixy Rules Engine: Author declarative YAML or markdown review rules with Dry Run testing against historical pull requests.
- Enterprise Self-Hosting & BYOK: Deploy in your private AWS, GCP, or Azure VPC with Bring-Your-Own-Key LLM routing and zero data retention.
- Inline diff patches: Generates one-click mergeable code corrections directly inside pull request comments.

2. Greptile — Best for Codebase Search & Contextual PR Summaries

Greptile indexes repositories into a vector graph database, enabling developers to ask conversational questions about their codebase and generating high-level PR context summaries. While strong at semantic search, it lacks deterministic AST taint flow analysis.

3. SonarQube / SonarCloud — Best for Legacy Static Quality Gates

SonarQube remains the traditional standard for enterprise static code analysis and test coverage gating. While it provides rigid compliance reporting, it suffers from slow CI execution times, alert fatigue from noisy rule profiles, and lacks automated fix generation.

4. GitHub Copilot PR Review — Best for Native GitHub Workspaces

GitHub's native pull request reviewer integrates tightly into GitHub Enterprise. It provides quick inline suggestions but lacks custom organization-wide rule enforcement and cannot run in private VPCs or multi-cloud GitLab/Bitbucket repositories.

5. Aikido Security — Best for Multi-Tool Security Triage

Aikido combines multiple open-source security scanners (SAST, DAST, dependency scanning) into a single management console. It is tailored for security engineers rather than daily developer code review workflows.

6. Cubic — Minimalist Lightweight Review Bot

Cubic offers basic diff summaries and markdown checklists for early-stage teams wanting low-friction setup without enterprise security governance.

7. Semgrep — Best for Fast AST Pattern Matching

Semgrep provides rapid, pattern-based AST searches in CI. While extraordinarily fast for known syntactic patterns, it does not provide AI-assisted patch generation or whole-repo cross-file reasoning.

Summary: How to Choose the Right Alternative

If your primary goal is eliminating PR review latency while maintaining strict security compliance and zero false positives, ScanDrix provides the ideal balance of deterministic compiler precision and AI reasoning. Teams looking for purely conversational codebase search may prefer Greptile, while legacy enterprises needing traditional test coverage reports often maintain SonarQube in parallel.]]></content:encoded>
    </item>
    <item>
      <title>Why Linters Miss Cross-File Vulnerabilities</title>
      <link>https://blog.scandrix.dev/why-linters-miss-cross-file-vulnerabilities/</link>
      <guid isPermaLink="true">https://blog.scandrix.dev/why-linters-miss-cross-file-vulnerabilities/</guid>
      <pubDate>Wed, 18 Mar 2026 00:00:00 GMT</pubDate>
      <category>Security</category>
      <dc:creator>ScanDrix Engineering</dc:creator>
      <description>Pattern matching is excellent inside a single file and structurally blind across files. Here is the concrete shape of the problem, and what actually fixes it.</description>
      <content:encoded><![CDATA[A linter is a pattern matcher with good intentions. It parses one file, looks for shapes it recognises, and reports them. That model is genuinely good at a large class of problems: unparameterised queries in the function you are looking at, a hardcoded credential two lines below, a dangerouslySetInnerHTML in a component.

It breaks down in one specific and very common situation: when the vulnerability is not in any single file, but in the relationship between files.

The shape of the problem

Consider a missing tenant filter. The bug is not in the query. The query is perfectly correct SQL. The bug is the absence of a WHERE organizationid = ? clause that was supposed to be added by a caller three directories away.

No single-file analyser can see this. Not because the implementation is weak, but because the information required to detect the bug is not present in the file being analysed. This is a category error, not a coverage gap.

 

Why chunk-level AI review inherits the same limit

The natural response was to add an LLM. Models are excellent at reasoning about intent, and reviewers assumed that reasoning would paper over the missing context.

It does not, because of how context is delivered. A model reviewing a diff is shown a window of the change. If the sanitising call happens in a file that is not in the window, the model is not able to reason about its absence. It will confidently review what it can see, which is exactly the failure mode that makes teams disable tools.

The fix is not a bigger window. It is compiling the whole codebase to a structure the reviewer can query, then asking questions against that structure instead of against a text slice.

- Parse every file in the dependency cone into an AST, not just the diff.
- Build call and data-flow edges across file boundaries, including through interfaces.
- Ask the model whether a required edge exists, rather than whether a pattern is present.
- Report the path when it is missing, so the developer can verify the reasoning.

The measurable difference

This is the axis our evaluation isolates. On single-file categories such as secret detection, pattern matching and AST analysis both do well. On cross-file taint tracking the gap is structural: a pattern tool can only see the file in front of it, while a whole-codebase index can follow the flow.

The takeaway is not that linters are bad. They are fast, deterministic, and excellent at what they cover. They are simply the wrong tool for architectural questions, and treating them as a security control creates a false sense of coverage.]]></content:encoded>
    </item>
    <item>
      <title>Cross-File Taint Tracking in a Monorepo</title>
      <link>https://blog.scandrix.dev/ast-taint-tracking-for-monorepos/</link>
      <guid isPermaLink="true">https://blog.scandrix.dev/ast-taint-tracking-for-monorepos/</guid>
      <pubDate>Wed, 04 Mar 2026 00:00:00 GMT</pubDate>
      <category>Engineering</category>
      <dc:creator>ScanDrix Engineering</dc:creator>
      <description>How cross-package dependencies in monorepos break naive linters, and how inverse-importer AST graphs keep taint analysis fast and accurate.</description>
      <content:encoded><![CDATA[A monorepo presents a specific problem for taint analysis. The vulnerability you care about usually starts in one package and ends in another, and the two packages are deliberately decoupled — that is the entire point of the architecture. A handler in apps/api receives request data. A sink in packages/db executes it. Neither package imports the other.

Build the cone, not the file

The fix is to compute the reverse dependency cone of every changed file, then parse only that. In a well-factored monorepo this is usually a small percentage of the repository, but it captures every path that could reach the change.

Crucially, the cone must be computed from the importer graph, not the import graph. Scanning what a change imports tells you what it depends on. Scanning what imports it tells you what can reach it — which is the direction that matters for regression review.

- Invert the import graph once and cache it per commit SHA.
- For each changed file, walk importers transitively to a configurable depth.
- Parse only the resulting cone; skip packages with no path to the change.
- Recompute the cache only when the build manifest changes, not per push.

Taint state has to be explicit

Once you have the cone, you need to decide what to track. We use a small lattice: untainted, tainted, and sanitised-with-evidence. That third state is the one that matters in practice, because it is what stops the analysis from drowning in false positives.

A sanitiser call is only accepted as a sanitiser if it appears on every path to the sink. If any path reaches the sink untainted, the finding stands. This strictness is what keeps the analysis from drowning in false positives.

 

Where the time actually goes

Parsing dominates, and it is the part worth optimising. Incremental parsing — reusing the AST for files that did not change — speeds up cold reviews on large monorepos. The second win was deferring model inference until after the deterministic pass, so the model only ever sees candidates that already survived pattern matching.

The result is an architecture built for sub-minute reviews, on repositories large enough that a full re-scan would take minutes.]]></content:encoded>
    </item>
    <item>
      <title>Dry-Run Your Rules Before You Enforce Them</title>
      <link>https://blog.scandrix.dev/dry-run-rules-before-you-enforce-them/</link>
      <guid isPermaLink="true">https://blog.scandrix.dev/dry-run-rules-before-you-enforce-them/</guid>
      <pubDate>Thu, 19 Feb 2026 00:00:00 GMT</pubDate>
      <category>Guides</category>
      <dc:creator>ScanDrix Engineering</dc:creator>
      <description>Shipping a new lint rule to an entire organisation on day one is how you get a rule disabled by Friday. Here is the rehearsal-first workflow we recommend.</description>
      <content:encoded><![CDATA[Every organisation eventually writes a rule that is technically correct and practically hated. The rule is right, the matches are real, and within a week someone adds a suppression comment to a file they were supposed to be improving.

The failure is almost never the rule's logic. It is shipping the rule without measuring it against the codebase that has to live with it.

Rehearse on history, not on the future

You cannot evaluate a rule's precision by reading it. You can only evaluate it against real commits. That is what a dry run is for: replay the rule over historical pull requests and report what it would have flagged, before it is allowed to comment on anything new.

 

Read three numbers

Precision tells you whether to keep the rule. Recall tells you whether it is worth anything. Blast radius tells you whether you can ship it today.

- Precision — of everything it flagged, how much was genuinely wrong? Below ~70% and you are generating noise.
- Recall — of the seeded issues it should have caught, how many did it? Below ~80% and it is giving false confidence.
- Blast radius — how many files in the last 90 days would it have touched? Above a few hundred, ship it as warn-only first.

Ship it in stages

The rollout that works in practice is three-stage and takes about two weeks. Report-only for one week, so the team sees findings without a CI failure. Then warn on changed lines only, so pre-existing debt does not block anyone. Then enforce on new code, leaving grandfathered lines alone.

Teams that follow this sequence keep their rules enabled. Teams that enable on day one do not — and the difference is almost entirely down to whether the team got to see the rule's output before it started gating their merges.]]></content:encoded>
    </item>
    <item>
      <title>BYOK LLM Routing for Security Reviews</title>
      <link>https://blog.scandrix.dev/byok-llm-routing-for-security-reviews/</link>
      <guid isPermaLink="true">https://blog.scandrix.dev/byok-llm-routing-for-security-reviews/</guid>
      <pubDate>Tue, 03 Feb 2026 00:00:00 GMT</pubDate>
      <category>Product</category>
      <dc:creator>ScanDrix Engineering</dc:creator>
      <description>Bringing your own model key is a privacy decision with real architectural consequences. What changes in the review pipeline, and what does not.</description>
      <content:encoded><![CDATA[Bring-your-own-key is usually sold as a line item. It is closer to an architectural commitment: once a customer can supply their own inference endpoint, the review pipeline can no longer assume it controls the model boundary.

The model is a swappable dependency

The deterministic half of a ScanDrix review is model-independent. Tree-sitter parsing, taint propagation, rule evaluation, and severity assignment all happen before any model is called. The model is used for intent classification and patch drafting.

That split is what makes BYOK tractable. Swapping providers changes the second half only, and the first half — the part that produces most findings — is unaffected.

- Deterministic pass: parse, propagate taint, evaluate Drixy rules, assign severity.
- Model pass: classify intent, explain the finding, draft the patch.
- Provider abstraction: Anthropic, OpenAI, Gemini, or a self-hosted vLLM / Ollama endpoint.

Self-hosted endpoints change the deployment story

Pointing at an internal vLLM endpoint is the configuration most often paired with a VPC deployment, and it is the one that requires the most care. The internal endpoint is frequently air-gapped, which means the review pipeline needs a complete local path — no fallback to a hosted provider.

A silent fallback to a public API is the failure mode to avoid at all costs, because it would move code outside the network boundary the customer paid to build. Fail loudly instead: if the configured endpoint is unreachable, fail the review and report it.

 

What BYOK does not change

Your code still transits our ephemeral analysis tier, and we still process diffs server-side to parse them. BYOK governs where model inference happens, not where parsing happens. For customers whose threat model forbids both, the answer is a self-hosted deployment, where the entire stack — API, queue, AST workers, and model — runs inside their own network.

If you are evaluating this for a compliance requirement, the question to ask is whether you need model locality or full-stack locality. They are different products, and only one of them is a VPC deployment.]]></content:encoded>
    </item>
  </channel>
</rss>
