Il CWE (Common Weakness Enumeration) è una tassonomia gerarchica delle tipologie di debolezze nel software e nell’hardware, mantenuta da MITRE. Si distingue fondamentalmente dal CVE: mentre il CVE cataloga istanze specifiche di vulnerabilità (“questa versione di Log4j ha questa vulnerabilità specifica”), il CWE cataloga le classi di difetti ricorrenti che generano vulnerabilità (“buffer overflow”, “SQL injection”, “race condition”). Ogni CVE è classificato con uno o più CWE che ne descrivono la tipologia sottostante.
Struttura gerarchica
I CWE sono organizzati in una gerarchia: Pillar → Class → Base → Variant. A ogni livello il difetto è descritto con maggiore specificità:
- Pillar (es. CWE-664 — Improper Control of a Resource): categoria astrattissima
- Class (es. CWE-400 — Uncontrolled Resource Consumption): più specifica
- Base (es. CWE-770 — Allocation of Resources Without Limits): descrive una tipologia concreta
- Variant (es. CWE-789 — Memory Allocation with Excessive Size Value): istanza specifica
CWE Top 25
Il NIST pubblica annualmente il CWE Top 25 Most Dangerous Software Weaknesses, calcolato analizzando migliaia di CVE del NVD. Le posizioni di testa persistenti:
| Posizione | CWE | Nome |
|---|---|---|
| 1 | CWE-787 | Out-of-bounds Write |
| 2 | CWE-79 | Cross-site Scripting (XSS) |
| 3 | CWE-89 | SQL Injection |
| 4 | CWE-416 | Use After Free |
| 5 | CWE-78 | OS Command Injection |
| 6 | CWE-20 | Improper Input Validation |
| 7 | CWE-125 | Out-of-bounds Read |
| 8 | CWE-22 | Path Traversal |
| 9 | CWE-352 | CSRF |
| 10 | CWE-434 | Unrestricted Upload of Dangerous File |
Utilizzo pratico
Il CWE è il vocabolario comune per la classificazione delle debolezze nel Secure SDLC:
- Gli strumenti SAST (Static Application Security Testing) mappano le loro regole ai CWE, permettendo di filtrare e prioritizzare i risultati per categoria di debolezza.
- Le linee guida di sviluppo sicuro (OWASP, SEI CERT Coding Standards) sono organizzate per CWE.
- I programmi di bug bounty usano i CWE per classificare le vulnerabilità segnalate dai ricercatori.
- I contratti di sviluppo software specificano sempre più spesso requisiti di assenza di CWE specifici (es. “nessun CWE-89 SQL Injection nel codice consegnato”).
Conoscere i CWE più comuni è il punto di partenza per un developer che vuole scrivere codice sicuro: ogni CWE ha una pagina dettagliata su cwe.mitre.org con descrizione, esempi di codice vulnerabile e mitigazioni.