Il Futuro dello Sviluppo Sicuro del Software: tra Sast, Dast, Iast, Sbom, Pentest e Tool Agentici

Quando si parla di sicurezza applicativa, il problema raramente è uno solo. È quasi sempre una catena di piccoli difetti, scelte sbagliate e controlli mancanti che, sommati, aprono la strada a incidenti gravi. È anche per questo che affidarsi a un singolo strumento di sicurezza è un’illusione pericolosa: tranquillizza il management, certo, ma non impedisce che l’incidente arrivi — puntuale — nel momento meno opportuno.

Nel tempo, il settore ha sviluppato approcci diversi per affrontare categorie differenti di rischi. Esistono molteplici tipologie di test di sicurezza applicativa e comprenderne davvero il valore significa sapere cosa individuano, cosa non vedono e, soprattutto, come integrarli tra loro. Solo così è possibile ridurre in modo concreto la superficie d’attacco e prevenire problemi che altrimenti emergerebbero troppo tardi.

Le linee guida possono offrire un supporto importante, ma in un ecosistema complesso — e ancor più in contesti enterprise — trasformare i principi in processi strutturati, rigorosi ed efficaci non è affatto banale. La realtà è sfumata, piena di eccezioni e compromessi.
Eppure, è proprio questo lo sforzo che vale la pena fare. E proveremo a farlo.

Il modello DevSecOps, cos’è e come si applica

Avvio delle iscrizioni al corso Cyber Offensive Fundamentals Vuoi smettere di guardare tutorial e iniziare a capire davvero come funziona la sicurezza informatica? La base della sicurezza informatica, al di là di norme e tecnologie, ha sempre un unico obiettivo: fermare gli attacchi dei criminali informatici. Pertanto "Pensa come un attaccante, agisci come un difensore". Ti porteremo nel mondo dell'ethical hacking e del penetration test come nessuno ha mai fatto prima. Per informazioni potete accedere alla pagina del corso oppure contattarci tramite WhatsApp al numero 379 163 8765 oppure scrivendoci alla casella di posta [email protected]. Supporta Red Hot Cyber attraverso:  L'acquisto del fumetto sul Cybersecurity Awareness Ascoltando i nostri Podcast Seguendo RHC su WhatsApp Seguendo RHC su Telegram Scarica gratuitamente “Byte The Silence”, il fumetto sul Cyberbullismo di Red Hot Cyber Se ti piacciono le novità e gli articoli riportati su di Red Hot Cyber, iscriviti immediatamente alla newsletter settimanale per non perdere nessun articolo. La newsletter generalmente viene inviata ai nostri lettori ad inizio settimana, indicativamente di lunedì.

Il modello DevSecOps (ne abbiamo parlato molto su questo palinsesto) rappresenta un’evoluzione naturale del concetto di DevOps, integrando la sicurezza direttamente nel ciclo di vita dello sviluppo software. Mentre DevOps si concentra sulla collaborazione tra sviluppatori e team operativi per velocizzare il rilascio delle applicazioni, DevSecOps introduce la sicurezza come responsabilità condivisa, distribuendo compiti e controlli lungo tutta la filiera. In pratica, ogni fase del processo di sviluppo – dalla progettazione alla produzione – deve considerare la sicurezza come elemento fondamentale, piuttosto che un’aggiunta finale. Questo approccio resiliente, permette di ridurre vulnerabilità, individuare problemi prima che diventino critici e creare applicazioni più robuste sin dall’inizio.

Un principio centrale del DevSecOps è la validazione continua dei sistemi. Ogni componente di un’applicazione viene testato più volte, spesso da mani diverse, per garantire che eventuali errori o vulnerabilità non sfuggano ai controlli. Questa ripetizione dei test, eseguita da team differenti e su tutta la catena IT (Sviluppo, Collaudo, Esercizio), attraverso strumenti automatizzati, riduce drasticamente il rischio di falle di sicurezza e garantisce che ogni modifica o aggiornamento sia sicuro. In questo contesto, la sicurezza non è più un compito isolato del reparto di Security, ma un impegno collettivo che richiede partecipazione attiva da parte di sviluppatori, tester, team operativi e specialisti della sicurezza.

