How we handle source code

Short version: your source code never leaves your environment. Analysis runs locally, we pull nothing into our cloud, and we send nothing to an LLM endpoint.

What happens during a CodeCharter run

codecharter analyze .
    │
    ▼
Your machine / your CI runner reads .cs files
    │
    ▼
The standard .NET build toolchain compiles them into a code model (locally)
    │
    ▼
Built-in and custom rules run against the model (locally)
    │
    ▼
Findings appear in the console or an output file (locally)

With a complete local rule cache and a valid license, the CLI makes no network calls during analysis. It only contacts the portal to download missing rule bundles (when you use portal rule profiles), to refresh a short-lived CI license (when CODECHARTER_API_KEY is set), or to send the optional, off-by-default telemetry event. Your source code is never part of any of these calls.

You can verify this: with the rule cache restored and a valid license in place, disconnect the machine from the network and the analyze run still completes.

What goes over the network

These are all the network touches, and none of them carries your application source code:

1. CLI and asset downloads from the portal. Your own scripts can fetch the CLI archive from https://codecharter.tools with bearer authentication using your API key. The official GitHub Action does the same under the hood: it downloads the CLI archive from the portal using the api-key input and runs it natively on the runner (no Docker, no container image) — see GitHub Actions for the full execution model.

2. Rule bundle downloads for portal profiles. codecharter restore and codecharter update (and the automatic preflight before analyze) download the rule bundles of your configured portal profiles.

3. CI license refresh. When CODECHARTER_API_KEY is set, the CLI fetches a short-lived license from the portal so CI runs stay licensed without manual steps.

4. Voluntary rule upload. codecharter push uploads your .ccr rule files as drafts to the portal — only when you run it, and only your rule files, never your application code.

5. Opt-in telemetry. Off by default. When enabled, the CLI sends one anonymous event per run: tool name, latency bucket, per-rule finding counts, and a hashed workspace id — no source, paths, or code. Details on the telemetry page.

All of these calls contain no source code, only metadata (versions, platform, profile names, API key).

What bochmann-software can know about your code

What	Do we know?
Which repos you have	no
Which languages you use	no
Which findings appear in your code	no — unless you enable optional anonymous telemetry, which sends per-rule finding counts, never the findings themselves
Which file names you have	no
Which rules you have active	no for local rules; if you use portal rule profiles, we can see which profiles your account downloads, not how they fire in your code
When you pulled the CLI	yes
Which platform the pull was	yes
Which API key pulled	yes
Which CodeCharter version	yes

We log only what we need for operations (subscription management, download audit). Download logs also record the client IP address and User-Agent of the request.

Benefits of local analysis

• GDPR and NDAs stay straightforward. When your code never reaches our servers, there is no data processing overhead for analysis data. The DPA covers only contact data and subscription records.
• Reproducible builds. Once your rule cache is restored, analysis on your machine runs independently of our service availability.
• Confidence in security reviews. Source code is more sensitive than contact data. With CodeCharter, that layer stays in your hands.

What would happen in a security incident

If someone were to break in and gain access to our database and servers:

• Source code: not affected because it is not stored with us.
• Findings from your codebase: not affected because we never store them. If you opted into anonymous telemetry, only per-rule counts without any code or file references exist on our side.
• Login data (email + password hash) would be affected. We never store plaintext passwords; the hashes cannot be reversed directly.
• API key hashes would be affected — in that case we would immediately revoke all existing keys and ask you to issue new ones.

We would notify the supervisory authority within 72 hours and inform you without undue delay, as the GDPR requires.

If you want to look deeper

The CLI is closed-source; you cannot see the exact code. However:

• We offer an on-request security review with your team (source walkthrough, architecture Q&A).
• We give penetration testers access to a test instance on request.
• Every download from the portal includes its SHA-256 checksum in the X-CodeCharter-Sha256 response header, and installer hashes are published with each release — so you can verify supply-chain integrity yourself. We can additionally provide hashes in advance on request.

Write to us if you need any of this.