DevSecOps: неден бастау керек — қадамдық жоспар

DevSecOps — бір сканер сатып алу емес, процесті өзгерту: қауіпсіздік әзірлеудің әр кезеңінің бөлігіне айналады. Кемелдікті бағалаудан және маңызды жүйелер тізімінен бастау керек, содан кейін жылдам жеңістерді (SCA, құпиялар, артефактілер репозиторийі) жасап, CI/CD-ге жұмсақ quality gates бар тексерулерді енгізу, адамдарды оқыту және нәтижені өлшеу қажет. Қазақстан мен Орталық Азиядағы жобаларда қолданатын жоспарымызбен бөлісеміз.

1-қадам. Қазір қай деңгейде екеніңізді түсіну

Инвентаризациядан бастаңыз: қанша қосымша мен команда бар, код қайда сақталады, CI/CD және релиздер қалай құрылған, қандай тексерулер бұрыннан бар. Кемелдік модельдеріне сүйенген пайдалы: OWASP SAMM (Software Assurance Maturity Model) — қауіпсіз әзірлеудің ағымдағы практикаларын бағалауға, итерациялар арқылы теңгерімді бағдарлама құруға және прогресті өлшеуге көмектесетін ашық рамка; OWASP DSOMM (DevSecOps Maturity Model) — дәл DevSecOps-қа бағытталған OWASP жобасы. Олар бастапқы нүкте мен мақсатты деңгейді бекітеді, сонда мақсат «қауіпсізірек болғымыз келеді» деген сөйлемге келіп тірелмейді.

Процеске қойылатын талаптарға тірек ретінде 2022 жылғы ақпанда жарияланған NIST SP 800-218 (SSDF) қызмет ете алады — қауіпсіз әзірлеудің жоғары деңгейлі практикалар жиынтығы. Ол әзірлеудің кез келген өмірлік цикл моделіне сай келеді және тапсырыс берушілер мен жеткізушілерге қауіпсіздік туралы сөйлесуге ортақ тіл береді.

2-қадам. Тәуекелдер мен басымдықтарды анықтау

Барлық қосымша бірдей маңызды емес. Интернет-банкинг пен ішкі вики әртүрлі бақылау деңгейін қажет етеді. Маңызды жүйелер тізімін өңдейтін деректері, интернеттен қолжетімділігі және бизнеске әсері бойынша жасаңыз да, енгізуді солардан бастаңыз. Мұндай тізім бюджеттің де негізі болады: енгізу бюджеті қосымшалар мен командалар санына және таңдалған құралдарға байланысты.

3-қадам. Жылдам жеңістер

• SCA және open-source бақылауы. Жалған іске қосылулар аз, әсері жоғары — SAST, DAST және SCA айырмашылығын қараңыз.
• Құпиялар кодтан тыс. Репозиторийлерден құпиясөздер мен токендерді тауып, оларды құпиялар қоймасына көшіріңіз — құпиялар туралы толығырақ.
• Зиянды пакеттерді бұғаттайтын қорғалған артефактілер репозиторийі.

Бұл шаралар әзірлеу процестерін бұзбай, бірнеше аптада байқалатын әсер береді және басшылыққа алғашқы нәтижелерді көрсетеді.

4-қадам. Тексерулерді конвейерге енгізу

Әр тексерудің өз орны бар:

• Commit / pull request: өзгерген код бойынша SAST, құпияларды іздеу.
• Жинау: SCA, SBOM жасау, контейнер образдарын сканерлеу.
• Тест стенді: DAST, frontend үшін FAST.
• Продакшн: DAST-сканерлеуді үнемі жүргізу және мониторинг.

Басынан бастап quality gates туралы келісіп алу маңызды: қандай олжалар релизді тоқтатады, қайсысы тапсырма болып ашылады. Жұмсақ бастаңыз — ақпараттандырудан, ережелерді бірте-бірте қатайтыңыз. DAST жоспарлы сканерлеулеріне кесте бойынша режим жақсы келеді, мысалы, бапталғаннан кейін аз қатысуды қажет ететін түнгі іске қосу. GitLab үшін техникалық жағы GitLab CI-ге SAST пен SCA-ны қалай енгізу керек мақаласында талданған.

5-қадам. Құралдарды пилот арқылы таңдау

Құралды вендор презентациясы бойынша сатып алмаңыз. Әртүрлі командалардың 3–5 репозиторийін алып, үміткерлерді бірдей деректерде тексеріңіз де, шын олжалардың үлесін, сканерлеу жылдамдығын және әзірлеушілерге ыңғайлылығын бағалаңыз. Мұндай тестті қалай ұйымдастыру керегі 30 күндік SAST және SCA пилоты мақаласында сипатталған.

6-қадам. Адамдарды оқыту

Әзірлеушілер нәтижелерді түсінбесе, құралдар пайдасыз. Қауіпсіз әзірлеу және олжаларды талдау бойынша қысқа практикалық курстар ең тез өтеледі. Біз AppSec және DevSecOps бойынша корпоративтік оқыту өткіземіз. Жақсы практика — әр әзірлеу командасында олжаларды бірінші талдап, әріптестерге көмектесетін «қауіпсіздік чемпионын» тағайындау.

7-қадам. Өлшеу

• Тексерулермен қамтылған қосымшалар үлесі
• Сыни осалдықтарды түзетудің орташа уақыты (MTTR)
• Продакшнға дейін және кейін табылған осалдықтар саны
• Жалған іске қосылулар үлесі

