# Dobavna veriga v spletu: agencija, ponudnik gostovanja, ponudnik vtičnikov

> Vaša spletna stran je odvisna od projekta PHP, distribucije, ponudnika gostovanja, agencije in ponudnikov vtičnikov. Tako dobavno verigo naredite vidno in odporno.

Vir: https://phpsos.de/sl/blog/lieferkette-agentur-hoster/  
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:** Dobavna veriga spletne strani sega od projekta PHP prek distribucije in ponudnika gostovanja do CMS, vtičnikov, agencije in vključenih storitev. Za IT-varnost šteje vsak člen, saj popravek do vaše spletne strani pride šele, ko so ga vsi posredovali naprej. Kdor verigo zapiše, za vsak člen določi pristojno službo in dokazilo ter omeji dostope, jo naredi odporno.

## Popravek in njegova dolga pot

Dne 21. 10. 2026 ob 14:00 UTC je projekt PHP objavil popravke za PHP2Shell. S tem vrzel ni bila zaprta za nobeno spletno stran. Najprej so morale distribucije, kot so Debian, Ubuntu ali družina RHEL, popravke prevzeti v svoje pakete; po poročilih so bili prenosi popravkov (backport) deloma dostavljeni še isti dan. Nato so morali ponudniki gostovanja in skrbniki te pakete namestiti in znova zagnati vse procese PHP. Šele potem je bila posamezna spletna stran zaščitena.

Vsak člen v tej verigi lahko zakasni. In pri vsakem je drugačna organizacija z lastnimi prednostnimi nalogami. Kdor ne ve, kako izgleda njegova veriga, ne more reči, kje je popravek trenutno.

Nekatere verige imajo dodatne člene, ki jih skoraj nihče ne pozna. Mnogi strežniki Debian in Ubuntu PHP ne prejemajo iz distribucije, ampak iz repozitorija Ondřeja Surýja na sury.org, razširjenega tretjega vira. Po poročilih je zagotavljal gradnje za vse veje od 5.6 do 8.5. To je koristno, vendar to ni varnostni arhiv Debiana: kdor uporablja ta vir, je odvisen od drugega člena, z lastnim ritmom in lastno odgovornostjo. Ali je strežnik tako nastavljen, pokaže seznam virov paketov in prav ta informacija sodi v dokumentacijo verige.

## Členi dobavne verige v pregledu

Naslednja tabela prikazuje značilne člene spletne strani PHP in kaj lahko zahtevate od vsakega.

| Člen | Značilno tveganje | Kaj naj določite |
|---|---|---|
| Projekt PHP | vrzel v interpreterju, konec podpore | v uporabi podprta različica, načrt za konec podpore |
| Distribucija ali tretji vir | prenos popravka manjka ali pride pozno | znan vir paketov, naročena varnostna obvestila |
| Ponudnik gostovanja ali platforma | posodobitev brez ponovnega zagona, brez informacije | obveznost posodobitve, ponovnega zagona, dokazila in obveščanja |
| Proizvajalec CMS | vrzel v jedru | kanal posodobitev, pristojna oseba |
| Ponudnik vtičnikov in tem | opuščene ali nevarne razširitve | samo vzdrževani vtičniki iz uradnih virov |
| Agencija ali razvijalec | obsežni dostopi, nejasna pristojnost | osebni dostopi, pisne naloge |
| Zunanji skripti in storitve | tuja koda v brskalniku, uhajanje podatkov | seznam, stalne različice, preverjen namen |

Dva primera iz tedna PHP2Shell kažeta, kako zlahka se člen spregleda. Vercel opozarja, da posodobitev lokalnega razvojnega okolja, kode aplikacije ali vtičnikov ne zadošča; odločilno je izvajalno okolje PHP, ki dejansko streže. Coolify svetuje, da se izvajalno okolje PHP vsake aplikacije posodobi posebej, tudi za Cloudflare. In po poročilih WordPress.org ne načrtuje lastne posodobitve proti PHP2Shell, ker vrzel leži v interpreterju. Kdor čaka na CMS, čaka zaman.

## Verigo naredite vidno: pet korakov

Tako uvedete red v odvisnosti svojih spletnih strani:

