# Aktualne odvisnosti: Composer, npm in vtičniki

> Paketi Composer, moduli npm in vtičniki CMS naj ostanejo aktualni: vzdrževalni postopek z ritmom, odgovornostjo, preizkusi in načrtom za primere brez popravka.

Vir: https://phpsos.de/sl/blog/abhaengigkeiten-aktuell-halten/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Kdor želi posodabljati odvisnosti, potrebuje postopek za tri svetove paketov: pakete Composer v kodi PHP, module npm v gradnji frontenda ter vtičnike ali teme v CMS. K temu sodijo stalen ritem, odgovorna oseba, preizkusi pred uvedbo in načrt za pakete brez posodobitve. Proti PHP2Shell to ne pomaga, ker je ta ranljivost v samem PHP, pomaga pa proti številnim ranljivostim v tuji kodi.

## Trije svetovi paketov, ena slepa pega

V tednu po 21. 10. 2026 se je vse vrtelo okoli interpreterja PHP. Mnoge ekipe so pri tem ugotovile, da ne poznajo natančno različic lastnih gradnikov. Spletna stran teče, agencija skrbi zanjo, vtičnik se že oglasi, ko je kaj novega: tako ali podobno se glasijo predpostavke, dokler nekdo ne pogleda.

Tipičen projekt PHP danes sestoji iz bistveno več tuje kot lastne kode. OWASP Top 10 ranljive in zastarele komponente navaja kot samostojno kategorijo tveganja. Težava redko tiči v manjkajočem orodju, ampak v manjkajoči rutini: posodobitve se zgodijo, ko ima nekdo čas, varnostna obvestila pa pristanejo v nabiralniku, ki ga nihče ne bere.

## Katere odvisnosti kje posodabljate?

Vsak svet paketov ima lastna orodja in lastne pasti. Naslednji pregled pomaga, da nič ne spregledate.

| Svet paketov | Prikaz stanja | Preverjanje ranljivosti | Tipična past |
|---|---|---|---|
| Composer (knjižnice PHP) | `composer show` | `composer audit` | posredni paketi, ki jih nihče ne pozna |
| npm (gradnja frontenda) | `npm ls` | `npm audit` | posodobitev brez nove gradnje nikoli ne pride na strežnik |
| Vtičniki in teme CMS | skrbniški vmesnik ali CLI | napotki proizvajalca, varnostne storitve | opuščeni vtičniki, plačljivi vtičniki brez kanala za posodobitve |
| PHP in razširitve | upravljanje paketov | varnostni sledilnik distribucije | prikazana različica pove malo o backportih |