La filosofia alla base del DevSecOps sottolinea che la sicurezza è una “shared responsibility”: solo quando tutti i membri della catena di sviluppo svolgono correttamente il loro ruolo è possibile costruire applicazioni davvero sicure. Non basta quindi implementare solo strumenti di sicurezza avanzati e scrivere codice sporco; occorre promuovere la cultura in cui ogni professionista e che quest’ultimo sia consapevole dei rischi e dei controlli necessari da svolgere durante il suo operato. La collaborazione e la comunicazione tra team diventano quindi essenziali, poiché ogni errore o trascuratezza può avere impatti significativi sull’intero sistema.

Il DevSecOps non è solo un concetto teorico: grandi player del settore, come il Dipartimento della Difesa statunitense (DoD), Tesla o Netflix, adottano questa metodologia per garantire che il codice prodotto sia affidabile e sicuro. Queste realtà dimostrano che, integrando sicurezza e sviluppo in modo continuo e condiviso, è possibile conciliare rapidità di rilascio e protezione dei dati. L’adozione del modello DevSecOps permette così di costruire software più resiliente e affidabile, proteggendo utenti e infrastrutture senza rallentare l’innovazione.

Static Application Security Test (SAST)

Chiamata in gergo comune anche SAST (Static Application Security Test), si tratta di un’analisi approfondita del codice senza attivare l’applicazione, è possibile individuare delle vulnerabilità. Lo strumento analizza il codice sorgente o le rappresentazioni intermedie per comprendere dove i dati forniti dall’utente potrebbero arrivare in posizioni rischiose, ad esempio all’interno di query di database, comandi shell, template o nel file system. Questo metodo rappresenta uno degli approcci più efficaci per rilevare i bug in una fase precoce, quando la correzione risulta ancora essere poco dispendiosa.

Il punto di forza dell’analisi statica è la capacità di identificare efficacemente i difetti più comuni: iniezioni, deserializzazione non sicura, crittografia debole, errori di autorizzazione, funzioni pericolose e casi in cui i dati di input non superano la normale convalida.

Questo è particolarmente utile quando l’analisi è integrata nella pipeline di build e quindi deve essere svolta nella fase di sviluppo del software: lo sviluppatore rileva il problema quasi immediatamente, anziché vederlo in un report un mese dopo.

Risulta anche una debolezza ben nota: gli scanner producono moltissimi falsi positivi. Per fasli positivi si intendono quelle vulnerabilità che il software di scansione etichetta come tali, ma che di fatto in produzione non lo sono.

Se un’applicazione presenta flussi di dati non standard, wrapper personalizzati e autorizzazioni complesse, lo strumento potrebbe non individuare il vero problema e quindi bombardare il team di avvisi. Come regola generale, vengono comunemente stabilite le seguenti linee guida: controllare rigorosamente le classi di vulnerabilità critiche e classificare le restanti in base al rischio e al contesto.

• Fase Devsecops: sviluppo e pipeline di build (Code, Build, Test e Plan)
• Precondizioni: conoscenza del dominio applicativo, dipendenze e librerie
• Quando applicarlo: in fase di scrittura del codice e prima di ogni rilascio.
• Ciò che rileva meglio: iniezioni, chiamate non sicure, errori di gestione dei dati di input, vulnerabilità tipiche del codice. Ad esempio vulnerabilità di tipo “broken Access Control” (o BAC) essendo proprie del comportamento applicativo in questa fase non vengono rilevate.

Dynamic, Application Security Test (DAST)

Chiamata in gergo comune anche DAST (Dynamic, Application Security Test), si tratta di una scansione dell’applicazione nel suo ambiente di esecuzione. I test dinamici funzionano al contrario: l’applicazione viene avviata e attaccata come una “scatola nera” attraverso interfacce: pagine web, client mobili, API, code e integrazioni. Questo è più vicino alla realtà, poiché le vulnerabilità spesso si manifestano non nel codice sorgente, ma in una combinazione di impostazioni (hardening), ambiente e comportamento degli utenti sulle applicazioni e dati in tempo reale.

