In breve: l'analisi statica verifica il codice PHP senza eseguirlo e trova così errori di tipo, variabili non definite, codice morto e chiamate su valori eventualmente vuoti. I due strumenti più diffusi sono PHPStan (livelli di regole da 0 a 10) e Psalm (livelli di errore da 1 a 8, con in più una taint analysis per i flussi di dati non sicuri). Trovano errori nella Sua applicazione, non nell'interprete PHP; contro vulnerabilità come PHP2Shell aiuta solo l'aggiornamento di PHP.
Che cos'è l'analisi statica?
Un test esegue il codice e ne confronta il risultato. L'analisi statica, invece, legge il codice come un revisore molto scrupoloso e deduce da tipi, valori di ritorno e chiamate dove qualcosa può andare storto. Trova errori anche in rami che nessun test raggiunge mai.
Per chi decide l'utilità è semplice: gli errori trovati prima della messa online costano una frazione di quelli che i clienti notano. Per gli sviluppatori è un compagno costante, che gira nell'ambiente di sviluppo e nella pipeline CI. Se l'analisi dà l'allarme per una modifica, questa non viene accettata finché l'errore non è corretto. Così non si accumula nuovo retaggio, mentre quello esistente viene smaltito gradualmente. Insieme ai test con PHPUnit e Pest costituisce il fondamento della qualità del codice.
PHPStan: livelli di regole da 0 a 10
PHPStan si installa come dipendenza di sviluppo e per funzionare richiede PHP dalla 7.4:
composer require --dev phpstan/phpstan
vendor/bin/phpstan analyse src tests
Senza altre indicazioni PHPStan controlla solo lo stretto necessario. Il rigore lo regola attraverso undici livelli, ciascuno dei quali include quelli sottostanti:
| Livello | Che cosa viene controllato in più (selezione) |
|---|---|
| 0 | classi e funzioni sconosciute, numero errato di argomenti, variabili sempre non definite |
| 3 | tipi di ritorno e tipi assegnati alle proprietà |
| 5 | tipi degli argomenti nelle chiamate di funzioni e metodi |
| 6 | indicazioni di tipo mancanti |
| 8 | chiamate di metodi e accessi a proprietà su valori che possono essere null |
| 10 | gestione più rigorosa di mixed, anche con tipi mancanti |
Con --level max gira sempre il livello più alto. La documentazione avverte però che un aggiornamento di PHPStan può allora portare molte nuove segnalazioni. Un tipico riscontro dal livello 8:
<?php
function kundenname(?Kunde $kunde): string
{
return $kunde->name(); // PHPStan: chiamata su un valore che può essere null
}
Introdurre PHPStan senza ondata di errori: la baseline
Nei progetti cresciuti nel tempo, a un livello alto PHPStan segnala spesso centinaia di punti. La baseline risolve il problema: salva in un file tutte le segnalazioni esistenti, e da lì in poi PHPStan segnala solo i nuovi errori.
vendor/bin/phpstan analyse --level 6 src tests --generate-baseline
Il file generato phpstan-baseline.neon lo includa nella configurazione:
includes:
- phpstan-baseline.neon
parameters:
level: 6
paths:
- src
- tests
Così il retaggio rimane documentato in modo visibile, mentre il nuovo codice deve essere pulito fin dall'inizio.
Psalm e la taint analysis
Psalm persegue obiettivi simili a PHPStan. I livelli vanno al contrario: 1 è il più rigoroso, 8 il più indulgente, il predefinito è 2. Psalm richiede PHP dalla 8.2 e si configura così:
composer require --dev vimeo/psalm
./vendor/bin/psalm --init
./vendor/bin/psalm --taint-analysis
La taint analysis è particolarmente interessante per la sicurezza. «Taint» significa contaminazione: Psalm contrassegna i dati provenienti da fonti che un aggressore può controllare, come $_GET, $_POST, $_COOKIE, $_REQUEST o php://input. Poi verifica se questi dati arrivano senza protezione in punti pericolosi, i cosiddetti sink: output con echo, include, header o query SQL. Tra le categorie integrate figurano, tra le altre, sql, html, shell, include, eval, ssrf e unserialize.
<?php
// Psalm segnala un flusso da $_GET all'output HTML (categoria html)
echo 'Hallo ' . $_GET['name'];
// Corretto: neutralizzare l'output in modo adeguato al contesto
echo 'Hallo ' . htmlspecialchars($_GET['name'] ?? '', ENT_QUOTES, 'UTF-8');
La documentazione di Psalm indica apertamente i limiti: l'analisi presuppone che la neutralizzazione avvenga correttamente. Errori sottili, come le virgolette mancanti attorno a un attributo HTML, possono comunque lasciare delle falle. Psalm raccomanda perciò query parametrizzate per SQL e template consapevoli del contesto per HTML. I risultati si possono emettere nel formato SARIF, che tra l'altro GitHub Code Scanning comprende.
Analisi statica e sicurezza dopo PHP2Shell
Qui vale la pena di fare una distinzione onesta. PHP2Shell, cioè CVE-2026-109618 e CVE-2026-109619, si trova nell'interprete PHP. Nessuno strumento che legga il codice della Sua applicazione trova queste vulnerabilità, e nessuna modifica al codice le chiude. Questo lo ottiene solo l'aggiornamento a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35.
Ciononostante l'analisi statica contribuisce alla sicurezza, in tre punti:
- Capacità di upgrade: trova il codice che non gira più sulle nuove versioni di PHP. Si abbassa così la soglia per passare da 8.1 o 8.2 a una versione supportata.
- Vulnerabilità proprie: la taint analysis trova percorsi per SQL injection, cross-site scripting o inclusione di file. Il progetto PHP chiarisce nella propria politica di sicurezza che dati non controllati passati a funzioni come
mysqli_query()non sono un errore di PHP, ma rientrano nella responsabilità dell'applicazione. - Robustezza: molti errori fatali nascono da chiamate su null o da tipi errati. In relazione a CVE-2026-109619 php.net consiglia espressamente di correggere nell'applicazione gli errori fatali attivabili dall'esterno.
L'analisi statica non sostituisce una revisione del codice per la sicurezza da parte di persone, ma la rende più efficiente, perché gli errori di routine sono già stati eliminati.
Come aiuta concretamente PHP SOS?
Nell'ambito di audit di sicurezza e penetration test procediamo così:
- Configurare gli strumenti: PHPStan o Psalm con livello adeguato e baseline, integrati nella Sua pipeline esistente.
- Valutare i riscontri di sicurezza: verifichiamo i risultati della taint analysis e separiamo i rischi reali dai falsi allarmi.
- Preparare l'upgrade: mostriamo quali punti impediscono il passaggio a una versione di PHP supportata.
- Consegnare i risultati: riceve un elenco in ordine di priorità con i punti concreti del codice per il Suo team o la Sua agenzia.
Domande frequenti
Qual è la differenza tra PHPStan e Psalm?
Entrambi verificano i tipi e trovano errori senza eseguire il codice. PHPStan conta i suoi livelli da 0 (permissivo) a 10 (rigoroso), Psalm da 8 (permissivo) a 1 (rigoroso). Psalm include una taint analysis integrata per i problemi di sicurezza.
Posso introdurre PHPStan in un vecchio progetto?
Sì. Con una baseline PHPStan salva in un file tutte le segnalazioni esistenti e da quel momento segnala solo i nuovi errori. Così il team parte senza un'ondata di errori e smaltisce gradualmente il retaggio del passato.
L'analisi statica trova PHP2Shell?
No. PHP2Shell si trova nell'interprete PHP, non nel Suo codice. Contro di esso aiuta solo l'aggiornamento di PHP. L'analisi statica aiuta però a preparare il codice alle nuove versioni di PHP, così che l'aggiornamento sia possibile più rapidamente.
Quale livello conviene scegliere?
Per iniziare un livello basso senza baseline oppure un livello più alto con baseline. Più importante del numero è che l'analisi giri automaticamente a ogni modifica e non lasci passare nuovi errori.