composer audit: kontrola závislostí na zranitelnosti

Stručně: composer audit porovnává balíčky vašeho projektu PHP se známými bezpečnostními hlášeními a ukazuje dotčené verze. Spouštějte příkaz při každém buildu a pravidelně také na produkčním stavu. Důležité po PHP2Shell: kontrola se týká knihoven, nikoli samotného interpretu PHP.

Proč závislosti potřebují pozornost právě teď

Moderní aplikace PHP se z největší části skládají z cizího kódu. E-shop postavený na Symfony nebo portál s Laravelem si snadno přinese několik desítek až stovek balíčků, mnohé z nich nepřímo přes jiné balíčky. Každá z těchto knihoven může obsahovat zranitelnost. OWASP Top 10 proto uvádí zastaralé a zranitelné komponenty jako samostatnou kategorii rizik.

V říjnu 2026 ukázalo PHP2Shell, jak rychle se kritická zranitelnost šíří do šířky. Obě zranitelnosti CVE-2026-109618 a CVE-2026-109619 sice postihují samotné PHP, nikoli balíčky Composeru. Mnoho týmů ale v těchto dnech přezkoumalo celý svůj řetězec a zjistilo, že stav svých závislostí vlastně přesně neznají.

Tuto mezeru v přehledu lze zacelit s malým úsilím. Composer v aktuálních verzích již potřebný nástroj obsahuje.

Co composer audit kontroluje a co ne

Příkaz čte nainstalované balíčky nebo soubor lock a dotazuje se na známá bezpečnostní hlášení k těmto balíčkům. U každého nálezu zobrazí balíček, dotčený rozsah verzí, závažnost, identifikátor hlášení a odkaz na popis.

Příkaz zohledňuje i nepřímé závislosti, tedy balíčky, které jste si nikdy sami nevyžádali, ale přicházejí s jinými balíčky. Právě tam zranitelnosti často zůstávají bez povšimnutí, protože tyto balíčky nikdo z týmu nezná. Novější verze Composeru navíc upozorňují na balíčky, které jejich autoři označili za opuštěné. Takové balíčky zpravidla už opravy nedostávají a měly by se nahradit.

Čistý výsledek tedy znamená jen to, že pro nainstalované verze balíčků není známo žádné hlášení. Neznámé zranitelnosti a chyby ve vlastním kódu nástroj nenajde. Jak ověřit stav PHP samotného, popisuje článek Jak správně ověřit verzi PHP a stav záplaty.

Spuštění composer audit a čtení výsledků

V adresáři projektu stačí jeden příkaz. Varianty se liší tím, co se kontroluje a jak se výsledek vypisuje.

# Zkontrolovat nainstalované balíčky
composer audit

# Zkontrolovat jen soubor lock, např. v buildu bez nainstalovaných balíčků
composer audit --locked

# Vynechat vývojové závislosti (stav jako na serveru)
composer audit --no-dev

# Strojově čitelný výstup pro vyhodnocení nebo tiketový systém
composer audit --format=json > audit-$(date +%F).json

Pokud příkaz zranitelnosti najde, skončí s chybovým kódem. To je záměr, protože tak se automatizovaný build přeruší. Vyhodnoťte každý nález: Je balíček na serveru nasazen, používá se dotčená funkce, existuje opravená verze?

# Které přímé závislosti jsou zastaralé?
composer outdated --direct
# Proč je určitý balíček nainstalován?
composer why vendor/paket
# Cíleně aktualizovat, se závislostmi
composer update vendor/paket --with-dependencies

Každou aktualizaci otestujte ve stagingovém prostředí. Bezpečnostní aktualizace v rámci stejné hlavní verze jsou většinou nekritické, nová hlavní verze naproti tomu může vyžadovat úpravy kódu.

Automatizace kontroly

Jednorázové spuštění mnoho nepomůže, protože nové zranitelnosti se stále objevují. Zapojte proto composer audit na dvou místech: do build pipeline při každé změně a do pravidelné kontroly produkčního stavu, i když se na kódu nic nemění.

Jednoduchý skript pro denní běh na build serveru nebo kontrolním serveru může vypadat takto:

#!/bin/sh
# Denní audit nasazeného stavu (upravte cestu)
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ášení ze systémového protokolu přeposílejte do svého monitoringu, interní schránky nebo tiketového systému. Důležité je, aby byl někdo odpovědný za vyhodnocení hlášení. Audit, jehož varování nikdo nečte, nechrání.

Čisté nasazení: deployment bez vedlejších účinků

I cesta na server ovlivňuje bezpečnost. Osvědčilo se několik základních pravidel:

• composer.lock zařadit do repozitáře a na serveru spouštět jen composer install, nikdy composer update.
• Instalovat s --no-dev, aby se testovací a ladicí nástroje nedostaly na produkční server.
• Adresář vendor/ držet mimo kořenový adresář webu, aby nebyl přímo dostupný přes URL.
• V buildu spouštět composer validate, aby se chybné nebo protichůdné údaje odhalily včas.

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

Věnujte pozornost také podpoře samotné verze PHP. Knihovny stále častěji vyžadují aktuální větve PHP. Kdo stále zůstává na PHP 8.1 nebo starším, nedostává pro samotné PHP už žádné oficiální aktualizace a novější verze balíčků s bezpečnostními opravami často nemůže nainstalovat. Plánování popisuje příručka PHP End-of-Life: rizika zastaralých verzí. Pokyny specifické pro framework najdete v článku Jak zabezpečit aplikace v Laravelu.

Jak konkrétně pomáhá PHP SOS?

• Zjistíme stav všech závislostí a nálezy vyhodnotíme podle skutečného využití.
• Zavedeme automatizované kontroly v buildu i provozu, s jasnou odpovědností za zjištění.
• Aktualizace plánujeme a testujeme, i když nové hlavní verze vyžadují úpravy.
• Na přání zkontrolujeme i vlastní kód a konfiguraci tam, kam automatický nástroj nedohlédne.

Kontrolu třetí stranou popisuje služba Bezpečnostní audit a penetrační test.

Časté dotazy

Zdroje

• OWASP Top 10
• OWASP Cheat Sheet Series
• php.net: bezpečnostní oznámení
• php.net: podporované verze