DevSecOps: joriy etishni nimadan boshlash — bosqichma-bosqich reja

DevSecOps — bu bitta skaner sotib olish emas, jarayonning o‘zgarishi: xavfsizlik ishlab chiqishning har bir bosqichining bir qismiga aylanadi. Yetuklikni baholash va muhim tizimlar ro‘yxatidan boshlash, so‘ng tezkor g‘alabalarni (SCA, sirlar, artefaktlar repozitoriysi) amalga oshirish, tekshiruvlarni yumshoq quality gates bilan CI/CD’ga integratsiya qilish, odamlarni o‘qitish va natijani o‘lchash lozim. Qozog‘iston va Markaziy Osiyodagi loyihalarimizda qo‘llaydigan rejani ulashamiz.

1-qadam. Hozir qayerdaligingizni tushunish

Inventarizatsiyadan boshlang: sizda nechta ilova va jamoa bor, kod qayerda saqlanadi, CI/CD va relizlar qanday tuzilgan, qanday tekshiruvlar allaqachon mavjud. Yetuklik modellariga tayanish foydali: OWASP SAMM (Software Assurance Maturity Model) — xavfsiz ishlab chiqishning joriy amaliyotlarini baholashga, iteratsiyalar bilan muvozanatli dastur qurishga va taraqqiyotni o‘lchashga yordam beradigan ochiq doira; OWASP DSOMM (DevSecOps Maturity Model) — aynan DevSecOps’ga yo‘naltirilgan OWASP loyihasi. Ular boshlang‘ich nuqta va maqsadli darajani qayd etadi, shunda maqsad «xavfsizroq bo‘lishni xohlaymiz» iborasiga aylanib qolmaydi.

Jarayonga qo‘yiladigan talablar uchun tayanch sifatida NIST SP 800-218 (SSDF) xizmat qilishi mumkin — 2022-yil fevralida e’lon qilingan xavfsiz ishlab chiqishning yuqori darajadagi amaliyotlari to‘plami. U ishlab chiqish hayotiy siklining istalgan modeliga mos keladi va buyurtmachilar hamda yetkazib beruvchilarga xavfsizlik haqida gaplashish uchun umumiy til beradi.

2-qadam. Xavflar va ustuvorliklarni aniqlash

Barcha ilovalar bir xil darajada muhim emas. Internet-banking va ichki wiki turli darajadagi nazoratni talab qiladi. Muhim tizimlar ro‘yxatini tuzing — ular qayta ishlaydigan ma’lumotlar, internetdan mavjudligi va biznesga ta’siri bo‘yicha — va joriy etishni ulardan boshlang. Bunday ro‘yxat bir vaqtning o‘zida byudjet uchun asos bo‘ladi: joriy etish byudjeti ilovalar soni, jamoalar va tanlangan vositalarga bog‘liq.

3-qadam. Tezkor g‘alabalar

• SCA va open-source nazorati. Yolg‘on ishga tushishlar minimal, samara maksimal — SAST, DAST va SCA farqiga qarang.
• Sirlar koddan tashqarida. Repozitoriylardagi parollar va tokenlarni toping va ularni sirlar omboriga ko‘chiring — sirlar haqida batafsil.
• Himoyalangan artefaktlar repozitoriysi zararli paketlarni bloklash bilan.

Bu choralar ishlab chiqish jarayonlarini buzmasdan, haftalar ichida sezilarli samara beradi va rahbariyatga birinchi natijalarni ko‘rsatadi.

4-qadam. Tekshiruvlarni konveyerga integratsiya qilish

Har bir tekshiruvga o‘z o‘rni bor:

• Commit / pull request: o‘zgargan kod bo‘yicha SAST, sirlarni qidirish.
• Yig‘ish: SCA, SBOM shakllantirish, konteyner image’larini skanerlash.
• Test stendi: DAST, frontend uchun FAST.
• Prodakshn: muntazam DAST-skanerlash va monitoring.