Zadnja vrstica strogo vzeto ne sodi med odvisnosti aplikacije, a se pogosto pozabi v istem zamahu. Enako velja za skripte, ki se vključujejo neposredno s tujih strežnikov, na primer knjižnice iz CDN, klepetalni gradniki ali koda za sledenje. V nobeni datoteki lock jih ni, a tečejo v brskalniku vaših obiskovalcev. Vključite jih na seznam in preverite, ali so vključene stalne različice namesto „vedno najnovejše“. Podrobnosti o `composer audit`, datoteki lock in vključitvi v gradnjo so v vodniku [Preverjanje odvisnosti Composer glede ranljivosti](https://phpsos.de/sl/ratgeber/composer-abhaengigkeiten-pruefen/). Kako Composer načeloma deluje, pojasnjuje [Composer: upravitelj paketov za PHP](https://phpsos.de/sl/php/composer/).

## Vzdrževalni cikel v šestih korakih

Trdnemu postopku ni treba biti zapleten. Obnesel se je ta vrstni red:

1. **Zabeležite stanje:** za vsak projekt seznam neposrednih odvisnosti z različico, izvorom in namenom. Datoteke lock (`composer.lock`, `package-lock.json`) sodijo v repozitorij.
2. **Zbirajte obvestila:** orodja za preverjanje tečejo ob vsaki gradnji in dodatno redno na dostavljenem stanju, tudi brez spremembe kode.
3. **Ocenite:** ali se prizadeti paket uporablja v produkcijskem delovanju, ali je prizadeta funkcija dosegljiva, ali obstaja odpravljena različica?
4. **Posodobite in preizkusite v stagingu:** najprej varnostne posodobitve znotraj iste glavne različice, skoke na nove glavne različice načrtujte kot samostojen projekt.
5. **Uvedite s potjo nazaj:** prejšnje stanje ostane na voljo kot paket ali izdaja, varnostna kopija baze podatkov pred posodobitvijo.
6. **Dokumentirajte:** kaj je bilo kdaj posodobljeno, kaj zavestno ne in zakaj.

Pri tem pazite na navedbe različic v `composer.json` in `package.json`. Preozke zahteve preprečijo, da bi se varnostni popravki sploh lahko namestili. Preširoke zahteve pa v projekt nepreverjeno prinesejo nove glavne različice. Obneslo se je, da se posodobitve znotraj glavne različice dovolijo, skok na naslednjo pa se načrtuje zavestno.

Za vtičnike v CMS je razpoložljive posodobitve pogosto mogoče prikazati tudi v ukazni vrstici, pri WordPressu na primer z WP-CLI:

```bash
# Prikaži razpoložljive posodobitve, ne da bi karkoli spremenil
wp plugin list --update=available
wp theme list --update=available
# Paketi frontenda: zastarele različice in znane ranljivosti
npm outdated
npm audit --omit=dev
```

> **Pomembno:**
> Samodejne posodobitve vtičnikov neposredno na produkcijskem sistemu so udobne, a tvegane, če nato nihče ne preverja. Vklopite jih samo, če sta zagotovljeni varnostna kopija pred vsakim zagonom in kontrola po njem.

## Kadar posodobitve ni

Vsakega obvestila ni mogoče rešiti z enim klikom. OWASP Cheat Sheet za ravnanje z ranljivimi odvisnostmi razlikuje več primerov, ki jih je dobro prenesti v vsakdan:

- **Popravek je na voljo:** namestite v stagingu, preizkusite, uvedite. Če se kaj pokvari, prilagodite lastno kodo, namesto da pustite posodobitev ležati.
- **Popravek je napovedan, a ga še ni:** uvedite zaobhod proizvajalca, prizadeto funkcijo po možnosti izklopite ali zaščitite, odločitev zabeležite.
- **Popravka ni pričakovati:** poiščite nadomestni paket ali popravek sami prenesite nazaj (backport), s preizkusom, ki loči ranljivost pred popravkom in po njem.

Pri vtičnikih CMS se pogosto pojavi četrti primer: vtičnik je opuščen. Takrat pomaga samo zamenjava ali odstranitev. Enako velja za vtičnike iz nejasnih virov, na primer „brezplačne“ kopije plačljivih vtičnikov. Ne prejemajo posodobitev prek uradnega kanala in nemalokrat sami vsebujejo škodljivo kodo. Napotke za upravljavce WordPressa zbira [WordPress in PHP2Shell](https://phpsos.de/sl/plattformen/wordpress/).

## Pojasnite odgovornost, preden pride naslednje obvestilo

Najpogostejši razlog za zastarele pakete ni tehnična ovira, ampak odprto vprašanje: kdo to naredi? Pri projektih, ki jih je zgradila agencija in se upravljajo notranje, se pogosto nihče ne počuti odgovornega. Za vsak projekt določite, kdo prejema obvestila, kdo ocenjuje in kdo odobrava, ter to zapišite.

Načrtujte tudi čas. Stalen vzdrževalni termin enkrat na mesec, ko se odvisnosti preverijo in posodobijo, preprečuje, da bi se posodobitve nabirale leta. Dlje ko projekt ni bil posodobljen, večji in tvegani je naslednji skok. Kako se posodobitve PHP in paketov vključijo v celovit potek, opisuje [Upravljanje popravkov kot postopek namesto gasilske akcije](https://phpsos.de/sl/blog/patch-management-prozess/).

## Kako konkretno pomaga PHP SOS?

- Zajamemo vse odvisnosti vaših projektov iz Composerja, npm in CMS ter označimo zastarele, ranljive in opuščene pakete.
- Vzpostavimo samodejna preverjanja in določimo, kdo ocenjuje katero obvestilo.
- Posodabljamo v stagingu, preizkusimo najpomembnejše postopke in uvedemo s potjo nazaj.
- V okviru [vzdrževalne pogodbe za varnost](https://phpsos.de/sl/leistungen/security-wartungsvertrag/) trajno prevzamemo mesečni cikel, vključno s posodobitvami PHP.

**Sklep:** Aktualne odvisnosti niso projekt, ampak rutina. Kdor stanje, ritem in odgovornost enkrat čisto uredi, mora ob naslednjem velikem obvestilu samo še preveriti, ne pa šele iskati.


## Pogosta vprašanja

**Kako pogosto naj se posodabljajo odvisnosti?**  
Varnostne posodobitve čim prej po presoji, rutinske posodobitve v stalnem ritmu, na primer mesečno. Pomembnejše od natančne pogostosti je, da je termin določen in da je nekdo za to odgovoren.

**Ali aktualen vtičnik ščiti pred PHP2Shell?**  
Ne. PHP2Shell je v samem interpreterju PHP. Proti temu pomaga samo posodobitev PHP s ponovnim zagonom vseh procesov PHP. Aktualni vtičniki in paketi so kljub temu pomembni, ker zapirajo lastne ranljivosti.

**Kaj naj storim z vtičnikom, ki ni več vzdrževan?**  
Nadomestite ali odstranite ga. Opuščen vtičnik ne dobi več popravkov, tudi če danes še deluje. Do zamenjave preverite, ali funkcijo res potrebujete, in odločitev dokumentirajte.

**Ali je treba frontend z npm posodobiti tudi na strežniku?**  
Paketi npm pogosto ležijo samo v gradnji in na strežnik pridejo kot končne datoteke. Ranljivost v paketu je kljub temu lahko v dostavljenem JavaScriptu. Po posodobitvi je zato treba znova zgraditi in znova dostaviti.

## Viri

- [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/)