Cerbercode analizza codice sorgente: è il dato più sensibile che un’azienda abbia. Questa pagina dice dove va quel codice, dove non va, e chi può vederlo — nel dettaglio che serve a chi deve farci passare un vendor assessment.
Il modello di distribuzione
La risposta alla domanda che conta viene prima di tutto il resto.
Cerbercode si installa on-premise, sull’infrastruttura del cliente o del partner, in container tramite Objlab Application Hub.
Non esiste una versione SaaS multi-tenant gestita da Objlab: non c’è un nostro server dove il tuo codice viene caricato.
Gli scanner girano come processi locali sulla macchina che ospita l’installazione, e leggono i sorgenti da lì.
Il database è PostgreSQL, sull’installazione del cliente. I risultati non vengono replicati verso di noi.
Nell’uso standard del prodotto Objlab non riceve né conserva codice sorgente dei clienti.
Dove va il codice, scenario per scenario
Ci sono tre situazioni in cui qualcuno tocca il codice, e vanno distinte con precisione perché hanno conseguenze diverse.
Scenario
Cosa si muove
Dove finisce
Scansione standard on-premise
Nulla esce dal perimetro: i sorgenti sono letti in locale
Resta tutto sull’installazione del cliente
Triage AI con provider locale (Ollama)
Estratti di codice verso il modello
Modello in esecuzione sulla stessa infrastruttura: non esce nulla
Triage AI con provider Anthropic
Fino a 80 righe di codice attorno al singolo finding
API Anthropic, fuori dal perimetro del cliente. Disabilitato di default
Scan gestiti da Objlab
Accesso ai repository o ai server indicati dal cliente
Il codice resta del cliente; nostri tecnici nominati possono leggerlo
Supporto tecnico
Sessione assistita aperta dal cliente
Nessuna credenziale permanente, nessuna copia di dati
Il triage AI è l’unico punto in cui il codice può uscire
Ed è una scelta del cliente, non nostra: si configura nel file di ambiente della sua installazione, e la impostazione di partenza non manda niente da nessuna parte.
Configurazione
Effetto
Nessun provider (default di fabbrica)
Triage AI spento. Nessun dato lascia l’installazione.
Provider locale (Ollama)
Il modello gira sulla stessa infrastruttura. Nessun dato esce.
Provider Anthropic
Vengono trasmesse fino a 80 righe di codice per finding analizzato. La soglia è configurabile.
Il traffico in uscita durante una scansione
Un’installazione che analizza dipendenze interroga fonti pubbliche di vulnerabilità. Chi valuta il prodotto vede quel traffico e giustamente chiede cosa contiene.
OSV — database open source delle vulnerabilità note
NVD — National Vulnerability Database, per arricchire i CVE
EPSS (FIRST) — punteggi di probabilità di sfruttamento
GitHub — solo se il cliente attiva l’integrazione con i suoi issue tracker
In tutti questi casi viaggiano identificatori di pacchetti, versioni e codici CVE. Non viaggia codice sorgente. È una distinzione che vale la pena verificare, non solo leggere: il traffico è ispezionabile.
Scan gestiti: cosa comporta davvero
Nel servizio di scansione gestita il cliente ci dà accesso ai propri repository o ai server su cui eseguire l’analisi. Va detto chiaramente, perché è l’unico caso in cui una persona di Objlab può leggere il codice del cliente. Le regole che applichiamo:
L’accesso lo concede il cliente, sui repository che decide lui, e lo revoca quando vuole.
L’accesso è nominativo: sappiamo e dichiariamo chi ce l’ha.
L’accesso è limitato alla durata dell’incarico, non è permanente.
Non conserviamo copie dei sorgenti oltre l’esecuzione dell’analisi concordata.
Su richiesta l’analisi si esegue interamente sull’infrastruttura del cliente, senza che i sorgenti la lascino.
Accesso di supporto
Per il supporto non manteniamo credenziali permanenti sulle installazioni dei clienti. L’accesso avviene su richiesta, in sessione assistita: il cliente la apre, e mentre lavoriamo c’è. È una postura più scomoda per noi e più difendibile per chi ci deve valutare.
Cosa viene conservato, e da chi
I risultati di una scansione — inclusi i frammenti di codice che accompagnano ogni finding, necessari per capire il problema e proporre la correzione — sono salvati nel database dell’installazione. Quel database è del cliente: è lui a decidere backup, tempi di conservazione e cancellazione, e a controllarne l’accesso. Objlab non ne detiene una copia.
Se trovi una vulnerabilità nel nostro prodotto
Abbiamo una politica di divulgazione coordinata pubblicata, e la rispettiamo anche quando è scomoda.
Segnalazioni a security@objlab.it, in italiano o in inglese.
Presa in carico entro 3 giorni lavorativi.
Valutazione iniziale e tempistica indicativa entro 10 giorni lavorativi.
Divulgazione pubblica non prima della release correttiva, con advisory sul repository.
Nessuna azione legale verso chi segnala in buona fede seguendo questa politica.
SBOM del prodotto in formato CycloneDX pubblicata dall’installazione stessa.
Documenti per il tuo assessment
Se stai compilando un questionario fornitori, questi li mandiamo su richiesta, senza passare da una call.
Scheda tecnica sul trattamento del codice sorgente
Accordo sul trattamento dei dati (DPA) da sottoscrivere
SBOM del prodotto in formato CycloneDX
Cronologia dei fix di sicurezza rilasciati
Descrizione dell’isolamento tra tenant per uso in ambito MSP
Il codice sorgente dei nostri clienti esce dall’Unione Europea?
Nell’uso standard non esce nemmeno dalla vostra infrastruttura, quindi la domanda non si pone. L’unica eccezione è il triage AI configurato su provider esterno, che è disabilitato di default e che potete semplicemente non attivare.
Objlab può accedere ai nostri dati?
Non nell’uso standard: l’installazione è vostra e non prevede canali di accesso verso di noi. Nel supporto entriamo solo in sessione assistita aperta da voi. Nei scan gestiti l’accesso lo concedete voi e lo revocate voi.
Serve un DPA?
Dipende dallo scenario, ed è giusto che sia il vostro ufficio legale a deciderlo. Nell’uso standard on-premise Objlab non tratta dati per vostro conto. Per scan gestiti e supporto forniamo un DPA da sottoscrivere prima dell’avvio.
Che succede ai nostri dati se interrompiamo il contratto?
Restano dove sono sempre stati: sulla vostra installazione, sotto il vostro controllo. Non c’è un nostro archivio da svuotare né un export da chiedere.
Come gestite le vulnerabilità dei vostri stessi componenti?
Cerbercode analizza sé stesso e pubblica la propria SBOM. Le vulnerabilità dei tool di terze parti che orchestriamo le segnaliamo a monte, ai rispettivi progetti.
Contenuti verificati sul prodotto il 10 agosto 2026.