Bog'liqliklar zaifliklari: composer, npm va ta'minot zanjiri xavfsizligi

Zamonaviy veb-ilovada o'zingiz yozgan kod — umumiy kodning kichik qismi. Laravel loyihasi vendor papkasida yuzlab paketlarni olib keladi, oddiy React frontend esa node_modules ichida undan ham ko'proq. Ularning har birini boshqa odamlar yozgan, va ularning har birida zaiflik topilishi mumkin.

Shuning uchun xavfsizlik faqat o'z kodingizni tekshirish bilan tugamaydi. Bu maqolada bog'liqliklardagi (dependencies) zaifliklarni qanday topish, qanday yangilash va bu jarayonni qanday avtomatlashtirishni ko'rsatamiz.

Muammo nimada

Ikki xil xavf bor:

1. Ma'lum zaifliklar. Kutubxonada zaiflik topiladi, unga CVE beriladi va tuzatilgan versiya chiqadi. Agar siz eski versiyada qolsangiz, zaiflik ochiq va uning tafsilotlari hammaga ma'lum. OWASP Top 10 (2021) da bu alohida toifa: A06 — Vulnerable and Outdated Components.
2. Ta'minot zanjiri (supply chain) hujumlari. Paketning o'zi zararli bo'ladi: nomi mashhur paketga o'xshatib yaratilgan (typosquatting), muallif akkaunti qo'lga kiritilib, yangi versiyaga zararli kod qo'shilgan yoki o'rnatish skripti serverda yoki dasturchi kompyuterida kod bajaradi.

Birinchi xavf odatiy va uni boshqarish oson. Ikkinchisi kamroq uchraydi, lekin aniqlash qiyinroq.

Siz yozmagan kod ham sizning kodingiz. Ekspertiza uchun vendor va node_modules ilovaning bir qismi.

Nima uchun bu ekspertiza uchun muhim

Ekspertiza skanerlari ilova ishlatadigan kutubxona versiyalarini turli yo'llar bilan aniqlaydi:

• Frontend'dagi JavaScript kutubxonalari (masalan, jQuery yoki Bootstrap'ning eski versiyalari) fayl nomi va ichidagi izohlardan aniqlanadi.
• Ochiq qolgan composer.lock, package.json yoki package-lock.json fayllari barcha paketlar va ularning versiyalarini bitta ro'yxatda beradi.
• HTTP headerlar va xato sahifalari framework versiyasini oshkor qilishi mumkin.

Versiya aniqlansa, unga mos ma'lum zaifliklar hisobotga topilma sifatida kiritiladi. Shuning uchun topshirishdan oldin bog'liqliklarni tekshirish va lock fayllarni ochiq qoldirmaslik kerak.

Tekshirib ko'ring:

for f in composer.json composer.lock package.json package-lock.json yarn.lock .env; do
  printf '%s  ' "$f"; curl -s -o /dev/null -w '%{http_code}\n' "https://sayt.uz/$f"
done

Barcha javoblar 404 yoki 403 bo'lishi kerak. Laravel'da veb-ildiz public/ papkasi bo'lsa, bu fayllar tabiiy ravishda tashqarida qoladi. Agar ildiz noto'g'ri sozlangan bo'lsa, ular ochiq bo'ladi.

O'zingiz qanday tekshirasiz

PHP: composer audit

Composer 2.4 dan beri o'rnatilgan audit buyrug'i bor. U composer.lock dagi paketlarni ma'lum zaifliklar bazasi bilan solishtiradi:

composer audit
composer audit --no-dev          # faqat production paketlari
composer audit --format=json     # CI uchun

Eskirgan paketlar ro'yxati:

composer outdated --direct

--direct faqat siz composer.json ga o'zingiz yozgan paketlarni ko'rsatadi — ularni yangilasangiz, ichki bog'liqliklar ham ko'pincha yangilanadi.

JavaScript: npm audit

