DevSecOps-dan qo'rqish va nafrat

Bizda 2 ta kod analizatori, 4 ta dinamik sinov vositasi, oʻz qoʻl sanʼatimiz va 250 ta skriptimiz bor edi. Bularning barchasi hozirgi jarayonda kerak emas, lekin DevSecOps-ni amalga oshirishni boshlaganingizdan so'ng, siz oxirigacha borishingiz kerak.

manba. Qahramonlar yaratuvchilari: Jastin Roiland va Den Harmon.

SecDevOps nima? DevSecOps haqida nima deyish mumkin? Qanday farqlar bor? Ilova xavfsizligi - bu nima haqida? Nima uchun klassik yondashuv endi ishlamaydi? Bu savollarning barchasiga javobni biladi Yuriy Shabalin dan Qilich baliq xavfsizligi. Yuriy hamma narsaga batafsil javob beradi va klassik Application Security modelidan DevSecOps jarayoniga o'tish muammolarini tahlil qiladi: xavfsiz ishlab chiqish jarayonini DevOps jarayoniga integratsiyalashuviga qanday to'g'ri yondashish va hech narsani buzmaslik, asosiy bosqichlardan qanday o'tish kerak. xavfsizlik testlari, qanday vositalardan foydalanish mumkin va ular nima bilan farq qiladi va tuzoqlarga duch kelmaslik uchun ularni qanday qilib to'g'ri sozlash kerak.

Ma'ruzachi haqida: Yuriy Shabalin - Kompaniyada bosh xavfsizlik arxitektori Qilich baliq xavfsizligi. SSDL-ni joriy qilish, ilovalarni tahlil qilish vositalarini yagona ishlab chiqish va sinov ekotizimiga umumiy integratsiya qilish uchun javobgar. Axborot xavfsizligi sohasida 7 yillik tajriba. Dasturiy ta'minotni ishlab chiqadigan va xizmatlar ko'rsatadigan "Alfa-Bank", "Sberbank" va "Positive Technologies" da ishlagan. ZerONights, PHDays, RISSPA, OWASP xalqaro konferentsiyalarida ma'ruzachi.

Ilova xavfsizligi: bu nima haqida?

Ilova xavfsizligi - Bu dastur xavfsizligi uchun javobgar bo'lgan xavfsizlik bo'limi. Bu infratuzilma yoki tarmoq xavfsizligiga taalluqli emas, balki biz yozgan narsalarga va ishlab chiquvchilar nimalar ustida ishlayotganiga taalluqlidir - bular ilovaning o'zi kamchiliklari va zaif tomonlari.

Nishon SDL yoki SDLC - Xavfsizlikni rivojlantirish hayot aylanishi - Microsoft tomonidan ishlab chiqilgan. Diagrammada kanonik SDLC modeli ko'rsatilgan, uning asosiy vazifasi rivojlanishning har bir bosqichida, talablardan tortib chiqarish va ishlab chiqarishgacha bo'lgan xavfsizlikning ishtirokidir. Microsoft sanoatda juda ko'p xatolar borligini, ular ko'proq ekanligini va buning uchun nimadir qilish kerakligini tushundi va ular kanonik bo'lib qolgan ushbu yondashuvni taklif qilishdi.

Ilova xavfsizligi va SSDL, odatda ishonganidek, zaifliklarni aniqlashga emas, balki ularning paydo bo'lishining oldini olishga qaratilgan. Vaqt o'tishi bilan Microsoft-ning kanonik yondashuvi takomillashtirildi, ishlab chiqildi va chuqurroq, batafsilroq sho'ng'inga kiritildi.

Kanonik SDLC turli metodologiyalarda juda batafsil - OpenSAMM, BSIMM, OWASP. Metodologiyalar har xil, ammo umuman olganda o'xshash.

Yetuklik modelida xavfsizlikni qurish

Menga eng yoqadi BSIMM - Yetuklik modelida xavfsizlikni qurish. Metodologiyaning asosi Ilova xavfsizligi jarayonini 4 domenga bo'lishdir: Boshqaruv, Razvedka, SSDL aloqa nuqtalari va Deployment. Har bir domenda 12 ta faoliyat sifatida ifodalangan 112 ta amaliyot mavjud.

112 ta faoliyatning har biri mavjud 3 etuklik darajasi: boshlang'ich, o'rta va rivojlangan. Siz barcha 12 ta amaliyotni bo'lim bo'yicha o'rganishingiz, siz uchun muhim bo'lgan narsalarni tanlashingiz, ularni qanday amalga oshirishni aniqlashingiz va asta-sekin elementlarni qo'shishingiz mumkin, masalan, statik va dinamik kod tahlili yoki kodni ko'rib chiqish. Tanlangan tadbirlarni amalga oshirish doirasida siz reja yozasiz va unga muvofiq xotirjamlik bilan ishlaysiz.

Nima uchun DevSecOps

DevOps - bu xavfsizlikni hisobga olish kerak bo'lgan umumiy, katta jarayon.

avval DevOps xavfsizlik tekshiruvlarini o'z ichiga oladi. Amalda, xavfsizlik guruhlari soni hozirgidan ancha kam edi va ular jarayon ishtirokchisi sifatida emas, balki unga talablar qo'yadigan va mahsulot sifatini ishlab chiqarish oxirida tekshiradigan nazorat va nazorat organi sifatida harakat qildilar. Bu xavfsizlik guruhlari rivojlanishdan devor orqasida bo'lgan va jarayonda qatnashmagan klassik yondashuv.

