SAST va SCA pilotini 30 kunda qanday o‘tkazish kerak

30 kunlik SAST va SCA pilotu to‘rt bosqichga sig‘adi: tayyorgarlik va o‘rnatishga bir hafta, skanerlash va natijalarni saralashga ikki hafta, xulosa va qarorga bir hafta. Asosiysi — maqsadlar, repozitoriylar to‘plami va o‘lchanadigan muvaffaqiyat mezonlarini oldindan belgilab olish, aks holda mahsulotlarni solishtirish o‘rniga bir to‘p taassurotga ega bo‘lasiz.

Pilot nega kerak va u demodan nimasi bilan farq qiladi

Vendor demosi mahsulot imkoniyatlarini tayyorlangan misolda ko‘rsatadi. Pilot (proof of concept) mahsulot sizning kodingizda, sizning konveyeringizda va sizning odamlaringiz bilan qanday ishlashini ko‘rsatadi. U taqdimot bilan yopib bo‘lmaydigan savollarga javob beradi: nechta haqiqiy zaiflik topiladi, vosita qancha shovqin yaratadi, skanerlash qancha vaqt oladi va dasturchilar u bilan ishlashga rozi bo‘ladimi. Asos qilib olish kerak bo‘lgan tanlov mezonlari «SAST-analizatorni qanday tanlash kerak» maqolasida bayon etilgan.

0-hafta: boshlanishdan oldingi tayyorgarlik

Bu ish butun pilotning muvaffaqiyatini belgilaydi, shuning uchun uni mahsulotlarni o‘rnatishdan oldin bajaring.

• Maqsadlarni shakllantiring. Masalan: barcha jamoalar uchun SAST va SCA tanlash; yopiq konturda ishlashni tasdiqlash; yig‘ish vaqtiga ta’sirni baholash.
• Rollarni belgilang. AT xavfsizligi tomonidan pilot egasi, DevOps'dan texnik mas’ul, 2–3 nafar ishtirokchi dasturchi, vendor yoki integrator vakili.
• Repozitoriylarni tanlang. 3–5 loyiha: turli tillar va jamoalar, oldingi penetratsion testlardan ma’lum zaifliklari bo‘lgan bitta loyiha, bog‘liqliklar tarixi katta bo‘lgan bitta loyiha. Bu o‘tkazib yuborilgan zaifliklarni tekshirish uchun etalon beradi.
• Ruxsatlarni kelishing. Git'dagi hisob yozuvlari, CI huquqlari, tarmoq qoidalari, skanerlash serverini o‘rnatish uchun joy. Ruxsatlardagi kechikishlar muddatlarning buzilishiga eng ko‘p sabab bo‘ladi.
• Metrikalarni aniqlang. Quyidagi bo‘limga qarang.
• Ma’lumotlar masalasini hal qiling. Kodni tashqariga uzatish mumkin bo‘lmasa, faqat lokal o‘rnatishni so‘rang va buni yozma ravishda tasdiqlang.

1-hafta: o‘rnatish va birinchi ishga tushirish

• Yechimlarni test konturida o‘rnating va mehnat sarfini o‘lchang: qancha soat va qaysi mutaxassislar kerak bo‘ldi. Bu egalik qilish qiymatini baholashga kiradi.
• Repozitoriylarni ulang va standart sozlamalar bilan birinchi skanerlashni bajaring. Topilmalar sonini va skanerlash vaqtini qayd eting.
• SCA uchun mahsulot bog‘liqliklarni qanday aniqlashini tekshiring: manifestlardan, yig‘ishdan, tranzitiv bog‘liqliklar hisobga olinadimi. Masalan, Sonatype Lifecycle 20 dan ortiq til va paket formatini qo‘llab-quvvatlaydi hamda SBOM yaratadi, OWASP Dependency-Track esa CycloneDX formatidagi SBOM'ni qabul qiladi, shuning uchun har bir mahsulotga kirish ma’lumotlari qanday ko‘rinishda kerakligini aniqlashtiring. SBOM haqida batafsil — «SBOM nima».

2–3-haftalar: natijalarni saralash va CI'ga integratsiya