Boshidanoq quality gates bo‘yicha kelishib olish muhim: qaysi topilmalar relizni bloklaydi, qaysilari vazifa sifatida ochiladi. Yumshoq boshlang — xabardor qilishdan, qoidalarni asta-sekin qattiqlashtiring. DAST’ning rejalashtirilgan skanerlari uchun jadval bo‘yicha rejim yaxshi mos keladi, masalan, sozlangandan keyin minimal ishtirok talab qiladigan tungi ishga tushirish. GitLab uchun texnik tomoni GitLab CI’ga SAST va SCA’ni qanday integratsiya qilish maqolasida tahlil qilingan.

5-qadam. Vositalarni pilot orqali tanlash

Vositani vendor taqdimotiga qarab sotib olmang. Turli jamoalarning 3–5 ta repozitoriysini oling, nomzodlarni bir xil ma’lumotlarda tekshiring va haqiqiy topilmalar ulushini, skanerlash tezligini va dasturchilar uchun qulaylikni baholang. Bunday testni qanday tashkil etish 30 kunda SAST va SCA pilot maqolasida tavsiflangan.

6-qadam. Odamlarni o‘qitish

Dasturchilar natijalarni tushunmasa, vositalar foydasiz. Xavfsiz ishlab chiqish va topilmalarni tahlil qilish bo‘yicha qisqa amaliy kurslar eng tez o‘zini oqlaydi. Biz AppSec va DevSecOps bo‘yicha korporativ o‘qitish o‘tkazamiz. Yaxshi amaliyot — har bir ishlab chiqish jamoasida topilmalarni birinchi bo‘lib tahlil qiladigan va hamkasblarga yordam beradigan «xavfsizlik chempioni»ni ajratish.

7-qadam. O‘lchash

• Tekshiruvlar bilan qamrab olingan ilovalar ulushi
• Muhim zaifliklarni tuzatishning o‘rtacha vaqti (MTTR)
• Prodakshndan oldin va keyin topilgan zaifliklar soni
• Yolg‘on ishga tushishlar ulushi

Metrikalar hisobot uchun hisobot emas, kerak: ular jarayon qayerda to‘xtab qolayotganini ko‘rsatadi va keyingi moliyalashtirishni asoslash ularga tayanadi.

Odatiy xatolar

• Vosita sotib olib, «hammasini yoqib qo‘yish» — jamoa minglab topilmalarda cho‘kadi.
• Relizlarni birinchi kundan bloklash — ishlab chiqish tekshiruvlarni aylanib o‘ta boshlaydi.
• DevSecOps’ni faqat AX kuchi bilan, ishlab chiqish va DevOps ishtirokisiz amalga oshirish.
• Tuzatish egalarini tayinlamaslik: mas’uli yo‘q topilmalar yopilmaydi.

Agar tashkilotingiz uchun harakatlar xaritasi kerak bo‘lsa, uni DevSecOps joriy etish sahifasida olish mumkin.

Rollar va mas’uliyat

Xavfsizlik uchun faqat bitta bo‘lim javob bersa, DevSecOps ishlamaydi. Amaliy taqsimot quyidagicha: AX xizmati siyosatlar va talablarni belgilaydi, yuqori xavfli topilmalarni tahlil qiladi va metrikalarni nazorat qiladi; dasturchilar o‘z kodi va bog‘liqliklaridagi nuqsonlarni tuzatadi; DevOps-muhandislar tekshiruvlarni konveyerlarga integratsiya qiladi va vositalar infratuzilmasini qo‘llab-quvvatlaydi; mahsulot egalari istisnolar va ustuvorliklar haqida qaror qabul qiladi. Bir nechta jamoali yirik tashkilotlar uchun har bir jamoada xavfsizlik uchun mas’ulni tayinlash foydali — u AX bilan aloqa nuqtasiga aylanadi.

Joriy etishda sur’atni qanday yo‘qotmaslik

Muvaffaqiyatsizlikning eng ko‘p uchraydigan stsenariysi — natijasi kechiktirilgan katta loyiha. Birinchi foydagacha bir yil ketadigan joriy etish rahbariyat yordamini va jamoalar ishtiyoqini yo‘qotadi. Teskari yondashuv ishlaydi: har biri ikki–to‘rt haftalik qisqa iteratsiyalar, ularning har birida jamoa aniq ko‘rinadigan natija oladi — topilgan va yopilgan sirlar, bloklangan zararli paket, muhim ilovalar holati bo‘yicha hisobot. Har bir iteratsiyadan keyin ustuvorliklarni oldingi bo‘limdagi metrikalar bo‘yicha qayta ko‘rib chiqish kerak.