npm audit
npm audit --omit=dev             # faqat production bog'liqliklari
npm audit --audit-level=high     # faqat high va critical
npm outdated

Zaif paket qayerdan kelayotganini bilish uchun:

npm ls <paket-nomi>

npm audit fix mos keladigan versiyalarga yangilaydi. npm audit fix --force esa major versiyani ham ko'tarishi mumkin, bu ilovani buzishi mumkin — uni faqat testlar bilan birga ishlating.

npm registriyidagi paket imzolarini tekshirish ham foydali:

npm audit signatures

Universal: OSV-Scanner

Bir nechta ekotizim aralash bo'lgan loyihalar uchun OSV-Scanner ochiq OSV bazasi bo'yicha barcha lock fayllarni bir vaqtda tekshiradi:

osv-scanner scan source -r .

Flutter va Dart

Mobil ilovalar uchun ham xuddi shu tamoyil:

flutter pub outdated

Mobil ilovadagi uchinchi tomon SDK'lari (analitika, reklama, to'lov) ham bog'liqlik hisoblanadi va ekspertizada tekshirilishi mumkin.

Lock fayllar: takrorlanadigan o'rnatish

composer.lock va package-lock.json aniq qaysi versiyalar o'rnatilishini qayd etadi. Ular bo'lmasa, har bir o'rnatishda boshqa versiyalar tushishi mumkin — jumladan, hali tekshirilmagan yangi va potentsial zararli versiyalar.

Qoidalar:

• Lock fayllar repozitoriyga commit qilinadi.
• Production va CI'da lock fayldan o'rnating, uni yangilamang:

composer install --no-dev --prefer-dist --optimize-autoloader
npm ci --omit=dev

npm install lock faylni o'zgartirishi mumkin, npm ci esa lock faylga qat'iy amal qiladi va u package.json ga mos kelmasa, xato beradi.

• Lock fayldagi o'zgarishlarni code review'da ko'rib chiqing. Kichik o'zgarish uchun yuzlab qator lock o'zgarishi — savol berish uchun sabab.

Avtomatlashtirish: Dependabot va Renovate

Qo'lda tekshirish bir marta foydali, lekin zaifliklar har kuni e'lon qilinadi. Yangilanishlarni avtomatik taklif qiladigan vosita ulang.

GitHub'da Dependabot uchun .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      minor-and-patch:
        update-types: ["minor", "patch"]

Dependabot har hafta yangilanishlar uchun pull request ochadi, xavfsizlik ogohlantirishlari esa alohida keladi. Renovate — o'xshash vosita, GitLab va boshqa platformalarda ham ishlaydi va guruhlash hamda avtomatik birlashtirish qoidalarini nozik sozlash imkonini beradi.

Asosiysi — PR'larni yig'ib qo'ymaslik. Haftada bir marta ko'rib chiqish va birlashtirish odatini yarating, testlar yashil bo'lsa, patch yangilanishlarini kechiktirmang.

CI'ga ham tekshiruv qo'shing, shunda zaif paket bilan kod production'ga chiqmaydi:

# GitHub Actions qadamlari
- run: composer install --no-interaction --prefer-dist
- run: composer audit --no-dev
- run: npm ci
- run: npm audit --omit=dev --audit-level=high

Tashlab qo'yilgan paketlar

Zaiflik e'lon qilinmagan, lekin muallif paketni qo'llab-quvvatlashni to'xtatgan — bu ham xavf. Keyingi zaiflik topilganda tuzatish chiqmaydi.

Composer tashlab qo'yilgan (abandoned) paketlar haqida install va update paytida ogohlantiradi. Composer 2.7 va undan yangi versiyalarida audit buni ham tekshiradi va siyosatni composer.json da belgilash mumkin:

{
  "config": {
    "audit": {
      "abandoned": "fail"
    }
  }
}

