Non esiste una sola OWASP Top 10 perché non esiste una sola superficie di attacco. Un’API espone oggetti e funzioni, un cluster espone ruoli e workload, un’app LLM attraversa prompt, tool e memoria. La lista Web resta un riferimento importante, non una carta d’identità per ogni sistema.

Il progetto OWASP mantiene oggi una quindicina di progetti Top 10 con maturità molto diverse: alcuni sono flagship guidati dai dati, altri sono draft o archivi storici che conservano più idea che attualità. Trattarli come equivalenti produce esattamente il tipo di sicurezza che non vuoi: una checklist elegante e una superficie di attacco che nessuno copre.

La gerarchia delle liste 🧭

Non tutte le liste hanno lo stesso peso, e sapere la differenza evita sia il feticismo sia lo snobismo:

Fascia	Liste	Cosa aspettarsi
Core	Web 2025, API 2023, Mobile 2024, LLM 2026, Kubernetes, CI/CD	Lì va concentrata l’analisi
Architettura	Cloud-Native, Serverless, Client-Side	Idee utili, edizioni datate o mai finalizzate
Trasversali	Privacy, Data Security	Rischi normativi e di ciclo di vita dei dati
Verticali	ML, Low-Code/No-Code, Desktop, Smart Contract	Solo per stack specifici
Proto-tassonomie	Cloud-Native interim, Serverless, Client-Side	Candidate list: concetti, non requisiti

La Web Top 10 del 2025 è costruita su dati relativi a circa 2,8 milioni di applicazioni; la CI/CD del 2022 non ha un modello di dati altrettanto solido e diverse liste sono esplicitamente “draft” o “interim”. La maturità è un filtro. Una lista storica può offrire concetti validi, ma citarla come requisito in un audit di quest’anno è un modo elegante per perdere credibilità.

Edizioni e cicli di vita ⏳

Le edizioni non sono simultanee: la Web è la 2025, la API la 2023, la Mobile la 2024, la LLM la 2026, la Kubernetes esiste in due numerazioni (2022 e 2025) che convivono sul sito ufficiale, la CI/CD è ferma alla 2022 ma resta il riferimento per le pipeline. Confrontare “le liste attuali” come se condividessero un calendario è un errore che si nota subito in una board di vulnerabilità. La domanda da farsi non è “quale lista uso?” ma “quale edizione risponde al layer che sto guardando e quale fonte la alimenta?”.

La nota metodologica più preziosa è dentro la Web Top 10 2025: otto categorie sono selezionate da dati di test e due dal giudizio di esperti, perché i test automatici non le catturano. Il punto non è credere o no a quelle due righe: è sapere che le liste mescolano prevalenza misurata e rischio emergente stimato, e comportarsi di conseguenza quando le usi per decidere.

Le lenti principali 🔍

Dominio	Lista utile	Cosa rende diverso il problema
Applicazione Web	OWASP Top 10 Web 2025	Request, sessione, business logic e browser
API	OWASP API Security 2023	Oggetti, proprietà, funzioni e trust tra servizi
Mobile	OWASP Mobile 2024	Device, storage locale, SDK e permessi
LLM e agenti	OWASP LLM 2026 + Agentic 2026	Contenuti ostili, output, tool e autonomia
Kubernetes e CI/CD	OWASP Kubernetes e CI/CD	Identità macchina, policy, immagini e pipeline

Ogni lista è una proiezione dello stesso spazio di rischio su un dominio specifico. La Mobile 2024 ha una categoria dedicata alle credenziali hardcoded (M1) perché non puoi fidarti del client; la Web Top 10 non ha bisogno di una riga equivalente perché il server custodisce i segreti. L’API Top 10 tratta l’injection in modo diverso dalla lista Web: l’ha addirittura rimossa nell’edizione 2023, perché è “agnostica rispetto all’API” e non serve ridirla a chi la legge, mentre l’autorizzazione sull’oggetto è il rischio dominante. L’emergere di una lista per agenti non indica che la sicurezza classica sia sparita: segnala che istruzioni, dati e capacità eseguibili hanno nuovi confini.

Il caso sai probabilmente dell’OWASP Top 10 per applicazioni agentiche (2026): è nata come progetto complementare alla LLM Top 10. La lista LLM copre il rischio del modello (prompt injection, output handling); quella agentica copre cosa succede quando al modello dai un obiettivo, memoria, tool e permessi permanenti (goal hijacking, abuso di tool, identità e privilegi). Due liste, due livelli, nessun conflitto.

Come scegliere la lente 🎯

Parti dall’architettura, non dal titolo della lista. Un prodotto SaaS con API, app mobile, RAG e Kubernetes richiede più riferimenti: nessuno di essi copre tutto. Considera anche maturità e data dell’edizione; una lista storica può offrire concetti utili senza essere un requisito attuale.

Il metodo pratico:

1. Elenca i layer reali del sistema: client, API, orchestratore, pipeline, componenti AI.
2. Abbina una lista per layer, senza forzare un’unica lista su tutto.
3. Annota i gap: una lista che non copre il tuo dominio non è un’omissione del progetto, è un invito a usare la lente accanto — non il libro sacro al posto del codice.

Anti-pattern classici: usare solo la Web Top 10 per un sistema serverless, dichiarare “siamo conformi OWASP” senza dire a quale delle quindici, o importare il framework di un’altra organizzazione senza rivederlo contro le tue architetture.

Un esempio concreto. Un servizio di e-commerce ha checkout e pannello admin (Web Top 10), inventory e pagamenti esposti via REST (API), un cluster con tenancy dei dati (Kubernetes), una pipeline che firma gli artefatti (CI/CD) e magari una chat di supporto basata su RAG (LLM). Cinque liste, un solo sistema: il giorno in cui un incidente ti chiede “dove sta il buco?”, la risposta non starà nella lista che ti piace di più.

Quando la lista non basta ⚠️

Alcuni progetti OWASP sono rimasti a livello di candidate list. La Cloud-Native Application Security, la Client-Side Security e ancora di più la Serverless non hanno mai raggiunto una versione finale numerata: il documento Serverless riusa le categorie Web del 2017 come “interpretazione” in attesa di una lista ufficiale mai pubblicata. Non sono inutili: sono proto-tassonomie che illuminano i rischi di un dominio mentre il progetto non li ha ancora sistematizzati.

Due astuzie per usare bene l’ecosistema:

• Data l’edizione: se stai valutando i rischi del tuo workload Kubernetes, la numerazione 2022 e quella 2025 convivono; scegliere una senza annotare l’altra confonderà il prossimo audit.
• Collega i progetti: il Low-Code/No-Code cita esplicitamente “A06:2021 Vulnerable and Outdated Components” come ispirazione, e la Privacy Top 10 dichiara di includere la Web Top 10 al suo interno. Quando i progetti parlano tra loro, segui il filo.

Le Top 10 non sono un catalogo di vulnerabilità da spuntare. Sono domande da porre al sistema corretto.

Prosegui con i livelli di astrazione prima di confrontare le categorie riga per riga, oppure salta alla tassonomia unificata.