Xavfsizlik bo‘yicha to‘plangan texnik qarz bilan ishlashni alohida o‘ylab ko‘rish lozim. Eski kod deyarli doim yuzlab topilmalarni o‘z ichiga oladi. Hammasini birdaniga yopishga urinmang: joriy holatni bazaviy chiziq sifatida qayd eting, o‘zgarishlarda yangi muhim muammolar paydo bo‘lishiga yo‘l qo‘ymang va eski qarzni alohida backlog‘da rejali qisqartiring.

DevSecOps oddiy AppSec’dan nimasi bilan farq qiladi

Ilovalar xavfsizligiga klassik yondashuv — reliz oldidan davriy tekshiruvlar, ko‘pincha tashqi mutaxassislar kuchi bilan. DevSecOps bu tekshiruvlarning bir qismini kundalik ishga ko‘chiradi: har bir o‘zgarishda avtomatik skanerlash, dasturchiga tezkor aloqa, barcha jamoalar uchun yagona siyosatlar. Davriy chuqurlashtirilgan tekshiruvlar yo‘qolmaydi: muhim tizimlarning pentesti va ekspert tahlili dasturning muhim qismi bo‘lib qoladi, lekin endi ular doimiy nazoratni almashtirmaydi, to‘ldiradi.

Dasturchilar uchun nima o‘zgaradi

Muvaffaqiyat yangi tekshiruvlar kundalik ishda qanday his etilishiga bog‘liq. Topilmalar dasturchi allaqachon ishlayotgan joyga kelishi kerak: pull request’ga, IDE’ga, vazifalar trekeriga. Har bir topilmada tushunarli tavsif, koddagi joy va tuzatish bo‘yicha tavsiya bo‘lishi kerak. Kontekstsiz «500 ta muammo topildi» kabi xabarlar rad etishni uyg‘otadi, tuzatishning tayyor usuli bilan uchta aniq topilma esa — harakatni. Shuning uchun boshida skanerlarni qat’iy ravishda nuqsonlarning muhim sinflariga sozlash va jamoa o‘rganib borgan sari qamrovni kengaytirish ma’qul.

Muhim jihat — vaqt. Agar pull request’dagi tekshiruv o‘nlab daqiqa davom etsa, uni aylanib o‘ta boshlashadi. Og‘ir skanerlar tungi ishga tushirishlarga yoki reliz branch’lariga chiqariladi, tez tekshiruvlar (sirlarni qidirish, o‘zgargan fayllar bo‘yicha SAST, manifestlar bo‘yicha SCA) esa asosiy oqimda qoldiriladi.

Loyihani rahbariyat oldida qanday asoslash

Rahbariyatni vositalar nomlari kamdan-kam qiziqtiradi. Uning bilan xavflar va qiymat tilida gaplashgan ma’qul: qaysi tizimlar muhim, insident bo‘lsa nima bo‘ladi, regulyatorlar va buyurtmachilar qanday talablar qo‘yadi, hozir reliz oldidan qo‘lda tekshiruvlarga qancha vaqt ketadi. Boshlang‘ich o‘lchovlar (qamrov, tuzatish vaqti, prodakshndagi topilmalar soni) hisob boshi nuqtasini beradi, metrikalarning bir necha chorakdan keyingi dinamikasi esa loyihani davom ettirish uchun dalilga aylanadi. Har birida tushunarli natijasi bor bir necha iteratsiyadan iborat reja tayyorlang, shunda byudjet muhokamasi aniq mazmun kasb etadi.

Ko‘p beriladigan savollar

Manbalar

• OWASP SAMM
• OWASP DevSecOps Maturity Model (DSOMM)
• NIST SP 800-218: Secure Software Development Framework (SSDF) v1.1
• OWASP DevSecOps Guideline: DAST