Raisetalk è sicuro? Cosa misuriamo, correggiamo e pubblichiamo

Una base sana ieri non lo è più oggi

Un software non si degrada perché lo si tocca. Si degrada perché il mondo intorno a lui si muove. Non avete modificato una riga di codice da tre settimane, eppure stamattina il vostro prodotto potrebbe essere vulnerabile: è appena stata pubblicata una CVE su una dipendenza transitiva che non avete mai scelto esplicitamente, l'immagine di base del vostro container include una libreria di sistema appena arrivata a fine supporto, un binario consegnato da un fornitore integra una versione bloccata di una libreria di terze parti, un'impostazione cloud considerata accettabile un anno fa è diventata una cattiva pratica documentata.

Il ritmo di pubblicazione delle vulnerabilità supera oggi il centinaio al giorno, considerando tutti i produttori di software. A questa cadenza, la domanda pertinente per valutare un fornitore non è «siete certificati?». È: che cosa succede da voi tra il momento in cui una vulnerabilità viene pubblicata e il momento in cui viene corretta? Quanto tempo, con quale meccanismo, con quale prova, e chi decide che è corretta.

Questa domanda ci riguarda in modo particolare. Raisetalk tratta registrazioni di chiamate, trascrizioni, dati personali di clienti finali che non hanno mai sentito parlare di noi: hanno semplicemente chiamato la loro banca, la loro compagnia assicurativa o il loro fornitore di energia. La fiducia che ci viene accordata è una fiducia delegata, e questo tipo di fiducia si dimostra, più che dichiararsi.

Questo articolo descrive quindi il meccanismo, non l'intenzione. Che cosa misuriamo, con quale frequenza, che cosa succede quando arriva una segnalazione, che cosa pubblichiamo e, infine, come questo approccio si confronta con le altre due risposte classiche del mercato: la certificazione e il penetration test.

Che cosa analizziamo, senza interruzione

Ci affidiamo ad Aikido Security come piattaforma di analisi e protezione. La scelta si deve a un motivo semplice: la copertura. Molti strumenti fanno benissimo una sola cosa, l'analisi statica del codice o il controllo della postura cloud. Il problema è che un attaccante non sceglie la sua porta d'ingresso in base alla suddivisione dei vostri strumenti. Una chiave API lasciata in un file di configurazione, una CVE in un pacchetto di sistema di un'immagine container e un ruolo IAM troppo ampio su un account di servizio si equivalgono perfettamente dal suo punto di vista.

Sei superfici sono quindi monitorate, in continuo.

Quest'ultimo punto merita una precisazione, perché lo si fa raramente. Uno scanner che si ferma alla pagina di login analizza solo la vetrina. Abbiamo quindi aperto allo scanner un accesso autenticato all'API, perché esplori anche ciò che si trova dietro l'autenticazione, dove si trovano le route che manipolano davvero i dati. È più scomodo, perché produce meccanicamente più finding. È proprio per questo che è utile.

Che cosa protegge mentre il codice gira

Analizzare significa trovare ciò che potrebbe essere sfruttato. Proteggere significa fermare ciò che viene sfruttato in quel preciso momento. Le due cose non si sostituiscono a vicenda, e utilizziamo due componenti distinti per la seconda metà del lavoro.

Un firewall applicativo integrato nell'API. Zen non viene eseguito davanti all'applicazione come un WAF classico posto in front-end: viene eseguito all'interno del processo applicativo, il che gli dà accesso al contesto di cui il front-end non dispone. Non vede soltanto una stringa sospetta in una richiesta HTTP, vede la query SQL realmente costruita, il comando realmente eseguito, il percorso di file realmente aperto. Può quindi distinguere una stringa che somiglia a un'iniezione da una stringa che ne produce effettivamente una. Da noi è attivo in modalità di blocco dall'autunno 2025, e non in semplice osservazione: un tentativo rilevato viene interrotto, non solo registrato nei log.

È una decisione che ha un costo, e bisogna dirlo: un firewall in modalità di blocco può, in teoria, interrompere una richiesta legittima. Ce ne assumiamo la responsabilità, ed è anche per questo che gli aggiornamenti di versione di questo componente vengono trattati con la stessa prudenza di una modifica funzionale, verificando che cosa cambiano nelle decisioni di blocco prima di rilasciarli.

Il controllo della postura delle postazioni di lavoro. Il secondo componente riguarda le nostre macchine, quelle da cui sviluppiamo e amministriamo la produzione. Cifratura del disco, blocco della sessione, aggiornamenti di sistema, antivirus attivo: questi controlli vengono verificati in continuo su ogni postazione. Non è conformità di facciata. Una piattaforma irreprensibile amministrata da un portatile non cifrato e lasciato aperto su un treno resta una piattaforma vulnerabile, e l'attaccante che prende di mira un produttore di software raramente ha il prodotto come primo bersaglio.