L’approccio dinamico è efficace nel rilevare errori di configurazione, vulnerabilità relative a framework non aggiornati, problemi di autenticazione e gestione delle sessioni, intestazioni di sicurezza non valide, XSS, alcune iniezioni, pannelli di amministrazione esposti e risposte del server “interessanti” che restituiscono informazioni non necessarie. L’hardening e la segregazione, è particolarmente sentito verso le API: spesso tutto sembra a posto finché non si iniziano a tirare i confini di tipi, permessi e sequenze di chiamata.

L’analisi dinamica è limitata dalla visibilità: se una sezione di funzionalità è nascosta dietro autorizzazioni (ad esempio autenticazione o specifico profilo) o è richiesto uno scenario specifico, lo scanner potrebbe non essere in grado di raggiungerla. Un altro problema tipico è il “rumore” delle vulnerabilità di basso livello che tecnicamente esistono ma non rappresentano un rischio reale. Non si parla in questo caso di “falsi positivi”, ma di vulnerabilità a basso impatto che da sole non portano ad alcuna compromissione. Pertanto, i risultati dei test dinamici richiedono quasi sempre una verifica contestuale e una definizione delle priorità. Meno invasivo del SAST, ma necessario.

• Fase Devsecops: sviluppo e pipeline di build, fase di controllo (Release, Operate, Deploy, Monitor)
• Precondizioni: conoscenza del dominio applicativo, dipendenze e librerie. E’ possibile utilizzarlo anche in modalità blackbox che autenticata (whitebox)
• Quando applicarlo: in ogni modifica sostanziale del codice e sempre su superfici esposte su interne
• Ciò che rileva meglio: errori di configurazione, patching di componenti non aggiornate, problemi di sessione, vulnerabilità di injezione (SQL injection, XSS, ecc…) e alcune vulnerabilità dell’interfaccia e dell’API.

Interactive Application Security Testing (IAST)

Chiamato in gergo tecnico IAST (Interactive Application Security Testing), si tratta di un test interattivo si colloca in una via di mezzo: l’applicazione viene eseguita, ma al suo interno viene eseguito un agente o una diagnostica avanzata, che monitora quali funzioni vengono effettivamente chiamate e quali dati fluiscono attraverso il codice. In sostanza, si tratta di un tentativo di combinare il meglio di entrambi gli approcci, statico e dinamico: meno congetture, più fatti.

Nei test IAST, occorre installare un software come “Agent” all’interno delle applicazioni le quali vengono comandate da una infrastruttura centralizzata, con tutti i pro e i difetti del caso.

Grazie alla sua visibilità “interna”, il test interattivo spesso rappresenta un modo accurato la traccia dei dati, dal parametro di input all’operazione pericolosa. Questo aiuta gli sviluppatori a capire rapidamente cosa esattamente deve essere corretto e riduce il numero di avvisi vuoti. Questo approccio funziona particolarmente bene in ambienti con test di integrazione completi: si eseguono scenari familiari, mentre l’agente raccoglie simultaneamente segnali su potenziali vulnerabilità.

Anche in questo caso, il problema è la verbosità delle vulnerabilità è un fattore problematico, in quanto possono essere tranquillamente incluse vulnerabilità altamente critiche (ad esempio da 9,8) perché analizzate dall’interno del server, ma che non verranno mai utilizzate da un aggressore in quanto presenti in pezzi di codice non eseguiti in produzione.

I limiti sono chiari: sono richiesti l’integrazione degli agenti, una corretta configurazione dell’ambiente e una copertura di test adeguata. Se la funzionalità non viene testata, il test interattivo non sarà in grado di risolverla da solo. Pertanto, raramente esiste da solo e di solito integra gli approcci statici e dinamici.