Asosiy muammo shundaki, axborot xavfsizligi rivojlanishdan ajralib turadi. Odatda bu qandaydir axborot xavfsizligi sxemasi bo'lib, unda 2-3 ta katta va qimmat vositalar mavjud. Har olti oyda bir marta tekshirilishi kerak bo'lgan manba kodi yoki dastur keladi va yiliga bir marta ishlab chiqariladi pentestlar. Bularning barchasi sanoatning chiqarilish sanasi kechiktirilishiga olib keladi va ishlab chiquvchi avtomatlashtirilgan vositalardan juda ko'p zaifliklarga duchor bo'ladi. Bularning barchasini qismlarga ajratish va ta'mirlash mumkin emas, chunki oldingi olti oylik natijalar saralanmagan, ammo bu erda yangi partiya.

Kompaniyamiz faoliyati davomida biz barcha sohalar va sohalardagi xavfsizlik bir xil g'ildirakda rivojlanishga erishish va aylanish vaqti kelganini tushunayotganini ko'ramiz. Agile. DevSecOps paradigmasi agile ishlab chiqish metodologiyasi, amalga oshirish, qo'llab-quvvatlash va har bir nashr va iteratsiyada ishtirok etish bilan juda mos keladi.

DevSecOps-ga o'tish

Xavfsizlikni rivojlantirish hayot tsiklidagi eng muhim so'z "jarayon". Asboblarni sotib olish haqida o'ylashdan oldin buni tushunishingiz kerak.

DevOps jarayoniga oddiygina vositalarni kiritish etarli emas - jarayon ishtirokchilari o'rtasidagi muloqot va tushunish muhimdir.

Asboblar emas, odamlar muhimroqdir.

Ko'pincha, xavfsiz rivojlanish jarayonini rejalashtirish vositani tanlash va sotib olish bilan boshlanadi va asbobni joriy jarayonga qo'shishga urinishlar bilan yakunlanadi, bu esa urinishlar bo'lib qoladi. Bu baxtsiz oqibatlarga olib keladi, chunki barcha vositalar o'ziga xos xususiyatlarga va cheklovlarga ega.

Xavfsizlik bo'limi keng imkoniyatlarga ega yaxshi, qimmat vositani tanlagan va uni jarayonga qo'shish uchun ishlab chiquvchilarga kelganida odatiy holdir. Ammo bu ish bermayapti - jarayon shunday tuzilganki, allaqachon sotib olingan vositaning cheklovlari hozirgi paradigmaga mos kelmaydi.

Birinchidan, qanday natijaga erishmoqchi ekanligingizni va jarayon qanday ko'rinishini tasvirlab bering. Bu jarayonda vosita va xavfsizlikning rolini tushunishga yordam beradi.

Foydalanilayotgan narsadan boshlang

Qimmatbaho asboblarni sotib olishdan oldin, sizda bor narsaga qarang. Har bir kompaniyada rivojlanish uchun xavfsizlik talablari bor, tekshiruvlar, pentestlar mavjud - nega bularning barchasini hamma uchun tushunarli va qulay shaklga aylantirmaysiz?

Odatda talablar javonda yotadigan qog'oz Talmuddir. Jarayonlarni ko'rish uchun kompaniyaga kelganimizda va dasturiy ta'minot uchun xavfsizlik talablarini ko'rishni so'raganimizda shunday holat bo'ldi. Bu bilan shug'ullangan mutaxassis uzoq vaqt qidirdi:

- Endi, eslatmalarning bir joyida bu hujjat yotadigan yo'l bor edi.

Natijada hujjatni bir haftadan keyin oldik.

Talablar, cheklar va boshqa narsalar uchun, masalan, sahifa yarating. Birlashuv - hamma uchun qulay.

Sizda mavjud bo'lgan narsalarni qayta formatlash va boshlash uchun undan foydalanish osonroq.

Xavfsizlik chempionlaridan foydalaning

Odatda, 100-200 ta ishlab chiquvchiga ega bo'lgan o'rtacha kompaniyada bir nechta funktsiyalarni bajaradigan va jismonan hamma narsani tekshirishga vaqtlari bo'lmagan bitta xavfsizlik mutaxassisi mavjud. Agar u qo'lidan kelganicha harakat qilsa ham, u faqat ishlanma yaratadigan barcha kodlarni tekshirmaydi. Bunday holatlar uchun kontseptsiya ishlab chiqilgan - Xavfsizlik bo'yicha chempionlar.

Xavfsizlik bo'yicha chempionlar - bu sizning mahsulotingiz xavfsizligidan manfaatdor bo'lgan ishlab chiqish guruhidagi odamlar.

Xavfsizlik chempioni - bu rivojlanish guruhiga kirish nuqtasi va xavfsizlik bo'yicha xushxabarchi.

Odatda, xavfsizlik bo'yicha mutaxassis ishlab chiqish guruhiga kelib, koddagi xatoni ko'rsatsa, u ajablanib javob oladi:

- Siz kimsiz? Sizni birinchi marta ko'ryapman. Menda hamma narsa yaxshi - mening katta do'stim menga kodni ko'rib chiqishda "qo'llash" ni berdi, biz davom etamiz!

Bu odatiy holat, chunki ishlab chiquvchi doimiy ravishda ishda va kodni ko'rib chiqishda o'zaro aloqada bo'lgan keksalarga yoki oddiygina jamoadoshlariga ko'proq ishonch bor. Agar xavfsizlik xodimi o'rniga xavfsizlik chempioni xato va oqibatlarga ishora qilsa, unda uning so'zi ko'proq og'irlik qiladi.

Bundan tashqari, ishlab chiquvchilar o'z kodlarini har qanday xavfsizlik mutaxassisiga qaraganda yaxshiroq bilishadi. Statik tahlil vositasida kamida 5 ta loyihaga ega bo'lgan odam uchun odatda barcha nuanslarni eslab qolish qiyin. Xavfsizlik chempionlari o'z mahsulotlarini bilishadi: nima bilan o'zaro ta'sir qilishlari va birinchi navbatda nimaga e'tibor berishlari - ular samaraliroq.

