Cybersecurity software ed embedded: l’approccio Develer

Intervista a Marco Giusti, cybersecurity director in Develer.

Develer è nota per la qualità tecnica nei progetti software e embedded. Quando e perché la sicurezza è diventata parte esplicita di questo modo di lavorare?

La sicurezza in Develer non nasce oggi. È sempre stata parte del modo in cui affrontiamo un progetto, perché i nostri clienti lavorano spesso in ambiti industriali o enterprise dove l’affidabilità non è negoziabile: un bug che passa inosservato su un dispositivo installato sul campo, o una falla che espone dati sensibili, non è solo un problema tecnico, è un problema che si ripercuote sul business del cliente.

Quello che è cambiato nell’ultimo anno è che abbiamo iniziato a formalizzare e rendere visibile questo approccio come standard riconosciuto internazionalmente, con un ruolo dedicato che coordina le pratiche di sicurezza e compliance lungo tutto il ciclo di sviluppo, dal firmware al software applicativo. Non è stata una scelta improvvisa: è la naturale evoluzione di un modo di lavorare che c’era già, ma che fino a poco tempo fa restava implicito, dentro le teste delle persone più che nei processi scritti. 

C’è anche un fattore esterno che ha accelerato questo percorso: il mercato è cambiato, il trend degli attacchi e delle compromissioni è in aumento costante, e i clienti ne sono consapevoli. Per questo la sicurezza per noi non riguarda solo il prodotto che consegniamo, ma l’organizzazione Develer nel suo insieme, intesa anche come continuità del business: sia il nostro sia quello dei clienti che dipendono da noi. Oggi vogliamo che tutto questo sia strutturato, misurabile e, soprattutto, visibile a chi lavora con noi.

Quando Develer inizia un nuovo progetto, quali sono le prime cose che vengono valutate dal punto di vista della sicurezza? Il cliente tipicamente se lo aspetta o lo sorprendete?

Nella maggior parte dei casi il cliente non si aspetta domande sulla sicurezza così presto. Arriva con un’idea di prodotto o una richiesta tecnica ben precisa, magari con un deadline già in testa, e si aspetta che si parli di funzionalità, di tecnologie, di tempi. Invece siamo noi a fermarci un momento prima e a chiedere dove verrà installato questo dispositivo, chi ci accede, che tipo di dati tratta, quali sono i vincoli normativi del settore in cui opera. 

Sono domande che il cliente spesso non sa nemmeno di doversi porre, perché il suo mestiere è il prodotto, non la sicurezza.

Per noi questo momento iniziale è già una forma di tutela per il cliente stesso: un rischio identificato in fase di analisi costa una conversazione, lo stesso rischio scoperto a progetto avviato o, peggio, dopo il rilascio, costa tempo, budget e a volte anche la fiducia dell’utente finale.

Per questo il nostro ruolo in questa fase diventa anche di guida, non solo di esecuzione: aiutiamo il cliente a farsi le domande giuste, prima ancora di scrivere una riga di codice.

Come si traduce concretamente l’attenzione alla sicurezza nel modo in cui si sviluppa il codice? Cosa fa la differenza rispetto ad una software house che non presta attenzione a questi temi?

La differenza si vede nei dettagli del processo, più che in un annuncio o in una certificazione appesa al muro. La revisione del codice, per esempio, non è solo un controllo di qualità funzionale: chi rilegge il lavoro di un collega si chiede anche se quella parte di codice potrebbe essere sfruttata in modo improprio, se gestisce correttamente gli errori, se espone qualcosa che non dovrebbe. Sono domande che diventano automatiche quando la sicurezza fa parte della cultura tecnica, e non un controllo imposto dall’alto.

Non crediamo in un traguardo finale in cui la sicurezza è “raggiunta” una volta per tutte. Lavoriamo secondo una logica di miglioramento continuo: pratiche, tecnologie, formazione delle persone e processi vengono rivisti e affinati costantemente, ciclo dopo ciclo. Questo significa anche investire nel far crescere le competenze di chi progetta o scrive codice ogni giorno, non solo aggiungere controlli automatici, perché uno strumento è efficace solo quanto la persona che lo usa e lo interpreta correttamente. 

L’eccellenza nel processo si può raggiungere, ed è quello a cui puntiamo ogni giorno. La sicurezza assoluta invece resta per definizione un traguardo irraggiungibile, non per un nostro limite, ma perché le minacce evolvono, le normative cambiano, gli strumenti che usiamo oggi saranno superati domani. Lo dimostrano anche le organizzazioni più grandi e strutturate al mondo, che investono risorse enormi e restano comunque esposte. Per questo la vera misura di maturità non è “essere sicuri”, ma essere costantemente in grado di adattarsi. Ed è proprio questa onestà a rendere credibile il nostro approccio agli occhi di un cliente che di sicurezza capisce.

Uno dei rischi meno visibili per chi commissiona software è la supply chain delle dipendenze. Come lo gestite su una scala come quella di Develer?

Sì, uno dei rischi meno visibili riguarda le dipendenze esterne: librerie, framework, componenti di terze parti che nessuno oggi riscrive da zero. È un rischio che pochi clienti considerano quando pensano alla sicurezza del proprio prodotto, perché tendono a immaginarla come qualcosa che riguarda solo il codice scritto specificamente per loro. In realtà, buona parte della superficie di rischio arriva da fuori, da componenti che nessuno ha scritto internamente ma che finiscono comunque dentro il prodotto finale. E non è solo un tema di vulnerabilità tecniche: anche la licenza con cui una dipendenza viene distribuita è un rischio, spesso ignorato, che può avere conseguenze legali concrete se non viene verificata con attenzione.

