# Tiekimo grandinė internete: agentūra, hostingo teikėjas, papildinių teikėjas

> Jūsų svetainė priklauso nuo PHP projekto, distribucijos, hostingo teikėjo, agentūros ir papildinių teikėjų. Kaip šią tiekimo grandinę padaryti matomą ir patikimą.

Šaltinis: https://phpsos.de/lt/blog/lieferkette-agentur-hoster/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** svetainės tiekimo grandinė tęsiasi nuo PHP projekto per distribuciją ir hostingo teikėją iki CMS, papildinių, agentūros ir įtrauktų paslaugų. IT saugumui svarbi kiekviena grandis, nes pataisa jūsų svetainę pasiekia tik tada, kai ją perdavė visi. Kas grandinę užrašo, kiekvienai grandžiai nustato atsakingą tarnybą ir įrodymą bei apriboja prieigas, padaro ją patikimą.

## Pataisa ir jos ilga kelionė

2026-10-21 14:00 UTC PHP projektas paskelbė PHP2Shell pataisas. Tuo spraga nebuvo uždaryta nė vienoje svetainėje. Pirmiausia distribucijos, tokios kaip Debian, Ubuntu ar RHEL šeima, turėjo perimti pataisas į savo paketus; pasak pranešimų, atgalinio perkėlimo (backport) pataisos kai kur buvo pateiktos tą pačią dieną. Tada hostingo teikėjai ir administratoriai turėjo įdiegti šiuos paketus ir iš naujo paleisti visus PHP procesus. Tik po to atitinkama svetainė buvo apsaugota.

Kiekviena šios grandinės grandis gali vilkinti. Ir prie kiekvienos prisišliejusi kita organizacija su savo prioritetais. Kas nežino, kaip atrodo jo grandinė, negali pasakyti, kur pataisa šiuo metu užstrigo.

Kai kurios grandinės turi papildomų grandžių, kurias vargu ar kas nors žino. Daugelis Debian ir Ubuntu serverių PHP gauna ne iš distribucijos, o iš Ondřej Surý saugyklos sury.org, plačiai paplitusio trečiojo šaltinio. Pasak pranešimų, ji pateikė kompiliacijas visoms šakoms nuo 5.6 iki 8.5. Tai naudinga, bet tai nėra Debian saugumo archyvas: kas naudoja šį šaltinį, priklauso nuo kitos grandies, su savo ritmu ir sava atsakomybe. Ar serveris taip sukonfigūruotas, parodo paketų šaltinių sąrašas, ir būtent ši informacija turi patekti į grandinės dokumentaciją.

## Tiekimo grandinės grandys apžvalgoje

Toliau pateiktoje lentelėje parodytos tipinės PHP svetainės grandys ir ko iš kiekvienos galite reikalauti.

| Grandis | Tipinė rizika | Ką turėtumėte nustatyti |
|---|---|---|
| PHP projektas | spraga interpretatoriuje, palaikymo pabaiga | naudojama palaikoma versija, palaikymo pabaigos planas |
| Distribucija arba trečiasis šaltinis | atgalinio perkėlimo pataisos nėra arba vėluoja | žinomas paketų šaltinis, užsiprenumeruoti saugumo pranešimai |
| Hostingo teikėjas arba platformos paslauga | atnaujinimas be paleidimo iš naujo, informacijos nėra | pareiga atnaujinti, paleisti iš naujo, pateikti įrodymą ir pranešti |
| CMS gamintojas | spraga branduolyje | atnaujinimų kanalas, atsakingas asmuo |
| Papildinių ir temų teikėjas | apleisti ar nesaugūs plėtiniai | tik prižiūrimi papildiniai iš oficialių šaltinių |
| Agentūra arba kūrėjas | plačios prieigos, neaiški atsakomybė | asmeninės prieigos, rašytinės užduotys |
| Išoriniai skriptai ir paslaugos | svetimas kodas naršyklėje, duomenų nutekėjimas | sąrašas, fiksuotos versijos, patikrintas tikslas |

Du PHP2Shell savaitės pavyzdžiai rodo, kaip lengva praleisti grandį. Vercel atkreipia dėmesį, kad nepakanka atnaujinti vietinės kūrimo aplinkos, programos kodo ar papildinių; lemia PHP vykdymo aplinka, kuri iš tikrųjų pateikia turinį. Coolify pataria atnaujinti kiekvienos programos PHP vykdymo aplinką atskirai, net už Cloudflare. O pasak pranešimų, WordPress.org neplanuoja savo atnaujinimo prieš PHP2Shell, nes spraga yra interpretatoriuje. Kas laukia CMS, laukia veltui.

## Padaryti grandinę matomą: penki žingsniai

Taip sutvarkysite savo svetainių priklausomybes:

1. **Užrašyti kiekvienos svetainės grandinę:** nuo PHP vykdymo aplinkos iki išorinių skriptų, nurodant teikėjo ar asmens vardą.
2. **Nustatyti kiekvienos grandies atsakomybę:** kas diegia atnaujinimus, kas tikrina, kas ką informuoja?
3. **Susitarti dėl įrodymų:** kas laikoma atlikta? PHP vykdymo aplinkos atveju, pavyzdžiui, paketo būsena ir paleidimas iš naujo, kaip aprašyta skyriuje [Kaip paklausti hostingo teikėjo apie pataisų būseną](https://phpsos.de/lt/ratgeber/hoster-patch-status-erfragen/).
4. **Apriboti prieigas:** kiekviena agentūra ir kiekvienas paslaugų teikėjas gauna tik reikalingas teises, su asmeninėmis paskyromis.
5. **Suplanuoti apėjimo kelius:** ką daryti, jei grandis iškrenta, pavyzdžiui, papildinio teikėjas nustoja veikti arba paslaugų teikėjas nepasiekiamas?

> **Patarimas:**
> Paklauskite kiekvieno paslaugų teikėjo, kaip jis informuoja jus apie kritines spragas. Kas atsako tik paklaustas, tokioje padėtyje kaip PHP2Shell yra rizika jūsų tvarkaraščiui. Atsakymą užfiksuokite raštu.

## Papildiniai ir plėtiniai: labiausiai neaiški vieta

Daugelyje svetainių didžiausia tiekimo grandinės dalis yra nematoma: papildiniai ir temos, atsiradę per metus. Kiekvienas iš kito teikėjo, su savo tempu saugumo atnaujinimų atžvilgiu. Kai kurie teikėjai savo produktą palieka, apie tai nepranešę. Kiti plėtiniai gaunami iš neoficialių šaltinių ir niekada negauna atnaujinimų.

Čia padeda paprasta taisyklė: kiekvienas papildinys turi turėti paskirtį, prižiūrimą teikėją ir oficialų gavimo šaltinį. Jei ko nors iš to trūksta, jis patenka į keitimo sąrašą. Panašiai ir su įtrauktomis paslaugomis, tokiomis kaip mokėjimo paslaugų teikėjai, rezervacijos sistemos, pokalbių langai ar analizės įrankiai. Jie į jūsų puslapį atneša savo kodą arba gauna jūsų lankytojų duomenis. Užfiksuokite, kurios paslaugos įtrauktos, kas jas užsakė ir ar jų dar reikia. Užmirštas teikėjo skriptas, su kuriuo seniai nebėra sutarties, yra grandis be atsakingo.

Kaip papildinius ir paketus nuolat atnaujinti, aprašyta straipsnyje [Priklausomybių atnaujinimas: Composer, npm ir papildiniai](https://phpsos.de/lt/blog/abhaengigkeiten-aktuell-halten/).

## Tiekimo grandinė, sutartys ir NIS2

Įmonėms, kurioms taikoma NIS2, tiekimo grandinės saugumas aiškiai priklauso rizikos valdymui, taigi ir santykiai su paslaugų teikėjais bei tiekėjais. Daugiau informacijos rasite skyriuje [NIS2 ir žiniatinklio serverių saugumas](https://phpsos.de/lt/compliance/nis2/). Tačiau ir be teisinės pareigos galioja: perduotos užduotys lieka jūsų rizika. Todėl penkių žingsnių rezultatai turi patekti į sutartis su agentūra, hostingo teikėju ir paslaugų teikėjais; kokius punktus ten reikėtų sureguliuoti, aprašyta straipsnyje [Sutartys su IT paslaugų teikėjais: aiškiai sureguliuoti saugumo pareigas](https://phpsos.de/lt/blog/dienstleistervertrag-sicherheit/). Šis puslapis yra bendro pobūdžio informacija ir nėra teisinė konsultacija.

## Kaip PHP SOS padeda konkrečiai?

- Kartu su jumis nubraižome kiekvienos svetainės tiekimo grandinę, nuo PHP vykdymo aplinkos iki išorinių skriptų.
- Tikriname papildinius, temas ir paketus dėl priežiūros būklės ir kilmės bei rekomenduojame pakeitimą, kur reikia.
- Su hostingo teikėju ir agentūra suderiname, kas už kurias grandis atsako ir kokie įrodymai pateikiami.
- Kur grandis neužimta, perimame ją nuolat per [saugumo priežiūros sutartį](https://phpsos.de/lt/leistungen/security-wartungsvertrag/).

**Išvada:** svetainės saugumas toks stiprus, kaip lėčiausia jos tiekimo grandinės grandis. Kas pažįsta grandinę ir kiekvieną grandį susieja su atsakinga tarnyba ir įrodymu, kritiniu atveju žino, kur užstrigo pataisa.


## Dažni klausimai

**Ką tiekimo grandinė reiškia svetainės atveju?**  
Visus dalyvius, nuo kurių darbo priklauso jūsų svetainės saugumas: PHP projektą, Linux distribuciją, hostingo teikėją ar platformos paslaugą, CMS gamintoją, papildinių ir temų teikėjus, agentūrą ir įtrauktas paslaugas, pavyzdžiui, mokėjimo paslaugų teikėjus ar išorinius skriptus.

**Ar aš atsakingas, jei paslaugų teikėjas neįdiegia pataisų?**  
Atsakomybė už savo svetainę ir joje esančius duomenis paprastai lieka jums, net jei užduotys perduotos kitiems. Todėl atsakomybės turi būti aiškiai nustatytos sutartyje ir tikrinamos. Dėl teisinio vertinimo kreipkitės į advokatą ir duomenų apsaugos pareigūną.

**Ar pakanka, kad hostingo teikėjas atnaujina PHP?**  
Hostingo teikėjo PHP vykdymo aplinkai taip, jei jis iš naujo paleidžia ir visus procesus ir tai įrodo. Jei dalis jūsų programos veikia kitur, pavyzdžiui, konteineriuose, platformos paslaugose ar antrame serveryje, ten kiekvieną vykdymo aplinką reikia atnaujinti atskirai.

**Kaip atpažinti rizikingus papildinius?**  
Įspėjamieji ženklai: ilgai nebuvo atnaujinimų, teikėjas be matomo saugumo kontakto, gavimas iš neoficialių šaltinių ir funkcijos, kurių niekas nebenaudoja. Tokius papildinius reikėtų pakeisti arba pašalinti.

## Šaltiniai

- [php.net: saugumo pranešimai](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/)