OWASP Top 10 nel ciclo di sviluppo: guida pratica

In breve

• L'OWASP Top 10 è la classifica delle 10 vulnerabilità più diffuse nelle applicazioni web. Pubblicata e aggiornata da una community internazionale di esperti.
• È diventata di fatto lo standard a cui guardano clienti, auditor e regolatori (Cyber Resilience Act incluso).
• I primi tre posti del 2021 sono ancora attualissimi: Broken Access Control, Cryptographic Failures, Injection.
• Per integrare la sicurezza nel ciclo di sviluppo non servono mesi: bastano 4-5 strumenti automatici (SAST, SCA, DAST, secret scan) e una policy chiara.
• Per software house italiane: con CRA in arrivo nel 2027, allinearsi a OWASP oggi non è "best practice", è preparazione regolatoria.

Cos'è OWASP e perché conta

OWASP (Open Web Application Security Project) è una fondazione no-profit che pubblica risorse sulla sicurezza del software. La loro Top 10 è il documento più citato al mondo nelle gare d'appalto, nei capitolati IT, nei requisiti dei clienti enterprise.

L'attuale lista è quella del 2021 (la prossima è attesa nel 2026/27):

1. A01 — Broken Access Control
2. A02 — Cryptographic Failures
3. A03 — Injection
4. A04 — Insecure Design
5. A05 — Security Misconfiguration
6. A06 — Vulnerable and Outdated Components
7. A07 — Identification and Authentication Failures
8. A08 — Software and Data Integrity Failures
9. A09 — Security Logging and Monitoring Failures
10. A10 — Server-Side Request Forgery (SSRF)

Fonte: OWASP Top 10.

Le tre vulnerabilità più frequenti, spiegate

A01 — Broken Access Control

L'utente A può vedere/modificare dati dell'utente B. Esempio classico: cambiando un ID nell'URL (/orders/123 → /orders/124) si vedono ordini di altri.

Come prevenirlo:

• Verificare i permessi su ogni endpoint, sempre.
• Test automatici che provino accessi cross-utente.
• Default "deny": se non è esplicitamente permesso, è negato.

A02 — Cryptographic Failures

Dati sensibili in chiaro: password salvate senza hash, dati personali in HTTP, token di sessione prevedibili.

Come prevenirlo:

• HTTPS ovunque, niente eccezioni.
• Password con hash moderno (bcrypt, argon2).
• Cifratura at-rest per dati personali e PI.

A03 — Injection

Codice malevolo che entra nei vostri sistemi attraverso input non sanificati: SQL injection, command injection, LDAP injection, NoSQL injection.

Come prevenirlo:

• Query parametrizzate (mai concatenare stringhe SQL).
• Validazione input lato server (mai fidarsi del client).
• ORM/query builder che fanno l'escape per voi.

Le altre 7, in formato lampo

• A04 — Insecure Design: la sicurezza pensata in fase di progettazione (threat modeling), non aggiunta dopo.
• A05 — Misconfiguration: server con porte aperte, account admin di default, banner che rivelano versioni.
• A06 — Componenti vulnerabili: librerie con CVE note non aggiornate.
• A07 — Auth failures: niente MFA, password deboli accettate, recovery insicuri.
• A08 — Integrity failures: aggiornamenti software senza firma, supply chain non verificata.
• A09 — Logging failures: niente log → impossibile investigare incidenti.
• A10 — SSRF: il vostro server fa richieste verso URL controllati dall'attaccante.

Come integrare la sicurezza nel ciclo di sviluppo

Non serve un programma da consulenti grandi. Cinque strumenti automatici, integrati nella pipeline CI/CD, coprono la stragrande maggioranza dei casi:

1. SAST (Static Analysis): scansiona il codice sorgente. Strumenti: SonarQube, Semgrep, GitHub CodeQL.
2. SCA (Software Composition Analysis): scansiona le dipendenze (npm, Maven, pip) per CVE note. Strumenti: Snyk, Dependabot, Renovate.
3. DAST (Dynamic Analysis): testa l'applicazione in esecuzione. Strumenti: OWASP ZAP, Burp Suite.
4. Secret scanning: blocca il commit di password, chiavi API, certificati. Strumenti: gitleaks, GitHub Secret Scanning.
5. Container scanning: per immagini Docker. Strumenti: Trivy, Grype.

Tutto questo gira automaticamente ad ogni commit. Lo sviluppatore si accorge dei problemi prima ancora del code review.

La pratica del "shift left"

Spostare i controlli di sicurezza il più "a sinistra" possibile, cioè il più presto possibile nel ciclo di sviluppo. Più si accorgete tardi di un problema, più costa risolverlo:

• Trovato in IDE: 1x.
• Trovato in CI: 5x.
• Trovato in test: 10x.
• Trovato in produzione: 100x.
• Sfruttato da un attaccante: incalcolabile.

Quindi: linter di sicurezza in IDE, scan in pre-commit, scan in pipeline, pen test prima della release. A scalare.

Threat modeling: pensare al peggio prima di scrivere codice

Una pratica spesso sottovalutata. Prima di iniziare una nuova feature:

• Cosa stiamo costruendo?
• Cosa potrebbe andare storto? (chi attacca, perché, come)
• Cosa facciamo per impedirlo?
• Abbiamo fatto abbastanza?

Sono le 4 domande del framework di Adam Shostack. 30 minuti in fase di design, ore di problemi risparmiate dopo.

Perché OWASP è importante per il Cyber Resilience Act

Il CRA, in vigore pieno dall'11 dicembre 2027, chiede esplicitamente "security by design" e gestione vulnerabilità per tutto il ciclo di vita del prodotto. Allinearsi a OWASP Top 10 è un primo passo concreto.

Strumenti come SBOM (Software Bill of Materials), che il CRA richiede, vanno a braccetto con la cultura OWASP.

Costi tipici per una software house

Per una PMI di sviluppo software (10-50 sviluppatori):

• Strumenti SAST/SCA/DAST: 5-25 mila euro/anno (esistono ottime opzioni open source per ridurre i costi).
• Pen test annuale esterno: 8-20 mila euro.
• Formazione sviluppatori: 5-15 mila euro/anno.
• Bug bounty / responsible disclosure: variabile, da 0 (gestito internamente) a decine di migliaia di euro per programmi pubblici.

Investimento totale: 20-60 mila euro/anno per essere in linea con OWASP. Si ammortizza con il primo cliente enterprise che vi chiede certificazione di sicurezza.

Approfondimenti

• OWASP Top 10
• OWASP ASVS — Application Security Verification Standard
• OWASP SAMM — Software Assurance Maturity Model

In sintesi

OWASP Top 10 non è un caprice da nerd: è quello che vi chiederanno clienti enterprise, auditor e, presto, regolatori europei. Cinque tool automatici nella pipeline, una giornata di threat modeling per ogni progetto importante, formazione una volta all'anno. È poco, e fa la differenza tra una software house "amatoriale" e una pronta per il 2027.