• Fase Devsecops: fase di sviluppo e pipeline di build (Release, Operate, Monitor)
• Precondizioni: Utilizzo di Agent installato sulla macchina, conoscenza del dominio applicativo per poter riconoscere i falsi positivi
• Quando utilizzarlo: in fase di collaudo delle applicazioni e in fase di esercizio in modo ricorsivo
• Ciò che cattura meglio: la conferma di tracce di dati reali, vulnerabilità che si manifestano in scenari specifici.

Analisi delle componenti Software e Bill of Materials (SBOM)

Un’applicazione moderna è quasi sempre composta da più elementi del semplice codice. Dipendenze, pacchetti, immagini container, framework e persino build front-end: tutti questi elementi forniscono funzionalità e introducono vulnerabilità. L’analisi dei componenti, chiamato anche in gergo tecnico SBOM (Software Bill of Materials ) aiuta a capire quali versioni delle librerie sono in uso, se presentano problemi noti e con quale urgenza necessitano di essere risolte.

È importante non trasformare il processo in una caccia a ogni patch immaginabile. A volte una vulnerabilità sembra spaventosa, ma è irraggiungibile nel tuo contesto, come dicevamo nel capitolo precedente. A volte è il contrario: tecnicamente “nella media”, ma si adatta perfettamente alla tua architettura e magari può essere utilizzata in concatenazione con altre sempre a basso impatto per creare un vettore di impatto reale molto critico. La definizione delle priorità, delle licenze accettabili e la pubblicazione di un elenco di componenti (SBOM) per evitare di ricostruire il quadro generale nel bel mezzo di un incidente.

Un vantaggio notevole dell’analisi delle dipendenze è che di solito è facilmente automatizzabile: il controllo viene eseguito durante la build, i prompt vengono visualizzati nel repository e il team riceve un elenco chiaro di “cosa aggiornare”. I database delle vulnerabilità disponibili pubblicamente, come OSV e NVD , vengono spesso utilizzati come fonti.

• Fase Devsecops: fase di sviluppo e pipeline di build (Release, Operate, Deploy, Monitor)
• Precondizioni: si tratta di una “spazzolata” sulla macchina. Occorre conoscenza del dominio applicativo per poter riconoscere i falsi positivi
• Quando utilizzarlo: in fase di esercizio delle applicazioni e in fase di aggiornamento delle dipendenze e delle librerie
• Ciò che rileva meglio: vulnerabilità note in componenti di terze parti, licenze rischiose, pacchetti obsoleti.

Penetration test: la simulazione di un attacco reale

Il penetration testing viene sempre utile laddove per coprire i limiti delle applicazioni, in quanto risulta essere una simulazione di attacco da parte di un hacker etico. La cosa che fa il professionista, non si limita solo a “rilevare” le vulnerabilità, ma creare un percorso che attraverso la loro concatenazione, consenta di accedere in modo illecito al sistema e quindi creare un danno.

I penetration test risultano sempre utili se mirano alla simulazione reale di un attacco informatico. Altresì i penetration test che si limitano solo ad effettuare una ricognizione, senza fornire gli “impatti reali” rilevati su un sistema, portano poco valore aggiunto alle tecniche automatizzate.

L’impatto reale, nello specifico risponde alla domanda “cosa potrebbe fare un criminale informatico sfruttando le debolezze del sistema?”. Se riusciamo a rispondere con “Accesso alla base dati ed esfiltrazione dei client previa conoscenza di un account utente con bassi privilegi da rete internet”, oppure “Accesso alle carte di credito compresi i codici CVV / CVC in modalità pre auth da una API esposta su internet”, oppure “Accesso alla base dati dei dipendenti comprendenti telefono, nome, cognome, indirizzo … ecc… sfruttando una credenziale con password predicibile da rete internet”, oppure “possibilità di impiantare malware o spegnere le infrastrutture del sistema” allora siete sulla strada giusta.

Si perché, questo genere di test di sicurezza, va a cercare quello che si chiama “Databreach potenziale”, e quindi un incidente di sicurezza mai avvenuto, che si cerca di rimediare prima che un “vero cattivo”, tenta di esfiltrare i veri “gioielli della corona” dalle infrastrutture aziendali. Su questo tema, quindi, un approccio maturo include preparazione. Concordare un perimetro, le regole di lavoro e di “gioco” (con il SOC, il Blue team), gli account di test, configurazioni sicure e criteri di accettazione.