Che cosa succede quando arriva una segnalazione

È qui che si gioca la differenza tra una piattaforma di analisi acquistata e una pratica di sicurezza reale. Uno strumento che fa emergere duecento segnalazioni produce duecento segnalazioni. Non produce sicurezza. La sicurezza comincia al passo successivo, quello che nessuno mostra durante una demo.

Il nostro processo è scritto e seguito ogni volta, nello stesso ordine.

1. Il raggruppamento per causa radice. Un gruppo di trentasei finding non corrisponde quasi mai a trentasei problemi. Spesso è una sola riga in un file di lock delle dipendenze, riflessa su tre immagini container e due repository. Il primo passo consiste quindi nel separare la causa radice unica dalle superfici coinvolte, e nel dire quante correzioni distinte sono realmente necessarie. È ciò che evita di confondere il volume delle segnalazioni con il carico di lavoro, e di trattare d'urgenza trentasei sintomi invece di un problema.

2. L'apertura di un ticket, con la sua scadenza. Ogni gruppo trattato dà luogo a un ticket nel repository interessato, con la sua gravità e la sua scadenza di trattamento. Nulla vive soltanto in una dashboard: ciò che non ha un ticket non ha un responsabile, e ciò che non ha una scadenza non ha una priorità.

3. La verifica nel nostro codice. È il passo che lo scanner non può fare al posto nostro. Una CVE annunciata su una libreria non dice se il codice vulnerabile è raggiungibile dal nostro. Andiamo a leggere i file interessati, a confermare la versione realmente installata, il vincolo realmente dichiarato e i chiamanti reali. Una vulnerabilità di tipo SSRF in una funzione che non chiamiamo mai non ha la stessa urgenza di una deserializzazione raggiungibile da una route pubblica. Questa verifica produce a volte la conclusione opposta a quella della segnalazione: falso positivo, codice morto o correzione già in atto. In quel caso la decisione viene tracciata con la sua motivazione, mai con una semplice archiviazione senza seguito.

4. La correzione, e tutto ciò che comporta. Un piano di remediation non si ferma al cambio di versione. Include esplicitamente i passi fuori dal codice: ricostruzione dell'immagine, rotazione di un segreto, riscrittura della cronologia se è stata esposta una credenziale, riavvio del servizio interessato. Un segreto tolto dal codice sorgente ma ancora valido presso il fornitore non è un segreto corretto.

5. La verifica dopo il rilascio, poi la chiusura da parte di un essere umano. Verifichiamo che la correzione sia effettivamente presente in ciò che gira, e non solo in ciò che è stato committato. Un'immagine ricostruita ma non rilasciata, un traffico rimasto vincolato alla vecchia revisione dopo un rollback: questi scarti sono classici, e trasformano una correzione in un'illusione di correzione. Solo a quel punto un essere umano chiude il ticket.

La base di hardening, nel dettaglio

Un meccanismo di rilevamento vale solo quanto la base su cui si applica. Ecco, senza pretesa di esaustività, le scelte che regolano oggi l'infrastruttura di Raisetalk. Non sono dichiarative: ognuna viene verificata in continuo dalle analisi descritte sopra, e uno scostamento diventa una segnalazione.

• Nessun container viene eseguito con i privilegi di amministratore. Sia i processi master sia i processi worker girano con un account non privilegiato, e i servizi sono in ascolto su porte non privilegiate.
• Le immagini non contengono alcun binario con bit SUID, e un controllo fa fallire la build dell'immagine se ne compare uno. Un passo di installazione aggiunto in seguito potrebbe reintrodurne uno senza che nulla lo segnali: un hardening che non si sorveglia da solo si perde sempre all'aggiornamento successivo.
• L'avvio sicuro è attivo sulle macchine virtuali, in modo che la catena di avvio venga verificata prima che il sistema si carichi.
• L'accesso amministrativo passa dall'identità, mai da una chiave condivisa. Autenticazione tramite l'identità cloud, chiavi SSH di progetto bloccate, accesso alle macchine tramite tunnel autenticato anziché tramite l'esposizione di una porta di amministrazione.
• Ogni servizio viene eseguito con un account dedicato, limitato ai permessi di cui ha realmente bisogno, e mai con un account predefinito: questi ultimi hanno, per costruzione, ruoli decisamente troppo ampi.
• È il database stesso a imporre la cifratura delle connessioni, invece di lasciarla alla discrezione del client che vi si connette.
• Il sito pubblico applica una Content Security Policy rigorosa, fino a vietare gli stili inline: un vincolo reale per chi scrive i componenti, e una superficie di iniezione in meno.

