Security

Your source code never leaves your environment.

Code Arch is built so that the most sensitive thing we touch — your source code — never leaves your environment. This page describes exactly how that works, in plain language.

If you have a security questionnaire you need answered, jump to theSecurity FAQ. If you want to report a vulnerability, emailsecurity@codearch.sh and we will respond within one business day.

The short version

Your source code never leaves the machine you install Code Arch on.There is no SaaS to send your code to. There is no cloud connection that has to be trusted. There is no telemetry agent in your production environment.

Code Arch runs on your laptop, on a developer's workstation, or on a server inside your network — wherever you choose to install it. It reads source code from a directory you explicitly authorize, analyzes it locally, stores the results in a local PostgreSQL database that you control, and renders the results in a browser that only accepts connections from localhost.

The optional LLM augmentation, when you choose to enable it, sends only derived facts (metric values and structural identifiers) — never source code, file contents, or file paths. The default configuration is fully offline.

This is the strongest data-handling guarantee any commercial code-analysis tool offers in 2026. Most alternatives (vFunction, CAST, CodeScene, GitHub Copilot Modernization) require either a cloud connection or a runtime telemetry agent in production. Code Arch requires neither.

How the data actually flows

When you run a scan

  1. You install Code Arch on a machine inside your network usingdocker compose up — no external services to provision, no API keys required, no accounts to create.
  2. You configure a CODEARCH_SCAN_ROOT environment variable pointing to a directory on disk. Code Arch can only read files inside that root.
  3. You submit a repository path (a subdirectory of CODEARCH_SCAN_ROOT) via the local web UI.
  4. The backend canonicalizes the path, verifies it lives under the configured root (rejecting symlinks that escape), and walks the directory parsing source files into an Abstract Syntax Tree.
  5. Analysis runs entirely in-process: AST extraction → module dependency graph → debt rule evaluation → Strangler Fig candidate ranking → dollar estimation.No part of this path makes any network call.
  6. Results are persisted to the local PostgreSQL container that came up alongside the backend.
  7. The browser, connected to 127.0.0.1:5173, renders the War Room dashboard from the local API.

At no point in this flow does any source code, file contents, file paths, or analysis result leave your machine.

When you enable the optional LLM augmentation

The deterministic analysis described above produces all numbers — debt scores, dollar estimates, dependency cycles, Strangler Fig rankings. The LLM does not produce or modify any number.

What the LLM does is write the narrative prose that explains those numbers in business language. Per-finding rationale ("This god class costs an estimated $14,000 to remediate because…"), Strangler Fig rationale ("Module billing is the strongest decoupling candidate because…"), and an executive summary at the top of the War Room.

When you enable LLM augmentation by settingcodearch.llm.provider=anthropic and providing anANTHROPIC_API_KEY, here is exactly what is sent to Anthropic's API:

This guarantee is enforced by code, not by policy. An integration test (LlmOfflineRegressionIT) asserts that the default configuration registers no LLM client at all — there is no outbound HTTP path to disable, because it does not exist. When the Anthropic adapter is active, a request-body assertion verifies that no .java, .cs, or absolute path string appears in any outbound request.

If the LLM call fails for any reason (network outage, rate limit, API error), the scan degrades gracefully to template-generated narrative. The scan never fails because of an LLM problem.

When the LLM is OFF (the default)

When codearch.llm.provider=none — the default — Code Arch makeszero outbound network connections during a scan. There is no telemetry, no usage reporting, no licensing check, no update check, no error reporting service. The application can run on an air-gapped machine.

Scans produce byte-identical numbers regardless of whether the LLM is on or off. The LLM only changes the prose.

Authentication and access

Code Arch v1 is a single-user tool. The backend binds to 127.0.0.1only and does not implement user authentication. This is appropriate because each user runs their own installation; there is no shared multi-user surface to protect.

Important: Do not expose the Code Arch backend to a network interface other than 127.0.0.1. The README and the docker-compose configuration enforce localhost-only binding by default. If you want to make Code Arch available to a team, run it behind an authenticated reverse proxy (e.g., your existing internal SSO gateway) — but recognize that v1 is not designed for shared multi-tenant use.

Multi-tenant authentication and role-based access control are on the roadmap for the future cloud version (see below). For self-hosted multi-team use today, isolate installations per team.

Path traversal and code execution

Two specific risks every code-analysis tool must address. We address them as follows:

Path traversal. Every repository path you submit is canonicalized using Java's Path.toRealPath() and verified to live strictly inside theCODEARCH_SCAN_ROOT you configured. Symlinks that escape the root are rejected. There is no mechanism for the application to read any file outside that root, no matter what input is supplied.

Code execution. Code Arch parses source code; it never executes it. There is no sandboxed runtime, no eval, no plugin loader that could be tricked into running attacker-controlled code from a scanned repository. The parser produces a read-only AST and discards the source string after analysis.

Storage and retention

Scan results are stored in the PostgreSQL container that ships with the docker-compose stack. This database lives on your machine, on the storage volume you configured. We do not have access to it.

You control retention. To delete a scan's data, drop the corresponding rows from thescans table (cascades to findings,strangler_candidates, scan_modules,scan_module_edges) or destroy the entire database volume. There is no soft-delete; deleted data is deleted.

Third parties (sub-processors)

The only third party that ever sees any data from your Code Arch installation is your chosen LLM provider, and only if you explicitly enable LLM augmentation.

Currently supported LLM providers:

If you do not enable LLM augmentation, no third party sees any data from your installation.

We will publish additional supported providers (OpenAI, Azure OpenAI, on-prem vLLM) as they are added. Bring-your-own-endpoint support is on the roadmap for organizations that want to route LLM calls through their own Azure OpenAI tenant or self-hosted inference server.

Encryption

In transit. Within your installation, traffic between the React frontend and the Spring Boot backend uses HTTP on localhost. Because both ends run on the same machine and the loopback interface is not exposed externally, this is appropriate. If you put Code Arch behind a reverse proxy for team access, terminate TLS at the proxy.

At rest. Scan results are stored in PostgreSQL, which inherits the encryption properties of the storage volume you mount. If you store the Docker volume on an encrypted disk (FileVault, BitLocker, LUKS, AWS EBS encryption, etc.), the data is encrypted at rest.

LLM transit. When LLM augmentation is enabled, requests to Anthropic's API go over TLS 1.2+ via the official Anthropic Java SDK.

Vulnerability disclosure

If you discover a security vulnerability in Code Arch, please emailsecurity@codearch.sh with details. We commit to:

Please do not file vulnerabilities as public GitHub issues.

Compliance

SOC 2 Type 2: Not yet attested. Because Code Arch is a self-hosted tool you install in your own environment, SOC 2 is less load-bearing than it would be for a SaaS — most of the controls SOC 2 verifies (data center physical security, access management, change management on hosted systems) are your responsibility, not ours, when you self-host. We will pursue SOC 2 Type 2 for the future cloud version (target: 2027). For today's self-hosted product, the relevant controls are the architectural ones described on this page.

GDPR / DPA: Code Arch self-hosted does not collect or process any personal data of your end users — it analyzes source code that you control on infrastructure that you control. A Data Processing Agreement is therefore not required for the self-hosted product (we are not a processor of your data). If you require a written attestation to that effect for your records, emailsecurity@codearch.sh and we will provide one.

ISO 27001, HIPAA, FedRAMP, etc.: Same logic — these compliance regimes regulate how a vendor handles your data. Because Code Arch self-hosted does not handle your data, our certification status is less directly relevant than the architecture. Reach out for specific compliance discussions, especially for the future cloud product.

Roadmap

The above describes Code Arch v1 — the self-hosted, single-user, localhost-bound architecture you can install today. We are also building a cloud-hosted version with the following added capabilities, expected over the next several quarters:

The self-hosted product will remain free of cloud dependency for organizations that prefer the strongest data-residency posture.

Questions?

Email security@codearch.sh. For sales-related security questions, sales@codearch.sh. For day-to-day product questions, hello@codearch.sh.

We are a small team and respond personally to every email.

Vendor questionnaire

Security FAQ

These answers are calibrated to Code Arch v1 (the self-hosted product). Copy-paste any answer directly into your security questionnaire. If a question relevant to your review is not addressed here, email security@codearch.sh and we will respond within one business day.

Architecture & data handling

Where does our source code go when we use Code Arch?

It does not go anywhere. Code Arch is a self-hosted tool you install on your own infrastructure (a developer machine, a workstation, or a server inside your network). Source code is read from a local disk path you authorize via the CODEARCH_SCAN_ROOT environment variable. Analysis runs entirely in-process on the machine you installed Code Arch on. No source code is transmitted to Code Arch the company, to any cloud service, or to any third party. There is no SaaS endpoint to send code to.

