Cerbercode

Software Objlab - OBJ-CERB-001 Vedi i prezzi →

Il fascicolo CRA che non esce dalla vostra rete. Cerbercode si installa presso di voi, anche in una rete senza accesso a Internet, analizza il software con 39 strumenti in 12 categorie e produce i documenti che il Cyber Resilience Act e le norme di settore chiedono: fascicolo tecnico, SBOM, VEX, bozze delle segnalazioni con le scadenze. Lo stesso prodotto serve chi lo usa per sé e chi eroga il servizio a più clienti, ciascuno isolato dagli altri. La conformità resta responsabilità del fabbricante: Cerbercode produce le evidenze e i documenti, la valutazione è del fabbricante e, dove previsto, dell'Organismo Notificato.

Cosa risolve

Dall'11 settembre 2026 le vulnerabilità sfruttate e gli incidenti gravi vanno segnalati: preallarme entro 24 ore, notifica entro 72 ore, relazione finale nei termini del CRA
Il fascicolo tecnico (Allegato VII) e la dichiarazione UE di conformità da avere pronti per l'11 dicembre 2027, e da tenere aggiornati a ogni rilascio
SBOM, VEX e priorità delle CVE (CISA KEV, EPSS) da ricostruire a mano, uno strumento alla volta
Il codice sorgente non può uscire dal perimetro aziendale, e a volte la rete non esce nemmeno verso Internet

Il fascicolo CRA che non esce dalla vostra rete

Tre cose insieme, nello stesso prodotto:

Si installa presso di voi, in container su un server Linux o Windows, anche in una rete
senza accesso a Internet. Il codice sorgente non lascia la vostra infrastruttura.
Produce i documenti, non solo la lista dei problemi: fascicolo tecnico CRA, SBOM, VEX,
dichiarazione di conformità e politica di gestione delle vulnerabilità in bozza, bozze delle
segnalazioni con le scadenze, fascicoli delle norme di settore.
Serve anche chi eroga il servizio a più clienti (MSP, MSSP, consulenti): ogni cliente
isolato, un pannello unico con punteggio CRA e andamento di ciascuno.

Che cosa analizza

39 strumenti di analisi in 12 categorie, eseguiti in parallelo e normalizzati in un unico
documento SARIF 2.1.0.

Categoria	Alcuni degli strumenti	Che cosa cerca
SAST, analisi statica	Bandit, Semgrep, ESLint-security, SpotBugs + FindSecBugs, analisi Roslyn per .NET, Flawfinder	Difetti nel codice sorgente, configurazioni predefinite insicure, rotte esposte senza autorizzazione, chiamate in uscita senza timeout
SCA, dipendenze	pip-audit, npm-audit, OWASP Dependency-Check, `dotnet list --vulnerable`, osv-scanner, Grype	Vulnerabilità note nelle librerie e nelle immagini container, pacchetti malevoli
DAST e IAST	nuclei, schemathesis, OWASP ZAP, verifica delle autorizzazioni, sonde DICOM e HL7-MLLP	L'applicazione in esecuzione
Segreti	detect-secrets, Gitleaks, ricerca nei binari	Credenziali nel codice, nella storia del repository e negli eseguibili
SBOM, IaC, licenze	Syft, Checkov, analisi delle licenze	Inventario dei componenti, Terraform, Kubernetes, Helm, Dockerfile, licenze a rischio
Igiene, PLC, qualità, architettura	controlli del repository, analisi IEC 61131-3, lizard, grafo dei moduli	File che non dovrebbero esserci, logica di controllo, complessità, dipendenze circolari

Linguaggi: Python, JavaScript e TypeScript, Java, C# e .NET, C e C++, infrastruttura come
codice, immagini container, PLC (IEC 61131-3). Con i verticali anche RPG, CL e COBOL su IBM i e
COBOL, PL/I, JCL e CICS su z/OS.

Il conteggio comprende gli strumenti dei verticali e dei moduli opzionali: ogni installazione
esegue quelli della propria licenza, e ogni scansione dichiara quali strumenti non ha eseguito e
perché. Uno strumento che non ha girato non produce «zero problemi».

