# composer audit: a függőségek ellenőrzése résekre

> A composer audit-tal PHP-függőségeit ellenőrizheti résekre. Parancsok, beépítés CI-be és deploymentbe, és miért kell magát a PHP-t külön javítani.

Forrás: https://phpsos.de/hu/ratgeber/composer-abhaengigkeiten-pruefen/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A `composer audit` összeveti a PHP-projektje csomagjait az ismert biztonsági közleményekkel, és megmutatja az érintett verziókat. Futtassa a parancsot minden buildnél és rendszeresen az éles állapoton. Fontos a PHP2Shell után: az ellenőrzés a könyvtárakat érinti, nem magát a PHP-értelmezőt.

## Miért kell a függőségekre éppen most figyelni

A modern PHP-alkalmazások nagyrészt idegen kódból állnak. Egy Symfonyra épülő webshop vagy egy Laravelt használó portál könnyen több tucat, akár több száz csomagot hoz magával, sokat közülük közvetve más csomagokon keresztül. Ezen könyvtárak bármelyike tartalmazhat rést. Az OWASP Top 10 ezért külön kockázati kategóriaként tartja számon az elavult és sebezhető összetevőket.

2026 októberében a PHP2Shell megmutatta, milyen gyorsan terjed széles körben egy kritikus rés. A CVE-2026-109618 és a CVE-2026-109619 rések ugyan magát a PHP-t érintik, nem a Composer-csomagokat. Sok csapat azonban ezekben a napokban a teljes láncát ellenőrizte, és megállapította, hogy a függőségeinek állapotát egyáltalán nem ismeri pontosan.

Ez az áttekintési hiány kevés ráfordítással pótolható. A Composer az aktuális verzióiban már magával hozza a megfelelő eszközt.

## Mit ellenőriz a composer audit, és mit nem

A parancs beolvassa a telepített csomagokat vagy a lock fájlt, és lekérdezi az ezekre a csomagokra vonatkozó ismert biztonsági közleményeket. Minden találatnál megmutatja a csomagot, az érintett verziótartományt, a súlyosságot, a közlemény azonosítóját és egy linket a leíráshoz.

| Szint | Ellenőrzi a composer audit? | Mivel ellenőrizze helyette |
|---|---|---|
| Composer-csomagok a projektben | igen | composer audit |
| PHP-értelmező (pl. PHP2Shell) | nem | csomagállapot, tárhelyszolgáltatói igazolás |
| PHP-bővítmények a rendszerből | nem | a disztribúció csomagkezelője |
| JavaScript-csomagok a frontendben | nem | az adott csomagkezelő eszköze |
| Saját alkalmazáskód | nem | kódellenőrzés, biztonsági audit |

A parancs a közvetett függőségeket is figyelembe veszi, vagyis azokat a csomagokat, amelyeket Ön soha nem kért, de más csomagokkal együtt jönnek. Éppen ott maradnak gyakran észrevétlenül a rések, mert a csapatban senki sem ismeri ezeket a csomagokat. Az újabb Composer-verziók ezen kívül jelzik azokat a csomagokat is, amelyeket a szerzőik elhagyottnak jelöltek. Az ilyen csomagok általában már nem kapnak javításokat, és le kell cserélni őket.

