# Lanac opskrbe na webu: agencija, pružatelj hostinga, proizvođač dodataka

> Vaša web-stranica ovisi o PHP projektu, distribuciji, pružatelju hostinga, agenciji i proizvođačima dodataka. Kako taj lanac učiniti vidljivim i otpornim.

Izvor: https://phpsos.de/hr/blog/lieferkette-agentur-hoster/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Lanac opskrbe web-stranice proteže se od PHP projekta preko distribucije i pružatelja hostinga do CMS-a, dodataka, agencije i uključenih usluga. Za IT sigurnost važna je svaka karika, jer zakrpa stiže do Vaše web-stranice tek kad je svi proslijede. Tko lanac zapiše, za svaku kariku odredi nadležno mjesto i dokaz te ograniči pristupe, čini ga otpornim.

## Zakrpa i njezin dugi put

Dana 21. 10. 2026. u 14:00 UTC PHP projekt objavio je ispravke za PHP2Shell. Time ranjivost nije bila zatvorena ni na jednoj web-stranici. Najprije su distribucije poput Debiana, Ubuntua ili obitelji RHEL morale preuzeti ispravke u svoje pakete; prema izvješćima backportovi su djelomično isporučeni još istog dana. Zatim su pružatelji hostinga i administratori morali instalirati te pakete i ponovno pokrenuti sve PHP procese. Tek tada je pojedina web-stranica bila zaštićena.

Svaka karika u tom lancu može usporiti. A uz svaku je vezana druga organizacija s vlastitim prioritetima. Tko ne zna kako izgleda njegov lanac, ne može reći gdje se zakrpa trenutno nalazi.

Neki lanci imaju dodatne karike koje jedva tko poznaje. Mnogi Debian i Ubuntu poslužitelji PHP ne dobivaju iz distribucije, nego iz repozitorija Ondřeja Surýja na sury.org, raširenog izvora treće strane. Prema izvješćima tamo su stavljeni na raspolaganje buildovi za sve grane od 5.6 do 8.5. To je korisno, ali nije sigurnosni arhiv Debiana: tko koristi taj izvor, ovisi o drugoj kariki, s vlastitim ritmom i vlastitom odgovornošću. Je li poslužitelj tako postavljen, pokazuje popis izvora paketa, a upravo ta informacija pripada u dokumentaciju lanca.

## Karike lanca opskrbe u pregledu

Sljedeća tablica prikazuje tipične karike PHP web-stranice i što od svake možete zahtijevati.

| Karika | Tipičan rizik | Što biste trebali utvrditi |
|---|---|---|
| PHP projekt | ranjivost u interpreteru, kraj podrške | podržana verzija u uporabi, plan za kraj podrške |
| Distribucija ili izvor treće strane | backport nedostaje ili kasni | poznat izvor paketa, pretplaćene sigurnosne obavijesti |
| Pružatelj hostinga ili platformska usluga | ažuriranje bez ponovnog pokretanja, nema informacija | obveza ažuriranja, ponovnog pokretanja, dokaza i obavijesti |
| Proizvođač CMS-a | ranjivost u jezgri | kanal ažuriranja, odgovorna osoba |
| Proizvođači dodataka i tema | napuštena ili nesigurna proširenja | samo održavani dodaci iz službenih izvora |
| Agencija ili razvojni programer | široki pristupi, nejasna odgovornost | osobni pristupi, pisani zadaci |
| Vanjske skripte i usluge | tuđi kod u pregledniku, curenje podataka | popis, čvrste verzije, provjerena svrha |

Dva primjera iz tjedna PHP2Shella pokazuju kako se lako previdi jedna karika. Vercel upozorava da ažuriranje lokalnog razvojnog okruženja, koda aplikacije ili dodataka nije dovoljno; odlučujuće je PHP izvršno okruženje koje stvarno isporučuje stranice. Coolify savjetuje da se PHP izvršno okruženje svake aplikacije ažurira zasebno, čak i iza Cloudflarea. A prema izvješćima WordPress.org ne planira vlastito ažuriranje protiv PHP2Shella jer je ranjivost u interpreteru. Tko čeka CMS, čeka uzalud.

## Lanac učiniti vidljivim: pet koraka

Ovako uvodite red u ovisnosti svojih web-stranica:

1. **Zapisati lanac po web-stranici:** od PHP izvršnog okruženja do vanjskih skripti, s imenom pružatelja ili osobe.
2. **Odrediti odgovornost po kariki:** Tko instalira ažuriranja, tko provjerava, tko koga obavještava?
3. **Dogovoriti dokaze:** Što se smatra obavljenim? Kod PHP izvršnog okruženja primjerice stanje paketa i ponovno pokretanje, kako je opisano u članku [Kako pitati pružatelja hostinga za stanje zakrpe](https://phpsos.de/hr/ratgeber/hoster-patch-status-erfragen/).
4. **Ograničiti pristupe:** Svaka agencija i svaki pružatelj usluga dobiva samo prava koja su mu potrebna, s osobnim računima.
5. **Planirati zaobilazne puteve:** Što učiniti ako karika ispadne, primjerice proizvođač dodatka odustane ili pružatelj usluga nije dostupan?

> **Savjet:**
> Pitajte svakog pružatelja usluga kako Vas obavještava o kritičnim ranjivostima. Tko odgovara samo na upit, u situaciji poput PHP2Shella rizik je za Vaš vremenski plan. Odgovor zabilježite pisanim putem.

## Dodaci i proširenja: najnepreglednije mjesto

Kod mnogih web-stranica najveći dio lanca opskrbe je nevidljiv: dodaci i teme koji su se tijekom godina nakupili. Svaki potječe od drugog proizvođača, s vlastitim tempom sigurnosnih ažuriranja. Neki proizvođači napuštaju svoj proizvod a da to ne najave. Druga se proširenja nabavljaju iz neslužbenih izvora i nikad ne dobivaju ažuriranja.

Ovdje pomaže jednostavno pravilo: svaki dodatak treba svrhu, održavanog proizvođača i službeni izvor nabave. Ako nedostaje jedno od toga, ide na popis za zamjenu. Slično vrijedi za uključene usluge poput pružatelja plaćanja, sustava rezervacija, chat prozora ili alata za analitiku. Oni na Vašu stranicu donose vlastiti kod ili primaju podatke Vaših posjetitelja. Zabilježite koje su usluge uključene, tko ih je naručio i trebaju li se još. Zaboravljena skripta pružatelja s kojim odavno više nema ugovora je karika bez odgovorne osobe.

Kako dodatke i pakete trajno održavati ažurnima, opisuje [Održavanje ovisnosti ažurnima: Composer, npm i dodaci](https://phpsos.de/hr/blog/abhaengigkeiten-aktuell-halten/).

## Lanac opskrbe, ugovori i NIS2

Za tvrtke koje spadaju pod NIS2 sigurnost lanca opskrbe izričito je dio upravljanja rizicima, dakle i odnosi s pružateljima usluga i dobavljačima. Pojedinosti su u članku [NIS2 i sigurnost web-poslužitelja](https://phpsos.de/hr/compliance/nis2/). No i bez zakonske obveze vrijedi: povjereni zadaci ostaju Vaš rizik. Zato rezultati tih pet koraka pripadaju u ugovore s agencijom, pružateljem hostinga i pružateljima usluga; koje točke tamo treba urediti, opisuje [Ugovori s IT pružateljima usluga: jasno urediti obveze sigurnosti](https://phpsos.de/hr/blog/dienstleistervertrag-sicherheit/). Ova stranica je opća informacija i nije pravni savjet.

## Kako PHP SOS konkretno pomaže?

- S Vama ucrtavamo lanac opskrbe svake web-stranice, od PHP izvršnog okruženja do vanjskih skripti.
- Provjeravamo dodatke, teme i pakete na stanje održavanja i podrijetlo te preporučujemo zamjenu gdje je potrebna.
- Usklađujemo s pružateljem hostinga i agencijom tko odgovara za koje karike i koji se dokazi isporučuju.
- Gdje je karika nepopunjena, preuzimamo je trajno putem [ugovora o sigurnosnom održavanju](https://phpsos.de/hr/leistungen/security-wartungsvertrag/).

**Zaključak:** Sigurnost web-stranice jednako je jaka kao najsporija karika njezina lanca opskrbe. Tko poznaje lanac i svaku kariku povezuje s nadležnim mjestom i dokazom, u kritičnom trenutku zna gdje se zakrpa nalazi.


## Česta pitanja

**Što lanac opskrbe znači kod web-stranice?**  
Svi sudionici o čijem radu ovisi sigurnost Vaše web-stranice: PHP projekt, Linux distribucija, pružatelj hostinga ili platformska usluga, proizvođač CMS-a, proizvođači dodataka i tema, agencija te uključene usluge poput pružatelja plaćanja ili vanjskih skripti.

**Jesam li ja odgovoran ako pružatelj usluga ne zakrpa?**  
Odgovornost za vlastitu web-stranicu i podatke na njoj u pravilu ostaje na Vama, čak i kad su zadaci povjereni drugima. Zato odgovornosti trebaju biti ugovorno jasne i provjeravane. Za pravnu procjenu nadležni su odvjetnik i službenik za zaštitu podataka.

**Je li dovoljno da pružatelj hostinga ažurira PHP?**  
Za PHP okruženje kod pružatelja hostinga da, pod uvjetom da ponovno pokrene i sve procese i to dokaže. Ako dijelovi Vaše aplikacije rade drugdje, primjerice u kontejnerima, na platformskim uslugama ili na drugom poslužitelju, tamo se svako izvršno okruženje mora zasebno ažurirati.

**Kako prepoznati rizične dodatke?**  
Znakovi upozorenja su dugo bez ažuriranja, proizvođač bez prepoznatljivog sigurnosnog kontakta, nabava iz neslužbenih izvora i funkcije koje nitko više ne koristi. Takve dodatke treba zamijeniti ili ukloniti.

## Izvori

- [php.net: sigurnosne objave](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/)