Composer: il gestore di pacchetti per PHP

In breve: Composer è il gestore di pacchetti per PHP. Legge dal file composer.json quali librerie servono a un progetto, le scarica nella cartella vendor, registra le versioni esatte in composer.lock e genera un autoloader che trova automaticamente le classi. Composer gestisce dunque il codice della Sua applicazione, non l'interprete PHP stesso: un aggiornamento di Composer non chiude alcuna vulnerabilità di PHP come PHP2Shell.

Che cos'è Composer e a che cosa serve?

Oggi quasi nessuna applicazione PHP è fatta solo di codice proprio. Framework, librerie per la posta, generazione di PDF o collegamenti ai pagamenti arrivano come pacchetti già pronti. Composer, il gestore di pacchetti per PHP, fa sì che questi pacchetti si combinino in versioni adatte e che ogni dipendenza porti con sé le proprie dipendenze.

Per chi decide significa: gran parte del codice che gira sul Suo server proviene da terzi. È efficiente, ma richiede manutenzione. Per amministratori e sviluppatori significa: chi usa Composer in modo pulito può sempre ricostruire quale versione di quale libreria giri in produzione.

La fonte standard dei pacchetti è, secondo la documentazione di Composer, Packagist.org. Altre fonti, ad esempio repository interni di un'agenzia, si possono inserire nel composer.json sotto repositories.

composer.json, composer.lock e vendor: i tre componenti

Composer lavora con tre elementi che conviene conoscere prima di rilevare un server o di incaricare un'agenzia.

Sotto require stanno i pacchetti di cui l'applicazione ha bisogno in esercizio. Sotto require-dev stanno gli strumenti per sviluppo e test, ad esempio framework di test o analisi statica. Questa separazione è importante perché gli strumenti di sviluppo non hanno nulla da fare su un server di produzione.

{
    "require": {
        "php": ">=8.3",
        "monolog/monolog": "^3.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    },
    "autoload": {
        "psr-4": { "App\\": "src/" }
    }
}

Le indicazioni di versione nell'esempio sono scelte solo a scopo illustrativo. Quali versioni servano al Suo progetto dipende dai suoi requisiti.

install o update: la differenza in esercizio

I due comandi suonano simili, ma hanno conseguenze molto diverse.

• composer install legge composer.lock e installa esattamente le versioni lì registrate. È riproducibile e appartiene alla consegna.
• composer update risolve di nuovo tutte le dipendenze, recupera le versioni adatte più recenti e riscrive composer.lock. Appartiene allo sviluppo, con test successivi.

Secondo la documentazione di Composer, update esegue dopo aver scritto il file lock anche una verifica di sicurezza (audit), a meno che non venga disattivata con --no-audit. install per impostazione predefinita non la esegue; a questo scopo esiste l'opzione --audit.

Autoloading: come Composer trova le classi

Composer genera il file vendor/autoload.php. Una volta incluso, PHP carica ogni classe solo quando serve. Per il codice proprio nella sezione autoload si stabilisce quale namespace stia in quale cartella. Per questo si raccomanda PSR-4, uno standard del PHP-FIG. Come funziona esattamente lo spiega la pagina Namespace e autoloading; un quadro di tutti gli standard è nella pagina Standard PSR.

<?php
require __DIR__ . '/../vendor/autoload.php';

$log = new Monolog\Logger('app');   // viene caricata automaticamente quando serve

Composer in produzione: consegnare in modo pulito

Per la consegna si è affermato un ordine fisso. Funziona al meglio in una pipeline di build e non a mano sul server.

1. Verificare il file lock: composer validate assicura che composer.json sia valido e composer.lock aggiornato.
2. Installare senza pacchetti di sviluppo: composer install --no-dev omette require-dev.
3. Ottimizzare l'autoloader: --optimize-autoloader (in breve -o) trasforma le regole in un elenco di classi. Con --classmap-authoritative PHP carica le classi esclusivamente da questo elenco.
4. Verifica di sicurezza: composer audit --locked controlla le versioni del file lock rispetto alle segnalazioni di sicurezza note e segnala i pacchetti abbandonati.
5. vendor fuori dal webroot: solo la cartella pubblica con lo script di ingresso dovrebbe essere raggiungibile via URL.

composer validate
composer install --no-dev --optimize-autoloader
composer audit --locked --no-dev

composer outdated mostra inoltre quali pacchetti installati hanno versioni più recenti. È la base per aggiornamenti pianificati invece di azioni singole e frettolose.

Composer, sicurezza e PHP2Shell

Composer e PHP2Shell riguardano due livelli diversi. Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 si trovano nell'interprete PHP stesso. Sono corrette in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, e dopo tutti i processi PHP vanno riavviati. Nessun composer update e nessun pacchetto in vendor cambia nulla in proposito.

Ciononostante Composer rientra in ogni verifica dopo un incidente. Chi porta codice dannoso su un server può anche modificare file in vendor, e vendor/autoload.php viene caricato a ogni richiesta. Un composer install pulito dal file lock verificato in una directory vuota è perciò un buon metodo per ripristinare l'insieme dei pacchetti. Come controllare regolarmente le dipendenze alla ricerca di vulnerabilità note lo descrive la guida composer audit.

Come aiuta concretamente PHP SOS?

• Rileviamo per ogni applicazione versione di PHP, pacchetti Composer e stato del file lock, separando nettamente interprete e librerie.
• Verifichiamo se vendor e file lock corrispondono e se in produzione si trovano pacchetti di sviluppo o file modificati.
• Impostiamo una consegna riproducibile con install --no-dev, autoloader ottimizzato e audit.
• Dopo un incidente ripristiniamo l'insieme dei pacchetti dal file lock verificato e documentiamo il risultato.

Domande frequenti

Fonti

• Composer: Basic usage
• Composer: Command-line interface
• Composer: The composer.json schema