# Piegādes ķēde tīmeklī: aģentūra, hostings, spraudņu piegādātājs

> Jūsu vietne ir atkarīga no PHP projekta, distribūcijas, hostinga, aģentūras un spraudņu piegādātājiem. Kā padarīt šo piegādes ķēdi redzamu un noturīgu.

Avots: https://phpsos.de/lv/blog/lieferkette-agentur-hoster/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Īsi sakot:** Vietnes piegādes ķēde stiepjas no PHP projekta caur distribūciju un hostinga pakalpojumu sniedzēju līdz CMS, spraudņiem, aģentūrai un iekļautajiem pakalpojumiem. IT drošībai ir svarīgs katrs posms, jo ielāps jūsu vietni sasniedz tikai tad, kad visi to ir nodevuši tālāk. Kas ķēdi pieraksta, katram posmam nosaka atbildīgo vietu un apliecinājumu un ierobežo piekļuves, tas padara to noturīgu.

## Viens ielāps un tā garais ceļojums

2026. gada 21. oktobrī plkst. 14:00 UTC PHP projekts publicēja PHP2Shell labojumus. Ar to nepilnība nebija aizvērta nevienai vietnei. Vispirms distribūcijām, piemēram, Debian, Ubuntu vai RHEL saimei, bija jāpārņem labojumi savās pakotnēs; saskaņā ar ziņojumiem atpakaļportējumi (backport) daļēji tika piegādāti jau tajā pašā dienā. Tad hostinga pakalpojumu sniedzējiem un administratoriem bija jāuzstāda šīs pakotnes un jāpārstartē visi PHP procesi. Tikai pēc tam attiecīgā vietne bija aizsargāta.

Katrs šīs ķēdes posms var aizkavēt. Un pie katra ir cita organizācija ar savām prioritātēm. Kas nezina, kā izskatās tā ķēde, nevar pateikt, kur ielāps pašlaik atrodas.

Dažām ķēdēm ir papildu posmi, ko gandrīz neviens nepazīst. Daudzi Debian un Ubuntu serveri PHP ņem nevis no distribūcijas, bet no Ondřej Surý repozitorija vietnē sury.org, plaši izplatīta trešā avota. Saskaņā ar ziņojumiem tas ir piegādājis būvējumus visiem zariem no 5.6 līdz 8.5. Tas ir noderīgi, taču tas nav Debian drošības arhīvs: kas izmanto šo avotu, tas ir atkarīgs no cita posma ar savu ritmu un savu atbildību. Vai serveris ir iestatīts šādi, parāda pakotņu avotu saraksts, un tieši šī informācija jāiekļauj ķēdes dokumentācijā.

## Piegādes ķēdes posmi pārskatā

Turpmākā tabula parāda PHP vietnes tipiskos posmus un to, ko varat prasīt no katra.

| Posms | Tipisks risks | Ko vajadzētu noteikt |
|---|---|---|
| PHP projekts | nepilnība interpretatorā, atbalsta beigas | izmantota atbalstīta versija, plāns atbalsta beigām |
| Distribūcija vai trešais avots | trūkst atpakaļportējuma vai tas nāk vēlu | zināms pakotņu avots, abonēti drošības paziņojumi |
| Hostinga pakalpojumu sniedzējs vai platformas pakalpojums | atjauninājums bez pārstartēšanas, nav informācijas | pienākums atjaunināt, pārstartēt, apliecināt un paziņot |
| CMS ražotājs | nepilnība kodolā | atjauninājumu kanāls, atbildīgā persona |
| Spraudņu un tēmu piegādātājs | pamesti vai nedroši paplašinājumi | tikai uzturēti spraudņi no oficiāliem avotiem |
| Aģentūra vai izstrādātājs | tālejošas piekļuves, neskaidra atbildība | personiskas piekļuves, rakstveida uzdevumi |
| Ārēji skripti un pakalpojumi | svešs kods pārlūkā, datu noplūde | saraksts, fiksētas versijas, pārbaudīts mērķis |