Is there ANY scenario where our source code could leave our network?

No. The deterministic analysis pipeline makes zero outbound network connections. This is enforced by an integration test (LlmOfflineRegressionIT) that verifies no LLM client is registered in the default configuration. If you optionally enable LLM augmentation (off by default), derived facts — module names, metric numbers, finding categories — are sent to your chosen LLM provider's API. Raw source code, file contents, file paths, and any string from disk that has not been transformed into a derived fact are never sent. This is enforced by a request-body assertion in the Anthropic adapter that fails the build if .java, .cs, or absolute path strings appear in any outbound LLM request.

Where are scan results stored?

In a PostgreSQL database that runs locally on the machine you installed Code Arch on, as part of the docker compose stack. Code Arch the company has no access to it.

How long is data retained?

For as long as you retain it. There is no automatic deletion. To delete a scan, drop the corresponding row from the scans table (cascades clean up findings, strangler_candidates, scan_modules, scan_module_edges). To delete everything, destroy the Postgres Docker volume.

Do you collect telemetry or analytics from our installation?

No. The application makes no outbound network connections in its default configuration. There is no telemetry, no error reporting service, no usage analytics, no license check phone-home.

Authentication & access control

How do users authenticate to Code Arch?

Code Arch v1 is a single-user tool that binds to 127.0.0.1 (localhost) only. Authentication is not implemented because there is no exposed network surface to protect — each user runs their own installation. Do not expose the backend to an external network interface.

Does Code Arch support SSO / SAML / LDAP / Active Directory?

Not in v1. The future cloud edition will include SAML SSO. For team use of the self-hosted product today, run Code Arch behind your organization's existing authenticated reverse proxy.

Does Code Arch support role-based access control (RBAC)?

Not in v1 (single-user architecture). RBAC is planned for the cloud edition.

Can multiple users share a Code Arch installation?

The v1 architecture is single-user. For team use, either (a) each developer runs their own installation, (b) operate a shared installation behind an authenticated proxy, or (c) wait for the cloud edition (on roadmap).

Code execution & path safety

Does Code Arch execute any code from our repositories?

No. Code Arch parses source code into Abstract Syntax Trees; it never executes scanned code. There is no sandboxed runtime, no plugin system that loads code from scanned repositories, no eval. The parser produces a read-only AST and discards the source string after analysis.

How is path traversal prevented?

Every repository path you submit is canonicalized via Java's Path.toRealPath() and verified to live strictly inside the CODEARCH_SCAN_ROOT you configured. Symlinks that escape the root are rejected. There is no mechanism in the application to read any file outside that root, regardless of input.

What if a scanned file is malicious (e.g., contains a zip-bomb-style construct)?

Code Arch only reads source files (.java, .cs) as text. It does not unzip archives, follow symbolic links beyond the configured root, or execute parser plugins. Standard parser robustness (token limits, line-length caps) protects against pathological inputs.

Third parties (sub-processors)

What third parties does Code Arch share data with?

Zero in the default configuration. If you optionally enable LLM augmentation (off by default), the LLM provider you choose receives derived facts as described above. Currently supported: Anthropic (via the official Anthropic Java SDK). On roadmap: OpenAI, Azure OpenAI, bring-your-own endpoint for self-hosted or customer-tenant LLMs.

Does Code Arch the company have any access to our data?

No. The self-hosted product runs entirely in your environment. We cannot read your scans, your source code, or your analysis results.

What is the legal/contractual basis for the data Anthropic receives when LLM augmentation is enabled?

Anthropic's standard API terms apply, including their commitment not to train on customer API data. For higher-tier guarantees (zero data retention, etc.), customers engage with Anthropic directly to obtain enterprise terms. Because the LLM call originates from your installation using an API key you provide, the contractual relationship is between you and Anthropic — Code Arch the company is not in the middle.

Encryption

Is data encrypted in transit?

Within your installation, the React frontend and Spring Boot backend communicate over HTTP on the localhost interface, which never traverses a network. If you put Code Arch behind a reverse proxy for team access, terminate TLS at the proxy. LLM API calls to Anthropic (when enabled) use TLS 1.2+ via the official Anthropic Java SDK.

Is data encrypted at rest?

Scan results are stored in PostgreSQL running in a Docker volume on your host machine. Encryption at rest depends on the encryption properties of the underlying storage you use — full-disk encryption (FileVault, BitLocker, LUKS) or volume encryption (EBS, etc.) provides encryption at rest. Code Arch does not implement application-level field encryption.