Senza questo, il processo si trasforma rapidamente in un mero esercizio di “rendicontazione dei bug a tutti i costi”. e questo lavoro non serve a nulla oltre a far spendere i soldi dell’azienda, nei posti sbagliati. Un buon report di penetration testing in genere descrive con un approccio TOP/DOWN, i problemi riscontrati, partendo dai vettori di attacco che definiscono gli “impatti reali”, e quindi il percorso di attacco, le condizioni di riproducibilità, le raccomandazioni e una valutazione realistica del rischio.

È importante ricordare che i penetration test non sostituiscono gli audit periodici e quindi SAST, DAST, IAST, SBOM e chi più ne ha più ne metta. Servono piuttosto a “finalizzare” e a “controllare”, quello che le tecnologie precedenti non riescono a “vedere”, qualora ovviamente vengono fatti bene.

• Fase Devsecops: sistema in esercizio up & running, dopo rilasci importanti, per sistemi critici, dopo importanti modifiche infrastrutturali (OPERATE e MONITOR)
• Precondizioni: analisi costose in quanto richiedono personale specializzato.
• Ciò che rileva meglio: Simula un attacco reale e rileva le catene di attacco utilizzate da un potenziale criminale informatico. Identifica gli errori logici applicativi, e vulnerabilità che coprono tutti i livelli di sicurezza (Hardening, Patching, Sviluppo Sicuro Del Codice).

Fuzzing (mutazione e test casuale dei dati di input)

Il fuzzing può sembrare, a prima vista, un approccio brutale e poco efficace. Viene sicuramente da pensare ad una persona che sbatte le mani in modo incontrollato sulla tastiera, ed in effetti non è poi così tanto lontano dalla realtà.

Inondare il sistema di spazzatura è in effetti in parte è vero, ma si tratta di spazzatura intelligente e controllata. L’idea di fondo è generare o modificare in modo sistematico i dati di input con l’obiettivo di forzare l’applicazione a comportamenti imprevisti, come crash, blocchi logici, consumo anomalo di memoria o stati incoerenti che non dovrebbero mai verificarsi in condizioni normali.

Questa tecnica risulta particolarmente efficace quando applicata a componenti che gestiscono logiche di parsing complesse, come parser, gestori di file, protocolli di rete e, più in generale, qualsiasi modulo che interpreti dati strutturati provenienti dall’esterno. Proprio in questi punti si concentrano gravi errori di validazione e assunzioni errate sugli input.

Nelle applicazioni moderne, il fuzzing viene utilizzato con successo sulle API, alterando parametri, tipi e limiti, sui meccanismi di elaborazione dei file durante le fasi di caricamento e conversione, e sui processi di serializzazione e deserializzazione dei dati che ci regalano potentissime falle di Remote Code Execution (RCE). Un’attività di fuzzing ben condotta non si limita a individuare semplici crash, ma consente, come anticipato, di far emergere vulnerabilità più profonde che, in determinate condizioni, possono portare all’esecuzione di codice remoto, a perdite di memoria, alla divulgazione di informazioni o all’aggiramento dei controlli di sicurezza.

Per quanto l’approccio possa apparire invasivo o “fastidioso”, è sempre preferibile che questi comportamenti anomali vengano scoperti in un ambiente di test controllato, dove possono essere svolte attività “distruttive”, piuttosto che in ambiente di produzione o, peggio, sfruttati da un attaccante reale. Tuttavia, dal punto di vista operativo, il fuzzing è una tecnica complessa e presenta molte difficoltà per padroneggiarla. Richiede tempo, risorse computazionali e una configurazione accurata. È necessario stabilire quali componenti sottoporre a test, come misurare in modo efficace la copertura del codice, come gestire e deduplicare i crash generati e come trasformare un errore grezzo in un risultato utile e comprensibile per gli sviluppatori. Nella pratica, si tende quindi a partire dalle aree considerate più rischiose e ad ampliare gradualmente la copertura nel tempo.