Shunday qilib, Xavfsizlik chempionlarini qo'llash va xavfsizlik guruhingiz ta'sirini kengaytirish haqida o'ylab ko'ring. Bu chempionning o'zi uchun ham foydalidir: yangi sohada kasbiy rivojlanish, uning texnik ufqlarini kengaytirish, texnik, boshqaruv va etakchilik mahoratini oshirish, bozor qiymatini oshirish. Bu ijtimoiy muhandislikning ba'zi bir elementi, rivojlanish guruhidagi "ko'zlaringiz".

Sinov bosqichlari

Paradigma 20 dan 80 gacha 20% harakat 80% natija beradi, deydi. Bu 20% avtomatlashtirilishi mumkin bo'lgan va kerak bo'lgan ilovalarni tahlil qilish amaliyotidir. Bunday faoliyatga misollar statik tahlil - SAST, dinamik tahlil - DAST и Ochiq manba nazorati. Men sizga tadbirlar haqida, shuningdek, vositalar haqida batafsil ma'lumot beraman, biz ularni jarayonga kiritishda odatda qanday xususiyatlarga duch kelamiz va buni qanday qilib to'g'ri bajarish kerak.

Asboblarning asosiy muammolari

Men barcha asboblar uchun tegishli bo'lgan va e'tibor talab qiladigan muammolarni ta'kidlayman. Yana takrorlamaslik uchun ularni batafsil tahlil qilaman.

Uzoq tahlil vaqti. Agar barcha sinovlar va yig'ilishlar uchun majburiyatni chiqarishdan boshlab 30 daqiqa vaqt kerak bo'lsa, axborot xavfsizligini tekshirish bir kun davom etadi. Shunday qilib, hech kim jarayonni sekinlashtirmaydi. Ushbu xususiyatni hisobga oling va xulosa chiqaring.

Yuqori darajadagi noto'g'ri salbiy yoki noto'g'ri ijobiy. Barcha mahsulotlar har xil, barchasi turli ramkalar va o'zlarining kodlash uslublaridan foydalanadi. Turli kod bazalari va texnologiyalarida asboblar turli darajadagi noto'g'ri salbiy va noto'g'ri pozitivlarni ko'rsatishi mumkin. Shunday qilib, aniq nima borligini ko'rib chiqing sizning kompaniyalar va uchun sizning ilovalar yaxshi va ishonchli natijalarni ko'rsatadi.

Mavjud vositalar bilan integratsiya yo'q. Asboblarni siz foydalanayotgan narsalar bilan integratsiya nuqtai nazaridan ko'rib chiqing. Misol uchun, agar sizda Jenkins yoki TeamCity bo'lsa, siz foydalanmayotgan GitLab CI bilan emas, balki ushbu dasturiy ta'minot bilan vositalarning integratsiyasini tekshiring.

Moslashtirishning etishmasligi yoki haddan tashqari murakkabligi. Agar vositada API bo'lmasa, u nima uchun kerak? Interfeysda bajarilishi mumkin bo'lgan hamma narsa API orqali mavjud bo'lishi kerak. Ideal holda, asbob cheklarni sozlash qobiliyatiga ega bo'lishi kerak.

Mahsulotni rivojlantirish yo'l xaritasi yo'q. Rivojlanish to'xtamaydi, biz doimo yangi ramkalar va funktsiyalardan foydalanamiz, eski kodni yangi tillarga qayta yozamiz. Biz sotib olgan vosita yangi ramkalar va texnologiyalarni qo'llab-quvvatlashiga ishonch hosil qilishni istaymiz. Shuning uchun mahsulotning haqiqiy va to'g'ri ekanligini bilish muhimdir nima bo'ladi? rivojlanish.

Jarayon xususiyatlari

Asboblarning xususiyatlariga qo'shimcha ravishda, rivojlanish jarayonining xususiyatlarini hisobga oling. Misol uchun, rivojlanishga to'sqinlik qilish keng tarqalgan xatodir. Keling, yana qanday xususiyatlarni hisobga olish kerakligini va xavfsizlik guruhi nimalarga e'tibor berish kerakligini ko'rib chiqaylik.

Ishlab chiqish va chiqarish muddatlarini o'tkazib yubormaslik uchun yarating turli qoidalar va har xil to'xtatuvchilarni ko'rsatish - zaifliklar mavjud bo'lganda qurish jarayonini to'xtatish mezonlari - turli muhitlar uchun. Misol uchun, biz hozirgi filialning rivojlanish stendiga yoki UATga borishini tushunamiz, ya'ni biz to'xtamaymiz va aytamiz:

"Bu erda zaif tomonlaringiz bor, siz boshqa joyga bormaysiz!"

Shu nuqtada, ishlab chiquvchilarga e'tibor berish kerak bo'lgan xavfsizlik muammolari mavjudligini aytish muhimdir.

Zaifliklarning mavjudligi keyingi sinovlarga to'sqinlik qilmaydi: qo'llanma, integratsiya yoki qo'llanma. Boshqa tomondan, ishlab chiquvchilar xavfsiz deb topilgan narsalarni e'tiborsiz qoldirmasliklari uchun mahsulot xavfsizligini qandaydir tarzda oshirishimiz kerak. Shuning uchun, ba'zida biz buni qilamiz: stendda, u rivojlanish muhitiga chiqarilganda, biz shunchaki ishlab chiqish haqida xabar beramiz:

- Bolalar, sizda muammolar bor, iltimos, ularga e'tibor bering.

UAT bosqichida biz yana zaifliklar haqida ogohlantirishlarni ko'rsatamiz va chiqarish bosqichida biz aytamiz:

- Bolalar, biz sizni bir necha bor ogohlantirdik, siz hech narsa qilmadingiz - biz sizni bu bilan qo'yib yubormaymiz.