Nessuno di questi punti è spettacolare preso singolarmente. È la loro combinazione, e soprattutto il fatto che vengano verificati in permanenza anziché una sola volta all'installazione, a costituire il lavoro reale.

A che punto siamo, al 19 agosto 2026

Alla data di pubblicazione di questo articolo, la dashboard non presenta alcuna segnalazione aperta sull'intero perimetro. I report di conformità generati dalla piattaforma danno i seguenti risultati.

La piattaforma colloca inoltre Raisetalk nel 5% delle applicazioni più sicure del suo parco. È un confronto relativo fornito da terzi, e lo citiamo come tale.

La trasparenza: la pagina pubblica, poi il report su richiesta

Un fornitore che afferma che va tutto bene vi chiede di credergli. Noi preferiamo lasciarvi guardare. Questo avviene su due livelli.

Il primo è pubblico, e datato. La pagina Sicurezza e conformità mostra il dettaglio dei controlli tecnici soddisfatti, criterio per criterio, per sette framework: SOC 2, ISO 27001:2022, NIS2, DORA, GDPR, PCI DSS e CIS Controls v8 (cinque alla pubblicazione di questo articolo: DORA e PCI DSS si sono aggiunti il 26 agosto 2026, quando i loro dati sono diventati accessibili tramite API). Non è scritta a mano. Viene rigenerata ogni giorno a partire dalla stessa fonte che produce i numeri di questo articolo, e mostra in evidenza la data dell'ultima sincronizzazione. Una pagina di conformità che non si è mossa da sei mesi non è una pagina di conformità, è uno screenshot.

Il secondo resta su richiesta. Il badge presente nel piè di pagina di tutte le pagine di questo sito apre un modulo di richiesta di accesso al report di audit di sicurezza. Il report viene generato a partire dallo stato reale della piattaforma al momento della richiesta, e non da un documento statico scritto una volta per tutte: è la stessa fonte che produce i numeri qui sopra.

Perché il report completo resta su richiesta, mentre il dettaglio dei controlli è pubblico? Perché va oltre la pagina: cronologia delle analisi, istantanea dei temi aperti, copertura dei sei framework che non dispongono di un'API. Un report di sicurezza descrive un perimetro tecnico, e sapere a chi lo si comunica fa parte dell'igiene elementare. Il modulo è breve e la richiesta viene trattata rapidamente.

È anche, per noi, un impegno a senso unico. Pubblicare un badge che dà accesso a una misura indipendente del nostro stato di sicurezza significa accettare in anticipo che un mese negativo sia visibile. È proprio ciò che rende l'informazione utile per il resto del tempo.

Gli altri approcci, e perché arrivano dopo

Due risposte dominano il mercato quando un acquirente pone la questione della sicurezza. Sono entrambe legittime, ed entrambe insufficienti da sole. La nostra posizione si riassume in una parola: l'ordine.

La certificazione ISO 27001

La ISO/IEC 27001 certifica un sistema di gestione della sicurezza delle informazioni. Un organismo accreditato verifica che abbiate identificato i vostri rischi, definito delle misure, documentato le vostre procedure, e che manteniate vivo il tutto. Il certificato è valido tre anni, con audit di sorveglianza annuali. È un lavoro serio, che struttura un'organizzazione in modo duraturo, ed è un segnale forte per un acquirente.

I suoi limiti dipendono dalla sua stessa natura, e non hanno nulla di polemico. L'audit procede per campionamento, a una data precisa. Convalida un sistema di gestione, non lo stato tecnico del vostro prodotto nel momento in cui il vostro potenziale cliente legge il certificato. Nulla in un certificato ottenuto a marzo vi informa sulla vulnerabilità critica pubblicata a ottobre su una dipendenza dell'applicazione. Il certificato attesta che l'organizzazione dispone di un processo per trattarla, il che è molto diverso dall'attestare che l'abbia trattata.

È una fotografia, scattata da un professionista, con un'ottima macchina. Resta una fotografia.

Il penetration test (pentest)

Il penetration test apporta ciò che nessuno scanner sa produrre: l'intelligenza di un attaccante umano. Concatenare tre debolezze singolarmente minori per ottenere un accesso che non dovrebbe esistere, sfruttare in modo improprio una logica di business perfettamente conforme al codice, accedere all'oggetto di un altro cliente manipolando un identificativo: tutto questo non si rileva con un'analisi per pattern.