• Fase Devsecops: sistema in ambiente di collaudo, soprattutto dopo modifiche nei parser e nei protocolli di comunicazione (TEST)
• Precondizioni: personale altamente specializzato
• Ciò che rileva meglio: elaborazione dei dati, overflow, blocchi, arresti anomali, condizioni impreviste.

Sistemi Agentici, basati sull’Intelligenza Artificiale

Per anni, i BAS (Breach and Attack Simulation) hanno rappresentato un passo importante verso l’automazione della sicurezza offensiva, consentendo alle organizzazioni di simulare attacchi reali e valutare l’efficacia dei controlli difensivi. Tuttavia, questi sistemi hanno sempre mostrato un limite strutturale: un comportamento predefinito, deterministico e fortemente monolitico, confinato a specifici sistemi, tecniche o vettori di attacco. In altre parole, il BAS osserva e replica scenari noti, ma fatica ad adattarsi, ad immaginare nuovi scenari come farebbe un attaccante umano.

L’avvento dei sistemi agentici basati su Intelligenza Artificiale generativa segna un cambio di paradigma profondo. Non si tratta più di eseguire una sequenza di tecniche codificate, ma di agenti autonomi in grado di osservare, pianificare, agire e adattarsi in base al contesto. Grazie ai Large Language Model e ai sistemi multi‑agent, oggi è possibile esplorare superfici di attacco complesse con una velocità e un’ampiezza che superano nettamente l’approccio manuale del penetration tester tradizionale. Questo vantaggio operativo non è marginale: riduce drasticamente il tempo di scoperta e amplia lo spazio delle possibilità esplorate, ma ci sono dei ma….

Il problema, tuttavia, resta invariato ed è tutt’altro che banale. Negli ambienti di esercizio e produzione, la domanda fondamentale è sempre la stessa: come consentire a questi agenti di operare senza controllo umano diretto, mantenendo però un comportamento non invasivo, silente e sicuro?

Già con i BAS tradizionali, mantenere questo equilibrio era un’impresa titanica, perché la pervasività di un attacco è sempre inversamente proporzionale alla stabilità e al ritmo operativo del sistema. Con agenti autonomi, capaci di apprendere e prendere decisioni autonome, la complessità aumenta in modo esponenziale. Un agente mal configurato può facilmente superare il confine tra simulazione e impatto catastrofico su un sistema (per estremizzare come l’abuso di una SQL injection per cancellare il database in esercizio).

Questi agenti non si limitano a eseguire exploit o scanner, ma sono in grado di ragionare sugli output, concatenare informazioni eterogenee, scegliere strategie alternative e adattare il comportamento in tempo reale, oltre il rischio costante e non prevedibile delle “allucinazioni” soprattutto in contesti dove deve “inventare”. In pratica, si avvicinano sempre di più al modello cognitivo di un attaccante reale, capace di muoversi lateralmente, cambiare tattica e sfruttare opportunità emergenti. È qui che il confine tra testing e simulazione realistica inizia a sfumare.

La sfida dei prossimi anni non sarà quindi solo tecnologica, ma etica, operativa e di governance. I sistemi agentici per il penetration testing promettono un realismo senza precedenti, ma richiedono nuovi modelli di controllo, limiti operativi chiari e meccanismi di osservabilità avanzata. In assenza di questi elementi, il rischio è quello di introdurre negli ambienti aziendali strumenti che si comportano troppo come attaccanti reali, senza le stesse responsabilità e vincoli.

• Fase Devsecops: sistema in ambiente di collaudo, come ciclo continuo di scansione (TO DO)
• Precondizioni: personale specializzato all’utilizzo di questi sistemi che risultano ancora in fase di standardizzazione
• Ciò che rileva meglio: vettori di attacco, bug di sicurezza non noti, overflow, blocchi, arresti anomali, condizioni impreviste.

Errori comuni che rovinano anche un buon programma Cyber

