Claude Mythos e l'identificazione di vulnerabilità

Segnalo questo articolo dal titolo "Mythos and Cybersecurity": https://www.schneier.com/blog/archives/2026/04/mythos-and-cybersecurity.html. 

 Claude ha sviluppato Mythos, motore di ricerca di vulnerabilità software e i risultati sono incredibili: migliaia di vulnerabilità identificate nei sistemi operativi più diffusi e altro. Questo ha suggerito a Anthropic di rendere disponibile questo motore solo a 50 grandi produttori di software. 

L'articolo di Bruce Schneier riflette sulla mancanza di dati sui falsi positivi, sulla attuale capacità di identificare vulnerabilità sui sistemi meno diffusi e quanto questo potrà essere pericoloso in futuro, sui rischi generali che corriamo considerando che i software sono attualmente sviluppati e mantenuti da società private. Sembra poi che GPT-5.5 sia altrettanto potente e già disponibile.

Sviluppo software, intelligenza artificiale e sicurezza

Roberto Piazzolla e Alessandro Vallega, il 12 gennaio 2026, hanno tenuto un webinar per il Clusit dal titolo "Vibe coding: programmare con l'AI, tra opportunità e rischi": https://clusit.it/blog/webinar-vibe-coding-programmare-con-lai-tra-opportunita-e-rischi/

Purtroppo è disponibile solo agli iscritti al Clusit. 

Posso dire che hanno parlato dei problemi di sicurezza del codice sviluppato con il supporto dell'IA.

Non mi dilungo oltre perché il contenuto è decisamente tecnico. Però posso riportare alcune raccomandazioni:

• bisogna formare i programmatori sulla sicurezza e i limiti dell'IA; inutile (e sbagliato) vietarla;
• se si usa il vibe coding, ossia si delega all'IA lo sviluppo o parte di esso, il lavoro si sposta sulla fase di test, funzionale e di sicurezza, e quindi il processo di sviluppo deve essere adattato (anche tecnologicamente, per esempio usando un'IA anche per i test);
• i possibili errori dell'IA implicano la necessità di segregare gli ambienti di sviluppo, test e produzione,
• effetto psicologico 1, sindrome dell'impostore: i programmatori si impauriscono quando vedono che l'IA, in alcuni casi, fa meglio di loro; ma questo solitamente succede a quelli bravi, quindi, se uno ha paura, vuol dire che è bravo e non deve aver paura;
• effetto psicologico 2, sindrome di Dunning-Kruger: i programmatori pensano di essere più bravi di quello che sono perché aiutati dall'IA; questo solitamente succede a quelli non bravi, quindi va prestata molta attenzione al fatto che potrebbero non controllare correttamente;
• effetto psicologico 3: il programmatore potrebbe non essere più soddisfatto dal proprio lavoro, visto che l'IA fa le cose divertenti (risolvere problemi), e poi, senza più la dopamina scatenata dalla gioia di risolvere problemi, potrebbe lavorare male e questo va affrontato.

Codice di condotta privacy per le imprese di sviluppo e produzione di software gestionale

Il Garante per la privacy ha approvato il codice di condotta per il trattamento dei dati personali effettuato dalle imprese di sviluppo e produzione di software gestionale e l'accreditamento dell'organismo di monitoraggio: https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/10075998.

In sintesi e imprecisamente: il codice di condotta può essere applicato da chiunque e chi lo applica può chiedere una sorta di certificazione all'organismo di monitoraggio, in questo caso Assosoftware.

Il mio commento è che sarà opportuno, per gli sviluppatori in generale, verificare l'applicazione dei requisiti funzionali e tecnici negli allegati A e B e adottare il modello di DPA in Allegato C.

Purtroppo questo codice arriva dopo 8 anni di fatica a selezionare i requisiti funzionali per i miei clienti e a produrre modelli di DPA. Fosse arrivato prima mi avrebbe risparmiato molta fatica!

Senza togliere niente agli articolisti, suggerisco di leggerlo nella sua versione ufficiale, visto che è di facile lettura.

Ringrazio Chiara Ponti che l’ha segnalato agli Idraulici della privacy.

Security-by-Design and Default Principles del CISA

Ottimo documento del CISA (Cybersecurity & infrastructure security agency degli USA) dal titolo "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default": https://www.cisa.gov/news-events/alerts/2023/04/13/shifting-balance-cybersecurity-risk-security-design-and-default-principles.

In poche pagine (15 in tutto, incluso indice e fuffa introduttiva) sono riportati e spiegati i principi di sviluppo e ingegnerizzazione sicuri.

Guide per lo sviluppo sicuro di NSA