Agar kod va dinamika haqida gapiradigan bo'lsak, unda faqat ushbu xususiyatda yozilgan xususiyatlar va kodlarning zaif tomonlarini ko'rsatish va ogohlantirish kerak. Agar ishlab chiquvchi tugmani 3 pikselga siljitsa va biz unga SQL in'ektsiyasi borligini va shuning uchun uni zudlik bilan tuzatish kerakligini aytsak, bu noto'g'ri. Faqat hozir nima yozilganiga va arizaga keladigan o'zgarishlarga qarang.

Aytaylik, bizda ma'lum bir funktsional nuqson bor - dastur ishlamasligi kerak: pul o'tkazilmaydi, tugmani bosganingizda keyingi sahifaga o'tmaydi yoki mahsulot yuklanmaydi. Xavfsizlik kamchiliklari - bular bir xil nuqsonlardir, lekin dasturning ishlashi nuqtai nazaridan emas, balki xavfsizlikda.

Barcha dasturiy ta'minot sifati muammolari xavfsizlik muammosi emas. Ammo barcha xavfsizlik muammolari dasturiy ta'minot sifati bilan bog'liq. Sherif Mansur, Expedia.

Barcha zaifliklar bir xil nuqsonlar bo'lganligi sababli, ular barcha rivojlanish nuqsonlari bilan bir joyda joylashgan bo'lishi kerak. Shunday qilib, hech kim o'qimaydigan hisobotlar va qo'rqinchli PDF-fayllarni unuting.

Men rivojlanish kompaniyasida ishlaganimda statik tahlil vositalaridan hisobot oldim. Men uni ochdim, dahshatga tushdim, qahva tayyorladim, 350 sahifani varaqladim, yopdim va ishlashni davom ettirdim. Katta hisobotlar o'lik xabarlardir. Odatda ular hech qaerga bormaydi, harflar o'chiriladi, unutiladi, yo'qoladi yoki biznes xavflarni qabul qilishini aytadi.

Nima qilish kerak? Biz shunchaki topilgan tasdiqlangan kamchiliklarni ishlab chiqish uchun qulay shaklga aylantiramiz, masalan, biz ularni Jira-da orqaga qo'yamiz. Biz nuqsonlarni birinchi o'ringa qo'yamiz va ularni funktsional nuqsonlar va sinov nuqsonlari bilan birga ustuvorlik tartibida yo'q qilamiz.

Statik tahlil - SAST

Bu zaifliklar uchun kod tahlili., lekin u SonarQube bilan bir xil emas. Biz shunchaki naqsh yoki uslubni tekshirmaymiz. Tahlil qilishda bir qator yondashuvlar qo'llaniladi: zaiflik daraxtiga ko'ra, bo'yicha DataFlow, konfiguratsiya fayllarini tahlil qilish orqali. Bu kodning o'ziga tegishli.

Yondashuvning ijobiy tomonlari: rivojlanishning dastlabki bosqichida koddagi zaifliklarni aniqlashhali stendlar yoki tayyor asboblar bo'lmaganda va bosqichma-bosqich skanerlash qobiliyati: kodning o'zgartirilgan qismini va faqat biz hozir qilayotgan funksiyani skanerlash, bu skanerlash vaqtini qisqartiradi.

Minusy - bu kerakli tillarni qo'llab-quvvatlamaslik.

Kerakli integratsiya, Mening sub'ektiv fikrimcha, asboblarda bo'lishi kerak:

• Integratsiya vositasi: Jenkins, TeamCity va Gitlab CI.
• Rivojlanish muhiti: Intellij IDEA, Visual Studio. Ishlab chiquvchi uchun hali ham eslab qolish kerak bo'lgan tushunarsiz interfeysga o'tmaslik, balki o'zining rivojlanish muhitida ish joyida topilgan barcha kerakli integratsiya va zaifliklarni ko'rish qulayroqdir.
• Kodni ko'rib chiqish: SonarQube va qo'lda ko'rib chiqish.
• Kamchiliklarni kuzatuvchilar: Jira va Bugzilla.

Rasmda statik tahlilning eng yaxshi vakillari ko'rsatilgan.

Asboblar emas, balki jarayon muhim, shuning uchun jarayonni sinab ko'rish uchun ham yaxshi bo'lgan ochiq manba echimlari mavjud.

SAST Open Source juda ko'p zaifliklar yoki murakkab DataFlowlarni topa olmaydi, lekin ular jarayonni yaratishda ishlatilishi mumkin va kerak. Ular jarayon qanday qurilishini, xatolarga kim javob berishini, kim xabar berishini va kim hisobot berishini tushunishga yordam beradi. Agar siz kodingiz xavfsizligini yaratishning dastlabki bosqichini amalga oshirmoqchi bo'lsangiz, Open Source echimlaridan foydalaning.

Agar siz sayohatning boshida bo'lsangiz va hech narsaga ega bo'lmasangiz, buni qanday qilib birlashtirish mumkin: CI yo'q, Jenkins yo'q, TeamCity yo'q? Keling, jarayonga integratsiyani ko'rib chiqaylik.

CVS darajasidagi integratsiya

Agar sizda Bitbucket yoki GitLab bo'lsa, siz darajada integratsiya qilishingiz mumkin Bir vaqtning o'zida versiyalar tizimi.

Voqea bo'yicha - so'rovni tortib ol, topshir. Siz kodni skanerlaysiz va tuzilish holati xavfsizlik tekshiruvidan o'tgan yoki muvaffaqiyatsizligini ko'rsatadi.

Qayta aloqa. Albatta, fikr-mulohaza har doim zarur. Agar siz shunchaki yon tomondan xavfsizlikni ta'minlagan bo'lsangiz, uni qutiga soling va bu haqda hech kimga aytmasangiz, keyin oy oxirida bir nechta xatolarni tashlab qo'ygan bo'lsangiz - bu to'g'ri emas va yaxshi emas.

Kodni ko'rib chiqish tizimi bilan integratsiya

