Supply chain PHP: scansione di 6.000+ advisory ogni notte

Le applicazioni PHP non muoiono di vecchiaia, muoiono di manutenzione mancata. In ogni progetto Composer non curato accadono tre cose in silenzio: nuove CVE vengono pubblicate sulle versioni effettivamente installate, autori smettono di mantenere librerie e marcano i pacchetti come abandoned, branch maggiori di framework escono dal security support. Dopo diciotto-ventiquattro mesi di immobilità, l'applicazione è formalmente funzionante ma esposta a vulnerabilità note e patchate da tempo nelle versioni nuove. Questo tool fa emergere quello stato in trenta secondi a partire dal solo manifest.

Cosa controlla l'audit, in concreto. Tre fonti distinte alimentano il triage. (1) Vulnerabilità note (CVE): l'API Packagist Security Advisory aggrega FriendsOfPHP/security-advisories e GitHub Advisory DB; OSV.dev (Open Source Vulnerabilities, gestito da Google) arricchisce ogni advisory con CVSS v3 vector e CWE ID. Coverage: 6.000+ advisory su 1.000+ pacchetti Composer. (2) End-of-life (EOL): endoflife.date pubblica i cicli release dei framework principali con data di fine security support. Pacchetti monitorati: PHP, Laravel (e illuminate/*), Symfony (e ogni symfony/*), Composer stesso, Guzzle, Twig, CakePHP, Drupal, GrumPHP. (3) Abandoned: il flag abandoned di Packagist viene letto per l'unione di tutti i pacchetti citati nelle advisory e dei top 2.000 pacchetti popolari, con cache TTL di 7 giorni. Risultato: 210+ pacchetti effettivamente abbandonati nel dataset.

Differenza fra audit del lock e audit del json. Il composer.lock contiene le versioni esatte risolte: il matcher fa lookup esatto contro l'intervallo affected dell'advisory (es. >=9.0.0,<9.5.6). Il composer.json contiene solo i constraint dichiarati (es. ^9.0): il matcher esegue intersezione fra il constraint utente e l'intervallo affected, segnalando se esiste almeno una versione installabile vulnerabile. Per audit rigorosi usa il lock. Il json è utile per stabilire se il vincolo permetterebbe di scaricare versioni vulnerabili anche con un nuovo composer install domani: lo flagga il triage, ma la verità è in produzione.

Il matcher di constraint è preciso. Non si limita al confronto major: implementa il caret ^X.Y.Z con la regola eccezione per major-zero (^0.5.0 = >=0.5.0 <0.6.0, ^0.0.5 = >=0.0.5 <0.0.6), il tilde ~X.Y, il wildcard X.Y.*, l'hyphen range 1.0 - 2.0, gli operatori >= <= > < =, l'OR || e l'AND comma-or-whitespace, le stability suffix -dev -alpha -beta -RC con priorità lessicografica. La normalizzazione è in DNF (disjunctive normal form) di intervalli e l'intersezione fra constraint è pairwise overlap: stessa semantica di composer/semver PHP, in JS vanilla, senza dipendenze.

Privacy operativa. Il composer.lock rivela la struttura completa di un progetto, le sue dipendenze transitive e gli eventuali pacchetti privati con riferimenti a repository VCS interni. Caricarlo su un servizio terzo per analisi preliminari non è una buona idea, anche con TLS: ogni servizio terzo è un vettore di leak per la mappa delle tue dipendenze. Qui non parte nessuna richiesta con i dati del manifest. Il dataset (16 shard advisory + 1 file EOL + 1 file abandoned) viene scaricato dal browser una sola volta al primo utilizzo e cachato in localStorage per le sessioni successive (invalidazione automatica via SHA-256 sui file pubblici). Audit, parsing e matching: tutto in locale.

Quando il triage statico è il livello giusto. Casi tipici. (a) Review preliminare di un progetto legacy senza accesso al filesystem: il cliente ti incolla il manifest in mail e vuole una valutazione in trenta secondi. (b) Pre-engagement audit per stimare lo sforzo di un eventuale incarico di adeguamento prima di firmare il preventivo. (c) Screen iniziale prima di un assessment cyber serio: definisci la lista dei high/critical da approfondire con esercizio di exploitability assessment, mappatura dei vettori applicabili, verifica della reachability dei codepath. (d) Self-check periodico per il proprietario dell'applicazione che vuole sapere se chi mantiene il codice sta facendo il suo lavoro.

Limite di scope. Il tool segnala CVE pubblicate, EOL noti, abbandoni dichiarati. Non sostituisce un Software Composition Analysis enterprise (Snyk, Mend, Sonatype): non controlla licenze, non genera SBOM CycloneDX, non analizza vulnerabilità di codice non-Composer (binari di sistema, script Node, container base image). Non sostituisce composer audit CLI integrato in pipeline. Non sostituisce un assessment manuale che valuti sfruttabilità reale dei vettori, presenza dei codepath nelle versioni, mitigazioni applicate a livello di hardening. È un triage e si propone come tale.

Il dataset è strutturato in tre componenti indipendenti, tutti pubblicati come file statici sotto /tools/resources/data/composer-audit/, ricompilati ogni notte da un job cron e versionati per SHA-256 nell'index.json.

Advisory (6.000+ in 1.000+ pacchetti). Sorgente primaria: Packagist Security Advisory API, che aggrega FriendsOfPHP/security-advisories (database YAML collaborativo) e i GitHub Security Advisories per pacchetti Composer. Sorgente di arricchimento: OSV.dev, dump Packagist completo, da cui estrarre per ogni advisory il CVSS v3 vector e gli identificatori CWE. Per ogni rilievo: id Packagist, cve, ghsa, severity dichiarata, CVSS, lista CWE, constraint affected (es. >=5.4.0,<5.4.50|>=6.0.0,<6.4.18|>=7.0.0,<7.1.11), data di reporting. Il payload viene shardato in 16 file per il primo nibble esadecimale di SHA-1 sul nome pacchetto: il browser carica solo i shard dei pacchetti effettivamente presenti nel manifest, non l'intero dataset.

End-of-life (9 prodotti, 133 cicli). Sorgente: endoflife.date via API /api/{product}.json. Per ogni ciclo: data di fine security support, flag LTS, latest patch release. Il client calcola lo status confrontando eol_date con today: eol se passato, soon-eol se entro 180 giorni, lts/current altrimenti. Pacchetti monitorati: PHP (vincolo del manifest), laravel/framework e tutti gli illuminate/*, symfony/symfony e ogni symfony/* standalone, composer/composer, guzzlehttp/guzzle, twig/twig, cakephp/cakephp, drupal/core, phpro/grumphp. Endoflife.date copre solo framework e tool con cicli pubblici: librerie singole come PHPUnit, Doctrine, Monolog, Flysystem, PHPStan, Carbon non hanno EOL pubblicato, sono coperte da CVE e abandoned.

Abandoned (210+ effettivamente abbandonati su 2.800 controllati). Strategia di copertura: union(A,B) dove A è l'insieme dei pacchetti citati nelle advisory (~1.000) e B è la lista dei top 2.000 pacchetti Packagist per popolarità. Per ogni nome: GET https://packagist.org/packages/{vendor}/{name}.json e lettura del campo abandoned (booleano true oppure stringa con il nome del sostituto suggerito). Cache su disco con TTL di 7 giorni per evitare re-fetch inutili a regime: a regime ogni esecuzione cron costa 30 secondi anziché i 4 minuti del primo bootstrap. Il client riceve solo i pacchetti effettivamente abandoned, non la lista completa dei controllati.

Atomicità delle pubblicazioni. Il job cron applica una scrittura atomica multifile: tutti i nuovi shard vengono scritti su file temporanei, rinominati uno per uno, e l'index.json con i nuovi SHA-256 è l'ultimo file rinominato. Se il processo muore a metà, i client continuano a leggere il dataset precedente tramite l'index.json non ancora aggiornato. Mai dataset parziale, mai mismatch fra index e shard. Se anche solo una delle tre fonti (Packagist, OSV, endoflife) fallisce, il job aborta senza pubblicare: meglio dataset vecchio di un giorno che dataset incompleto.

Punteggio aggregato 0-100. Calcolato come 100 - somma(severity_weights), dove i pesi sono: critical 30, high 15, medium 7, low 3, info 1. Lettura: 80-100 verde (postura supply chain ragionevole), 50-79 giallo (interventi pianificabili nelle prossime sprint), 0-49 rosso (debito tecnico significativo, alcuni interventi richiedono mitigazione immediata). Il punteggio non è una metrica di qualità del software in generale: misura solo la salute del manifest dal punto di vista di vulnerabilità, EOL e abbandono.

Severity dei finding. critical: vulnerabilità con CVSS >= 9.0 oppure severity Packagist critical, tipicamente RCE non autenticato, SQL injection diretta, deserializzazione insicura. high: CVSS 7.0-8.9 oppure severity high, oppure pacchetto EOL con CVE storica, oppure pacchetto abbandonato in produzione. medium: CVSS 4.0-6.9, vincolo PHP prossimo a EOL, dipendenze su dev branch. low: CVSS 1.0-3.9, vincolo PHP non specificato, repository non Packagist con type basso rischio (composer mirror, github). info: raccomandazioni operative (roave/security-advisories non installato, plugin Composer abilitati, repository VCS custom). Le finding sono ordinate dalla più grave alla meno grave dentro il blocco risultati.

Cosa fare in concreto, per priorità. (1) Per ogni critical: aggiornare immediatamente alla versione fixed indicata nel CVE record, oppure documentare per iscritto perché il vettore non è applicabile al codepath specifico (es. funzionalità non utilizzata, mitigazione applicata altrove). Non rimandare. (2) Per ogni high: pianificare upgrade entro la sprint corrente. Se il pacchetto è abbandonato, sostituire con il replacement suggerito o con un fork mantenuto. Se il framework è EOL, valutare il costo di upgrade alla branch corrente o LTS. (3) Per medium e low: backlog di hardening trimestrale, refactor incrementale del manifest verso vincoli stringenti (^X.Y minimo, mai *), rimozione di dipendenze su dev branch in favore di tag stabili. (4) Per info: aggiungere roave/security-advisories:dev-latest come dev dependency, eseguire composer audit in CI/CD, audit periodico dei plugin Composer abilitati con allow-plugins.

Format del finding CVE. Ogni rilievo CVE riporta versione installata, identificatori (CVE, GHSA), CVSS vector quando disponibile, lista CWE, constraint affected esatto. Il link nel campo Riferimenti punta a CVE Record (cve.org) o GitHub Advisory: lì trovi descrizione tecnica, exploit pubblici se documentati, versione fixed esatta, e il commit di patch upstream. Da girare al team con il messaggio operativo: aggiornare a versione fixed entro X giorni, oppure produrre un'analisi scritta della reachability del vettore nel codice applicativo.

Il tool consuma un dataset statico ricompilato giornalmente da shared/cron/build_composer_audit_db.php. Tre fonti distinte alimentano il triage:

• Advisory (Packagist Security API + OSV.dev): 6.000+ advisory su 1.000+ pacchetti Composer, arricchite con CVSS vector e CWE ID dal database OSV. Coverage indipendente dalla popolarità del pacchetto.
• EOL (endoflife.date): framework e tool con cicli release pubblici. Pacchetti monitorati: php, laravel/framework (e illuminate/*), symfony/symfony (e ogni symfony/*), composer/composer, guzzlehttp/guzzle, twig/twig, cakephp/cakephp, drupal/core, phpro/grumphp. Per ogni branch: data di fine security support, status (current / lts / soon-eol / eol).
• Abandoned (Packagist): campo abandoned letto da Packagist per l'unione di (a) tutti i pacchetti citati nelle advisory e (b) i top 2.000 pacchetti Composer per popolarità. ~2.800 pacchetti unici controllati per ciclo, cache TTL 7 giorni.

Librerie non coperte da EOL (PHPUnit, Doctrine, Monolog, Flysystem, PHPStan, Carbon, eccetera) restano comunque monitorate per CVE e abbandono: endoflife.date traccia solo framework/CMS, le librerie Composer non hanno cicli EOL pubblici equivalenti.