Deduplica e decisioni di triage

Lo stesso problema trovato da più strumenti è una riga sola. Due risultati con lo stesso
file, la stessa riga, la stessa CWE e la stessa regola si uniscono, resta quello dello
strumento più preciso e la riga dice chi altro l'ha visto. Una vulnerabilità che due strumenti
chiamano in modo diverso (GHSA, CVE, PYSEC) è una voce sola, quando gli strumenti ne
pubblicano gli alias.
Le decisioni di triage non dipendono dal numero di riga. Falso positivo, rischio accettato,
corretto: la decisione si riconosce da percorso, regola, CWE e messaggio. Se il codice si sposta
di riga o si aggiunge un import in cima al file, la decisione resta. Se lo stesso problema
compare in un altro file, Cerbercode propone la decisione già presa e un revisore la conferma.
Ciò che la scansione decide da sola (codice di test, dipendenze di sviluppo) porta il motivo e
si revoca con un clic.

Le vulnerabilità che contano

Priorità: prima le vulnerabilità sfruttate attivamente (catalogo CISA KEV), poi quelle con
probabilità di sfruttamento alta (EPSS), poi le gravi per CVSS (NVD).
Raggiungibilità leggera: per ogni pacchetto vulnerabile Cerbercode dice se il codice lo
importa. Se nessun progetto lo importa, propone il «non colpito» per il VEX con la motivazione,
e il revisore decide. L'analisi guarda gli import, non le chiamate.
Pacchetti malevoli: gli avvisi del feed OpenSSF malicious-packages diventano critici, con
il consiglio di togliere la dipendenza e ruotare le credenziali; le versioni pubblicate da pochi
giorni sono segnalate.
Correzione come pull request in bozza per le dipendenze vulnerabili con una versione
corretta nota (npm, Python, Maven).

Segnalazioni CRA e DORA

Dall'11 settembre 2026 l'articolo 14 del CRA obbliga il fabbricante a segnalare le
vulnerabilità sfruttate attivamente e gli incidenti gravi: preallarme entro 24 ore,
notifica entro 72 ore, relazione finale entro 14 giorni dalla correzione (vulnerabilità)
o entro un mese dalla notifica (incidenti).

Quando una vulnerabilità del catalogo KEV compare nell'ultima scansione di un prodotto,
Cerbercode apre da solo la bozza della segnalazione.
Per ogni fase calcola la scadenza, mostra quanto manca e avvisa a 6 ore, a 1 ora e alla
scadenza (email e SIEM). Gli avvisi possono arrivare anche in Slack e Microsoft Teams.
Prepara il testo di ogni fase con i dati del fascicolo e del registro delle vulnerabilità.
L'invio resta vostro. La piattaforma unica di segnalazione dell'ENISA non offre un'API:
il testo si incolla lì, e in Cerbercode si registra il protocollo ricevuto. Una bozza che non
va notificata si archivia con la motivazione, che resta nel registro di audit.

Per DORA, la stessa logica per gli incidenti ICT gravi: notifica iniziale entro 4 ore, intermedia
entro 72 ore, finale entro un mese.

I documenti che produce

Fascicolo tecnico CRA: Allegato I, Parti I e II, Allegato VII. Si genera dai dati delle
scansioni, si sigilla (impronta crittografica, sola lettura) e si firma in PAdES. Nell'edizione Enterprise la firma porta anche la marca temporale RFC 3161 di una TSA,
anche qualificata eIDAS (PAdES B-T, oppure B-LT per la conservazione a lungo termine).
Dichiarazione UE di conformità (Allegato V) e politica di gestione delle vulnerabilità
in bozza, security.txt (RFC 9116) e pacchetto di consegna per l'Organismo Notificato.
SBOM in CycloneDX 1.5 e SPDX 2.3; VEX in OpenVEX e CSAF 2.0 (profilo
VEX), per dire a un cliente che una CVE nota non lo riguarda, e perché.
Fascicoli dei verticali, sigillati e firmati PAdES.
Report tecnici ed esecutivi, esportazioni CSV e XLSX, andamento storico; per chi eroga il
servizio, la scheda di ogni cliente e il report di servizio mensile.

