composer audit: kontrola závislostí na zraniteľnosti

Stručne: composer audit porovnáva balíky vášho projektu PHP so známymi bezpečnostnými hláseniami a zobrazuje dotknuté verzie. Príkaz spúšťajte pri každom builde a pravidelne na produkčnom stave. Dôležité po PHP2Shell: kontrola zachytáva knižnice, nie samotný interpreter PHP.

Prečo závislosti potrebujú pozornosť práve teraz

Moderné aplikácie PHP sa vo väčšej časti skladajú z cudzieho kódu. E-shop postavený na Symfony alebo portál s Laravelom si rýchlo prinesie niekoľko desiatok až stovky balíkov, mnohé z nich nepriamo cez iné balíky. Každá z týchto knižníc môže obsahovať zraniteľnosť. OWASP Top 10 preto uvádza zastarané a zraniteľné komponenty ako samostatnú kategóriu rizika.

V októbri 2026 PHP2Shell ukázalo, ako rýchlo sa kritická zraniteľnosť rozšíri. Obe zraniteľnosti CVE-2026-109618 a CVE-2026-109619 sa síce týkajú samotného PHP a nie balíkov Composeru. Mnohé tímy však v týchto dňoch preverili celý svoj reťazec a zistili, že stav svojich závislostí vlastne presne nepoznajú.

Túto medzeru v prehľade možno zaplniť s malou námahou. Composer prináša vhodný nástroj už v aktuálnych verziách.

Čo composer audit kontroluje a čo nie

Príkaz číta nainštalované balíky alebo súbor lock a dopytuje známe bezpečnostné hlásenia k týmto balíkom. Pri každom náleze zobrazí balík, dotknutý rozsah verzií, stupeň závažnosti, identifikátor hlásenia a odkaz na popis.

Príkaz zohľadňuje aj nepriame závislosti, teda balíky, ktoré ste si nikdy sami nevyžiadali, ale prichádzajú spolu s inými balíkmi. Práve tam sa zraniteľnosti často skrývajú bez povšimnutia, pretože tieto balíky nikto v tíme nepozná. Novšie verzie Composeru upozorňujú aj na balíky, ktoré ich autori označili za opustené. Také balíky spravidla už nedostávajú opravy a mali by sa nahradiť.

Čistý výsledok teda znamená iba to, že pre nainštalované verzie balíkov neexistuje žiadne známe hlásenie. Neznáme zraniteľnosti a chyby vo vlastnom kóde nástroj nenájde. Ako stav PHP skontrolovať sami, popisuje príspevok Správne overiť verziu PHP a stav záplat.

Spustiť composer audit a čítať výsledky

V adresári projektu stačí jeden príkaz. Varianty sa líšia v tom, čo sa kontroluje a ako sa výsledok vypisuje.

# Skontrolovať nainštalované balíky
composer audit

# Skontrolovať iba súbor lock, napr. v builde bez nainštalovaných balíkov
composer audit --locked

# Vynechať vývojárske závislosti (stav ako na serveri)
composer audit --no-dev

# Strojovo čitateľný výstup pre vyhodnotenie alebo tiketový systém
composer audit --format=json > audit-$(date +%F).json

Ak príkaz nájde zraniteľnosti, skončí s chybovým kódom. To je zámer, pretože tak sa automatizovaný build preruší. Posúďte každý nález: je balík na serveri nasadený, používa sa dotknutá funkcia, existuje opravená verzia?

# Ktoré priame závislosti sú zastarané?
composer outdated --direct
# Prečo je nainštalovaný určitý balík?
composer why vendor/paket
# Cielene aktualizovať, so závislosťami
composer update vendor/paket --with-dependencies

Každú aktualizáciu otestujte v staging prostredí. Bezpečnostné aktualizácie v rámci tej istej hlavnej verzie sú zväčša nekritické, nová hlavná verzia môže naopak vyžadovať úpravy kódu.

Kontrolu zautomatizovať

Jednorazové spustenie pomôže málo, pretože nové zraniteľnosti sa stávajú známymi priebežne. composer audit preto zapojte na dvoch miestach: do build pipeline pri každej zmene a do pravidelnej kontroly produkčného stavu, aj keď sa na kóde nič nemení.

Jednoduchý skript pre denný beh na build serveri alebo kontrolnom serveri môže vyzerať takto:

#!/bin/sh
# Denný audit dodávaného stavu (cestu prispôsobiť)
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

Hlásenie zo systémového logu presmerujte do svojho monitoringu, internej schránky alebo tiketového systému. Dôležité je, aby bol niekto zodpovedný za posudzovanie hlásení. Audit, ktorého varovania nikto nečíta, nechráni.

Čisto dodať: deployment bez vedľajších účinkov

Aj cesta na server ovplyvňuje bezpečnosť. Osvedčilo sa niekoľko základných pravidiel:

• composer.lock pridať do repozitára a na serveri spúšťať iba composer install, nikdy composer update.
• Inštalovať s --no-dev, aby sa testovacie a ladiace nástroje nedostali na produkčný server.
• Adresár vendor/ držať mimo koreňového adresára webu, aby nebol dostupný priamo cez URL.
• V builde spúšťať composer validate, aby sa chybné alebo protichodné údaje odhalili včas.

composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction

Dbajte navyše na podporu samotnej verzie PHP. Knižnice čoraz častejšie vyžadujú aktuálne vetvy PHP. Kto ešte zostáva na PHP 8.1 alebo starších, nedostáva pre samotné PHP už žiadne oficiálne aktualizácie a novšie verzie balíkov s bezpečnostnými opravami často nemôže nainštalovať. Plánovanie k tomu popisuje príručka PHP End of Life: riziká zastaraných verzií. Pokyny špecifické pre framework nájdete na stránke Zabezpečiť aplikácie Laravel.

Ako konkrétne pomáha PHP SOS?

• Zmapujeme stav všetkých závislostí a nálezy posúdime podľa skutočného používania.
• Zriadime automatizované kontroly v builde aj v prevádzke s jasnou zodpovednosťou za nálezy.
• Aktualizácie plánujeme a testujeme, aj keď nové hlavné verzie vyžadujú úpravy.
• Na želanie preveríme aj vlastný kód a konfiguráciu tam, kam automatický nástroj nedohliadne.

Kontrolu treťou stranou popisuje služba Bezpečnostný audit a penetračný test.

Časté otázky

Zdroje

• OWASP Top 10
• OWASP Cheat Sheet Series
• php.net: bezpečnostné hlásenia
• php.net: podporované verzie