# Atkarību uzturēšana aktuālas: Composer, npm un spraudņi

> Composer pakotnes, npm moduļi un CMS spraudņi atjaunināti: uzturēšanas process ar ritmu, atbildību, testiem un plānu gadījumiem, kad ielāpa nav.

Avots: https://phpsos.de/lv/blog/abhaengigkeiten-aktuell-halten/  
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:** Kas grib atjaunināt atkarības, tam vajadzīgs process trim pakotņu pasaulēm: Composer pakotnēm PHP kodā, npm moduļiem frontend būvējumā un spraudņiem vai motīviem CMS. Klāt nāk fiksēts ritms, atbildīga persona, testi pirms izvietošanas un plāns pakotnēm bez atjauninājuma. Pret PHP2Shell tas nepalīdz, jo šī ievainojamība ir pašā PHP, bet palīdz pret daudzajām ievainojamībām svešā kodā.

## Trīs pakotņu pasaules, viens akls plankums

Nedēļā pēc 2026. gada 21. oktobra viss griezās ap PHP interpretatoru. Daudzas komandas pie tam pamanīja, ka precīzi nepazīst savu pašu pamatelementu versijas. Vietne darbojas, aģentūra rūpējas, spraudnis jau pats paziņos, ja būs kaut kas jauns: tā vai līdzīgi skan pieņēmumi, kamēr kāds neapskatās.

Tipisks PHP projekts šodien sastāv no ievērojami vairāk sveša nekā paša koda. OWASP Top 10 ievainojamas un novecojušas komponentes min kā atsevišķu riska kategoriju. Problēma reti ir trūkstošs rīks, bet trūkstoša rutīna: atjauninājumi notiek, kad kādam ir laiks, un drošības paziņojumi nonāk pastkastē, ko neviens nelasa.

## Kuras atkarības kur atjauninājat?

Katrai pakotņu pasaulei ir savi rīki un savas kļūmes. Turpmākais pārskats palīdz neko nepalaist garām.

| Pakotņu pasaule | Parādīt sastāvu | Pārbaudīt ievainojamības | Tipiska kļūme |
|---|---|---|---|
| Composer (PHP bibliotēkas) | `composer show` | `composer audit` | netiešas pakotnes, ko neviens nepazīst |
| npm (frontend būvējums) | `npm ls` | `npm audit` | atjauninājums bez pārbūves serverī nenonāk nekad |
| CMS spraudņi un motīvi | admin saskarne vai CLI | ražotāja norādes, drošības pakalpojumi | pamesti spraudņi, pirkti spraudņi bez atjauninājumu kanāla |
| PHP un paplašinājumi | pakotņu pārvaldība | distributīva security tracker | parādītā versija maz pasaka par backport |

Pēdējā rinda stingri ņemot nepieder lietojumprogrammas atkarībām, bet bieži tiek aizmirsta tajā pašā elpas vilcienā. Tas pats attiecas uz skriptiem, kas tiek iekļauti tieši no svešiem serveriem, piemēram, bibliotēkām no CDN, tērzēšanas logrīkiem vai izsekošanas koda. Tie neparādās nevienā Lock failā, bet darbojas jūsu apmeklētāju pārlūkā. Iekļaujiet tos sarakstā un pārbaudiet, vai iekļautas fiksētas versijas, nevis „vienmēr jaunākā". Detaļas par `composer audit`, Lock failu un integrēšanu būvējumā ir ceļvedī [Composer atkarību pārbaude uz ievainojamībām](https://phpsos.de/lv/ratgeber/composer-abhaengigkeiten-pruefen/). Kā Composer principā strādā, skaidro [Composer: PHP pakotņu pārvaldnieks](https://phpsos.de/lv/php/composer/).

## Uzturēšanas cikls sešos soļos

Noturīgam procesam nav jābūt sarežģītam. Šī secība ir pierādījusi sevi:

1. **Fiksēt sastāvu:** katram projektam tiešo atkarību saraksts ar versiju, izcelsmi un mērķi. Lock faili (`composer.lock`, `package-lock.json`) pieder repozitorijam.
2. **Apkopot paziņojumus:** pārbaudes rīki darbojas katrā būvējumā un papildus regulāri uz piegādātā stāvokļa, arī bez koda izmaiņām.
3. **Novērtēt:** vai skartā pakotne tiek izmantota ražošanā, vai skartā funkcija ir sasniedzama, vai ir labota versija?
4. **Atjaunināt un testēt staging:** vispirms drošības atjauninājumi tajā pašā galvenajā versijā, lēcienus uz jaunām galvenajām versijām plānot kā atsevišķu darbu.
5. **Izvietot ar atkāpšanās ceļu:** iepriekšējais stāvoklis paliek pieejams kā pakotne vai izlaidums, datubāzes rezerves kopija pirms atjauninājuma.
6. **Dokumentēt:** kas kad tika atjaunināts, kas apzināti ne un kāpēc.

Ņemiet vērā versiju norādes failos `composer.json` un `package.json`. Pārāk šauras prasības neļauj drošības labojumus vispār instalēt. Pārāk plašas prasības turpretī projektā ievelk nepārbaudītas jaunas galvenās versijas. Pierādījusies prakse ir atļaut atjauninājumus galvenās versijas ietvaros un lēcienu uz nākamo plānot apzināti.