What encryption algorithms are used?

TLS 1.2+ for any outbound API calls (LLM). For at-rest, see above — depends on your storage choice.

Vulnerability management

Do you have a vulnerability disclosure program?

Yes. Email security@codearch.sh. We commit to acknowledging reports within one business day and providing preliminary assessments within three.

How are dependencies kept up to date?

The backend uses Maven with dependabot integration on the source repository. The frontend uses npm with similar automated dependency monitoring. Security patches to dependencies are released as point updates within one week of upstream availability for high-severity issues.

Has Code Arch undergone penetration testing?

Not yet. Because the v1 architecture has no exposed network surface (localhost-only, no authentication system, no multi-tenancy, no remote attack surface), the standard pentest scope is limited. We will commission a third-party pentest before the cloud edition launches.

Do you have a Software Bill of Materials (SBOM)?

Yes — generated as part of the build via the spring-boot-maven-plugin's SBOM goal. Available on request.

Compliance & certifications

Are you SOC 2 compliant?

Not yet attested. Because Code Arch v1 is self-hosted (you host the data and the application; we host nothing on your behalf), SOC 2 is less directly applicable — most SOC 2 controls verify how a vendor operates infrastructure on the customer's behalf, which is your responsibility for self-hosted Code Arch. SOC 2 Type 2 attestation is planned for the future cloud edition (target: 2027). For the self-hosted product, the relevant controls are architectural: localhost-only, no network egress, no shared infrastructure, no Code Arch personnel with access to your data. These are documented on the Security page and verifiable in the source code.

Are you GDPR compliant? Can you sign a DPA?

Code Arch self-hosted does not process personal data of your end users. We are not a processor of your data because we never receive your data — the application runs in your environment. A DPA is therefore not strictly required, but we will provide a written attestation to that effect on request. The cloud edition will include a standard DPA.

Are you ISO 27001 / HIPAA / FedRAMP / PCI compliant?

These compliance regimes regulate how a vendor handles your data. Because Code Arch self-hosted does not handle your data, our compliance status is less directly relevant than the architecture. For specific compliance discussions, especially around the future cloud edition or supported on-prem deployment in regulated environments, contact compliance@codearch.sh.

Operations & SLAs

What is your uptime SLA?

Not applicable to the self-hosted product — uptime depends on your operational practices. For the cloud edition (when launched), the SLA will be published in the cloud terms.

How is the application updated?

Releases are published as new Docker images on a versioned schedule. You pull updates on your own cadence by updating your docker-compose.yml image tags. There is no auto-update mechanism that could push code to your installation without your action — your environment is fully under your control.

How are backups handled?

Backups are your responsibility for the self-hosted product. Standard Docker volume backup practices apply (database dumps, snapshots of the Postgres volume). The cloud edition will include managed backups as part of the service.

What is the support response time?

Community support via email (hello@codearch.sh) with best-effort response. Paid plans include email support with documented response-time SLAs — see pricing for details. Enterprise plans include named-contact support with shorter SLAs.

Business continuity

What happens if Code Arch the company goes out of business?

Your installation continues to work. Because the self-hosted product runs entirely on your infrastructure with no required external dependencies (the default configuration makes zero outbound network calls), Code Arch can continue running indefinitely without our involvement. Source code escrow can be arranged for enterprise contracts.

Is the source code available to customers?

Discussed on a contract-by-contract basis for Enterprise customers via source code escrow. The deterministic analysis pipeline, parser code, and rule engine are fully audited as part of the SBOM and can be reviewed under NDA on request.

Where is Code Arch the company incorporated?

Code Arch is operated by Archlight Labs LLC, a US-based limited liability company.

Sales process & contracting

Do you accept the customer's MSA, or only your own?

Both are negotiable. For Enterprise contracts (above $25K/year), we typically use our MSA with customer-side redlines. For smaller agreements, our standard click-through Terms of Service apply.

Do you carry cyber liability insurance?

Yes. Coverage details available on request as part of the contracting process.

Will you complete our security questionnaire?

If most of your questionnaire is covered by this FAQ, please reference these answers directly (citing this document) — that is the fastest path for both sides. For questions not covered here, contact security@codearch.sh with the questionnaire and we will provide written responses, typically within five business days.

Have a question this page didn't answer?