SBOM nima va kompaniyaga nima uchun kerak

SBOM (Software Bill of Materials, «dasturiy ta’minot spetsifikatsiyasi») — bu ilova yig‘ilgan komponentlar ro‘yxati: kutubxonalar, ularning versiyalari, yetkazib beruvchilar, litsenziyalar va bog‘liqliklar. CISA uni tarkibiy qismlar ro‘yxatiga o‘xshatadi. Kompaniyaga SBOM «yangi zaiflik bizga ta’sir qildimi» degan savolga daqiqalar ichida javob berish va DT yetkazib beruvchilaridan shaffoflikni talab qilish uchun kerak.

Nima uchun hamma SBOM haqida gapira boshladi

Zamonaviy ilova deyarli har doim ko‘plab open-source komponentlarni o‘z ichiga oladi, ularning aksariyati yig‘ishga to‘g‘ridan-to‘g‘ri emas, tranzitiv bog‘liqliklar sifatida tushadi. Mashhur kutubxonada muhim zaiflik topilganda birinchi savol — «bizda u bormi va qayerda?». SBOM bo‘lmasa, javobni qo‘lda kunlab qidirishadi; SBOM bilan esa inventar bo‘yicha qidiruv bajariladi.

Ko‘rsatkichli misol — Log4Shell (CVE-2021-44228): Log4j kutubxonasi turli vendorlarning mahsulotlarida ishlatiladi va tashkilotlar uning aynan qayerda borligini shoshilinch aniqlashga majbur bo‘lgan. Bu xavf haqida batafsil — DT yetkazib berish zanjiriga hujumlar materialida.

Yetkazib berish zanjirlariga hujumlardan keyin SBOM’ga talablar tartibga solishda paydo bo‘la boshladi. AQShning 14028-sonli «Improving the Nation's Cybersecurity» Prezident farmoni 2021-yil 12-mayda imzolanib, DT yetkazib berish zanjiri xavfsizligini alohida bo‘limga ajratdi va SBOM’ning minimal elementlarini aniqlash vazifasini qo‘ydi; 2021-yil iyulida NTIA «The Minimum Elements For a Software Bill of Materials» hisobotini e’lon qildi. AQShning normativ talablari Markaziy Osiyo davlatlarida bevosita amal qilmaydi, ammo SBOM’ni tobora ko‘proq xalqaro vendorlar, yirik buyurtmachilar va banklar so‘ramoqda.

SBOM tarkibiga nimalar kiradi

• Har bir komponentning nomi va versiyasi
• Yetkazib beruvchi yoki muallif
• Noyob identifikatorlar (purl, CPE) va xeshlar
• Bog‘liqliklar aloqalari — tranzitivlarini ham qo‘shgan holda
• Litsenziyalar

Ma’lumotlar qanchalik to‘liq bo‘lsa, zaifliklar bazalari bilan solishtirish shunchalik aniq bo‘ladi. Versiyalar va identifikatorlarsiz SBOM avtomatik tahlil uchun foydasiz.

Formatlar: CycloneDX va SPDX

Ikkita asosiy ochiq standart — CycloneDX va SPDX.

• CycloneDX: OWASP Foundation va Ecma International tomonidan ishlab chiqiladi; ECMA-424 standarti sifatida tasdiqlangan (2025-yil 10-dekabrda e’lon qilingan). SBOM’dan tashqari SaaSBOM va HBOM’ni ham tavsiflaydi, formatlari — JSON, XML va Protobuf. Tarixan xavfsizlikka yo‘naltirilgan.
• SPDX: Linux Foundation loyihasi, ISO/IEC 5962:2021 xalqaro standarti. Kelib chiqishi, litsenziyalar va xavfsizlik ma’lumotlarini tavsiflaydi; an’anaviy ravishda litsenziya komplaensida kuchli.

Aksar vositalar ikkala format bilan ishlay oladi, shuning uchun buyurtmachilaringiz so‘raydigan formatni tanlang, ideal holda esa ikkalasini ham berishni uddalang.

SBOM’ni qanday shakllantirish