npm'da eskirgan (deprecated) paketlar o'rnatish paytida npm warn deprecated sifatida chiqadi — bu ogohlantirishlarni e'tiborsiz qoldirmang. Har bir tashlab qo'yilgan paket uchun muqobil toping yoki uni olib tashlang.

Ta'minot zanjirini himoyalash

• Paket nomini tekshiring. Yangi paket qo'shishdan oldin uning rasmiy nomi, yuklab olishlar soni, repozitoriysi va oxirgi faolligini ko'ring. Bitta harf farqi — typosquatting belgisi.
• O'rnatish skriptlarini cheklang. npm paketlari postinstall kabi skriptlarni bajarishi mumkin. CI'da kerak bo'lmasa, npm ci --ignore-scripts ishlating (lekin ba'zi paketlar skriptlarsiz ishlamasligini hisobga oling).
• Kamroq bog'liqlik — kamroq xavf. Bir qatorlik vazifa uchun paket qo'shmang.
• CDN orqali yuklanadigan skriptlarga SRI qo'shing. Shunda CDN'dagi fayl o'zgartirilsa, brauzer uni bajarmaydi:

<script src="https://cdn.example.com/lib.min.js"
        integrity="sha384-..."
        crossorigin="anonymous"></script>

• Production serverda build qilmang. Frontend'ni CI'da yig'ib, tayyor artefaktni serverga chiqaring — serverda node_modules va build vositalari kerak emas.

SBOM: nimadan iboratligingizni biling

SBOM (Software Bill of Materials) — ilovadagi barcha komponentlar va ularning versiyalari ro'yxati, standart formatda (CycloneDX yoki SPDX). Yangi zaiflik e'lon qilinganda, SBOM bor bo'lsa, "bu paket bizda bormi va qaysi versiyada?" degan savolga bir necha soniyada javob topasiz.

# npm (npm 10+)
npm sbom --sbom-format cyclonedx > sbom-npm.json

# Composer (CycloneDX plagini orqali)
composer require --dev cyclonedx/cyclonedx-php-composer
composer CycloneDX:make-sbom --output-file=sbom-php.json

SBOM'ni har bir reliz bilan birga saqlang. Bu ekspertiza va mijozlar bilan ishlashda ham foydali: ilova tarkibini aniq ko'rsatib bera olasiz.

Qisqa checklist

1. composer audit --no-dev va npm audit --omit=dev jiddiy zaifliklarsiz.
2. composer.lock va package-lock.json repozitoriyda, production'da composer install va npm ci ishlatiladi.
3. Lock fayllar, package.json, .env brauzer orqali ochilmaydi.
4. Frontend'da eski jQuery, Bootstrap va boshqa kutubxonalar yo'q.
5. Dependabot yoki Renovate ulangan, PR'lar muntazam ko'rib chiqiladi.
6. CI zaif bog'liqlik bilan build'ni to'xtatadi.
7. Tashlab qo'yilgan va deprecated paketlar almashtirilgan.
8. CDN skriptlarida SRI bor, production serverda build qilinmaydi.
9. Har bir reliz uchun SBOM yaratiladi.

Xulosa

Bog'liqliklarni boshqarish — bir martalik ish emas, balki jarayon. Bir marta composer audit va npm audit ni ishga tushirib, topilganini yopish ekspertiza uchun yaxshi boshlanish. Lekin uzoq muddatda lock fayllar, avtomatik yangilanishlar va CI tekshiruvi ilovani har kuni xavfsiz holatda ushlab turadi. Kodda saqlanadigan kalit va parollar haqida esa sirlar va kalitlarni boshqarish maqolasida yozganmiz.

Loyihangizdagi bog'liqliklar va server sozlamalari qanday holatda ekanini bilmoqchimisiz? Skanerlash uchun ariza qoldiring — Claude AI agenti va mutaxassisimiz kod bazasi va konfiguratsiyani ko'rib chiqadi, topilgan teshiklarni yopishga va ekspertizaga tayyorlanishga yordam beramiz.