Il 95% dei responsabili della sicurezza subisce pressioni per nascondere le cattive notizie
Un nuovo report Checkmarx, "The Future of Application Security in the Era of AI", rileva che il 95% dei CISO subisce pressioni per sopprimere o ritardare le risultanze di sicurezza legate alla compliance.
La pressione arriva da ogni direzione: il board, le relazioni pubbliche, i team di prodotto e vendita, e i dirigenti C-level preoccupati per i tempi, il classico "non prima della call sugli utili". Non viene quasi mai detto esplicitamente.
Le risultanze di sicurezza vengono inquadrate come ostacoli agli obiettivi di business anziché come informazioni sul rischio. Gli esperti citati indicano un'unica soluzione concreta: coinvolgere il CISO nella strategia aziendale e rendere la disclosure ordinaria normale prima di una crisi, non durante.
Fonte: Dark Reading · Checkmarx report, 15 Jun 2026
La mia analisi
95%. Rileggete quel numero. Quasi ogni responsabile della sicurezza ha ricevuto pressioni per tacere, rallentare o ammorbidire una risultanza. Non da persone malintenzionate. Da un board che protegge un numero, un team di vendita che protegge un accordo, un team di comunicazione che protegge una data di lancio.
Ecco la trappola. La pressione non viene quasi mai messa per iscritto. Nessuno vi manda una mail con scritto "insabbiate questo". Sentite semplicemente il clima gelare in sala quando lo sollevate. Proprio quella negabilità è ciò che lo rende pericoloso, ed è esattamente il motivo per cui funziona.
La risposta non è eroismo. È rendere la disclosure noiosa. Normalizzarla quando non c'è nulla che bruci, in modo che quando accade qualcosa dire la verità sia già un'abitudine. Se il vostro board sente parlare di sicurezza solo dopo un incidente, avete perso la battaglia mesi prima.
86.000 credenziali Fortinet, e nessuno ha dovuto forzare nulla
Una campagna ora denominata FortiBleed ha prodotto un database verificato di oltre 86.000 credenziali funzionanti per firewall e VPN Fortinet esposti su Internet, in 194 paesi. Il ricercatore Kevin Beaumont stima che si tratti di circa la metà di tutti i firewall Fortinet esposti online.
Molte delle password erano state sottratte in incidenti precedenti e non erano mai state ruotate. Un attore di lingua russa ha decifrato gli hash SSL VPN e si è spostato nel Active Directory interno.
Il 18 giugno, CISA ha emesso un alert invitando i clienti Fortinet a reimpostare le credenziali, conservare le credenziali di amministrazione con PBKDF2, esaminare i log, abilitare la MFA resistente al phishing e limitare l'accesso alla gestione.
Fonte: SecurityWeek · CISA alert, 18 Jun 2026
La mia analisi
Metà dei firewall Fortinet esposti su Internet, con credenziali funzionanti presenti in un database compilato da qualcuno. E in parte è peggio di una violazione recente: una quota di quelle password era stata sottratta molto tempo fa e semplicemente non era mai stata cambiata.
Questo è il punto da tenere a mente. Gli attaccanti non stanno forzando l'accesso. Stanno effettuando il login. Credenziali valide, porta principale, nessun exploit necessario.
Se gestite apparati edge Fortinet, CISA vi ha fornito la lista per il fine settimana: chiudete le sessioni, reimpostate le credenziali, imponete la MFA resistente al phishing, limitate l'accesso alla gestione. Ma la lezione è a monte di tutto questo. Una password sottratta che non ruotate non è un incidente che avete superato. È una chiave permanente che state pagando per tenere in circolazione.
Un token GitHub dimenticato. Due mesi dentro Novo Nordisk.
Novo Nordisk, il produttore danese di Ozempic, ha comunicato una violazione l'11 giugno. Il vettore di accesso segnalato è un singolo token di accesso GitHub ad alti privilegi, lasciato esposto nel codice JavaScript lato client su un sottodominio poco noto.
Da lì gli attaccanti hanno clonato repository privati, raccolto ulteriori credenziali presenti nel codice e si sono spostati più in profondità.
Il gruppo che rivendica l'attacco afferma di essere rimasto all'interno per oltre due mesi e di aver sottratto più di 700.000 file, circa 1,3 TB, inclusi codice sorgente, dati farmaceutici, modelli AI interni e dati relativi a circa 11.500 partecipanti pseudonimizzati a trial clinici; il gruppo ha poi avviato la pubblicazione dei dati dopo che un riscatto da 25 milioni di dollari non è stato pagato.
Il verdetto degli esperti: i repository e le pipeline CI/CD sono ormai sistemi di produzione, le credenziali machine raramente hanno un responsabile o una pianificazione di rotazione, e il raggio d'impatto di quella singola credenziale ha rappresentato l'intera violazione.
Fonte: Dark Reading · disclosed 11 Jun 2026
La mia analisi
Un token. Presente nel codice lato client, su un sottodominio che nessuno monitorava. Questo era l'unico punto d'ingresso. Due mesi all'interno di una delle maggiori aziende farmaceutiche del pianeta, e via con codice sorgente, dati farmaceutici e dati di trial clinici.
Stessa storia di FortiBleed, costume diverso. Nessuno ha violato un perimetro. Erano autenticati. E le credenziali aggiuntive di cui avevano bisogno per andare più in profondità erano semplicemente nei repository, in attesa.
La parte scomoda per voi: con tutta probabilità avete centinaia di credenziali machine, token, account di servizio, chiavi API, senza proprietario, senza rotazione, senza monitoraggio. Monitorate le persone. Chi monitora le chiavi? Trattate i repository e le pipeline come sistemi di produzione, perché per un attaccante il repository del codice è la planimetria dell'edificio, non un archivio.
Non si può conservare la mailbox di un ex dipendente. Ho dovuto spiegarlo questa settimana.
Questa settimana ho condotto un audit ISO 27001 per un ente di certificazione. L'azienda detiene il certificato da anni ed è rimasta genuinamente sorpresa nell'apprendere che non può semplicemente mantenere attive le mailbox degli ex dipendenti. Non è una novità.
All'inizio di quest'anno, l'autorità belga per la protezione dei dati ha comminato una multa di circa 176.000 euro a una grande società tecnologica esattamente per questo: un ex dipendente aveva scoperto che la propria mailbox era ancora attiva sei mesi dopo l'uscita dall'azienda. La posizione del Garante è netta.
È possibile fare affidamento su un interesse legittimo per conservare una mailbox per un breve periodo di passaggio di consegne, pensiamo a un mese, dopodiché deve essere eliminata. E limitare l'accesso non equivale a eliminarla. I dati conservati sono ancora oggetto di trattamento.
Fonte: Baker McKenzie · Belgian DPA decision, May 2026
La mia analisi
Stesso tema dei tre punti precedenti, dal lato della compliance. Accessi e dati che avrebbero dovuto essere eliminati, ancora presenti. Nessun attacco. L'esposizione era già all'interno dell'organizzazione.
Due errori comuni. Primo: bloccare un account non equivale a eliminarlo. Una mailbox che non si riesce più ad aprire è ancora conservata, e la conservazione è ancora un trattamento ai sensi del GDPR. Il Garante lo ha detto chiaramente. Secondo: quella mailbox non contiene solo i dati dell'ex dipendente. Contiene tutto ciò che chiunque abbia mai scritto a quella persona. Il raggio d'impatto è più ampio di una singola persona, ancora una volta.
Ed ecco la parte che dovrebbe far riflettere: questa azienda era certificata. Da anni. Ha comunque sbagliato. Un framework vi dice come appare una buona prassi. Non gestisce il vostro offboarding al posto vostro. Quindi verificate onestamente: quando qualcuno lascia l'azienda, cosa succede concretamente alla sua mailbox e chi firma la conferma che è stata eliminata?
Il mio nuovo webinar PECB è disponibile: colmare il decision gap
A proposito di decisioni prese sotto pressione: il mio webinar per PECB è ora disponibile online. Si intitola "Closing the Decision Gap: How Risk-Informed Decisions Build Digital Trust".
Tratta dello spazio tra la conoscenza dei rischi e l'effettiva azione su di essi, e del motivo per cui buone decisioni sul rischio costruiscono fiducia, all'interno dell'organizzazione e con le persone che servite. Se il filo conduttore di questo numero ha toccato un nervo, questo è la versione strategica della stessa conversazione.
Fonte: Watch on YouTube · PECB webinar
La mia analisi
Guardate i quattro punti precedenti. Ciascuno è, in fondo, una decisione che nessuno ha preso in tempo. Ruotare la chiave. Eliminare la mailbox. Dire la cosa difficile al board. Il risk management vive o muore in quel gap tra il sapere e il fare.
Quel gap è l'intero contenuto del talk. Se siete voi a dover prendere quelle decisioni, o a doverle difendere davanti a persone che preferirebbero non sentirle, guardatelo. Poi ditemi se ho sbagliato qualcosa.