Bir marta, biz bir qator muhim loyihalarda texnik AppSec foydalanuvchisi uchun standart sharhlovchi sifatida ishladik. Yangi kodda xatolar aniqlanganmi yoki xatolik yo'qligiga qarab, ko'rib chiquvchi tortishish so'rovi holatini "qabul qilish" yoki "ish kerak" holatini o'rnatadi - yoki hammasi joyida yoki aniq nima yaxshilanishi kerak bo'lgan havolalar. takomillashtirish kerak. Ishlab chiqarilayotgan versiya bilan integratsiya qilish uchun, agar axborot xavfsizligi testidan o'tmagan bo'lsa, biz birlashtirishni taqiqlashni yoqdik. Biz buni qo'lda kodni ko'rib chiqishga kiritdik va jarayonning boshqa ishtirokchilari ushbu jarayon uchun xavfsizlik holatini ko'rdilar.

SonarQube bilan integratsiya

Ko'pchilik bor sifatli darvoza kod sifati nuqtai nazaridan. Bu erda ham xuddi shunday - siz bir xil eshiklarni faqat SAST asboblari uchun qilishingiz mumkin. Xuddi shu interfeys, bir xil sifatli darvoza bo'ladi, faqat u chaqiriladi xavfsizlik eshigi. Bundan tashqari, agar sizda SonarQube-dan foydalangan holda jarayon bo'lsa, u erda hamma narsani osongina birlashtira olasiz.

CI darajasida integratsiya

Bu erda hamma narsa juda oddiy:

• Avtotestlar bilan teng, birlik sinovlari.
• Rivojlanish bosqichlari bo'yicha bo'linish: ishlab chiqish, sinov, ishlab chiqarish. Turli xil qoidalar to'plami yoki turli xil muvaffaqiyatsizlik holatlari kiritilishi mumkin: yig'ishni to'xtating, yig'ishni to'xtatmang.
• Sinxron/asinxron ishga tushirish. Biz xavfsizlik testlarining tugashini kutmoqdamiz yoki yo'q. Ya'ni, biz ularni ishga tushirdik va davom etamiz, keyin esa hamma narsa yaxshi yoki yomon degan maqomga ega bo'lamiz.

Bularning barchasi mukammal pushti dunyoda. Haqiqiy hayotda bunday narsa yo'q, lekin biz intilamiz. Xavfsizlikni tekshirish natijalari birlik sinovlari natijalariga o'xshash bo'lishi kerak.

Masalan, biz katta loyihani oldik va endi uni SAST - OK bilan skanerlashga qaror qildik. Biz ushbu loyihani SASTga itarib yubordik, u bizga 20 000 zaifliklarni berdi va irodali qaror bilan biz hamma narsa yaxshi deb qaror qildik. 20 000 zaifliklar bizning texnik qarzimizdir. Biz qarzni qutiga solamiz, biz uni asta-sekin tozalaymiz va kuzatuvchilarni buzish uchun xatolar qo'shamiz. Keling, kompaniyani yollaymiz, hamma narsani o'zimiz qilaylik yoki Xavfsizlik bo'yicha chempionlar bizga yordam bersin - va texnik qarz kamayadi.

Va yangi koddagi barcha yangi paydo bo'lgan zaifliklar birlikdagi yoki avtotestlardagi xatolar bilan bir xil tarzda yo'q qilinishi kerak. Nisbatan aytganda, yig'ilish boshlandi, biz uni o'tkazdik, ikkita sinov va ikkita xavfsizlik testi muvaffaqiyatsiz tugadi. OK - biz bordik, nima bo'lganini ko'rib chiqdik, bir narsani tuzatdik, boshqasini tuzatdik, keyingi safar uni ishga tushirdik - hammasi yaxshi edi, hech qanday yangi zaifliklar paydo bo'lmadi, hech qanday sinov muvaffaqiyatsiz tugadi. Agar bu vazifa chuqurroq bo'lsa va siz uni yaxshi tushunishingiz kerak bo'lsa yoki zaifliklarni tuzatish kaput ostidagi narsalarning katta qatlamlariga ta'sir qilsa: nuqson kuzatuvchisiga xato qo'shildi, u birinchi o'ringa qo'yiladi va tuzatiladi. Afsuski, dunyo mukammal emas va ba'zida sinovlar muvaffaqiyatsizlikka uchraydi.

Xavfsizlik eshigiga misol sifatida koddagi zaifliklar mavjudligi va soni bo'yicha sifatli eshikning analogidir.

Biz SonarQube bilan birlashamiz - plagin o'rnatilgan, hamma narsa juda qulay va ajoyib.

Rivojlanish muhiti bilan integratsiya

Integratsiya imkoniyatlari:

• Qabul qilishdan oldin ishlab chiqish muhitidan skanerlash.
• Natijalarni ko'rish.
• Natijalarni tahlil qilish.
• Server bilan sinxronizatsiya.

Serverdan natijalarni olish shunday ko'rinadi.

Bizning rivojlanish muhitimizda Intelliya IDEA shunchaki skanerlash paytida bunday zaifliklar aniqlanganligi haqida xabar beradigan qo'shimcha element paydo bo'ladi. Siz darhol kodni tahrirlashingiz, tavsiyalarni ko'rishingiz va Oqim grafigi. Bularning barchasi ishlab chiquvchining ish joyida joylashgan, bu juda qulay - boshqa havolalarni kuzatib borish va qo'shimcha narsalarni ko'rib chiqishning hojati yo'q.

Ochiq manbalar

Bu mening sevimli mavzuim. Hamma ochiq kodli kutubxonalardan foydalanadi - nima uchun siz hamma narsa allaqachon amalga oshirilgan tayyor kutubxonani olishingiz mumkin bo'lsa, bir nechta tayoqchalar va velosipedlarni yozishingiz kerak?