Qo‘lda — variant emas: bog‘liqliklar har bir yig‘ish bilan o‘zgaradi. SBOM CI/CD’da SCA sinfidagi vositalar tomonidan avtomatik generatsiya qilinadi. Masalan, Sonatype Lifecycle va SBOM Manager har bir yig‘ishda SBOM shakllantiradi, komponentlarni zaifliklar bazasi va kompaniya siyosatlari bilan solishtiradi hamda mahsulotning barcha versiyalari uchun SBOM’ni saqlash imkonini beradi. Tanlash uchun muqobillar sharhi — SCA-yechimlarni taqqoslash maqolasida.

Generatsiyaning amaliy qoidalari:

• SBOM’ni «orqaga qarab» repozitoriy bo‘yicha emas, yig‘ish bosqichida shakllantiring — shunda unga artefaktlarning haqiqiy versiyalari tushadi.
• Har bir reliz uchun SBOM saqlang: zaiflik allaqachon prod’da turgan versiyada topilishi mumkin.
• SBOM’ni zaifliklar bazasi bilan bir marta emas, uzluksiz solishtiring: yangi CVE’lar relizdan keyin ham paydo bo‘ladi.

SBOM’ni xavfsizlik uchun qanday qo‘llash

1. Yangi CVE’larga javob: ta’sirlangan ilovalarni bir zumda qidirish.
2. Siyosatlar: muhim zaifliklarga yoki taqiqlangan litsenziyalarga ega komponentlarni taqiqlash.
3. DT’ni qabul qilish: pudratchilar va vendorlardan SBOM talab qiling.
4. Audit va komplaens: yetkazib berish zanjiri nazorat qilinayotganining isboti.

CISA qayd etishicha, SBOM VEX bilan juftlikda ishlaydi — bu muayyan mahsulotga ma’lum zaiflik ta’sir qiladimi-yo‘qmi haqidagi bayonot. Bu mahsulotingizda yetib bo‘lmaydigan komponentlar zaifliklarini saralashga va bo‘sh tikketlarga vaqt sarflamaslikka yordam beradi. SBOM bilan AppSec vositalarining boshqa sinflarini ham birga qo‘llash qulay: SCA tarkib uchun, SAST va DAST — o‘z kodi va ilova xatti-harakati uchun javob beradi.

Frontend uchun SBOM

Alohida ko‘r nuqta — brauzerda uchinchi tomon CDN’laridan yuklanadigan mijoz JavaScript’i. Yig‘ishda tuzilgan klassik SBOM uni ko‘rmaydi: skript allaqachon runtime’da ulanadi. Buning uchun Frontend SBOM mavjud bo‘lib, uni, masalan, DPA FAST Analyzer shakllantiradi.

SBOM bilan ishlashdagi odatiy xatolar

• «Ko‘rsatish uchun» SBOM. Fayl audit uchun bir marta shakllantirilib, unutib qo‘yildi. Eskirgan SBOM uning yo‘qligidan xavfliroq: u nazorat borligi haqida yolg‘on tuyg‘u yaratadi.
• Faqat to‘g‘ridan-to‘g‘ri bog‘liqliklar. Muammolarning ko‘pchiligi tranzitiv komponentlar orqali keladi, shuning uchun bog‘liqliklar aloqalarisiz SBOM kam ma’lumot beradi.
• Javob jarayoni yo‘q. Inventarning o‘zi zaifliklarni yopmaydi: ilovalar egalari, tuzatish muddatlari va zaif kodning haqiqiy yetib borishi bo‘yicha ustuvorlashtirish kerak.
• Turli jamoalarda turli formatlar. Har bir jamoa SBOM’ni o‘zicha shakllantirsa, ma’lumotlarni yagona manzaraga keltirib bo‘lmaydi. Format va saqlash joyi bo‘yicha kelishib oling.
• Konteynerlar va image’larni e’tiborsiz qoldirish. Operatsion tizim va bazaviy image’lar komponentlari ham yetkazib beriladigan mahsulot tarkibiga kiradi.

SBOM’ni joriy etishni nimadan boshlash kerak

Darhol barcha ilovalarni qamrab olish shart emas. Amaliy harakatlar tartibi:

1. Bir nechta muhim ilovani tanlang va ularning yig‘ishida SBOM’ning avtomatik generatsiyasini yoqing.
2. Formatni (CycloneDX, SPDX yoki ikkalasi) va AX xizmati uchun mavjud saqlash joyini kelishib oling.
3. Zaifliklar bazasi bilan solishtirishni ulang va yangi topilmalar haqida xabarnomalarni sozlang.
4. Siyosatlarni belgilang: qaysi zaifliklar va litsenziyalar joiz emas va istisnolar haqida qarorni kim qabul qiladi.
5. SBOM talabini shartnomalarga va pudratchilardan DT’ni qabul qilish jarayoniga qo‘shing.
6. Qamrovni asta-sekin qolgan ilovalar va konteyner image’lariga kengaytiring.

Bunday yondashuv birinchi natijalarni tez olishga va jamoalarni ortiqcha yuklamaslikka imkon beradi. U xavfsiz ishlab chiqishni joriy etishning umumiy rejasiga yaxshi mos tushadi, vositalar bo‘yicha qarorlarni esa kichik pilotda tekshirish qulay.

SBOM va yetkazib berish zanjiri

SBOM «ichida nima bor» degan savolga javob beradi, ammo ichida zararli kod yo‘qligini kafolatlamaydi. Shuning uchun uni umuman yig‘ishga nima tushishini nazorat qilish bilan to‘ldirishadi: komponentlarni tekshiradigan artefaktlar repozitoriysi, shubhali paketlarni bloklash va ruxsat siyosatlari. Bu choralar birgalikda yetkazib berish zanjiri nazoratini shakllantiradi: siz mahsulot tarkibini bilasiz va unga ochiq-oydin xavfli narsani o‘tkazmaysiz. Buyurtmachilarga DT yetkazib beradigan tashkilotlar uchun SBOM ishonch elementiga ham aylanadi: u mahsulot tarkibi ma’lum va boshqariluvchan ekanini ko‘rsatadi.

SBOM kimga tegishli bo‘lishi kerak

Rasman SBOM avtomatik generatsiya qilinadi, lekin uning egasi bo‘lishi kerak. Odatda bu AX xizmati yoki ishlab chiqish platformasi jamoasi: ular format, saqlash joyi va siyosatlarni belgilaydi, mahsulot jamoalari esa o‘z ilovalaridagi topilmalarni tuzatish uchun javob beradi. Mas’uliyatni aniq taqsimlash muhim: busiz SBOM omborda to‘planadi, ammo xabarnomalarga hech kim javob bermaydi. SBOM’ni tashqariga — buyurtmachilar, regulyatorlar, hamkorlarga — kimga va qaysi ko‘rinishda uzatilishini hamda unda qaysi ma’lumotlarni oshkor qilish joizligini oldindan hal qilish ham foydali.

Amaliy misol: yangi CVE paydo bo‘lganda nima qilish kerak

Tasavvur qiling, mashhur kutubxonada muhim zaiflik e’lon qilindi. SBOM bo‘lmasa, jamoa ishlab chiqish chatlariga savollar tarqatadi, javob kutadi va yo‘l-yo‘lakay ayrim ilovalar eski ko‘rsatmalar bo‘yicha yig‘ilishini aniqlaydi. SBOM bilan tartib boshqacha:

1. AX xizmati zaif komponent va versiyani barcha saqlangan SBOM bo‘yicha qidiradi va ta’sirlangan ilovalar hamda relizlar ro‘yxatini oladi.
2. Ro‘yxat muhimlik bo‘yicha saralanadi: internet-servislar va sezgir ma’lumotli tizimlar birinchi o‘rinda.
3. Har bir ilova uchun zaif kodga yetib borish mumkinligi aniqlanadi; bu yerda «ta’sirlangan / ta’sirlanmagan» VEX-maqomi yordam beradi.
4. Egalar o‘tish kerak bo‘lgan versiya va tuzatish muddati ko‘rsatilgan vazifalarni oladi.
5. Yangi yig‘ma siyosat bo‘yicha tekshiriladi: zaif versiyali komponent endi relizga o‘tmaydi.

«Bir necha kun qidirdik» va «bir necha daqiqada ro‘yxat oldik» o‘rtasidagi farq ko‘pincha zaiflikni hujumchilardan oldin yopishga ulgurasizmi-yo‘qmi, degan savolni hal qiladi.

Ko‘p beriladigan savollar

Manbalar

• CISA: Software Bill of Materials (SBOM)
• CycloneDX: Specification Overview
• SPDX: About the specification
• CISA: Apache Log4j Vulnerability Guidance