Pe scurt: composer audit compară pachetele proiectului dumneavoastră PHP cu anunțurile de securitate cunoscute și arată versiunile afectate. Rulați comanda la fiecare build și periodic pe starea de producție. Important după PHP2Shell: verificarea cuprinde bibliotecile, nu interpretorul PHP însuși.
De ce au nevoie dependențele de atenție tocmai acum
Aplicațiile PHP moderne constau în cea mai mare parte din cod străin. Un magazin pe baza Symfony sau un portal cu Laravel aduce repede câteva zeci până la sute de pachete, multe dintre ele indirect, prin alte pachete. Fiecare dintre aceste biblioteci poate conține o vulnerabilitate. OWASP Top 10 include de aceea componentele învechite și vulnerabile ca o categorie de risc separată.
În octombrie 2026, PHP2Shell a arătat cât de repede se extinde o vulnerabilitate critică. Cele două vulnerabilități CVE-2026-109618 și CVE-2026-109619 afectează PHP însuși, nu pachetele Composer. Multe echipe și-au verificat totuși în aceste zile întregul lanț și au constatat că nu cunosc deloc exact starea dependențelor lor.
Această lacună de vizibilitate se poate închide cu puțin efort. Composer aduce deja instrumentul potrivit în versiunile actuale.
Ce verifică composer audit și ce nu
Comanda citește pachetele instalate sau fișierul lock și interoghează anunțurile de securitate cunoscute pentru aceste pachete. Pentru fiecare rezultat arată pachetul, intervalul de versiuni afectat, gravitatea, identificatorul anunțului și un link către descriere.
| Nivel | Verificat de composer audit? | Cum se verifică altfel |
|---|---|---|
| Pachete Composer din proiect | da | composer audit |
| Interpretorul PHP (de ex. PHP2Shell) | nu | starea pachetelor, confirmarea furnizorului de hosting |
| Extensii PHP din sistem | nu | managerul de pachete al distribuției |
| Pachete JavaScript din frontend | nu | instrumentul managerului de pachete respectiv |
| Codul propriu al aplicației | nu | code review, audit de securitate |
Comanda ia în considerare și dependențele indirecte, deci pachetele pe care nu le-ați cerut niciodată, dar care vin odată cu alte pachete. Tocmai acolo se află adesea vulnerabilități neobservate, deoarece nimeni din echipă nu cunoaște aceste pachete. Versiunile mai noi ale Composer atrag atenția și asupra pachetelor marcate de autori ca abandonate. Asemenea pachete, de regulă, nu mai primesc corecturi și ar trebui înlocuite.
Un rezultat curat înseamnă deci doar că pentru versiunile instalate ale pachetelor nu există niciun anunț cunoscut. Vulnerabilitățile necunoscute și erorile din codul propriu nu le găsește instrumentul. Cum verificați singur starea PHP descrie articolul Cum verificați corect versiunea PHP și starea patchului.
Rularea composer audit și citirea rezultatelor
În directorul proiectului este suficientă o comandă. Variantele diferă prin ceea ce se verifică și prin modul în care este afișat rezultatul.
# Verificarea pachetelor instalate
composer audit
# Verificarea doar a fișierului lock, de ex. în build fără pachete instalate
composer audit --locked
# Omiterea dependențelor de dezvoltare (starea ca pe server)
composer audit --no-dev
# Ieșire citibilă de mașină pentru evaluare sau sistemul de tichete
composer audit --format=json > audit-$(date +%F).json
Dacă comanda găsește vulnerabilități, se încheie cu un cod de eroare. Este intenționat, deoarece astfel un build automatizat se oprește. Evaluați fiecare rezultat: este pachetul folosit pe server, se folosește funcția afectată, există o versiune corectată?
# Ce dependențe directe sunt învechite?
composer outdated --direct
# De ce este instalat un anumit pachet?
composer why vendor/paket
# Actualizare țintită, cu dependențe
composer update vendor/paket --with-dependencies
Testați fiecare actualizare într-un mediu de staging. Actualizările de securitate din cadrul aceleiași versiuni majore sunt de regulă necritice, în timp ce o versiune majoră nouă poate cere adaptări ale codului.
Automatizarea verificării
Un apel unic ajută puțin, deoarece vulnerabilități noi devin cunoscute continuu. Integrați de aceea composer audit în două locuri: în pipeline-ul de build, la fiecare modificare, și într-o verificare periodică a stării de producție, chiar dacă nu se schimbă nimic în cod.
Un script simplu pentru o rulare zilnică pe serverul de build sau de verificare poate arăta astfel:
#!/bin/sh
# Audit zilnic al stării livrate (adaptați calea)
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
Redirecționați mesajul din jurnalul de sistem către monitorizarea dumneavoastră, către căsuța internă sau către sistemul de tichete. Important este ca cineva să fie responsabil de evaluarea mesajelor. Un audit ale cărui avertismente nu le citește nimeni nu protejează.
Stabiliți în composer.json, sub config.platform.php, versiunea PHP care rulează pe server. Atunci Composer rezolvă doar pachete care se potrivesc acestei stări, iar composer check-platform-reqs arată abaterile.
Livrare curată: deployment fără efecte secundare
Și drumul spre server influențează securitatea. S-au dovedit utile câteva reguli de bază:
- Includeți
composer.lockîn depozit și rulați pe server doarcomposer install, niciodatăcomposer update. - Instalați cu
--no-dev, pentru ca instrumentele de test și de depanare să nu ajungă pe serverul de producție. - Păstrați dosarul
vendor/în afara rădăcinii web, astfel încât să nu fie accesibil direct printr-un URL. - Rulați
composer validateîn build, pentru a recunoaște din timp indicații greșite sau contradictorii.
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
Acordați atenție și suportului pentru versiunea PHP însăși. Bibliotecile presupun tot mai des ramuri PHP actuale. Cine mai rămâne pe PHP 8.1 sau mai vechi nu mai primește actualizări oficiale pentru PHP și adesea nu mai poate instala versiuni mai noi ale pachetelor cu corecturi de securitate. Planificarea în acest sens o descrie ghidul PHP End-of-Life: riscurile versiunilor învechite. Indicații specifice frameworkurilor găsiți la Cum securizați aplicațiile Laravel.
Cum ajută PHP SOS concret?
- Inventariem starea tuturor dependențelor și evaluăm rezultatele după utilizarea reală.
- Configurăm verificări automatizate în build și în funcționare, cu responsabilitate clară pentru constatări.
- Planificăm și testăm actualizările, chiar dacă versiunile majore noi cer adaptări.
- La cerere, verificăm și codul propriu și configurarea, acolo unde nu se uită niciun instrument automat.
O verificare de către terți o descrie serviciul Audit de securitate și test de penetrare.
Întrebări frecvente
Găsește composer audit și PHP2Shell?
Nu. composer audit verifică pachetele din proiectul dumneavoastră, nu interpretorul PHP de pe server. PHP2Shell se află în PHP însuși și se remediază doar printr-o actualizare PHP și o repornire a tuturor proceselor PHP.
Trebuie composer.lock să fie în depozit?
La aplicații, da. Fișierul lock stabilește exact ce versiuni sunt instalate. Doar așa composer audit verifică starea care rulează efectiv pe server, iar fiecare deployment instalează aceleași versiuni.
Ce fac dacă pentru un pachet afectat nu există actualizare?
Verificați dacă proiectul dumneavoastră folosește funcția afectată și documentați evaluarea. Dacă nu există remediere, vin în discuție un pachet de înlocuire, un patch propriu sau o securizare provizorie la nivel de server.
Cât de des ar trebui să rulez composer audit?
La fiecare build și, în plus, periodic, de exemplu zilnic, chiar și fără modificări de cod. Vulnerabilități noi sunt raportate continuu, iar o stare care a fost curată ieri poate fi afectată astăzi.