# Composer: il gestore di pacchetti per PHP

> Composer spiegato: capire composer.json, composer.lock, vendor e autoloader, consegnare in produzione in modo pulito e mantenere le dipendenze in sicurezza.

Fonte: https://phpsos.de/it/php/composer/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**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.

| Componente | Contenuto | Va nel repository? |
|---|---|---|
| `composer.json` | pacchetti desiderati con intervalli di versione (`require`, `require-dev`), regole di autoload, impostazioni | sì |
| `composer.lock` | versioni risolte esattamente di tutti i pacchetti, anche indiretti | sì, secondo la documentazione di Composer espressamente |
| `vendor/` | codice scaricato dei pacchetti e autoloader generato | no, viene generato durante l'installazione |

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.

```json
{
    "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](https://phpsos.de/it/php/namespaces-autoloading/); un quadro di tutti gli standard è nella pagina [Standard PSR](https://phpsos.de/it/php/psr-standards/).

```php
<?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.

```bash
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](https://phpsos.de/it/ratgeber/composer-abhaengigkeiten-pruefen/).

> **Importante:**
> Un `composer audit` senza segnalazioni non dice nulla sullo stato di patch di PHP. Verifichi il runtime PHP separatamente, ad esempio con il nostro [servizio di patch PHP](https://phpsos.de/it/leistungen/php-patch-service/).

## 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

**Il file composer.lock deve andare nel repository Git?**  
Sì. La documentazione di Composer raccomanda espressamente di fare il commit di composer.lock. Solo così sviluppo, CI e produzione installano esattamente le stesse versioni dei pacchetti.

**Qual è la differenza tra composer install e composer update?**  
install installa le versioni registrate in composer.lock. update risolve di nuovo le dipendenze, recupera versioni più recenti adatte e riscrive composer.lock. Sul server di produzione va usato solo install.

**Un aggiornamento di Composer chiude la vulnerabilità PHP2Shell?**  
No. Composer gestisce le librerie della Sua applicazione, non l'interprete PHP. PHP2Shell si chiude solo con l'aggiornamento del runtime PHP a una versione corretta e il riavvio di tutti i processi PHP.

**Dove dovrebbe stare la cartella vendor?**  
Idealmente fuori dalla directory web raggiungibile pubblicamente. Molti framework mettono nel webroot solo una cartella public, mentre vendor sta un livello più in alto.

## Fonti

- [Composer: Basic usage](https://getcomposer.org/doc/01-basic-usage.md)
- [Composer: Command-line interface](https://getcomposer.org/doc/03-cli.md)
- [Composer: The composer.json schema](https://getcomposer.org/doc/04-schema.md)