Qui va fatta una distinzione che consideriamo fondamentale, e che spesso il cliente non si aspetta di sentire. Quando un progetto viene consegnato e il rapporto si conclude lì, quello che offriamo è una fotografia della sicurezza al momento della consegna: un controllo puntuale, fatto bene, che include anche la verifica delle licenze delle dipendenze utilizzate, ma legato a quel preciso istante nel tempo.
Le vulnerabilità nelle dipendenze, però, non rispettano quella fotografia: vengono scoperte anche mesi o anni dopo, su componenti che erano considerati sicuri al momento del rilascio. 

Per questo, sui progetti in cui siamo coinvolti anche nel mantenimento nel tempo, il discorso cambia radicalmente: in questo scenario possiamo attivare un monitoraggio continuo, che segue le dipendenze ben oltre la consegna, dal punto di vista sia della sicurezza sia della conformità delle licenze, e reagisce quando emerge un nuovo rischio, anche su codice scritto tempo prima. 

È la differenza tra uno stato di sicurezza e conformità fotografata in un istante e una postura invece che continua ad operare nel tempo, ed è un punto che ogni cliente dovrebbe chiarire fin dall’inizio con il proprio fornitore: cosa succede alla sicurezza del prodotto il giorno dopo la consegna?

Tra l’imminente entrata in vigore del Cyber Resilience Act e il raggiungimento dello standard ISO 27001, in che modo Develer integra l’adempimento normativo con il proprio percorso di maturità interna?

Sono due cose diverse che vanno nella stessa direzione, e credo sia importante non confonderle, perché rispondono a logiche opposte.

Il Cyber Resilience Act (CRA) è un regolamento europeo: chi produce prodotti con elementi digitali, quindi non solo hardware connesso ma anche software standalone e firmware, dovrà rispettarlo per legge. Non è una scelta commerciale né un valore aggiunto da comunicare, è un obbligo con scadenze precise.

Alcuni dei nostri clienti, soprattutto quelli più piccoli o meno strutturati, non ne hanno ancora sentito parlare, e rischiano di trovarsi impreparati quando le scadenze si avvicineranno.

La ISO 27001 invece è uno standard di certificazione volontaria. Nessuno ci obbliga a perseguirla, ma abbiamo scelto di farlo come parte del nostro percorso di maturità, perché ci dà un framework riconosciuto internazionalmente per strutturare tutto quello di cui abbiamo parlato finora: i processi, il miglioramento continuo, la formazione delle persone. 

Nella pratica, un’organizzazione che lavora bene su uno standard come la ISO 27001 parte avvantaggiata nel rispondere a un obbligo normativo come il CRA: i fondamentali di gestione del rischio, risposta agli incidenti e controllo dei processi si sovrappongono in buona parte, anche se il CRA aggiunge requisiti specifici sul prodotto che la ISO 27001, per sua natura più organizzativa, non copre da sola.

Per noi il messaggio è semplice: rispondiamo a quello che la legge impone, e investiamo in quello che scegliamo di fare in più.

Molti sviluppatori usano strumenti AI per lo sviluppo. Come decidete quali usare, e come garantite che il codice del cliente rimanga protetto?

Usiamo strumenti AI nello sviluppo quotidiano, come ormai fanno quasi tutti. La differenza, credo, è che da noi non è una scelta lasciata al singolo sviluppatore che adotta quello che preferisce: c’è un’attenta valutazione a monte su quali strumenti adottare, e una policy interna che definisce come vanno usati, in particolare su cosa non deve mai finire in un sistema esterno o in un modello di terze parti.

Il punto più delicato riguarda proprio il codice del cliente. Quando lavoriamo su un progetto, quel codice è spesso proprietà intellettuale del cliente, a volte anche particolarmente sensibile, ed è nostro compito garantire che non venga usato per addestrare modelli esterni né reso accessibile a chi non dovrebbe vederlo. È un tema su cui pochi fornitori sono davvero trasparenti, perché richiede di ammettere apertamente quali strumenti si usano e con quali limiti, invece di lasciare la questione nel vago. Per noi è diventato un criterio di fiducia in più da offrire al cliente: non solo diciamo che usiamo l’AI, ma spieghiamo come la governiamo.

A un CTO o responsabile prodotto che sta valutando Develer per un progetto, cosa vorresti che portasse via da questa conversazione riguardo alla sicurezza?

Avrei piacere fosse ben comprensibile che la sicurezza in Develer non è uno strato aggiunto sopra il lavoro tecnico, qualcosa che si attiva su richiesta o si fattura a parte. Fa parte di come lavoriamo da sempre, e quello che stiamo facendo ora è solo renderla più visibile e più strutturata, perché crediamo che un cliente debba poterla vedere, non solo darla per scontata.

La sicurezza assoluta è un’utopia, lo abbiamo già detto: quello che offriamo non è una promessa impossibile da mantenere, ma una gestione strutturata del rischio residuo, misurabile e in costante affinamento. Chi vende sicurezza come uno stato definitivo da raggiungere, di solito, non conosce bene il proprio dominio.
Quello che posso garantire è un percorso di miglioramento continuo, un processo che si mette in discussione e adatta la propria postura di sicurezza man mano che il contesto, le minacce e le normative cambiano.

Scegliere un fornitore di sviluppo, in fondo, significa scegliere a chi affidare qualcosa che poi porterà il proprio nome sul mercato, davanti ai propri clienti. La responsabilità finale del prodotto resta in capo al committente. Proprio per questo non consideriamo la sicurezza un servizio accessorio, ma un impegno che ci prendiamo insieme al cliente fin dal primo giorno. 

Se c’è una cosa sola che vorrei restasse di questa conversazione, è che con noi la sicurezza non è una domanda a cui si risponde solo quando qualcosa è già andato storto: è una domanda a cui rispondiamo insieme, da subito.