Метрикалар есеп үшін есеп болу үшін қажет емес: олар бойынша процестің қай жерде тоқтап тұрғаны көрінеді, ал келесі қаржыландыру солар негізінде дәлелденеді.

Типтік қателер

• Құрал сатып алып, «бәрін қосу» — команда мыңдаған олжаның астында қалады.
• Релиздерді алғашқы күннен бұғаттау — әзірлеу тексерулерді айналып өте бастайды.
• DevSecOps-ты әзірлеу мен DevOps-сыз, тек АҚ күшімен жүргізу.
• Түзетуге жауаптыларды тағайындамау: жауаптысы жоқ олжалар жабылмайды.

Ұйымыңызға арналған әрекеттер картасы қажет болса, оны DevSecOps енгізу бетінен алуға болады.

Рөлдер және жауапкершілік

Қауіпсіздікке тек бір бөлім жауап берсе, DevSecOps жұмыс істемейді. Тиімді бөлу былай көрінеді: АҚ қызметі саясаттар мен талаптарды анықтайды, жоғары тәуекелді олжаларды талдайды және метрикаларды бақылайды; әзірлеушілер өз кодындағы және тәуелділіктеріндегі ақауларды түзетеді; DevOps-инженерлер тексерулерді конвейерлерге енгізеді және құралдар инфрақұрылымын қолдайды; өнім иелері ерекшеліктер мен басымдықтар туралы шешім қабылдайды. Бірнеше командасы бар ірі ұйымдарда әр командада қауіпсіздікке жауаптыны тағайындаған пайдалы — ол АҚ-мен байланыс нүктесіне айналады.

Енгізу кезінде қарқынды қалай жоғалтпау керек

Сәтсіздіктің ең жиі сценарийі — нәтижесі кейінге қалдырылған үлкен жоба. Алғашқы пайдаға дейін бір жыл кететін енгізу басшылықтың қолдауы мен командалардың құлшынысын жоғалтады. Кері тәсіл жұмыс істейді: екі–төрт аптадан тұратын қысқа итерациялар, олардың әрқайсысында команда нақты көрінетін нәтиже алады — табылған және жабылған құпиялар, бұғатталған зиянды пакет, маңызды қосымшалардың жай-күйі бойынша есеп. Әр итерациядан кейін басымдықтарды алдыңғы бөлімдегі метрикалар бойынша қайта қарау керек.

Қауіпсіздік бойынша жинақталған техникалық борышпен жұмысты жеке ойластырған жөн. Ескі код дерлік әрқашан жүздеген олжаны қамтиды. Бәрін бірден жабуға тырыспаңыз: ағымдағы жай-күйді базалық сызық ретінде бекітіңіз, өзгерістерде жаңа сыни мәселелердің пайда болуына жол бермеңіз және ескі борышты жеке бэклогта жүйелі түрде азайтыңыз.

DevSecOps қарапайым AppSec-тен несімен ерекшеленеді

Қосымшалар қауіпсіздігінің классикалық тәсілі — релиз алдындағы мерзімді тексерулер, жиі сыртқы мамандардың күшімен. DevSecOps бұл тексерулердің бір бөлігін күнделікті жұмысқа көшіреді: әр өзгеріске автоматты сканерлеу, әзірлеушіге жылдам кері байланыс, барлық командаларға бірыңғай саясаттар. Мерзімді терең тексерулер жоғалмайды: маңызды жүйелердің пентесті мен сараптамалық талдау бағдарламаның маңызды бөлігі болып қала береді, бірақ енді олар тұрақты бақылауды алмастырмайды, толықтырады.

Әзірлеушілер үшін не өзгереді

Табыс жаңа тексерулердің күнделікті жұмыста қалай сезілетініне байланысты. Олжалар әзірлеуші жұмыс істеп жатқан жерге келуі тиіс: pull request-ке, IDE-ге, тапсырмалар трекеріне. Әр олжада түсінікті сипаттама, кодтағы орны және түзету бойынша ұсыным болуы керек. Контекстсіз «500 мәселе табылды» деген хабарлар қарсылық тудырады, ал түзетудің дайын тәсілі бар үш нақты олжа — әрекетке итермелейді. Сондықтан бастапқыда сканерлерді ақаулардың сыни кластарына ғана қатаң баптап, команда үйренген сайын қамтуды кеңейткен дұрыс.

Маңызды сәт — уақыт. Pull request-тегі тексеру ондаған минутқа созылса, оны айналып өте бастайды. Ауыр сканерлеулерді түнгі іске қосуларға немесе релиз тармақтарына шығарады, ал жылдам тексерулерді (құпияларды іздеу, өзгерген файлдар бойынша SAST, манифестер бойынша SCA) негізгі ағында қалдырады.

Жобаны басшылық алдында қалай негіздеу керек

Басшылыққа құралдардың атауы сирек қызық. Онымен тәуекелдер мен құн тілінде сөйлесу тиімдірек: қандай жүйелер маңызды, инцидент болса не болады, реттеушілер мен тапсырыс берушілер қандай талап қояды, релиз алдындағы қолмен тексерулерге қазір қанша уақыт кетеді. Бастапқы өлшемдер (қамту, түзету уақыты, продакшндағы олжалар саны) санақ нүктесін береді, ал бірнеше тоқсаннан кейінгі метрикалар динамикасы жобаны жалғастыруға дәлел болады. Әр итерациясында түсінікті нәтижесі бар бірнеше итерациядан тұратын жоспар дайындаңыз, сонда бюджет туралы талқылау нақты болады.

Жиі қойылатын сұрақтар

Дереккөздер

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