# Függőségek naprakészen tartása: Composer, npm és bővítmények

> Composer-csomagok, npm-modulok és CMS-bővítmények frissen tartása: karbantartási folyamat ritmussal, felelőssel, tesztekkel és terv javítás nélkül.

Forrás: https://phpsos.de/hu/blog/abhaengigkeiten-aktuell-halten/  
Á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:** Aki függőségeket akar frissíteni, annak három csomagvilágra kell folyamat: Composer-csomagokra a PHP-kódban, npm-modulokra a frontend-buildben, valamint bővítményekre vagy témákra a CMS-ben. Ide tartozik egy rögzített ritmus, egy felelős személy, tesztek a kitelepítés előtt és egy terv a frissítés nélküli csomagokra. A PHP2Shell ellen ez nem segít, mert az a rés magában a PHP-ban van, de segít az idegen kód sok rése ellen.

## Három csomagvilág, egy vakfolt

A 2026. október 21. utáni héten minden a PHP-értelmező körül forgott. Sok csapat eközben észrevette, hogy nem ismeri pontosan a saját építőelemeinek verzióit. A weboldal fut, az ügynökség foglalkozik vele, a bővítmény jelentkezik, ha van valami új: így vagy hasonlóan szólnak a feltevések, amíg valaki utána nem néz.

Egy tipikus PHP-projekt ma lényegesen több idegen, mint saját kódból áll. Az OWASP Top 10 a sebezhető és elavult komponenseket külön kockázati kategóriaként vezeti. A probléma ritkán a hiányzó eszköz, hanem a hiányzó rutin: a frissítések akkor történnek meg, ha valakinek van ideje, a biztonsági közlemények pedig egy olyan postafiókba kerülnek, amelyet senki sem olvas.

## Mely függőségeket frissíti hol

Minden csomagvilágnak saját eszközei és saját buktatói vannak. A következő áttekintés segít, hogy semmit se hagyjon ki.

| Csomagvilág | Állomány megjelenítése | Rések ellenőrzése | Tipikus buktató |
|---|---|---|---|
| Composer (PHP-könyvtárak) | `composer show` | `composer audit` | közvetett csomagok, amelyeket senki sem ismer |
| npm (frontend-build) | `npm ls` | `npm audit` | egy újraépítés nélküli frissítés sosem ér el a szerverre |
| CMS-bővítmények és témák | admin felület vagy CLI | gyártói tájékoztatók, biztonsági szolgáltatások | felhagyott bővítmények, frissítési csatorna nélküli fizetős bővítmények |
| PHP és bővítményei | csomagkezelő | a disztribúció security trackere | a megjelenített verzió keveset mond a backportokról |