Uno dei principali errori nella sicurezza applicativa è affidarsi a un singolo strumento e considerare il problema chiuso. L’analisi statica (SAST) non riesce a rilevare configurazioni o comportamenti nell’ambiente di esecuzione, mentre uno scanner dinamico (DAST) spesso non comprende la logica di business. Allo stesso modo, il controllo delle dipendenze (SBOM) non protegge dai propri errori di autorizzazione o da pratiche di sviluppo scorrette. Senza una combinazione integrata di approcci, ci si limita inevitabilmente a scegliere quali classi di problemi ignorare, lasciando buchi significativi nella sicurezza.

Un altro errore frequente è trascurare il processo di gestione dei risultati. Test e scan producono grandi quantità di informazioni, ma se non vengono prioritizzati, convalidati e trasformati in azioni concrete, il team percepisce rapidamente questi output come rumore e il processo perde di “credibilità”. È fondamentale definire regole di criticità coerenti, cicli di revisione brevi e assegnazioni chiare dei responsabili, così da trasformare i risultati in interventi misurabili. Anche la metrica conta: non ha senso basarsi sul numero totale di problemi rilevati, ma piuttosto sul numero di problemi correlati al rischio effettivo che sono stati risolti.

Infine, il terzo errore è pretendere la perfezione fin dall’inizio. È molto più efficace partire con un set minimo di controlli, raggiungere una stabilità operativa e aumentare gradualmente il rigore. In caso contrario, la pipeline rallenta, i report si accumulano e gli utenti cominciano a bypassare i controlli, compromettendo il valore stesso della sicurezza implementata. Una sicurezza percepita come ostacolo o fastidio non viene rispettata e, di fatto, non è sicurezza.

Concludendo

La sfida principale in tutti i programmi di sicurezza, oggi più che mai, è il commitment. Non basta disporre di strumenti avanzati o metodologie sofisticate: occorre che i CEO, i direttori IT e della Security e i leader dei vari team comprendano appieno la necessità di lavorare in modo strutturato e coordinato, e che traducano questa visione in comportamenti concreti lungo tutta l’organizzazione. Solo quando la cultura della sicurezza verrà diffusa dal vertice verso il resto della popolazione aziendale si crea un ecosistema in cui ogni individuo conosce il proprio ruolo e le proprie responsabilità, e può contribuire in maniera significativa a ridurre i rischi.

Il mondo reale, tuttavia, non è perfetto e la sicurezza non si costruisce in un giorno. Tutto si sviluppa gradualmente, con passi incrementali, iterazioni continue e tanti ma tanti errori. Tra questi Adattamenti ai cambiamenti tecnologici e di business. Il rischio zero semplicemente non esiste: anche dopo aver investito milioni in persone, processi e software, un databreach potrebbe sempre verificarsi. Questo non significa fallimento, ma evidenzia che la sicurezza è un percorso, non un punto di arrivo, e che la resilienza di un sistema dipende dalla capacità di imparare dagli incidenti e migliorare costantemente (ritorniamo agli errori).

Infine, tutto ciò che abbiamo visto ci insegna una verità fondamentale: gli strumenti da soli non servono a nulla senza persone che li comprendano e interpretino i risultati. Molto spesso si pensa che acquistare un appliance, collegarlo al rack e premere un pulsante avvio e avere le lucine accese, risolve i problemi.

In realtà è proprio da lì che tutto comincia. La sicurezza richiede consapevolezza, competenza, analisi critica e capacità di azione continua. È un viaggio lungo, in cui tecnologia, processi e persone devono muoversi insieme, altrimenti le migliori soluzioni restano solo una promessa teorica.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

Massimiliano Brolli

Responsabile del RED Team e della Cyber Threat Intelligence di una grande azienda di Telecomunicazioni e dei laboratori di sicurezza informatica in ambito 4G/5G. Ha rivestito incarichi manageriali che vanno dal ICT Risk Management all’ingegneria del software alla docenza in master universitari.

Aree di competenza: Bug Hunting, Red Team, Cyber Threat Intelligence, Cyber Warfare e Geopolitica, Divulgazione