Divi piemēri no PHP2Shell nedēļas parāda, cik viegli kāds posms tiek palaists garām. Vercel norāda, ka nepietiek ar vietējās izstrādes vides, lietojumprogrammas koda vai spraudņu atjauninājumu; izšķirošs ir PHP izpildlaiks, kas faktiski nodrošina saturu. Coolify iesaka katras lietojumprogrammas PHP izpildlaiku atjaunināt atsevišķi, arī aiz Cloudflare. Un saskaņā ar ziņojumiem WordPress.org neplāno savu atjauninājumu pret PHP2Shell, jo nepilnība ir interpretatorā. Kas gaida uz CMS, tas gaida veltīgi.

## Ķēdes padarīšana redzamu: pieci soļi

Tā jūs sakārtojat savu vietņu atkarības:

1. **Pierakstīt ķēdi katrai vietnei:** no PHP izpildlaika līdz ārējiem skriptiem, ar piegādātāja vai personas nosaukumu.
2. **Noteikt atbildību katram posmam:** kurš uzstāda atjauninājumus, kurš pārbauda, kurš ko informē?
3. **Vienoties par apliecinājumiem:** ko uzskata par paveiktu? PHP izpildlaikam, piemēram, pakotnes stāvoklis un pārstartēšana, kā aprakstīts sadaļā [Kā jautāt hostinga pakalpojumu sniedzējam par ielāpa stāvokli](https://phpsos.de/lv/ratgeber/hoster-patch-status-erfragen/).
4. **Ierobežot piekļuves:** katra aģentūra un katrs pakalpojumu sniedzējs saņem tikai vajadzīgās tiesības, ar personiskiem kontiem.
5. **Plānot apkārtceļus:** ko darīt, ja kāds posms atkrīt, piemēram, spraudņa piegādātājs pamet produktu vai pakalpojumu sniedzējs nav sasniedzams?

> **Padoms:**
> Pajautājiet katram pakalpojumu sniedzējam, kā tas jūs informē par kritiskām nepilnībām. Kas atbild tikai pēc pieprasījuma, tāds PHP2Shell veida situācijā ir risks jūsu laika grafikam. Atbildi fiksējiet rakstveidā.

## Spraudņi un paplašinājumi: visneskaidrākā vieta

Daudzām vietnēm lielākā ķēdes daļa ir neredzama: spraudņi un tēmas, kas pievienotas gadu gaitā. Katrs nāk no cita piegādātāja ar savu tempu drošības atjauninājumos. Daži piegādātāji pamet savu produktu, to nepaziņojot. Citi paplašinājumi tiek iegūti no neoficiāliem avotiem un nekad nesaņem atjauninājumus.

Šeit palīdz vienkāršs noteikums: katram spraudnim vajadzīgs mērķis, uzturēts piegādātājs un oficiāls ieguves avots. Ja trūkst kāda no tiem, tas nonāk nomaiņas sarakstā. Līdzīgi ir ar iekļautajiem pakalpojumiem, piemēram, maksājumu pakalpojumu sniedzējiem, rezervēšanas sistēmām, tērzēšanas logiem vai analīzes rīkiem. Tie ienes savu kodu jūsu lapā vai saņem jūsu apmeklētāju datus. Fiksējiet, kādi pakalpojumi ir iekļauti, kas tos pasūtījis un vai tie vēl ir vajadzīgi. Aizmirsts piegādātāja skripts, ar kuru jau sen vairs nav līguma, ir posms bez atbildīgā.

Kā spraudņus un pakotnes pastāvīgi uzturēt aktuālus, apraksta [Atkarību uzturēšana aktuālā stāvoklī: Composer, npm un spraudņi](https://phpsos.de/lv/blog/abhaengigkeiten-aktuell-halten/).

## Piegādes ķēde, līgumi un NIS2

Uzņēmumiem, uz kuriem attiecas NIS2, piegādes ķēdes drošība skaidri ietilpst riska pārvaldībā, tātad arī attiecības ar pakalpojumu sniedzējiem un piegādātājiem. Sīkāk skatiet [NIS2 un tīmekļa serveru drošība](https://phpsos.de/lv/compliance/nis2/). Taču arī bez likumiskā pienākuma ir spēkā: ārpakalpojumā nodotie uzdevumi paliek jūsu risks. Tāpēc piecu soļu rezultāti jāiekļauj līgumos ar aģentūru, hostinga pakalpojumu sniedzēju un pakalpojumu sniedzējiem; kādi punkti tur jāregulē, apraksta [IT pakalpojumu sniedzēju līgumi: skaidri regulēt drošības pienākumus](https://phpsos.de/lv/blog/dienstleistervertrag-sicherheit/). Šī lapa ir vispārīga informācija un nav juridiskā konsultācija.

## Kā PHP SOS palīdz konkrēti?

- Mēs kopā ar jums uzzīmējam katras vietnes piegādes ķēdi, no PHP izpildlaika līdz ārējiem skriptiem.
- Mēs pārbaudām spraudņu, tēmu un pakotņu uzturēšanas stāvokli un izcelsmi un iesakām aizstājēju, kur nepieciešams.
- Mēs saskaņojam ar hostinga pakalpojumu sniedzēju un aģentūru, kurš par kuriem posmiem atbild un kādi apliecinājumi tiek sniegti.
- Kur kāds posms ir neaizņemts, mēs to pastāvīgi pārņemam ar [drošības apkopes līgumu](https://phpsos.de/lv/leistungen/security-wartungsvertrag/).

**Secinājums:** Vietnes drošība ir tik stipra, cik lēnākais tās piegādes ķēdes posms. Kas pazīst ķēdi un katru posmu sasaista ar atbildīgo vietu un apliecinājumu, ārkārtas situācijā zina, kur ielāps atrodas.


## Biežāk uzdotie jautājumi

**Ko nozīmē piegādes ķēde attiecībā uz vietni?**  
Visi iesaistītie, no kuru darba ir atkarīga jūsu vietnes drošība: PHP projekts, Linux distribūcija, hostinga pakalpojumu sniedzējs vai platformas pakalpojums, CMS ražotājs, spraudņu un tēmu piegādātāji, aģentūra un iekļautie pakalpojumi, piemēram, maksājumu pakalpojumu sniedzēji vai ārēji skripti.

**Vai es esmu atbildīgs, ja pakalpojumu sniedzējs neuzstāda ielāpus?**  
Atbildība par savu vietni un tajā esošajiem datiem parasti paliek pie jums, arī ja uzdevumi ir nodoti ārpakalpojumā. Tāpēc atbildības jomām jābūt skaidri noteiktām līgumā un tās jāpārbauda. Juridiskajam novērtējumam kompetenti ir jurists un datu aizsardzības speciālists.

**Vai pietiek, ja hostinga pakalpojumu sniedzējs atjaunina PHP?**  
Hostinga pakalpojumu sniedzēja PHP izpildlaikam jā, ja tas pārstartē arī visus procesus un to apliecina. Ja jūsu lietojumprogrammas daļas darbojas citur, piemēram, konteineros, platformas pakalpojumos vai otrā serverī, tur katrs izpildlaiks jāatjaunina atsevišķi.

**Kā atpazīt riskantus spraudņus?**  
Brīdinājuma pazīmes ir ilgi nebijuši atjauninājumi, piegādātājs bez saskatāma drošības kontakta, iegāde no neoficiāliem avotiem un funkcijas, ko neviens vairs neizmanto. Šādi spraudņi jānomaina vai jānoņem.

## Avoti

- [php.net: drošības paziņojumi](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/)