La tassonomia unificata 🧠
Questa tassonomia è una lettura analitica della serie, non una nuova Top 10 OWASP. Normalizza i fallimenti che ricompaiono in domini diversi e conserva le differenze nel meccanismo e nel controllo. Il suo valore è tutto qui: tenere insieme ciò che è davvero lo stesso e annotare con cura ciò che lo è soltanto in apparenza.
Il metodo è semplice: si parte da una proprietà di sicurezza fondamentale (autorizzazione, integrità dei dati, disponibilità), si vede come il suo fallimento si manifesta nei vari domini e si risale alle categorie OWASP che lo nominano. La normalizzazione non è una semplificazione: è una compressione che perde solo ciò che puoi ricostruire tornando al dominio.
Dieci concetti trasversali 🔟
- Autorizzazione e access control: chi può fare cosa su quale risorsa.
- Identità e autenticazione: chi o cosa sta agendo davvero.
- Input e injection: contenuti non fidati che alterano un interprete o un flusso.
- Output ed esecuzione downstream: output che diventa codice, query o azione.
- Supply chain e provenienza: componenti, dati e artefatti di cui non verifichi origine e integrità.
- Crittografia e secret: protezione e ciclo di vita delle informazioni sensibili.
- Hardening e configurazione: default, policy e superfici esposte.
- Risorse e disponibilità: consumo, limiti e resilienza.
- Telemetria ed eccezioni: capacità di vedere, capire e gestire il fallimento.
- Logica autonoma e agency: decisioni o tool con potere oltre il confine previsto.
Ogni concetto viola una proprietà precisa, ed è quella che devi citare quando spieghi la priorità al business:
| Concetto | Proprietà violata | Manifestazione per dominio |
|---|---|---|
| Access control | Autorizzazione, riservatezza | A01, API1/API3/API5, K03, LLM08 |
| Identità | Autenticità, non ripudio | A07, API2, K06, CICD-SEC-2 |
| Input e injection | Separazione dati/istruzioni | A05, M4, LLM01, S1 |
| Output downstream | Integrità, contenimento | LLM02, A05 (parziale) |
| Supply chain | Integrità del software | A03, M2, K02, CICD-SEC-3/8/9, LLM05 |
| Crittografia e secret | Riservatezza, autenticità | A04, M1/M10, K08, CICD-SEC-6 |
| Hardening | Difesa in profondità | A02, API8, M8, K01/K09, CICD-SEC-7 |
| Risorse | Disponibilità | API4, LLM04, S7 |
| Telemetria | Auditabilità, rilevabilità | A09/A10, K05, CICD-SEC-10, S5/S10 |
| Agency | Integrità del flusso, intenzioni | API6, LLM08/LLM09, CICD-SEC-1 |
flowchart TD
A[Proprietà di sicurezza] --> B[Concetto normalizzato]
B --> C[Manifestazione di dominio]
C --> D[Categoria OWASP e controlli]
Due esempi completi 🧪
Access control. Segui il concetto numero 1: nel Web è una route raggiungibile senza check (A01); in API si scompone in tre granularità — oggetto (API1 BOLA), proprietà (API3) e funzione (API5 BFLA) — perché un’API espone direttamente il grafo degli oggetti; in Kubernetes diventa RBAC permissivo dichiarato nel manifest (K03); in un agente diventa la distinzione tra “quanto può fare questo attore non umano” e “questa richiesta passa il check” (LLM08). Il principio è affine; la verifica non lo è, e scrivere una sola test suite sperando di coprirli tutti è un errore.
Injection. Il concetto 3 ha due facce che NON vanno appiattite. L’injection classica (A05, S1, M4) abusa una grammatica ben definita — SQL, shell, XML — e il fix esiste: parametrizzazione ed escaping rispetto a quella grammatica. La prompt injection (LLM01) non abusa una grammatica: mette contenuto ostile nello stesso canale usato per le istruzioni legittime, e non esiste un’equivalente della parametrizzazione per l’istruzione in linguaggio naturale. Chiamarle “la stessa cosa” ti fa scegliere i controlli sbagliati per entrambe.
Crittografia e secret. Il concetto 6 è quello con le posture più diverse: la Web lo tratta come fallimento crittografico (A04), la Mobile lo scompone in tre voci — credenziali conservate male (M1), dati sensibili su storage insicuro (M9), primitivi deboli (M10) — Kubernetes lo chiama secret management (K08: Base64 in etcd, non una cifratura) e la CI/CD lo vede come igiene delle credenziali (CICD-SEC-6). Quattro posture per lo stesso principio; la norma, non l’eccezione.
Supply chain. Segui il concetto 5 e scenderai lungo l’intera catena del delivery: dipendenze (A03 e SCA), SDK mobile opachi (M2), immagini e chart (K02), action e artefatti di build (CICD-SEC-3/8/9), fino ai pesi e ai dataset del modello (LLM05). Un solo concetto, il confine di cosa deve essere verificato cambia a ogni salto di layer.
Usarla correttamente 🧭
Prendi una proprietà, segui il concetto e poi torna al dominio. La tassonomia serve a evitare buchi tra team e tool: una policy sui privilegi deve coprire utenti, service account, pipeline e agenti. Non serve a sostituire la documentazione OWASP della tecnologia che stai valutando.
Tre regole d’uso:
- Una riga della tassonomia non è un verdetto. Individua dove il concetto vive nel tuo sistema e verifica che i controlli coprano quel dominio specifico.
- Non confondere proiezioni con duplicati. La matrice che userete dopo esiste proprio per distinguerle.
- Aggiorna con le edizioni. La tassonomia è vivente quanto le liste che la alimentano: l’arrivo di A10 (condizioni eccezionali) e di LLM08 (agency) nel 2025/2026 ha cambiato il peso reale dei concetti 9 e 10.
I limiti da dichiarare ⚠️
La normalizzazione ha confini netti. I modelli linguistici violano l’assunto classico che istruzioni e dati siano separabili: per questo il concetto 3 è una famiglia, non un’identità. Gli smart contract girano su invarianti economici (rientranze, precisione, oracoli) che non si mappano bene su A01–A10: se il tuo dominio è Web3, la tassonomia serve meno della lista dedicata. E alcune liste sono così immature che non offrono una “manifestazione” da collegare, ma solo un’intuizione da annotare.
La tassonomia è una lente, non una bibbia. Quando forza il quadro, il quadro ha ragione.
Leggi poi la matrice di cross-reference per applicare questi concetti su più domini.