1. **Zapišite verigo za vsako spletno stran:** od izvajalnega okolja PHP do zunanjih skriptov, z imenom ponudnika ali osebe.
2. **Določite pristojnost za vsak člen:** Kdo namešča posodobitve, kdo preverja, kdo koga obvešča?
3. **Dogovorite dokazila:** Kaj velja za opravljeno? Pri izvajalnem okolju PHP na primer stanje paketa in ponovni zagon, kot je opisano v [Tako vprašate ponudnika gostovanja po stanju popravkov](https://phpsos.de/sl/ratgeber/hoster-patch-status-erfragen/).
4. **Omejite dostope:** Vsaka agencija in vsak ponudnik dobi samo pravice, ki jih potrebuje, z osebnimi računi.
5. **Načrtujte nadomestne poti:** Kaj storiti, če člen odpove, na primer ponudnik vtičnika opusti izdelek ali ponudnik ni dosegljiv?

> **Nasvet:**
> Vprašajte vsakega ponudnika, kako vas obvešča o kritičnih vrzelih. Kdor odgovori samo na vprašanje, je v razmerah, kot je PHP2Shell, tveganje za vaš časovni načrt. Odgovor zabeležite pisno.

## Vtičniki in razširitve: najmanj pregledno mesto

Pri mnogih spletnih straneh je največji del dobavne verige neviden: vtičniki in teme, ki so se dodajali skozi leta. Vsak izvira od drugega ponudnika, z lastnim tempom pri varnostnih posodobitvah. Nekateri ponudniki svoj izdelek opustijo, ne da bi to napovedali. Druge razširitve se prevzemajo iz neuradnih virov in nikoli ne dobijo posodobitev.

Tu pomaga preprosto pravilo: vsak vtičnik potrebuje namen, vzdrževanega ponudnika in uradni vir. Če ena od teh stvari manjka, pride na seznam za zamenjavo. Podobno velja za vključene storitve, kot so ponudniki plačil, sistemi za rezervacije, klepetalna okna ali orodja za analizo. Prinašajo lastno kodo na vašo stran ali prejemajo podatke vaših obiskovalcev. Zabeležite, katere storitve so vključene, kdo jih je naročil in ali so še potrebne. Pozabljen skript ponudnika, s katerim že zdavnaj ni več pogodbe, je člen brez odgovorne osebe.

Kako vtičnike in pakete trajno ohranjate ažurne, opisuje [Ažurne odvisnosti: Composer, npm in vtičniki](https://phpsos.de/sl/blog/abhaengigkeiten-aktuell-halten/).

## Dobavna veriga, pogodbe in NIS2

Za podjetja, ki spadajo pod NIS2, je varnost dobavne verige izrecno del upravljanja tveganj, torej tudi odnosi do ponudnikov in dobaviteljev. Podrobnosti so na strani [NIS2 in varnost spletnih strežnikov](https://phpsos.de/sl/compliance/nis2/). A tudi brez zakonske obveznosti velja: oddane naloge ostanejo vaše tveganje. Zato rezultati petih korakov sodijo v pogodbe z agencijo, ponudnikom gostovanja in ponudniki; katere točke je tam treba urediti, opisuje [Pogodbe z IT-ponudniki: jasna ureditev varnostnih obveznosti](https://phpsos.de/sl/blog/dienstleistervertrag-sicherheit/). Ta stran je splošna informacija in ni pravno svetovanje.

## Kako PHP SOS pomaga konkretno?

- Z vami zarišemo dobavno verigo vsake spletne strani, od izvajalnega okolja PHP do zunanjih skriptov.
- Vtičnike, teme in pakete preverimo glede vzdrževanja in izvora ter priporočimo zamenjavo, kjer je potrebno.
- S ponudnikom gostovanja in agencijo uskladimo, kdo odgovarja za katere člene in katera dokazila se dostavljajo.
- Kjer je člen nezaseden, ga trajno prevzamemo prek [pogodbe o varnostnem vzdrževanju](https://phpsos.de/sl/leistungen/security-wartungsvertrag/).

**Sklep:** Varnost spletne strani je tako močna kot najpočasnejši člen njene dobavne verige. Kdor verigo pozna in vsak člen poveže s pristojno službo in dokazilom, ve v skrajnem primeru, kje je popravek.


## Pogosta vprašanja

**Kaj pomeni dobavna veriga pri spletni strani?**  
Vsi udeleženci, od katerih dela je odvisna varnost vaše spletne strani: projekt PHP, distribucija Linux, ponudnik gostovanja ali platforma, proizvajalec CMS, ponudniki vtičnikov in tem, agencija in vključene storitve, kot so ponudniki plačil ali zunanji skripti.

**Ali sem odgovoren, če ponudnik ne namešča popravkov?**  
Odgovornost za lastno spletno stran in podatke na njej praviloma ostane pri vas, tudi če so naloge oddane. Zato morajo biti pristojnosti v pogodbi jasne in preverjene. Za pravno oceno sta pristojna odvetnik in pooblaščenec za varstvo podatkov.

**Ali zadošča, da ponudnik gostovanja posodobi PHP?**  
Za izvajalno okolje PHP pri ponudniku da, če znova zažene tudi vse procese in to dokaže. Če deli vaše aplikacije tečejo drugje, na primer v vsebnikih, na storitvah platform ali na drugem strežniku, je treba tam vsako izvajalno okolje posodobiti posebej.

**Kako prepoznam tvegane vtičnike?**  
Opozorilni znaki so dolgo brez posodobitev, ponudnik brez prepoznavnega varnostnega stika, prevzem iz neuradnih virov in funkcije, ki jih nihče več ne uporablja. Takšne vtičnike je treba zamenjati ali odstraniti.

## Viri

- [php.net: varnostna obvestila](https://www.php.net/)
- [Vercel: PHP2Shell Security Bulletin](https://vercel.com/kb/bulletin/php2shell-security-bulletin)
- [Coolify: PHP Security Advisory](https://coolify.io/docs/knowledge-base/php-security-advisory-2026)
- [BSI](https://www.bsi.bund.de/)