In breve: composer audit confronta i pacchetti del Suo progetto PHP con i bollettini di sicurezza noti e mostra le versioni interessate. Esegua il comando a ogni build e regolarmente sullo stato di produzione. Importante dopo PHP2Shell: il controllo riguarda le librerie, non l'interprete PHP stesso.
Perché le dipendenze richiedono attenzione proprio adesso
Le moderne applicazioni PHP sono composte in gran parte da codice altrui. Uno shop basato su Symfony o un portale con Laravel porta con sé rapidamente da qualche decina a centinaia di pacchetti, molti dei quali indirettamente tramite altri pacchetti. Ognuna di queste librerie può contenere una vulnerabilità. La OWASP Top 10 elenca perciò i componenti obsoleti e vulnerabili come categoria di rischio a sé.
A ottobre 2026 PHP2Shell ha mostrato con quale rapidità una vulnerabilità critica si diffonda. Le due vulnerabilità CVE-2026-109618 e CVE-2026-109619 riguardano PHP stesso e non i pacchetti Composer. In quei giorni molti team hanno però controllato l'intera catena e hanno scoperto di non conoscere con precisione lo stato delle proprie dipendenze.
Questa lacuna nel quadro d'insieme si colma con poco sforzo. Composer include già lo strumento adatto nelle versioni attuali.
Che cosa controlla composer audit e che cosa no
Il comando legge i pacchetti installati o il file lock e interroga i bollettini di sicurezza noti per questi pacchetti. Per ogni riscontro mostra pacchetto, intervallo di versioni interessato, livello di gravità, identificativo del bollettino e un link alla descrizione.
| Livello | Controllato da composer audit? | Come controllare altrimenti |
|---|---|---|
| Pacchetti Composer nel progetto | sì | composer audit |
| Interprete PHP (ad es. PHP2Shell) | no | stato dei pacchetti, conferma dell'hoster |
| Estensioni PHP del sistema | no | gestione pacchetti della distribuzione |
| Pacchetti JavaScript nel frontend | no | strumento del rispettivo gestore di pacchetti |
| Codice applicativo proprio | no | code review, audit di sicurezza |
Il comando considera anche le dipendenze indirette, cioè pacchetti che non ha mai richiesto direttamente ma che arrivano tramite altri pacchetti. Proprio lì le vulnerabilità restano spesso inosservate, perché nessuno nel team conosce quei pacchetti. Le versioni più recenti di Composer segnalano inoltre i pacchetti che i loro autori hanno contrassegnato come abbandonati. Tali pacchetti di norma non ricevono più correzioni e vanno sostituiti.
Un risultato pulito significa quindi solo che per le versioni dei pacchetti installate non esiste alcun bollettino noto. Vulnerabilità sconosciute ed errori nel codice proprio non vengono trovati dallo strumento. Come verificare direttamente lo stato di PHP è descritto nell'articolo Verificare correttamente la versione di PHP e lo stato delle patch.
Eseguire composer audit e leggere i risultati
Nella directory del progetto basta un comando. Le varianti si distinguono per ciò che viene controllato e per come viene emesso il risultato.
# Controllare i pacchetti installati
composer audit
# Controllare solo il file lock, ad es. nel build senza pacchetti installati
composer audit --locked
# Escludere le dipendenze di sviluppo (stato come sul server)
composer audit --no-dev
# Output leggibile da macchina per analisi o sistema di ticket
composer audit --format=json > audit-$(date +%F).json
Se il comando trova vulnerabilità, termina con un codice di errore. È voluto, perché così un build automatizzato si interrompe. Valuti ogni riscontro: il pacchetto è in uso sul server, la funzione interessata viene utilizzata, esiste una versione corretta?
# Quali dipendenze dirette sono obsolete?
composer outdated --direct
# Perché è installato un determinato pacchetto?
composer why vendor/paket
# Aggiornare in modo mirato, con le dipendenze
composer update vendor/paket --with-dependencies
Provi ogni aggiornamento in un ambiente di staging. Gli aggiornamenti di sicurezza all'interno della stessa versione principale sono di solito poco critici, mentre una nuova versione principale può richiedere adattamenti del codice.
Automatizzare il controllo
Una chiamata singola serve a poco, perché nuove vulnerabilità diventano note di continuo. Integri quindi composer audit in due punti: nella pipeline di build a ogni modifica e in un controllo regolare dello stato di produzione, anche se il codice non cambia.
Un semplice script per un'esecuzione giornaliera sul server di build o di controllo può apparire così:
#!/bin/sh
# Audit giornaliero dello stato rilasciato (adattare il percorso)
cd /srv/build/meine-anwendung || exit 1
if ! composer audit --locked --no-dev --format=plain > /var/log/composer-audit.log 2>&1; then
logger -t composer-audit "Lücken in meine-anwendung gefunden, siehe /var/log/composer-audit.log"
fi
Inoltri la segnalazione dal log di sistema al Suo monitoraggio, alla Sua casella interna o al Suo sistema di ticket. È importante che qualcuno sia responsabile della valutazione delle segnalazioni. Un audit i cui avvisi nessuno legge non protegge.
Definisca in composer.json, sotto config.platform.php, la versione di PHP che gira sul server. Composer risolve allora solo pacchetti adatti a quello stato e composer check-platform-reqs mostra le differenze.
Rilasciare in modo pulito: deployment senza effetti collaterali
Anche il percorso verso il server influisce sulla sicurezza. Alcune regole di base si sono dimostrate valide:
- Includere
composer.locknel repository e sul server eseguire solocomposer install, maicomposer update. - Installare con
--no-dev, in modo che strumenti di test e debug non finiscano sul server di produzione. - Tenere la cartella
vendor/fuori dalla directory radice web, così che non sia raggiungibile direttamente tramite un URL. - Eseguire
composer validatenel build per riconoscere presto indicazioni errate o contraddittorie.
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
Faccia inoltre attenzione al supporto della versione di PHP stessa. Le librerie richiedono sempre più spesso rami PHP attuali. Chi è ancora fermo a PHP 8.1 o precedenti non riceve più aggiornamenti ufficiali per PHP stesso e spesso non può più installare le versioni più recenti dei pacchetti con correzioni di sicurezza. La pianificazione al riguardo è descritta nella guida Fine del supporto di PHP: rischi delle versioni obsolete. Indicazioni specifiche per i framework si trovano in Mettere in sicurezza le applicazioni Laravel.
Come aiuta concretamente PHP SOS?
- Rileviamo lo stato di tutte le dipendenze e valutiamo i riscontri in base all'uso effettivo.
- Impostiamo controlli automatizzati nel build e in esercizio, con responsabilità chiare per i risultati.
- Pianifichiamo e testiamo gli aggiornamenti, anche quando nuove versioni principali richiedono adattamenti.
- Su richiesta verifichiamo anche il codice proprio e la configurazione, dove nessuno strumento automatico guarda.
Una verifica da parte di terzi è descritta nel servizio Audit di sicurezza e penetration test.
Domande frequenti
composer audit trova anche PHP2Shell?
No. composer audit controlla i pacchetti del Suo progetto, non l'interprete PHP sul server. PHP2Shell si trova in PHP stesso e si risolve solo con un aggiornamento di PHP e il riavvio di tutti i processi PHP.
composer.lock deve stare nel repository?
Per le applicazioni sì. Il file lock registra quali versioni esatte sono installate. Solo così composer audit controlla lo stato che gira davvero sul server e ogni deployment installa le stesse versioni.
Che cosa fare se per un pacchetto interessato non esiste un aggiornamento?
Verifichi se il Suo progetto usa davvero la funzione interessata e documenti la valutazione. Se non esiste una correzione, si possono considerare un pacchetto sostitutivo, una patch propria o una protezione provvisoria a livello di server.
Ogni quanto dovrei eseguire composer audit?
A ogni build e inoltre regolarmente, ad esempio ogni giorno, anche senza modifiche al codice. Nuove vulnerabilità vengono segnalate di continuo e uno stato pulito ieri può essere interessato oggi.