# composer audit: kontrola závislostí na zraniteľnosti

> Pomocou composer audit skontrolujete závislosti PHP na zraniteľnosti. Príkazy, zapojenie do CI a deploymentu a prečo sa samotné PHP záplatuje osobitne.

Zdroj: https://phpsos.de/sk/ratgeber/composer-abhaengigkeiten-pruefen/  
Stav: 25.10.2026  
Poskytovateľ: PHP SOS, Núdzová pomoc pri PHP a bezpečnosť serverov. Okamžitá pomoc cez WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20de%C5%88%2C%20PHP%20SOS%2C%20potrebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20serverom%20s%20PHP.%20Spolo%C4%8Dnos%C5%A5%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**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.

| Úroveň | Kontroluje ju composer audit? | Ako kontrolovať namiesto toho |
|---|---|---|
| Balíky Composeru v projekte | áno | composer audit |
| Interpreter PHP (napr. PHP2Shell) | nie | Stav balíka, potvrdenie poskytovateľa hostingu |
| Rozšírenia PHP zo systému | nie | Správa balíkov distribúcie |
| Balíky JavaScriptu vo frontende | nie | Nástroj príslušného správcu balíkov |
| Vlastný kód aplikácie | nie | Code review, bezpečnostný audit |

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](https://phpsos.de/sk/php2shell/php-version-pruefen/).

## 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.

```bash
# 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?

```bash
# 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:

```bash
#!/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.

> **Tip:**
> V `composer.json` určte pod `config.platform.php` verziu PHP, ktorá beží na serveri. Composer potom rieši iba balíky, ktoré sa k tomuto stavu hodia, a `composer check-platform-reqs` ukáže odchýlky.

## Č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.

```bash
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í](https://phpsos.de/sk/ratgeber/php-end-of-life-risiken/). Pokyny špecifické pre framework nájdete na stránke [Zabezpečiť aplikácie Laravel](https://phpsos.de/sk/plattformen/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](https://phpsos.de/sk/leistungen/sicherheitsaudit-penetrationstest/).


## Časté otázky

**Nájde composer audit aj PHP2Shell?**  
Nie. composer audit kontroluje balíky vo vašom projekte, nie interpreter PHP na serveri. PHP2Shell sídli v samotnom PHP a odstráni sa iba aktualizáciou PHP a reštartom všetkých procesov PHP.

**Musí byť composer.lock v repozitári?**  
Pri aplikáciách áno. Súbor lock určuje, ktoré verzie sú presne nainštalované. Iba tak composer audit kontroluje stav, ktorý skutočne beží na serveri, a každé nasadenie nainštaluje tie isté verzie.

**Čo robiť, ak pre dotknutý balík neexistuje aktualizácia?**  
Preverte, či váš projekt dotknutú funkciu vôbec používa, a posúdenie zdokumentujte. Ak oprava neexistuje, prichádza do úvahy náhradný balík, vlastná záplata alebo dočasné zabezpečenie na úrovni servera.

**Ako často by som mal spúšťať composer audit?**  
Pri každom builde a navyše pravidelne, napríklad denne, aj bez zmeny kódu. Nové zraniteľnosti sa hlásia priebežne a stav, ktorý bol včera čistý, môže byť dnes dotknutý.

## Zdroje

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: bezpečnostné hlásenia](https://www.php.net/)
- [php.net: podporované verzie](https://www.php.net/supported-versions.php)