Albatta, bu to'g'ri, lekin kutubxonalar ham odamlar tomonidan yoziladi, ular ma'lum xavflarni ham o'z ichiga oladi va vaqti-vaqti bilan yoki doimiy ravishda xabar qilinadigan zaifliklar mavjud. Shuning uchun, Ilova xavfsizligi bo'yicha keyingi qadam bor - bu ochiq manba komponentlarini tahlil qilish.

Ochiq manba tahlili - OSA

Asbob uchta katta bosqichni o'z ichiga oladi.

Kutubxonalarda zaifliklarni qidirish. Masalan, vosita biz kutubxonadan foydalanayotganimizni biladi va u CVE yoki kutubxonaning ushbu versiyasi bilan bog'liq xato kuzatuvchilarda ba'zi zaifliklar mavjud. Uni ishlatmoqchi bo'lganingizda, vosita kutubxonaning zaif ekanligi haqida ogohlantirish beradi va zaifliklari bo'lmagan boshqa versiyadan foydalanishni maslahat beradi.

Litsenziyaning tozaligini tahlil qilish. Bu hozircha bu yerda unchalik mashhur emas, lekin agar siz chet elda ishlasangiz, vaqti-vaqti bilan u yerda ishlatib bo'lmaydigan yoki o'zgartirib bo'lmaydigan ochiq manba komponentidan foydalanganingiz uchun soliq olishingiz mumkin. Litsenziyalangan kutubxona siyosatiga ko'ra, biz buni qila olmaymiz. Yoki, agar biz uni o'zgartirsak va undan foydalansak, kodimizni joylashtirishimiz kerak. Albatta, hech kim o'z mahsulotining kodini nashr qilishni xohlamaydi, lekin siz o'zingizni bundan himoya qilishingiz mumkin.

Sanoat muhitida ishlatiladigan komponentlarni tahlil qilish. Keling, gipotetik vaziyatni tasavvur qilaylik, biz nihoyat ishlab chiqishni yakunladik va mikroservisimizning so'nggi versiyasini chiqardik. U erda ajoyib yashaydi - bir hafta, bir oy, bir yil. Biz uni yig'maymiz, xavfsizlik tekshiruvlarini o'tkazmaymiz, hamma narsa yaxshi ko'rinadi. Ammo to'satdan, chiqarilgandan ikki hafta o'tgach, biz sanoat muhitida ushbu maxsus tuzilmada ishlatadigan Open Source komponentida muhim zaiflik paydo bo'ladi. Agar biz nima va qayerda foydalanayotganimizni yozmasak, biz bu zaiflikni ko'ra olmaymiz. Ba'zi vositalar hozirda sanoatda qo'llaniladigan kutubxonalardagi zaifliklarni kuzatish imkoniyatiga ega. Bu juda foydali.

Xususiyatlar:

• Rivojlanishning turli bosqichlari uchun turli xil siyosatlar.
• Sanoat muhitida komponentlarni kuzatish.
• Tashkilot ichidagi kutubxonalarni nazorat qilish.
• Turli qurilish tizimlari va tillarini qo'llab-quvvatlash.
• Docker tasvirlarini tahlil qilish.

Ochiq manba tahlili bilan shug'ullanadigan sanoat rahbarlarining bir nechta misollari.

Bu yagona bepul Tobelikni tekshirish OWASP dan. Siz uni birinchi bosqichlarda yoqishingiz mumkin, u qanday ishlashini va nimani qo'llab-quvvatlashini ko'rishingiz mumkin. Asosan, bularning barchasi bulutli mahsulotlar yoki mahalliy, ammo ularning bazasi ortida ular hali ham Internetga yuboriladi. Ular sizning kutubxonalaringizni emas, balki xeshlarni yoki o'zlari hisoblagan qiymatlarini va zaifliklar mavjudligi haqida ma'lumot olish uchun o'z serverlariga barmoq izlarini yuboradilar.

Jarayon integratsiyasi

Kutubxonalarning perimetri nazorati, ular tashqi manbalardan yuklab olinadi. Bizda tashqi va ichki omborlar mavjud. Masalan, Event Central Nexus’da ishlaydi va biz omborimizda “tanqidiy” yoki “yuqori” maqomga ega bo‘lgan zaifliklar yo‘qligiga ishonch hosil qilishni xohlaymiz. Siz Nexus Firewall Lifecycle vositasi yordamida proksi-serverni sozlashingiz mumkin, shunda bunday zaifliklar o'chiriladi va ichki omborda tugamaydi.

CI ga integratsiya. Avtotestlar, birlik testlari va rivojlanish bosqichlariga bo'linish bilan bir xil darajada: ishlab chiqish, test, ishlab chiqarish. Har bir bosqichda siz har qanday kutubxonalarni yuklab olishingiz, har qanday narsadan foydalanishingiz mumkin, ammo agar "tanqidiy" maqomda qiyin narsa bo'lsa, ishlab chiqarishga chiqarish bosqichida ishlab chiquvchilarning e'tiborini jalb qilish kerak.

Artefaktlar bilan integratsiya: Nexus va JFrog.

Rivojlanish muhitiga integratsiya. Siz tanlagan vositalar ishlab chiqish muhitlari bilan integratsiyaga ega bo'lishi kerak. Ishlab chiquvchi o'z ish joyidagi skanerlash natijalariga kirish huquqiga ega bo'lishi yoki CVSga kirishdan oldin kodni o'zi skanerlash va zaifliklarni tekshirish imkoniyatiga ega bo'lishi kerak.

CD integratsiyasi. Bu menga juda yoqadigan va men allaqachon aytib o'tgan ajoyib xususiyat - sanoat muhitida yangi zaifliklarning paydo bo'lishini kuzatish. Bu shunga o'xshash narsa ishlaydi.

