Code analysis is usually described from the output backward: findings, severity, confidence, remediation. An AI-assisted analyzer introduces an equally important question before any finding exists: what is the security model of the analysis pipeline itself?
Source code is sensitive data. It is also untrusted input containing scripts, symlinks, configuration, generated files, and natural-language instructions. A service that inspects repositories must protect customer source from the platform while protecting the platform from the source.
Consent Must Be Specific
Connecting a repository for dependency metadata should not silently authorize source processing. These workflows expose different data and carry different costs.
Rorix Code Analysis requires explicit organization enrollment, per-project enablement, and acceptance of a source-processing disclosure. Pull-request analysis is a second opt-in choice.
That separation makes consent reversible and scoped. Disabling a project stops new analysis without requiring the entire GitHub integration to be removed.
Analyze an Exact Revision
A finding is reviewable only when it points to stable source. The analyzer should receive an exact commit SHA, not a moving branch name that can resolve differently between queueing and execution.
Rorix checks out one exact 40-character commit and disables Git hooks, credential helpers, LFS, submodules, and repository-supplied configuration. Those features are useful in developer workflows but can execute code, fetch additional content, or alter checkout behavior inside an automated service.
The repository is data to inspect, not an instruction set for the analyzer.
Do Not Build the Repository by Default
Installing dependencies and running project scripts dramatically expands the trust boundary. Package restore can execute build targets, contact registries, and consume credentials or network access.
The Code Analysis beta does not execute repository scripts or install dependencies. Trusted DeepSec configuration and Rorix's .NET matchers are mounted outside the checkout. The repository's own .deepsec files and written instructions are ignored.
This trades some possible coverage for a much clearer execution boundary—an appropriate choice for an early advisory product.
Put Hard Limits Around the Input
Isolation is necessary but insufficient. Oversized or pathological repositories can exhaust storage, memory, time, or model budget.
The beta rejects checkouts above 500 MiB or 50,000 entries, escaping symlinks, and analyzed text files above 2 MiB. Baseline and pull-request workflows also have separate limits on files per wave, batch size, concurrency, duration, and changed-file count.
Hard limits make partial coverage explainable. They also prevent one run from monopolizing shared capacity.
Make Model Access Short-Lived and Bounded
A long-lived provider key inside an analysis worker creates unnecessary exposure. Rorix issues a short-lived AI Gateway key for each run with a hard spend cap, then revokes it when the run completes, fails, times out, reaches its budget, or is cancelled.
The platform reserves the maximum applicable cost before accepting work and permits only one active analysis run per organization. Budget exhaustion remains visible as a partial outcome instead of triggering unlimited retries.
Cost control is part of the safety boundary because an adversarial input can try to turn computation into spend.
Retention and Deletion Are Product Features
Source-derived artifacts should not live forever because cleanup was left for later. Rorix encrypts analysis artifacts and applies bounded retention: longer for baseline state, shorter for pull-request state and redacted diagnostics.
Normalized findings can remain for lifecycle tracking, but raw state, prompts, and source artifacts are not downloadable through customer APIs. Project deletion fails closed if the associated Code Analysis objects cannot be deleted first.
These rules make “delete the project” a data lifecycle guarantee rather than a dashboard-only action.
Keep the Output Advisory
Isolation and revalidation reduce risk; they do not make model-assisted findings infallible. The beta never blocks a merge. Incomplete coverage, findings, timeouts, failures, and budget exhaustion produce a neutral GitHub check rather than a misleading success or failure verdict.
Read the Code Analysis beta model for the full data flow, limits, and retention policy. The product overview explains the review workflow.
An analyzer cannot credibly ask developers to trust its security advice unless its own handling of source, execution, credentials, cost, and deletion is designed with the same care.