Az utolsó sor szigorúan véve nem tartozik az alkalmazás függőségei közé, de gyakran ugyanabban a pillanatban elfelejtik. Ugyanez érvényes az idegen szerverekről közvetlenül beágyazott szkriptekre, például CDN-ből származó könyvtárakra, chat-widgetekre vagy követőkódra. Egyetlen lock-fájlban sem szerepelnek, de a látogatói böngészőjében futnak. Vegye fel őket a listára, és ellenőrizze, hogy rögzített verziókat ágyaztak-e be a „mindig a legújabb” helyett. A `composer audit`, a lock-fájl és a buildbe illesztés részleteit a [Composer-függőségek ellenőrzése résekre](https://phpsos.de/hu/ratgeber/composer-abhaengigkeiten-pruefen/) útmutató tartalmazza. Hogy a Composer alapvetően hogyan működik, azt a [Composer: a PHP csomagkezelője](https://phpsos.de/hu/php/composer/) magyarázza el.

## A karbantartási ciklus hat lépésben

Egy teherbíró folyamatnak nem kell bonyolultnak lennie. Ez a sorrend vált be:

1. **Az állomány rögzítése:** minden projekthez a közvetlen függőségek listája verzióval, eredettel és céllal. A lock-fájlok (`composer.lock`, `package-lock.json`) a repositoryba tartoznak.
2. **A közlemények gyűjtése:** az ellenőrző eszközök minden buildnél lefutnak, és ezenkívül rendszeresen a kiszolgált állapoton is, kódmódosítás nélkül is.
3. **Értékelés:** használják-e az érintett csomagot éles üzemben, elérhető-e az érintett funkció, van-e javított verzió?
4. **Frissítés és tesztelés stagingben:** először a biztonsági frissítések ugyanazon főverzión belül, az új főverziókra való ugrásokat külön vállalkozásként tervezni.
5. **Kitelepítés visszaúttal:** az előző állapot csomagként vagy release-ként elérhető marad, adatbázis-mentés a frissítés előtt.
6. **Dokumentálás:** mit frissítettek mikor, mit nem tudatosan, és miért.

Ügyeljen közben a `composer.json` és a `package.json` verziómegadásaira. A túl szűk megadások megakadályozzák, hogy a biztonsági javítások egyáltalán telepíthetők legyenek. A túl tág megadások viszont ellenőrizetlenül hoznak új főverziókat a projektbe. Az vált be, ha engedélyezi a frissítéseket a főverzión belül, a következőre való ugrást pedig tudatosan tervezi.

A CMS-bővítményeknél a rendelkezésre álló frissítések gyakran a parancssorban is megjeleníthetők, a WordPressnél például a WP-CLI-vel:

```bash
# Elérhető frissítések megjelenítése, bármit is módosítva
wp plugin list --update=available
wp theme list --update=available
# Frontend-csomagok: elavult verziók és ismert rések
npm outdated
npm audit --omit=dev
```

> **Fontos:**
> Az automatikus bővítményfrissítések közvetlenül az éles rendszeren kényelmesek, de kockázatosak, ha utána senki sem ellenőriz. Csak akkor kapcsolja be őket, ha minden futás előtt mentés, utána pedig ellenőrzés biztosított.

## Ha nincs frissítés

Nem minden közleményt lehet egy kattintással megoldani. A sebezhető függőségek kezeléséről szóló OWASP Cheat Sheet több esetet különböztet meg, amelyek jól átvihetők a mindennapokra:

- **Elérhető javítás:** stagingben telepíteni, tesztelni, kitelepíteni. Ha valami elromlik, a saját kódot kell igazítani ahelyett, hogy a frissítés heverne.
- **Bejelentett, de még nem elérhető javítás:** a gyártó kerülőmegoldását megvalósítani, az érintett funkciót ha lehet kikapcsolni vagy elzárni, a döntést rögzíteni.
- **Nem várható javítás:** helyettesítő csomagot keresni, vagy a javítást magunk visszaportolni, olyan teszttel, amely megkülönbözteti a rést a javítás előtt és után.

A CMS-bővítményeknél gyakori a negyedik eset: a bővítményt felhagyták. Ilyenkor csak a csere vagy az eltávolítás segít. Ugyanez érvényes a tisztázatlan forrásból származó bővítményekre, például a fizetős bővítmények „ingyenes” másolataira. Ezek nem kapnak frissítést a hivatalos csatornán, és nem ritkán maguk is kártékony kódot tartalmaznak. A WordPress-üzemeltetők számára a tudnivalókat a [WordPress és a PHP2Shell](https://phpsos.de/hu/plattformen/wordpress/) foglalja össze.

## Felelősség tisztázása, mielőtt jön a következő közlemény

Az elavult csomagok leggyakoribb oka nem technikai akadály, hanem egy nyitott kérdés: ki csinálja? Az olyan projekteknél, amelyeket egy ügynökség épített, és belül üzemeltetnek, gyakran senki sem érzi magát felelősnek. Minden projektre határozza meg, ki kapja a közleményeket, ki értékel és ki hagy jóvá, és írja le.

Tervezzen ezenkívül időt. Egy havi rögzített karbantartási időpont, amelyen a függőségeket ellenőrzik és frissítik, megakadályozza, hogy a frissítések évekig felgyűljenek. Minél hosszabb ideje nem frissítettek egy projektet, annál nagyobb és kockázatosabb a következő ugrás. Hogyan illeszkednek a PHP és a csomagok frissítései egy átfogó folyamatba, azt a [Patchmenedzsment folyamatként, nem tűzoltásként](https://phpsos.de/hu/blog/patch-management-prozess/) írja le.

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

- Felmérjük a projektjei összes függőségét a Composerből, az npm-ből és a CMS-ből, és megjelöljük az elavult, sebezhető és felhagyott csomagokat.
- Automatikus ellenőrzéseket állítunk be, és meghatározzuk, ki melyik közleményt értékeli.
- Stagingben frissítünk, teszteljük a legfontosabb folyamatokat, és visszaúttal telepítünk.
- A [biztonsági karbantartási szerződés](https://phpsos.de/hu/leistungen/security-wartungsvertrag/) keretében tartósan átvesszük a havi ciklust, a PHP-frissítésekkel együtt.

**Összegzés:** A naprakész függőségek nem projekt, hanem rutin. Aki az állományt, a ritmust és a felelősséget egyszer rendesen szabályozza, a következő nagy közleménynél már csak ellenőriznie kell, nem keresgélnie.


## Gyakori kérdések

**Milyen gyakran kell frissíteni a függőségeket?**  
A biztonsági frissítéseket az értékelés után a lehető leghamarabb, a rutinfrissítéseket rögzített ritmusban, például havonta. A pontos gyakoriságnál fontosabb, hogy az időpont rögzített legyen, és legyen valaki felelős érte.

**Véd egy naprakész bővítmény a PHP2Shell ellen?**  
Nem. A PHP2Shell magában a PHP-értelmezőben van. Ez ellen csak a PHP-frissítés segít az összes PHP-folyamat újraindításával. A naprakész bővítmények és csomagok ettől még fontosak, mert saját réseket zárnak le.

**Mit kezdjek egy bővítménnyel, amelyet már nem gondoznak?**  
Cserélje le vagy távolítsa el. Egy felhagyott bővítmény nem kap több javítást, még ha ma még működik is. A csere előtt ellenőrizze, hogy a funkcióra valóban szükség van-e, és dokumentálja a döntést.

**A frontendet az npm-mel a szerveren is frissíteni kell?**  
Az npm-csomagok gyakran csak a buildben vannak, és kész fájlokként kerülnek a szerverre. Egy csomag hibája ettől még benne lehet a kiszolgált JavaScriptben. Egy frissítés után ezért újra kell építeni és újra kell kiszolgálni.

## Források

- [OWASP: Vulnerable Dependency Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [Composer](https://getcomposer.org/)
- [WordPress](https://wordpress.org/)