Dalla newsletter Crypto-Gram segnalo che NSA ha pubblicato due guide per lo sviluppo sicuro.

Il primo ha titolo "Software Supply Chain Guidance for Developers":
- https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3146465/nsa-cisa-odni-release-software-supply-chain-guidance-for-developers/.

Il secondo ha titolo "Software Supply Chain Guidance for Suppliers" (che purtroppo ha le prime 22 pagine su 45 in formato foto e non testo):
- https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3204427/esf-partners-nsa-and-cisa-release-software-supply-chain-guidance-for-suppliers/.

Si tratta di cose note, ma ben approfondite.

Mia presentazione "Spunti per lo sviluppo sicuro del software"

Il 7 ottobre 2022, alla "AppSec and Cybersecurity Governance 2022" organizzata da ISACA Venice Chapter, OWASP Italia e Ca' Foscari University a Mestre, ho avuto l'opportunità di presentare alcune riflessioni su cosa non funziona nello sviluppo sicuro del software:
- https://www.cesaregallotti.it/Pdf/Pubblicazioni/20220-10-07-Slides-ISACA-Venice.pdf.

L'iniziativa è stata molto bella e ringrazio in particolare Alberto Elia Martin di ISACA Venice per avermi invitato (il programma della giornata è disponibile su https://sites.google.com/owasp.org/assg2022/) e i tanti colleghi che ho avuto modo di incontrare nuovamente o di conoscere di persona.

7 ottobre a Mestre: mio intervento per ISACA Venice

Il 7 ottobre mi hanno invitato a tenere un intervento per ISACA Venice. Ne sono molto onorato:
- https://sites.google.com/owasp.org/assg2022/home?authuser=0.

Il mio intervento avrà titolo "Spunti per lo sviluppo sicuro del software". Pubblicherò le slide prossimamente.

Linee guida di design per i siti internet e i servizi digitali della PA

Franco Vincenzo Ferrari mi ha segnalato la pubblicazione delle "Linee guida di design per i siti internet e i servizi digitali della PA". La notizia è qui:
- https://www.agid.gov.it/it/agenzia/stampa-e-comunicazione/notizie/2022/07/27/pubblicate-linee-guida-design-i-siti-internet-i-servizi-digitali-pa?s=03.

