Pochi ingegneri di sicurezza: automazione, AI e SOP pulito

Non ci sono abbastanza persone per fare questo lavoro. È il fatto scomodo dietro la cybersecurity automotive, e sta peggiorando, non migliorando.

I conti non tornano

Gli studi sulla forza lavoro di ISC2 hanno stimato la carenza globale di cybersecurity nell’ordine dei milioni, circa 4.8 million secondo la loro stima del 2026, con il settore che dovrebbe crescere di circa l’87% per soddisfare la domanda. Circa il 90% dei team di sicurezza segnala un divario di competenze.

Ora restringi il campo all’automotive. Testare una ECU non è sicurezza IT generica. Servono persone che conoscano CAN e CAN FD, UDS e DoIP, SecurityAccess, le sessioni diagnostiche e i vincoli in tempo reale di un target embedded, e che sappiano mappare il tutto su ISO/SAE 21434. È un sottoinsieme minuscolo e sovraccarico di un campo già in carenza. Nel frattempo il mercato della cybersecurity automotive cresce in fretta, da circa quattro miliardi di dollari nel 2026 verso dodici miliardi e oltre entro i primi anni 2030. La domanda sta scalando un dirupo mentre il bacino di persone in grado di testare davvero una centralina si muove appena.

Poi conta il lavoro. Un programma veicolo moderno ha decine di ECU. Ognuna ha molte release lungo il percorso verso la produzione, e altre dopo. Se il testing di sicurezza approfondito dipende dal prenotare uno di una manciata di specialisti per ogni release di ogni ECU, la coda è più lunga del programma stesso. Qualcosa salta, e di solito è il testing.

La SOP è un muro che colpisci una volta sola

L’inizio della produzione non si sposta. Quando un veicolo raggiunge la SOP, il costo di un difetto di sicurezza cambia completamente: quello che prima dell’avvio della linea era un commento in una code review diventa, dopo, una campagna sul campo o un richiamo. E sotto UN R155 e ISO/SAE 21434 non puoi semplicemente spedire e sperare. Devi dimostrare che le mitigazioni sono state testate e che i problemi noti sono stati gestiti.

Quindi l’obiettivo reale è specifico: arrivare alla SOP senza risultati facili da trovare noti. Non una ECU perfetta, che nessuno può promettere, ma una in cui i risultati ovvi, ad alto impatto, della prima ora sono spariti e documentati. Servizi diagnostici raggiungibili senza autenticazione. SecurityAccess debole o di default. XCP o CCP esposti. Identificatori scrivibili che dovrebbero essere bloccati. Sono comuni, sono devastanti, e sono del tutto evitabili, se qualcuno li testa a ogni release.

È quest’ultima clausola il nocciolo del problema. Un singolo pentest pre-SOP è un’istantanea del software che avevi quella settimana. La ECU continua a cambiare. Una funzione aggiunta due sprint dopo riapre silenziosamente un servizio, e nessuno testa di nuovo fino al prossimo audit, momento in cui è già nell’auto.

Non puoi risolverlo assumendo. Puoi moltiplicare

L’istinto è assumere più specialisti. È l’istinto giusto e non basta, perché le persone non ci sono da assumere, e persino un team raddoppiato non può ri-testare a mano ogni release di ogni ECU.

È qui che l’AI e l’automazione cambiano l’economia di base, e vale la pena essere precisi su come. L’AI non colmerà il divario di competenze da sola, e chiunque ti dica che sostituisce i tuoi ingegneri di sicurezza ti sta vendendo qualcosa. Quello che fa davvero, bene, è far crescere il team che hai già: codificare ciò che un buon tester fa a mano in motori che girano senza di lui, così i pochi esseri umani vengono impiegati nel lavoro che solo gli umani possono fare.

In concreto, la conoscenza di come enumerare uno stack UDS, sondare SecurityAccess, fuzzare un’interfaccia in sicurezza o attraversare un gateway DoIP è stabile e ripetibile. Non ha bisogno di uno specialista presente ogni volta. Ha bisogno di uno specialista una volta, per costruire il test, e poi di una macchina che lo esegua a ogni release per sempre. Lo specialista è così libero per il percorso di attacco inedito, la TARA, la cosa che l’automazione non può immaginare.

Come appare in un programma reale

È esattamente ciò per cui AutoST è costruito. I suoi motori portano la conoscenza del testing: enumerazione UDS, analisi SecurityAccess (0x27), fuzzing UDS e CAN, DoIP e SOME/IP, IVI Android. Colleghi la ECU a un banco una volta, e da lì in poi AutoST gira dall’API e in CI.

Così il testing passa da “uno specialista, se è libero, prima dell’audit” a “automaticamente, a ogni release importante”. Ogni build di ogni ECU riceve lo stesso passaggio di sicurezza di base. I risultati facili da trovare vengono intercettati nel momento in cui sono introdotti, non scoperti nell’auto. Alla SOP hai una traccia datata che mostra che ogni release è stata testata e che i problemi noti sono stati chiusi, che è anche esattamente ciò che un assessor ISO/SAE 21434 vuole vedere.

E la manciata di ingegneri di sicurezza che hai smette di spendere le sue ore preziose a ritrovare lo stesso SecurityAccess debole sulla quarantesima ECU. Le spende sugli attacchi che hanno davvero bisogno di un essere umano.

La versione onesta

L’automazione non rende superflui gli ingegneri di sicurezza. Rende decisivi quelli che hai. AutoST gestisce l’ampiezza e la regressione così un piccolo team può coprire un intero programma veicolo e arrivare alla SOP senza risultati facili da trovare noti. La profondità, la creatività, la TARA e l’audit hanno ancora bisogno di persone, e Zyberum porta anche quelle, come un team che ha portato programmi Tier 1, Tier 2 e OEM esattamente attraverso questo percorso. Le referenze sono disponibili su richiesta.

Se il tuo programma ha più ECU che ingegneri di sicurezza, cosa che vale per quasi tutti, quel divario è il problema che AutoST è stato creato per colmare. Prenota una demo e ti mostreremo com’è davvero testare ogni release.