Ancoraggio su catena e verifica indipendente

Nell'edizione Enterprise, a ogni scansione e a ogni fascicolo sigillato Cerbercode scrive un
manifesto: commit, strumenti con la versione, banche dati usate, impronte di SARIF, SBOM e
PDF, esito e lacune. Le impronte, raccolte in lotti, si ancorano su Bitcoin con
OpenTimestamps (oppure, a scelta, sulla Notary Platform di Objlab).

Chi verifica lo fa fuori dalla piattaforma: con il client ufficiale OpenTimestamps o con
lo script che accompagna la prova, senza fidarsi di Cerbercode.
«Ancorato» solo con la conferma della catena; senza Internet i manifesti restano in attesa, e
lo stato lo dice.
L'ancoraggio prova che il manifesto esisteva in quel momento e non è cambiato dopo; non prova
che la scansione fosse corretta. Affianca firma e marca temporale, non le sostituisce.

Anche senza Internet

Con il modulo Banca dati vulnerabilità offline le fonti stanno in copia locale: OSV, NVD,
CISA KEV, EPSS, EUVD, GitHub e gli avvisi CSAF dei fornitori OT (Siemens, Schneider Electric,
ABB, CISA ICS), insieme alle banche dati di Grype, osv-scanner e Trivy.

Si aggiorna con un pacchetto firmato da Objlab: il server verifica firma, impronta di ogni
file e versione, rifiuta un pacchetto più vecchio di quello installato e lo installa in modo
atomico.
Il fascicolo dice quale istantanea ha usato ogni strumento. Uno scanner senza banca dati è
dichiarato non eseguito, mai «nessuna vulnerabilità».

Codice di terze parti: sandbox in micro-VM

Per analizzare software che non avete scritto voi: l'applicazione si costruisce e si avvia in una
macchina virtuale isolata (KVM) che non raggiunge né l'host né la rete, e anche gli scanner
SAST, SCA e dei segreti possono girare in una VM a parte con il sorgente in sola lettura. Se la
VM non può partire, gli scanner non girano sul server e il report lo dichiara.

Utenti, ruoli e integrazioni

SSO con OpenID Connect; SAML 2.0 e provisioning SCIM 2.0 nell'edizione Enterprise.
Ruoli per progetto (edizione Enterprise): responsabile su un progetto, analista su un altro,
lettore su un terzo; progetti ad accesso riservato.
Repository GitHub, GitLab e Bitbucket: una scansione a ogni push e pull request, con l'esito
sulla PR; CLI, GitHub Action e GitLab CI per le pipeline; SARIF caricabile nella scheda Security
di GitHub.
Connettori: Jira, GitHub Issues, GitLab Issues, Azure DevOps Boards, ServiceNow, SIEM
(syslog/CEF) e Splunk.
Slack e Microsoft Teams: notifiche per cliente o per progetto (finding nuovi, vulnerabilità
sfruttate, allarmi della sorveglianza, scadenze delle segnalazioni CRA e DORA). In Slack si
prende in carico, si marca un falso positivo o si apre un ticket con un clic; in Teams,
tramite Workflows, il clic porta alla conferma in Cerbercode.

Norme coperte

Nel nucleo il Cyber Resilience Act. Come verticali: NIS2 e ISO/IEC 27001, DORA,
IEC 62443-4-1, 4-2 e 3-3, EN IEC 81001-5-1 (dispositivi medici), FprEN 50742 (macchine,
in voto finale), OWASP ASVS 5.0, IBM i / AS-400, e per i fornitori di siti americani
NIST SSDF (attestazione DOE) e NRC RG 5.71.

Installazione