Particolarmente significativi sono le linee guida stesse (https://docs.italia.it/italia/design/lg-design-servizi-web/it/versione-corrente/index.html) e il Manuale operativo di design (dove non appare alcun paragrafo dedicato alla sicurezza, ahimè).

Le linee guida sono molto ad alto livello e per quanto riguarda la privacy e la sicurezza ripropongono requisiti generali.

Insomma: è opportuno sapere che esistono, ma non mi sembrano significative.

La sicurezza del software open source

Bruce Schenier ha segnalato un'analisi sulla (scarsa) sicurezza del software open-source dal titolo "Open-Source Security: How Digital Infrastructure Is Built on a House of Cards":
- https://www.lawfareblog.com/open-source-security-how-digital-infrastructure-built-house-cards.

In sostanza, viene detto che gli utilizzatori di software open-source sono principalmente i venditori di software, che riciclano quello open-source e non si preoccupano della sua sicurezza e pertanto si dovrebbero attivare misure istituzionali in questo senso. La UE ha adottato una strategia sul software open-source che richiede di "esplorare opportunità per servizi di supporto dedicati per le soluzioni open-source ritenute critiche".

L'argomento è importante e quindi, ritengo, va seguito con attenzione.

2022 CWE Top 25 Most Dangerous Software Weaknesses

E' stata pubblicata la lista "2022 CWE Top 25 Most Dangerous Software Weaknesses":
- https://cwe.mitre.org/top25/archive/2022/2022_cwe_top25.html.

La lettura è resa complicata perché, per leggere le raccomandazioni, è necessario accedere alla pagina di ogni vulnerabilità e poi consultare la sezione "Potential Mitigations". Per come ragiono io, avrei preferito leggere le raccomandazioni per poi approfondire, eventualmente, quali minacce contrastano. Questa iniziativa è comunque notevole.

Programma di bug bounty

Pierluigi Stefli di Datapro mi ha segnalato questa pagina web di un programma di bug bounty promosso da una società di prodotti di smart energy:
- https://www.solaredge.com/it/cyber-security-policy.

In breve, questa società chiede di segnalarle vulnerabilità sui suoi sistemi e fornisce una ricompensa a certe condizioni (p.e. tempo per correggere gli errori prima della divulgazione).

Pierluigi me l'ha segnalata perché è la prima che vede così strutturata. E, a mia volta, la segnalo perché è la prima volta che ne vedo una così strutturata.

OWASP Top 10:2021

Segnalo che è stata pubblicata la nuova versione delle 10 vulnerabilità applicative più importanti secondo OWASP:
- https://owasp.org/Top10/.

La precedente era del 2017.

Purtroppo non trovo una versione in pdf da poter studiare in formato cartaceo. L'analsii è decisamente molto tecnica e, quindi, sarò grato a chi mi segnalerà articoli di appronfondimento di questa versione.

App medicali e sicurezza

A metà 2017 avevo segnalato un articolo sul "futuro" regolamento UE sui dispositivi medici. Poi il regolamento è stato pubblicato, ma non ho più trattato l'argomento, anche se, in questi anni, ho collaborato in alcuni progetti relativi ai dispositivi medici e all'attenzione che il nuovo regolamento pone sulla sicurezza informatica.

Mi ha risvegliato Enos D'Andrea che ringrazio. Mi ha ricordato che il 26 maggio 2021 scade il termine per l'applicazione del regolamento europeo sui dispositivi medici approvato nel 2017. La scadenza era inizialmente prevista per l'anno scorso ed è stata posticipata di un anno causa COVID.

Il regolamento include anche requisiti di privacy e sicurezza per il software con finalità diagnostiche, incluse le applicazioni che monitorano i parametri di salute con finalità diagnostiche, che dovranno quindi obbligatoriamente certificarsi. Complesso è capire la differenza tra app di fitness e mediche.

Innanzi tutto ricordo l'articolo "iniziale" che avevo segnalato nel 2017:
- https://www.filodiritto.com/app-medicali-e-nuovo-regolamento-ue-sui-dispositivi-medici.

Poi segnalo dove trovare il Regolamento aggiornato ad oggi (ultimo aggiornamento del 23 aprile 2020):
- https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:02017R0745-20200424.

Quindi segnalo la "MDCG 2019-16 - Guidance on Cybersecurity for medical devices":
- https://ec.europa.eu/docsroom/documents/41863.

Comunque io non sono esperto di questa materia, ma credo sia giusto tenerla monitorata.

Materiale di formazione su OWASP Top 10 per il web

Glauco Rampogna (questo mese mi ha fornito molte indicazioni interessanti!) mi ha segnalato questo sito dove sono disponibili applicazioni interattive per formazione delle OWASP Top 10 per il web:
- https://application.security/free/owasp-top-10.

Come dice Glauco, può essere usato "al posto di mille webinar a pagamento". E in effetti ho trovato più indicazioni utili e approfondite qui che nelle presentazioni che ho sentito finora, tranne una di Paolo Perego (https://codiceinsicuro.it/) ormai troppi anni fa.

Io confesso di aver guardato solo la ricostruzione dell'attacco a Capital One con un attacco SSRF e la "Vertical Privilege Escalation". Non ho capito proprio tutto, ma penso proprio si tratti di un buon approccio per spiegare ai non tecnici come me alcune possibili vulnerabilità e ai tecnici come mitigarle.

GDPR e linee guida per lo sviluppo del CNIL

Pietro Calorio degli Idraulici della privacy mi ha segnalato la pubblicazione del "GDPR Guida per sviluppatori: La CNIL pubblica una GDPR guida per sviluppatori". Essa è la traduzione italiana della guida che avevo già commentato a giugno:
- http://blog.cesaregallotti.it/2020/06/gdpr-developers-guide-del-cnil.html.

Per chi volesse la versione originale in francese, in versione 1.0.1, è su GitHub:
- https://github.com/LINCnil/GDPR-Developer-Guide/releases/tag/V1.0.

Le recenti versioni in inglese e in italiano sono anch'esse su GitHub:
- https://github.com/LINCnil/GDPR-Developer-Guide/releases/tag/V1.0.

L'attuale versione è decisamente molto migliore di quella che avevo letto a giugno. Ancora una volta sono accennati molti elementi per la sicurezza dello sviluppo e delle applicazioni e quindi le persone interessate dovrebbero approfondirli con i link messi a disposizione. E', insomma, una lettura che raccomando.

La guida è molto concentrata sul processo di sviluppo e sulla sicurezza dell'ambiente di sviluppo, mentre i requisiti (funzionali e tecnici) da considerare per le applicazioni sono molto pochi. Speriamo nelle prossime versioni.

GDPR developer's guide del CNIL

Il CNIL (ossia il Garante privacy francese) ha pubblicato una GDPR developer's guide:
- https://www.cnil.fr/en/gdpr-developers-guide.

Ci sono cose molto interessanti e molto puntuali, inclusi link a piattaforme, a presentazioni più dettagliate, a documenti di approfondimento.

Al momento gli approfondimenti sono disomogenei e quindi, per esempio, sono presentati gli strumenti di gestione della configurazione del software e le linee guida di codifica sicura per C e C++, ma sono accennati ma non elencati strumenti di controllo automatico del codice prima della messa in produzione.

Però il CNIL permette di contribuire e quindi credo che in qualche futura versione questi aspetti saranno ben approfonditi.

Sicuramente quello che c'è merita già un approfondimento (io ho trovato molti punti) ed è sicuramente molto di più di quanto vedo in giro.

Ringrazio Glauco Rampogna per aver segnalato questa iniziativa agli Idraulici della privacy.

Documento ENISA sulla sicurezza del software

ENISA ha pubblicato il rapporto "Advancing Software Security in the EU":
- https://www.enisa.europa.eu/publications/advancing-software-security-through-the-eu-certification-framework.

Sono 16 pagine molto dense.

Infatti da una parte il paragrafo 2.4 "Existing standards and good practices" riporta alcuni documenti significativi relativi allo sviluppo sicuro. In particolare, io non conoscevo per niente l'OWASP ASVS, che ho invece trovato molto interessante (anche se avrei preferito, come al solito, un documento di "progettazione" e non di "verifica"):
- https://owasp.org/www-project-application-security-verification-standard/.


Il capitolo 3, dedicato ai problemi relativi alla sicurezza del software, anche se molto corto, riporta considerazioni che non ho mai trovato altrove. Le raccomandazioni, ossia i successivi passi che ENISA e altre istituzioni europee potrebbero prendere, mi sembrano anch'esse di adeguata profondità
(anzi... evitano proprio di citare la solita "formazione", che è sì importante, ma sembra il rifiugio di chi non ha idee).

Articolo di approfondimento sul CMMC

Segnalo questo articolo di Giustino Fumagalli e Paolo Sferlazza dal titolo "Una nuova frontiera nelle certificazioni di sicurezza cyber: Il CMMC":
- https://www.ictsecuritymagazine.com/articoli/una-nuova-frontiera-nelle-certificazioni-di-sicurezza-cyber-il-cmmc/.

Mi sembra un articolo molto chiaro che permette di capire bene cos'è questo CMMC, anche dal punto di vista tecnico.

Del CMMC avevo già accennato a febbraio 2020, facendo riferimento a due altri articoli in inglese:
- http://blog.cesaregallotti.it/2020/02/cybersecurity-maturity-model.html.

Il modello al momento si trova a questo URL:
- https://www.acq.osd.mil/cmmc/draft.html.

Sviluppatori e sicurezza

Su Crypto-Gram del 15 agosto è segnalato un articolo di ZDNet dal titolo "No love lost between security specialists and developers":
- https://www.zdnet.com/article/no-love-lost-between-security-specialists-and-developers/.

Riguarda un'indagine condotta presso gli sviluppatori e i professionisti della sicurezza e Bruce Schneier riporta alcuni dati:
- il 49% dei professionisti della sicurezza (immagino quindi di estrazione sistemistica o reziaria) denuncia fatica nel rendere prioritarie le correzioni delle vulnerabilità presso gli sviluppatori;
- il 68% dei professionisti della sicurezza pensa che meno della metà degli sviluppatori sia capace di individuare le vulnerabilità nel codice prima di passarlo in ambiente di test;
- il 70% degli sviluppatori, dall'altra parte, dichiare di non riceve alcun aiuto o linea guida per scrivere codice sicuro.

Io non sono un gran sostenitore di tutte queste indagini ("survey"), ma penso che queste indicazioni siano molto interessanti.

Strumenti per la sicurezza applicativa

Credo che gli strumenti per la sicurezza delle applicazioni software siano tra i meno considerati, anche se oggi sempre più necessari.

Tutto ha un'origine storica: inizialmente la sicurezza era solo una questione di infrastruttura informatica, non delle applicazioni. Per quanto oggi tutti siano consapevoli che non è più così (e da tempo) c'è ancora carenza di reale competenza, anche sugli strumenti che si possono utilizzare. Come consulente e auditor chiedo sempre se sono usati strumenti per il controllo del software: quasi mai sono usati strumenti per il controllo della sicurezza, qualche volta sono usati quelli per il controllo della qualità e spesso non è usato niente (anzi... sono guardato con sorpresa).

Non mi proclamo esperto e quindi non so giudicarlo appieno, ma segnalo questo articolo dal titolo "10 Hottest DevSecOps Tools You Need To Know About":
- https://www.crn.com/slide-shows/security/10-hottest-devsecops-tools-you-need-to-know-about/1.

Dovrebbe essere utile almeno come punto di partenza.