Cerbercode analyses source code — the most sensitive asset a company has. This page states where that code goes, where it does not, and who can read it, in the detail a vendor assessment requires.
The answer to the question that matters comes before everything else.
There are three situations in which someone touches the code, and they must be told apart precisely because the consequences differ.
| Scenario | What moves | Where it ends up |
|---|---|---|
| Standard on-premise scan | Nothing leaves the perimeter: sources are read locally | Everything stays on the customer installation |
| AI triage with a local provider (Ollama) | Code excerpts sent to the model | Model runs on the same infrastructure: nothing leaves |
| AI triage with the Anthropic provider | Up to 80 lines of code around a single finding | Anthropic API, outside the customer perimeter. Disabled by default |
| Objlab-managed scans | Access to repositories or servers designated by the customer | Code stays the customer’s; named Objlab engineers can read it |
| Technical support | Assisted session opened by the customer | No standing credentials, no copies of data |
And it is the customer’s choice, not ours: it is configured in the environment file of their own installation, and the starting setting sends nothing anywhere.
| Configuration | Effect |
|---|---|
| No provider (factory default) | AI triage off. No data leaves the installation. |
| Local provider (Ollama) | The model runs on the same infrastructure. No data leaves. |
| Anthropic provider | Up to 80 lines of code per analysed finding are transmitted. The limit is configurable. |
An installation that analyses dependencies queries public vulnerability sources. Whoever assesses the product sees that traffic and rightly asks what is in it.
In all these cases what travels are package identifiers, versions and CVE codes. Source code does not. It is a distinction worth verifying rather than just reading: the traffic is inspectable.
In the managed scanning service the customer grants us access to their repositories or to the servers where the analysis runs. This must be said plainly, because it is the only case in which an Objlab person can read customer code. The rules we apply:
For support we hold no standing credentials on customer installations. Access happens on request, in an assisted session: the customer opens it, and stays present while we work. It is less convenient for us and more defensible for whoever has to assess us.
Scan results — including the code excerpts attached to each finding, needed to understand the issue and propose a fix — are stored in the installation’s database. That database is the customer’s: they decide backups, retention and deletion, and control access to it. Objlab holds no copy.
We publish a coordinated disclosure policy, and we follow it even when it is inconvenient.
If you are filling in a vendor questionnaire, we send these on request, without a call first.
In standard use it does not even leave your infrastructure, so the question does not arise. The only exception is AI triage configured with an external provider, which is disabled by default and which you can simply leave off.
Not in standard use: the installation is yours and has no access channel towards us. For support we only enter through an assisted session you open. For managed scans you grant the access and you revoke it.
It depends on the scenario, and it is right for your legal team to decide. In standard on-premise use Objlab does not process data on your behalf. For managed scans and support we provide a DPA to sign before we start.
It stays where it always was: on your installation, under your control. There is no archive of ours to purge and no export to request.
Cerbercode scans itself and publishes its own SBOM. Vulnerabilities in the third-party tools we orchestrate are reported upstream to the respective projects.
Content verified against the product on 10 August 2026.