Egy tiszta eredmény tehát csak annyit jelent, hogy a telepített csomagverziókhoz nincs ismert közlemény. Az ismeretlen réseket és a saját kódban lévő hibákat az eszköz nem találja meg. Hogyan ellenőrizheti maga a PHP-állapotot, azt a [A PHP-verzió és a javítási állapot helyes ellenőrzése](https://phpsos.de/hu/php2shell/php-version-pruefen/) cikk írja le.

## A composer audit futtatása és az eredmények olvasása

A projektkönyvtárban egy parancs elég. A változatok abban különböznek, hogy mit ellenőriznek és hogyan adják ki az eredményt.

```bash
# Telepített csomagok ellenőrzése
composer audit

# Csak a lock fájl ellenőrzése, pl. a buildben telepített csomagok nélkül
composer audit --locked

# A fejlesztési függőségek kihagyása (állapot, mint a szerveren)
composer audit --no-dev

# Géppel olvasható kimenet kiértékeléshez vagy jegykezelő rendszerhez
composer audit --format=json > audit-$(date +%F).json
```

Ha a parancs réseket talál, hibakóddal fejeződik be. Ez szándékos, mert így megszakad egy automatizált build. Értékelje minden találatot: használatban van a csomag a szerveren, használják az érintett funkciót, van javított verzió?

```bash
# Mely közvetlen függőségek elavultak?
composer outdated --direct
# Miért van telepítve egy adott csomag?
composer why vendor/paket
# Célzott frissítés függőségekkel
composer update vendor/paket --with-dependencies
```

Minden frissítést teszteljen staging környezetben. Az ugyanazon főverzión belüli biztonsági frissítések többnyire problémamentesek, egy új főverzió ezzel szemben a kód módosítását igényelheti.

## Az ellenőrzés automatizálása

Egyszeri futtatás keveset segít, mert új réseket folyamatosan ismernek meg. Építse be a `composer audit`-ot ezért két helyre: a build-pipeline-ba minden módosításnál, és az éles állapot rendszeres ellenőrzésébe, akkor is, ha a kódon nem változik semmi.

Egy egyszerű szkript a build- vagy ellenőrző szerveren napi futtatáshoz így nézhet ki:

```bash
#!/bin/sh
# A kiszállított állapot napi auditja (az útvonalat igazítsa)
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
```

Irányítsa az üzenetet a rendszernaplóból a felügyeletébe, a belső postafiókjába vagy a jegykezelő rendszerébe. Fontos, hogy valaki felelős legyen az üzenetek értékeléséért. Egy audit, amelynek figyelmeztetéseit senki sem olvassa, nem véd.

> **Tipp:**
> Rögzítse a `composer.json`-ban a `config.platform.php` alatt a szerveren futó PHP-verziót. Ekkor a Composer csak olyan csomagokat old fel, amelyek ehhez az állapothoz illenek, és a `composer check-platform-reqs` megmutatja az eltéréseket.

## Tiszta kiszállítás: deployment mellékhatások nélkül

A szerverre vezető út is befolyásolja a biztonságot. Néhány alapszabály bevált:

- A `composer.lock`-ot vegye fel a tárolóba, és a szerveren csak `composer install`-t futtasson, soha nem `composer update`-et.
- `--no-dev` kapcsolóval telepítsen, hogy a teszt- és hibakereső eszközök ne kerüljenek az éles szerverre.
- A `vendor/` mappát tartsa a web gyökérkönyvtárán kívül, hogy közvetlenül URL-en keresztül ne legyen elérhető.
- Futtassa a `composer validate`-et a buildben, hogy a hibás vagy ellentmondó adatokat korán felismerje.

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

Ügyeljen magának a PHP-verziónak a támogatására is. A könyvtárak egyre inkább aktuális PHP-ágakat követelnek meg. Aki még PHP 8.1-en vagy régebbin ragadt, magához a PHP-hoz már nem kap hivatalos frissítéseket, és az újabb, biztonsági javításokat tartalmazó csomagverziókat gyakran már nem tudja telepíteni. Ennek tervezését a [PHP End of Life: az elavult verziók kockázatai](https://phpsos.de/hu/ratgeber/php-end-of-life-risiken/) útmutató írja le. Keretrendszer-specifikus tudnivalókat a [Laravel-alkalmazások védelme](https://phpsos.de/hu/plattformen/laravel/) oldalon talál.

## Hogyan segít konkrétan a PHP SOS?

- Felmérjük az összes függőség állapotát, és a találatokat a tényleges használat szerint értékeljük.
- Automatizált ellenőrzéseket állítunk be a buildben és az üzemben, a megállapítások egyértelmű felelősségével.
- Megtervezzük és teszteljük a frissítéseket, akkor is, ha az új főverziók módosításokat igényelnek.
- Kívánságra a saját kódot és a konfigurációt is ellenőrizzük, ahová egyetlen automatikus eszköz sem lát be.

Egy harmadik fél által végzett ellenőrzést a [Biztonsági audit és penetrációs teszt](https://phpsos.de/hu/leistungen/sicherheitsaudit-penetrationstest/) szolgáltatás ír le.


## Gyakori kérdések

**Megtalálja a composer audit a PHP2Shellt is?**  
Nem. A composer audit a projektjében lévő csomagokat ellenőrzi, nem a szerveren lévő PHP-értelmezőt. A PHP2Shell magában a PHP-ban van, és csak a PHP frissítésével és az összes PHP-folyamat újraindításával háríthatók el.

**Kell a composer.lock a tárolóba?**  
Alkalmazásoknál igen. A lock fájl rögzíti, pontosan mely verziók vannak telepítve. Csak így ellenőrzi a composer audit a ténylegesen a szerveren futó állapotot, és minden deployment ugyanazokat a verziókat telepíti.

**Mit tegyek, ha egy érintett csomaghoz nincs frissítés?**  
Ellenőrizze, hogy a projektje egyáltalán használja-e az érintett funkciót, és dokumentálja az értékelést. Ha nincs javítás, szóba jön egy helyettesítő csomag, egy saját patch vagy átmeneti védelem a szerver szintjén.

**Milyen gyakran futtassam a composer audit-ot?**  
Minden buildnél, és ezen felül rendszeresen, például naponta, kódmódosítás nélkül is. Új réseket folyamatosan jelentenek, és egy tegnap még tiszta állapot ma már érintett lehet.

## Források

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [php.net: támogatott verziók](https://www.php.net/supported-versions.php)