Bizda bor Ommaviy komponentlar omborlari — tashqaridagi ba'zi vositalar va bizning ichki omborimiz. Biz unda faqat ishonchli komponentlar bo'lishini istaymiz. So'rovni proksi-server orqali yuborishda biz yuklab olingan kutubxonada zaifliklar yo'qligini tekshiramiz. Agar u biz oʻrnatgan va ishlab chiqish bilan albatta muvofiqlashadigan muayyan siyosatlarga toʻgʻri kelsa, biz uni yuklamaymiz va boshqa versiyadan foydalanishimiz soʻraladi. Shunga ko'ra, kutubxonada haqiqatan ham tanqidiy va yomon narsa bo'lsa, ishlab chiquvchi o'rnatish bosqichida kutubxonani olmaydi - unga yuqoriroq yoki pastroq versiyadan foydalanishga ruxsat bering.

• Qurilishda biz hech kimning hech qanday yomon narsa siljimaganligini, barcha komponentlar xavfsiz ekanligini va hech kim flesh-diskda xavfli narsa olib kelmaganligini tekshiramiz.
• Bizda faqat omborda ishonchli komponentlar mavjud.
• Joylashtirishda biz paketning o'zini yana bir bor tekshiramiz: urush, jar, DL yoki Docker tasviri siyosatga mos kelishiga ishonch hosil qilish uchun.
• Sanoatga kirishda biz sanoat muhitida nima sodir bo'layotganini kuzatib boramiz: muhim zaifliklar paydo bo'ladi yoki ko'rinmaydi.

Dinamik tahlil - DAST

Dinamik tahlil vositalari ilgari aytilganlarning barchasidan tubdan farq qiladi. Bu foydalanuvchining dastur bilan ishlashiga taqlid qilishning bir turi. Agar bu veb-ilova bo'lsa, biz mijozning ishini taqlid qiluvchi so'rovlarni yuboramiz, old tomondagi tugmachalarni bosing, shakldan sun'iy ma'lumotlarni yuboramiz: tirnoq, qavs, turli kodlashdagi belgilar, ilova qanday ishlashini va qanday ishlashini ko'rish uchun tashqi ma'lumotlar.

Xuddi shu tizim Ochiq manbada shablon zaifliklarini tekshirish imkonini beradi. DAST biz qaysi Ochiq manbadan foydalanayotganimizni bilmagani uchun u shunchaki “zararli” naqshlarni chiqaradi va server javoblarini tahlil qiladi:

- Ha, bu yerda deserializatsiya muammosi bor, lekin bu erda emas.

Bunda katta xavflar bor, chunki agar siz ushbu xavfsizlik testini sinovchilar ishlayotgan skameykada o'tkazsangiz, yoqimsiz narsalar yuz berishi mumkin.

• Ilova server tarmog'ida yuqori yuk.
• Integratsiyalar yo'q.
• Tahlil qilinadigan dastur sozlamalarini o'zgartirish imkoniyati.
• Kerakli texnologiyalarni qo'llab-quvvatlash yo'q.
• O'rnatishda qiyinchilik.

Nihoyat AppScan-ni ishga tushirganimizda shunday vaziyat yuzaga keldi: biz dasturga kirish uchun uzoq vaqt harakat qildik, 3 ta hisob qaydnomasiga ega bo'ldik va xursand bo'ldik - nihoyat hamma narsani tekshiramiz! Biz skanerlashni boshladik va AppScan qilgan birinchi narsa administrator paneliga kirish, barcha tugmalarni teshish, ma'lumotlarning yarmini o'zgartirish va keyin serverni butunlay o'chirish edi. pochta shakli- so'rovlar. Sinov bilan ishlab chiqish shunday dedi:

- Bolalar, siz meni hazillashyapsizmi?! Biz sizga hisob berdik, siz esa stend o‘rnatdingiz!

Mumkin bo'lgan xavflarni ko'rib chiqing. Ideal holda, axborot xavfsizligini sinab ko'rish uchun alohida stend tayyorlang, u hech bo'lmaganda qandaydir tarzda atrof-muhitning qolgan qismidan ajratiladi va shartli ravishda boshqaruv panelini tekshiring, yaxshisi qo'lda rejimda. Bu pentest - biz hozir ko'rib chiqmaydigan harakatlarning qolgan foizi.

Buni yuk sinovining analogi sifatida ishlatishingiz mumkinligini hisobga olish kerak. Birinchi bosqichda siz 10-15 ipli dinamik skanerni yoqishingiz va nima sodir bo'lishini ko'rishingiz mumkin, lekin odatda, amaliyot shuni ko'rsatadiki, yaxshi narsa yo'q.

Biz odatda foydalanadigan bir nechta manbalar.

Ta'kidlashga arziydi Burp Suite har qanday xavfsizlik mutaxassisi uchun "Shveytsariya pichog'i" dir. Hamma undan foydalanadi va bu juda qulay. Endi korporativ nashrning yangi demo versiyasi chiqdi. Agar ilgari bu plaginlar bilan mustaqil yordamchi dastur bo'lsa, endi ishlab chiquvchilar nihoyat bir nechta agentlarni boshqarish mumkin bo'lgan katta serverni yaratmoqdalar. Bu ajoyib, sinab ko'rishingizni maslahat beraman.

Jarayon integratsiyasi

Integratsiya juda yaxshi va sodda tarzda amalga oshiriladi: muvaffaqiyatli o'rnatishdan so'ng skanerlashni boshlang stend uchun arizalar va muvaffaqiyatli integratsiya testidan so'ng skanerlash.

Agar integratsiya ishlamasa yoki stublar va soxta funktsiyalar mavjud bo'lsa, bu befoyda va foydasiz - biz qanday naqsh jo'natmasak ham, server xuddi shunday javob beradi.

• Ideal holda, alohida sinov stendi.
• Sinovdan oldin, kirish ketma-ketligini yozing.
• Boshqaruv tizimini sinovdan o'tkazish faqat qo'lda amalga oshiriladi.

jarayon