Tuttavia il suo limite è di budget, ed è strutturale. Si acquista un numero di giornate, quindi si definisce un perimetro. Tutto ciò che è fuori perimetro non viene testato, e spesso il report non ne farà menzione, o lo farà in caratteri minuscoli... Descriverà ciò che è stato trovato là dove si è cercato. Come la certificazione, il test vale per una data, una versione e soprattutto un perimetro limitato. Il rilascio del mese successivo ne rende obsoleta una parte.

I tre approcci, fianco a fianco

Queste tre colonne non si sostituiscono. Si completano, in quest'ordine. Farsi certificare senza avere un controllo continuo significa documentare con cura un processo che non si sa eseguire. Commissionare un penetration test su un perimetro in cui restano dipendenze vulnerabili note significa pagare al prezzo di un esperto la scoperta di ciò che uno scanner trova gratuitamente in una notte. E commissionarlo su un perimetro ristretto, scelto proprio perché lo si padroneggia già, significa comprare una buona notizia anziché un'informazione: è decisa nel momento in cui si redige il perimetro, non nel momento del test. Un penetration test utile è quello il cui perimetro è stato scelto per la sua difficoltà, e la cui estensione viene comunicata insieme alla conclusione.

La nostra sequenza è quindi questa: prima la misura permanente e la correzione sistematica, perché è ciò che protegge realmente i dati dei nostri clienti oggi. Una certificazione ISO 27001 è prevista in seguito, e un penetration test esterno è nella nostra roadmap: verranno a convalidare e completare fondamenta esistenti, non a sostituirle né a farne le veci.

Che cosa il controllo continuo non sostituisce

Sarebbe disonesto concludere senza dire dove si ferma ciò che descriviamo qui.

Una piattaforma di analisi non conosce il vostro business. Sa che una query SQL è costruita per concatenazione. Non sa che un utente di un team non deve mai vedere le valutazioni di un altro team. Queste regole sono specifiche del nostro prodotto, e nessun database di vulnerabilità le contiene. Per questo manteniamo internamente il nostro modello delle minacce: le unità di deployment, le superfici di ingresso, i confini di fiducia e le regole di business che non devono mai cedere. Viene riletto e aggiornato come il codice, e serve da mappa quando cerchiamo ciò che nessuno strumento cercherà al posto nostro.

Un punteggio di conformità non è una garanzia. Indica che non sussiste alcun problema noto sul perimetro osservato. È apprezzabile, e non dice nulla delle vulnerabilità che non sono ancora pubbliche. Nessuno può promettere il contrario, e bisogna diffidare di chi lo fa.

La sicurezza resta una catena. Include i nostri subfornitori, i nostri fornitori di modelli di IA, il provider di hosting e l'uso che i vostri team fanno della piattaforma. È proprio per questo che il controllo degli accessi per ruoli e perimetri e la pseudonimizzazione dei dati personali fanno parte dello stesso tema delle vulnerabilità: determinano ciò che resta protetto il giorno in cui qualcosa cede altrove.

L'ultima parola

Avremmo potuto scrivere un articolo breve: «zero vulnerabilità, tredici framework, top 5%». Sarebbe stato esatto, e non avrebbe dimostrato nulla. I numeri che contano in sicurezza non sono quelli che si mostrano, sono quelli che si possono spiegare: da dove vengono, che cosa coprono, che cosa lasciano fuori, e che cosa succede il giorno in cui peggiorano.

La sicurezza di un software non è uno stato, è un ritmo. Non si dimostra con un documento annuale, ma con la capacità di trattare, settimana dopo settimana, ciò che la misura fa emergere, anche quando è scomodo, anche quando obbliga a ricostruire una macchina o a ritoccare un componente che funzionava benissimo.

E poiché l'affermazione di un fornitore non vale mai quanto la verifica di un acquirente: il dettaglio dei controlli è sulla pagina Sicurezza e conformità, e il report completo in fondo a questa pagina.

Verificate voi stessi

• Consultare il dettaglio dei controlli, framework per framework: la pagina Sicurezza e conformità, rigenerata ogni giorno
• Richiedere il report di audit di sicurezza: accedere al modulo, oppure cliccare sul badge nel piè di pagina.
• Le nostre risposte sui dati e sul GDPR: le domande frequenti
• Porci una domanda precisa: www.raisetalk.com/it/contact

I numeri citati in questo articolo corrispondono allo stato rilevato il 19 agosto 2026. Evolvono: è proprio questo il loro interesse. Una dashboard di sicurezza che non si è mossa da sei mesi non è il segno di un prodotto stabile, è il segno di una misura ferma. La domanda giusta da porre a un fornitore, noi compresi, non è quindi «il vostro punteggio è buono oggi?». È «che cosa succede da voi il giorno in cui non lo è più?».