In container: PostgreSQL, backend, interfaccia e proxy con TLS. Su un server Linux
(consigliato per l'esercizio) oppure su Windows con Docker Desktop o Podman, con gli stessi
strumenti di analisi; anche in Kubernetes con chart Helm. Nessuna dipendenza da servizi
esterni o da abbonamenti cloud.

Voce	Minimo	Consigliato
CPU	2 vCPU	4 vCPU
Memoria	4 GB	8 GB
Disco	20 GB	50 GB

Come si prova

Chiedete la prova a Objlab: per 30 giorni Cerbercode gira in un solo container, con i dati
di una demo (clienti di fantasia) e una licenza di prova firmata da Objlab. Alla scadenza resta
consultabile in sola lettura.

Limiti dichiarati

Nessuno strumento automatico rende conforme un prodotto. Cerbercode produce l'evidenza
tecnica e la organizza secondo la norma; la valutazione resta del fabbricante e, dove previsto,
dell'Organismo Notificato.
Le segnalazioni non partono da Cerbercode: le prepara, calcola le scadenze e avvisa; l'invio
alla piattaforma ENISA lo fa il fabbricante.
Raggiungibilità: guarda gli import, non le chiamate; per questo il «non colpito» è una
proposta che un revisore accetta.
IEC 62443 e ASVS: maturità, livelli SL e livello ASVS li dichiara il fabbricante, Cerbercode
non li attesta.
La sandbox in micro-VM richiede KVM sulla macchina o sul nodo Kubernetes.
L'ancoraggio su catena prova esistenza e integrità del manifesto, non la correttezza della
scansione.

Compliance & normative

CRA

Cyber Resilience Act (Reg. UE 2024/2847)

Nel nucleo. Requisiti dell'Allegato I, Parti I e II, collegati a CWE e strumenti; fascicolo tecnico dell'Allegato VII sigillato e firmato PAdES; dichiarazione UE di conformità (Allegato V) e politica di gestione delle vulnerabilità in bozza; segnalazioni dell'art. 14 con le scadenze di 24 ore, 72 ore e relazione finale.

NIS2

NIS2 (Dir. UE 2022/2555) e ISO/IEC 27001:2022

Le misure di gestione del rischio dell'art. 21 e i controlli tecnici dell'Annex A collegati agli strumenti, con ciò che resta da documentare a mano.

DORA

DORA (Reg. UE 2022/2554)

Verticale per i fornitori ICT di banche e intermediari: 20 requisiti (art. 5-30), fascicolo sui test di resilienza, pacchetto di evidenze per le banche clienti, notifiche degli incidenti ICT gravi, registro delle informazioni nel formato EBA, piano correttivo dei TLPT, analisi del codice z/OS.

IEC 62443

IEC 62443-4-1, 62443-4-2 e 62443-3-3

Verticale per fornitori e integratori industriali: 47 requisiti di processo della 4-1 con l'autovalutazione della maturità, requisiti di componente della 4-2 per livello SL-C, zone e conduit della 3-3 con SL-T. Fascicolo sigillato e firmato PAdES. Maturità e livelli SL li dichiara il fabbricante o l'integratore.

IEC 81001-5-1

EN IEC 81001-5-1, software di dispositivo medico

Verticale MedTech: 17 requisiti (12 verificati automaticamente), integrazione con IEC 62304 e MDR 2017/745, fascicolo Medical Device Cybersecurity, sonde DICOM e HL7-MLLP.

FprEN 50742

FprEN 50742:2026 e Regolamento Macchine (UE) 2023/1230

Verticale Industria/OT: fascicolo nella struttura della norma (percorsi A e B) firmato PAdES, analisi del codice PLC, metriche di qualità e di architettura. La norma è in voto finale e il fascicolo la cita come tale.

ASVS

OWASP ASVS 5.0.0

I 17 capitoli V1-V17 con l'evidenza tecnica e i limiti dichiarati. Non certifica un livello ASVS: nessuno strumento automatico può farlo.

SSDF / NRC

NIST SP 800-218 (SSDF), DOE e NRC RG 5.71

Per i fornitori di siti DOE e di centrali NRC: i 42 task SSDF richiamati dall'attestazione DOE/CISA e 31 controlli della RG 5.71, con SBOM anche in SPDX 2.3 e fascicoli firmati PAdES, anche in inglese. L'attestazione la firma il fabbricante.

IBM i

IBM i / AS-400 (NIS2 art. 21.2)

13 requisiti: analisi di RPG, CL e COBOL e postura del sistema in esercizio. Senza il collegamento al sistema i requisiti relativi si dichiarano non misurati, non conformi.

Report e dossier

Fascicolo tecnico CRAPDF sigillato, firma PAdES, marca temporale RFC 3161 (Enterprise)
Allegato VII, da conservare e consegnare all'Organismo Notificato o all'autorità
Dichiarazione UE di conformitàPDF (bozza)
Allegato V, da completare e firmare a cura del fabbricante
Politica di gestione delle vulnerabilità e security.txtPDF + RFC 9116
Il canale di segnalazione richiesto dall'Allegato I, Parte II
Bozze delle segnalazioni CRA e DORATesto per fase, con le scadenze
Da incollare nella piattaforma di segnalazione; il protocollo si registra in Cerbercode
SBOMCycloneDX 1.5 · SPDX 2.3
Inventario dei componenti per clienti, autorità e fornitori
VEXOpenVEX 0.2.0 · CSAF 2.0
Dire a un cliente che una CVE nota non lo riguarda, e perché
Fascicoli dei verticaliPDF sigillato, firma PAdES, marca temporale RFC 3161 (Enterprise)
DORA, IEC 62443, IEC 81001-5-1, FprEN 50742, SSDF/DOE, NRC RG 5.71
Pacchetto di consegnaZIP
Fascicolo, dichiarazione, politica, SBOM e riferimenti in un archivio solo
Report tecnico ed esecutivoHTML + PDF, CSV, XLSX
Per il team di sviluppo e sicurezza e per la direzione
Scheda cliente e report di servizioPDF, anche mensile
Per chi eroga il servizio a più clienti
Manifesto e prova di ancoraggioJSON + file .ots (Enterprise)
Verifica indipendente che scansione e fascicolo non siano cambiati dopo l'ancoraggio

Provalo

Cerbercode in quattro passaggi

Dalla scansione al fascicolo tecnico dell'Allegato VII, passando per la deduplica e il punteggio di conformità.

Domande frequenti

Dobbiamo sostituire gli analizzatori che già usiamo?

No. Cerbercode non reinventa gli analizzatori: ne orchestra 39 in 12 categorie, fra cui Bandit, Semgrep, SpotBugs con FindSecBugs, OWASP Dependency-Check, osv-scanner, Grype, Gitleaks e Checkov, e normalizza i loro risultati in SARIF 2.1.0. Importa anche rapporti SARIF di strumenti esterni. Quello che cambia è che i risultati arrivano in un posto solo, deduplicati fra strumenti diversi e collegati ai requisiti delle norme.

Che cosa produce di concreto per il Cyber Resilience Act?

Il fascicolo tecnico dell'Allegato VII, sigillato e firmato in PAdES; la dichiarazione UE di conformità (Allegato V) e la politica di gestione delle vulnerabilità in bozza; la SBOM in CycloneDX e SPDX; il VEX in OpenVEX e CSAF; il file security.txt e un pacchetto di consegna per l'Organismo Notificato. La conformità resta responsabilità del fabbricante: Cerbercode produce le evidenze e i documenti, la valutazione è del fabbricante e, dove previsto, dell'Organismo Notificato. Nell'edizione Enterprise i fascicoli firmati portano anche la marca temporale RFC 3161 e si possono ancorare su catena per una verifica indipendente.

Cerbercode invia le segnalazioni CRA all'ENISA?

No. Dall'11 settembre 2026 le vulnerabilità sfruttate e gli incidenti gravi si segnalano con un preallarme entro 24 ore, una notifica entro 72 ore e una relazione finale entro 14 giorni dalla correzione o un mese dalla notifica. Cerbercode apre la bozza quando una vulnerabilità sfruttata compare nella scansione, calcola le scadenze, avvisa prima che scadano e prepara il testo di ogni fase. L'invio lo fa il fabbricante sulla piattaforma unica dell'ENISA, che non offre un'API, e in Cerbercode si registra il protocollo ricevuto.

Se marchiamo un problema come falso positivo, lo ritroviamo alla scansione dopo?

No. In Cerbercode la decisione di triage si riconosce da percorso, regola, CWE e messaggio, non dal numero di riga: se il codice si sposta di riga o si aggiunge un import in cima al file, la decisione resta. Se lo stesso problema compare in un altro file, Cerbercode propone la decisione già presa e un revisore la conferma, perché un falso positivo in un file di test non lo è per forza nel codice di produzione.

Lo stesso problema trovato da due strumenti compare due volte?

No. Due risultati con lo stesso file, la stessa riga, la stessa CWE e la stessa regola diventano una riga sola, che tiene il risultato dello strumento più preciso e dice chi altro l'ha visto. Una vulnerabilità che due strumenti chiamano in modo diverso, per esempio GHSA e CVE, è una voce sola del registro quando gli strumenti ne pubblicano gli alias.

Funziona in una rete senza accesso a Internet?

Sì. Con il modulo Banca dati vulnerabilità offline OSV, NVD, CISA KEV, EPSS, EUVD, GitHub, gli avvisi CSAF dei fornitori OT e le banche dati degli scanner stanno in copia locale, e si aggiornano con un pacchetto firmato da Objlab che il server verifica prima di installarlo. Il fascicolo dice quale istantanea è stata usata.

Il nostro codice esce dalla nostra rete?

No. Cerbercode si installa presso di voi, in container su un server Linux o Windows, oppure in Kubernetes. Gli analizzatori girano sulle vostre macchine e il codice sorgente non lascia la vostra infrastruttura. Il triage assistito da un modello linguistico è opzionale e può girare interamente in locale.

Si integra con GitHub, GitLab o Azure DevOps?

Sì. I repository GitHub, GitLab e Bitbucket si collegano per una scansione a ogni push e pull request, con l'esito sulla PR; ci sono la CLI, una GitHub Action e il modello per GitLab CI. Il SARIF si carica nella scheda Security di GitHub, e i finding diventano ticket in Jira, GitHub, GitLab, Azure DevOps Boards o ServiceNow. Le notifiche arrivano anche in Slack e Microsoft Teams.

Quali linguaggi copre?

Python, JavaScript e TypeScript, Java, C# e .NET, C e C++, l'infrastruttura come codice, le immagini container e i PLC (IEC 61131-3). Con i verticali anche RPG, CL e COBOL su IBM i e COBOL, PL/I, JCL e CICS su z/OS.

Si può provare prima di acquistare?

Sì: chiedete la prova a Objlab. Per 30 giorni Cerbercode gira in un solo container, con i dati di una demo e una licenza di prova firmata da Objlab; alla scadenza resta consultabile in sola lettura.

Provala Area clienti — scarica Parla con un esperto

Casi d'uso

Fascicolo, dichiarazione e SBOM

Produttore di software: il fascicolo CRA a ogni rilascio

Le scansioni della release alimentano il fascicolo dell'Allegato VII, che si sigilla, si firma e va nel pacchetto di consegna con la SBOM e la dichiarazione in bozza.

Rete isolata, banca dati locale

Costruttore di macchine: evidenze OT senza Internet

Analisi del codice PLC e delle dipendenze con la banca dati in copia locale, avvisi CSAF dei fornitori OT e fascicoli FprEN 50742 e IEC 62443 firmati PAdES.

Clienti isolati, pannello unico

Fornitore di servizi gestiti: più clienti da un'istanza

Ogni cliente isolato, punteggio CRA e andamento di ciascuno, report di servizio mensile, e in un colpo d'occhio quali clienti sono esposti a una nuova vulnerabilità.