• Dasturchilar bilan birga triaj. Topilmalardan tasodifiy tanlanma oling (masalan, har bir mahsulot bo‘yicha 50–100 ta) va har birini haqiqiy, yolg‘on yoki «dolzarb emas» deb belgilang. Bir nechta nomzodni solishtirsangiz, topilmani qaysi mahsulot topganini bilmasdan, ko‘r-ko‘rona saralang.
• O‘tkazib yuborilganlarni tekshirish. Zaifliklari ma’lum loyihada har bir vosita pentest tasdiqlagan narsani topganini tekshiring.
• CI/CD'ga integratsiya. GitLab, GitHub yoki Jenkins'da pull request skanerlashini ulang. Tekshiruv vaqtini o‘lchang va inkremental rejim ishlayotganiga ishonch hosil qiling; OWASP SAST'ni aynan pull request'da ishga tushirishni tavsiya qiladi.
• SCA siyosatlari. Kritik zaifliklar va taqiqlangan litsenziyalarda yig‘ishni to‘xtatuvchi qoidani sozlang va u nechta yig‘ishni to‘xtatishini ko‘ring. Jamoalar ishini falaj qilmaslik uchun avval ogohlantirish rejimini yoqing.
• Zararli paketlardan himoya. Agar bunday funksiyani baholayotgan bo‘lsangiz, uni alohida tekshiring. Sonatype'da bu Firewall mahsulotining vazifasi bo‘lib, u zararli komponentlarni yuklab olishda bloklaydi va shubhalilarini karantinga joylaydi.
• Sozlash. Yolg‘on ishga tushishlarni bostirib ko‘ring, o‘z qoidangizni qo‘shing, Jira'da vazifalar tayinlang. Bu jamoangiz uchun qanchalik oson ekanini baholang.

4-hafta: yakunlar va qaror

• Metrikalarni har bir nomzod bo‘yicha yagona jadvalga to‘plang.
• Dasturchilar bilan retrospektiva o‘tkazing: nima xalaqit berdi, nima yordam berdi, ular bu vosita bilan har kuni ishlashga tayyormi.
• 3 yillik hisob-kitobli tijoriy taklif so‘rang va infratuzilma hamda qo‘llab-quvvatlash qiymatini qo‘shing. Hisoblash yondashuvi — «Open-source yoki tijoriy AppSec vositalari» maqolasida.
• Rahbariyat uchun qisqa hisobot tayyorlang: nimani tekshirdingiz, nimani aniqladingiz, qaysi qarorni tavsiya qilasiz va qanday xavflar qolmoqda.

Qaysi metrikalarni yig‘ish kerak

• Haqiqiy ishga tushishlar ulushi: tanlanmadagi haqiqiy topilmalarning uning hajmiga nisbati.
• Ma’lum zaifliklarni qamrab olish: avval tasdiqlangan nuqsonlardan nechtasi topildi.
• Skanerlash vaqti: repozitoriyni to‘liq va pull request'ni skanerlash.
• Tillar va bog‘liqliklarni qamrab olish: stekning barcha texnologiyalari tahlil qilinganmi, «ko‘r zonalar» yo‘qmi.
• Joriy etish va qo‘llab-quvvatlashga mehnat sarfi: kishi-soatlarda.
• Bitta topilmani saralash vaqti: dasturchilarda o‘lchang.
• Dasturchi uchun qulaylik: pilotdan keyin ishtirokchilar o‘rtasida qisqa so‘rovnoma.
• Sizning konturingizda ishlash: agar bu talab bo‘lsa, tashqi tarmoqqa chiqmasdan o‘rnatish tasdiqlanganmi.

Chegaraviy qiymatlarni oldindan kelishib oling, masalan «haqiqiy ishga tushishlar ulushi kelishilgan ko‘rsatkichdan past emas» va «pull request tekshiruvi belgilangan vaqtdan oshmaydi». Aniq qiymatlar tashkilotingizga bog‘liq, universal me’yorlar mavjud emas.

Pilotning odatiy xatolari