Umuman jarayon haqida va xususan, har bir vositaning ishi haqida bir oz umumlashtirilgan. Barcha ilovalar bir-biridan farq qiladi - biri dinamik tahlil bilan, ikkinchisi statik tahlil bilan, uchinchisi OpenSource tahlili, pentestlar yoki umuman boshqa narsa, masalan, voqealar bilan yaxshiroq ishlaydi. Waf.

Har bir jarayon nazoratni talab qiladi.

Jarayon qanday ishlashini va uni qayerda yaxshilash mumkinligini tushunish uchun siz qo'lingizdan kelgan barcha narsalardan, jumladan ishlab chiqarish ko'rsatkichlari, asboblardan ko'rsatkichlar va nuqsonlarni kuzatuvchilardan ko'rsatkichlarni to'plashingiz kerak.

Har qanday ma'lumot foydali bo'ladi. U yoki bu vosita qayerda yaxshiroq qo'llanilishini, jarayonning o'ziga xos tarzda sustlashishini turli nuqtai nazardan ko'rib chiqish kerak. Vaqtga qarab jarayonni qayerda yaxshilash kerakligini bilish uchun ishlab chiqish javob vaqtlarini ko'rib chiqishga arziydi. Ma'lumotlar qanchalik ko'p bo'lsa, yuqori darajadan har bir jarayonning tafsilotlarigacha ko'proq bo'limlar tuzilishi mumkin.

Barcha statik va dinamik analizatorlarning o'z API-lari, o'zlarining ishga tushirish usullari, printsiplari borligi sababli, ba'zilarida rejalashtiruvchilar mavjud, boshqalari esa yo'q - biz vosita yozmoqdamiz. AppSec orchestrator, bu mahsulotdan butun jarayonga bitta kirish nuqtasini yaratish va uni bir nuqtadan boshqarish imkonini beradi.

Menejerlar, ishlab chiquvchilar va xavfsizlik muhandislari bitta kirish nuqtasiga ega bo'lib, ular nima ishlayotganini ko'rishlari, skanerlashni sozlashlari va ishga tushirishlari, skanerlash natijalarini olishlari va talablarni yuborishlari mumkin. Biz qog'ozbozlikdan voz kechishga, hamma narsani rivojlanish tomonidan qo'llaniladigan odamga aylantirishga harakat qilmoqdamiz - status va ko'rsatkichlar bilan birlashish sahifalari, Jira yoki turli nuqsonlarni kuzatuvchilardagi nuqsonlar yoki CIda sinxron/asinxron jarayonga integratsiya. /CD.

Key Takeaways

Asboblar asosiy narsa emas. Avval jarayonni o'ylab ko'ring - keyin vositalarni amalga oshiring. Asboblar yaxshi, lekin qimmat, shuning uchun siz jarayondan boshlashingiz va rivojlanish va xavfsizlik o'rtasida aloqa va tushunishni o'rnatishingiz mumkin. Xavfsizlik nuqtai nazaridan, hamma narsani "to'xtatish" shart emas, rivojlanish nuqtai nazaridan, agar yuqori mega super tanqidiy narsa bo'lsa, uni yo'q qilish kerak va muammoga ko'z yummaslik kerak.

Mahsulot sifati - umumiy maqsad ham xavfsizlik, ham rivojlanish. Biz bitta narsani qilamiz, biz hamma narsa to'g'ri ishlashini ta'minlashga harakat qilamiz va hech qanday obro'-e'tibor xavfi yoki moliyaviy yo'qotishlar yo'q. Shuning uchun biz aloqani yaxshilash va mahsulot sifatini yaxshilash uchun DevSecOps, SecDevOps yondashuvini ilgari suramiz.

Sizda mavjud bo'lgan narsadan boshlang: talablar, arxitektura, qisman tekshiruvlar, treninglar, ko'rsatmalar. Barcha amaliyotlarni barcha loyihalarga darhol qo'llashning hojati yo'q - iterativ harakat. Yagona standart yo'q - tajriba va turli yondashuv va yechimlarni sinab ko'ring.

Axborot xavfsizligi nuqsonlari va funktsional nuqsonlar o'rtasida teng belgi mavjud.

Hamma narsani avtomatlashtiringbu harakat qiladi. Nima harakat qilmasa ham, uni harakatlantiring va avtomatlashtiring. Agar biror narsa qo'lda qilingan bo'lsa, bu jarayonning yaxshi qismi emas. Ehtimol, uni ko'rib chiqish va uni avtomatlashtirishga arziydi.

Agar IS jamoasi kichik bo'lsa - Xavfsizlik chempionlaridan foydalaning.

Ehtimol, men gapirgan narsa sizga mos kelmasligi mumkin va siz o'zingizning biror narsangizni o'ylab topasiz - va bu yaxshi. Lekin jarayoningiz uchun talablar asosida vositalarni tanlang. Jamiyat nima deydi, bu vosita yomon, bu yaxshi, deb qaramang. Ehtimol, sizning mahsulotingiz uchun buning aksi bo'ladi.

Asboblarga qo'yiladigan talablar.

• Past darajadagi noto'g'ri ijobiy.
• Tahlil qilish uchun etarli vaqt.
• Foydalanish qulayligi.
• Integratsiyalarning mavjudligi.
• Mahsulotni ishlab chiqish yo'l xaritasini tushunish.
• Asboblarni sozlash imkoniyati.

Yuriyning hisoboti DevOpsConf 2018 ko‘rgazmasida eng yaxshilaridan biri sifatida tanlandi. Bundan ham qiziqarli g‘oyalar va amaliy holatlar bilan tanishish uchun 27 va 28 may kunlari Skolkovoga keling. DevOpsConf doirasida festivali RIT++. Yaxshisi, agar siz o'z tajribangizni baham ko'rishga tayyor bo'lsangiz, unda murojaat qiling hisobot uchun 21 aprelgacha.

Manba: www.habr.com