CMS spraudņiem pieejamos atjauninājumus bieži var parādīt arī komandrindā, WordPress, piemēram, ar WP-CLI:

```bash
# Parādīt pieejamos atjauninājumus, neko nemainot
wp plugin list --update=available
wp theme list --update=available
# Frontend pakotnes: novecojušas versijas un zināmas ievainojamības
npm outdated
npm audit --omit=dev
```

> **Svarīgi:**
> Automātiski spraudņu atjauninājumi tieši ražošanas sistēmā ir ērti, bet riskanti, ja pēc tam neviens nepārbauda. Ieslēdziet tos tikai tad, ja pirms katras palaišanas ir nodrošināta rezerves kopija un pēc tam kontrole.

## Ja atjauninājuma nav

Ne katru paziņojumu var atrisināt ar klikšķi. OWASP Cheat Sheet par rīcību ar ievainojamām atkarībām izšķir vairākus gadījumus, kurus labi var pārnest uz ikdienu:

- **Ielāps pieejams:** ieviest staging, testēt, izvietot. Ja kaut kas salūst, pielāgot savu kodu, nevis atstāt atjauninājumu neieviestu.
- **Ielāps paziņots, bet vēl nav:** ieviest ražotāja apiešanas risinājumu, skarto funkciju pēc iespējas izslēgt vai norobežot, lēmumu fiksēt.
- **Ielāps nav gaidāms:** meklēt aizvietojošu pakotni vai pašiem atpakaļ portēt labojumu, ar testu, kas ievainojamību atšķir pirms un pēc ielāpa.

CMS spraudņiem bieži sastopams ceturtais gadījums: spraudnis ir pamests. Tad palīdz tikai aizstāšana vai noņemšana. Tas pats attiecas uz spraudņiem no neskaidriem avotiem, piemēram, „bezmaksas" pirkto spraudņu kopijām. Tie atjauninājumus pa oficiālo kanālu nesaņem un ne reti paši satur ļaunprātīgu kodu. Norādes WordPress operatoriem apkopo [WordPress un PHP2Shell](https://phpsos.de/lv/plattformen/wordpress/).

## Atbildību noskaidrot, pirms atnāk nākamais paziņojums

Biežākais novecojušu pakotņu iemesls nav tehnisks šķērslis, bet atklāts jautājums: kas to dara? Projektos, ko uzbūvējusi aģentūra un kas tiek uzturēti iekšēji, bieži neviens nejūtas atbildīgs. Katram projektam nosakiet, kas saņem paziņojumus, kas novērtē un kas apstiprina, un to pierakstiet.

Plānojiet arī laiku. Fiksēts uzturēšanas termiņš mēnesī, kurā atkarības tiek pārbaudītas un atjauninātas, novērš atjauninājumu uzkrāšanos gadiem. Jo ilgāk projekts nav atjaunināts, jo lielāks un riskantāks kļūst nākamais lēciens. Kā PHP un pakotņu atjauninājumi iekļaujas vispārējā procesā, apraksta [Ielāpu pārvaldība kā process, nevis ugunsdzēsība](https://phpsos.de/lv/blog/patch-management-prozess/).

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

- Mēs apkopojam visas jūsu projektu atkarības no Composer, npm un CMS un atzīmējam novecojušās, ievainojamās un pamestās pakotnes.
- Mēs iestatām automātiskas pārbaudes un nosakām, kas kuru paziņojumu novērtē.
- Mēs atjauninām staging, testējam svarīgākos procesus un izvietojam ar atkāpšanās ceļu.
- [Drošības uzturēšanas līguma](https://phpsos.de/lv/leistungen/security-wartungsvertrag/) ietvaros mēs ilgstoši uzņemamies ikmēneša ciklu, PHP atjauninājumus ieskaitot.

**Secinājums:** Aktuālas atkarības nav projekts, bet rutīna. Kas sastāvu, ritmu un atbildību vienreiz sakārto, tam pie nākamā lielā paziņojuma jāpārbauda, nevis vispirms jāmeklē.


## Biežāk uzdotie jautājumi

**Cik bieži jāatjaunina atkarības?**  
Drošības atjauninājumus pēc iespējas drīz pēc novērtēšanas, ikdienas atjauninājumus fiksētā ritmā, piemēram, ik mēnesi. Svarīgāks par precīzu biežumu ir tas, ka termiņš ir noteikts un kāds par to atbild.

**Vai aktuāls spraudnis pasargā no PHP2Shell?**  
Nē. PHP2Shell ir pašā PHP interpretatorā. Pret to palīdz tikai PHP atjauninājums ar visu PHP procesu pārstartēšanu. Aktuāli spraudņi un pakotnes tomēr ir svarīgi, jo aizver savas ievainojamības.

**Ko darīt ar spraudni, kas vairs netiek uzturēts?**  
Aizstāt vai noņemt. Pamests spraudnis labojumus vairs nesaņem, pat ja šodien vēl darbojas. Līdz aizstāšanai jāpārbauda, vai funkcija tiešām ir vajadzīga, un lēmums jādokumentē.

**Vai arī frontend ar npm serverī jāatjaunina?**  
Bieži npm pakotnes ir tikai būvēšanā un serverī nonāk kā gatavi faili. Ievainojamība pakotnē tomēr var būt piegādātajā JavaScript. Pēc atjauninājuma tāpēc jāpārbūvē un jāpiegādā no jauna.

## Avoti

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