• Yozma muvaffaqiyat mezonlari yo‘q. Natijada kim ishonarliroq gapirsa, o‘sha hal qiladi.
• Pilot faqat demo loyihalarda. Ular haqiqiy shovqin va murakkablikni ko‘rsatmaydi.
• Dasturchilar jalb qilinmagan. Ularsiz haqiqiy va yolg‘on ishga tushishlarni baholab bo‘lmaydi.
• Nomzodlar juda ko‘p. Ikki-uch mahsulot — 30 kunda har birini sifatli baholash mumkin bo‘lgan chegara.
• Nomzodlar uchun turli sharoitlar. Bir xil repozitoriylar, sozlashning bir xil chuqurligi, bir xil muddatlar.
• Qarorsiz pilot. Qarorni kim va qachon qabul qilishini oldindan belgilang, aks holda loyiha cho‘zilib ketadi.

Pilotdan keyin nima qilish kerak

Mahsulot tanlangach, qamrovni bosqichma-bosqich kengaytiring: avval kritik ilovalar, keyin qolgan jamoalar. «Faqat ogohlantirishlar» rejimidan boshlang, so‘ng kritik topilmalar bo‘yicha bloklashni kiriting. To‘liq manzara uchun DevSecOps xaritasini ko‘rib chiqing: DevSecOps joriy etish xizmatlari vositalarni shunchaki o‘rnatmasdan, jarayonlarga joylashtirishga yordam beradi. Pilot uchun mahsulotlarni solishtirish: SAST va SCA.

Pilot yakunlari bo‘yicha hisobot shabloni

Pilot natijalarini rahbariyatga ko‘rsatish va xaridda foydalanish mumkin bo‘lishi uchun ularni besh bo‘limdan iborat qisqa hujjatga rasmiylashtiring. Birinchisi — maqsadlar va chegaralar: qaysi repozitoriylar va mahsulotlar qatnashdi va qanday sharoitlarda. Ikkinchisi — har bir nomzod bo‘yicha metrikalar jadvali. Uchinchisi — dasturchilarning xulosalari: nima qulay bo‘ldi va nima xalaqit berdi. To‘rtinchisi — mehnat sarfi va uch yillik egalik qilish qiymatining bahosi. Beshinchisi — tavsiya va bosqichlar hamda mas’ullar ko‘rsatilgan joriy etish rejasi.

Hisobotga haqiqiy topilmalardan namunalar ilova qiling: vosita aniqlagan ikki-uch tasdiqlangan zaiflik va ikki-uch odatiy yolg‘on topilma. Bunday misollar rahbariyatni har qanday foizdan yaxshiroq ishontiradi, chunki ular qiymat va xarajatlarni sizning kodingizdagi aniq holatlarda ko‘rsatadi.

Tashkiliy tomonni ham unutmang: ishlab chiqish jamoalarini bir oy davomida konveyerlarida qo‘shimcha tekshiruvlar paydo bo‘lishi haqida oldindan ogohlantiring va pilot natijalari alohida dasturchilarni baholash uchun ishlatilmasligini tushuntiring. Bunsiz ishtirokchilar muammolarni yashira boshlaydi yoki skanerlashni aylanib o‘tadi, natijada siz buzilgan manzaraga ega bo‘lasiz. Pilot bo‘yicha savollar uchun yagona kanal va to‘siqlar hamda oraliq raqamlar muhokama qilinadigan haftalik qisqa uchrashuv belgilang.

Agar pilot bir nechta mamlakatda yoki xolding bir nechta yuridik shaxsida o‘tkazilsa, yagona metrikalar to‘plamini oldindan belgilang: shunda natijalarni maydonchalar o‘rtasida solishtirish va xarid hamda barcha jamoalar uchun standart bo‘yicha umumiy qaror qabul qilish mumkin bo‘ladi.

Ko‘p so‘raladigan savollar

Manbalar

• OWASP DevSecOps Guideline: Static Application Security Testing
• Sonatype Lifecycle: mahsulot sahifasi
• Sonatype Firewall: mahsulot sahifasi
• OWASP Dependency-Track
• Semgrep Docs: Semgrep Code overview