SAST талдағышын қалай таңдау керек: критерийлер мен чек-лист

SAST талдағышын жарияланған тілдер мен ережелер санына қарап емес, өз кодыңыздағы нәтижеге қарап таңдау керек: ол нақты осалдықтардың қаншасын табады, қанша артық шу тудырады және жинау конвейеріне қаншалықты оңай кіріктіріледі. Қысқа жол: төмендегі алты-жеті критерийден талаптар тізімін жасап, 2–3 үміткерді таңдаңыз да, оларды бір репозиторийлер жиынтығында салыстырыңыз.

SAST не істей алады және не істей алмайды

Статикалық талдау (SAST) қосымшаны іске қоспай-ақ бастапқы немесе бинарлық кодты зерттейді және сенімсіз деректердің қауіпті функцияларға түсу жолдарын іздейді: SQL-инъекциялар, XSS, каталогтар бойынша өту, қауіпсіз емес криптография, кодқа қатты жазылған құпиялар. Ол ерте кезеңде, IDE-де немесе pull request кезінде жұмыс істейді және нақты жолды көрсетеді. OWASP DevSecOps Guideline нұсқаулығы SAST-ты pull request кезінде іске қосып, тәуелділіктер үшін SCA-мен біріктіруді және құралды қолданылатын стекке қарай таңдауды ұсынады.

SAST не істемейді: орта конфигурациясының қателерін көрмейді, үшінші тарап кітапханаларындағы осалдықтарды тексермейді (ол үшін SCA керек) және динамикалық тестілеуді алмастырмайды. Құрал кластарының шекаралары туралы толығырақ: SAST, DAST, SCA және MAST: айырмашылығы неде.

SAST талдағышын таңдау критерийлері

1. Дәл сіздің стекке тиесілі тілдер мен фреймворктер

«30+ тілді қолдайды» деген сан тереңдік туралы ештеңе айтпайды. Кейбір тілдер қарапайым үлгілер деңгейінде, кейбірі деректер ағындарын толыққанды талдаумен қолдау табады. Semgrep құжаттамасында да қолдау жетілгендігі тілден тілге өзгеретіні тікелей айтылған. Өндірістік жүйелерде шынымен қолданылатын тілдердің, фреймворктердің және нұсқалардың тізімін жасап, талдағышты вендордың демонстрациялық жобаларында емес, солардың өзінде тексеріңіз. Мобильді кодты, SQL диалектерін, 1С скрипттерін, банктік ядроның legacy-тілдерін талдау қажет пе, жеке нақтылаңыз.

2. Дәлдік: жалған іске қосылулар мен өткізіп алулар

Бұл — басты критерий. Жалған іске қосылуы көп талдағышты әзірлеушілер бір айдан кейін оқуын қояды. Өткізіп алулары бар талдағыш жалған қауіпсіздік сезімін тудырады. Талдау тереңдігі екі көрсеткішке де әсер етеді: Semgrep құжаттамасында файлдар арасындағы талдау жалған іске қосылуды азайтып, шынайыларын көбейтетіні, бірақ көбірек уақыт алатыны, ал Community редакциясы тек функция немесе файл шегінде талдайтыны атап өтілген. Вендорға сұрақ қойыңыз: процедуралар аралық және файлдар аралық талдау бар ма, құрал осалдықтарды растай ма (мысалы, сынақ сұрауымен), іске қосылуларды белгілеп, түсініктемемен басуға бола ма.

3. Әзірлеу процесіне интеграция

Талдағыштың сіздің командаларыңыз жұмыс істейтін жерде жұмыс істейтінін тексеріңіз:

• Нұсқаларды басқару жүйелері және CI/CD: GitLab, GitHub, Bitbucket, Jenkins, TeamCity; CLI және REST API болуы.
• Тапсырма трекерлері: табылған олқылықтарды қолмен көшірместен Jira-ға немесе баламасына беру.
• Pull request режимі: тек өзгерген кодты инкременттік сканерлеу, әйтпесе тексеру сағаттап созылады.
• IDE: плагиндер пайдалы, бірақ pull request-пен салыстырғанда қосымша маңызды.

Кіріктіру тәжірибесі туралы «DevSecOps: неден бастау керек» материалынан оқыңыз.

4. Орналастыру моделі және деректермен жұмыс

Орталық Азиядағы банктер, телеком және мемлекеттік сектор үшін бастапқы кодты сыртқы бұлтқа беруге жиі болмайды. Толыққанды on-premise орнатудың (қысқартылған нұсқа емес) бар-жоғын, ол интернетке шықпайтын жабық контурда жұмыс істей ме және ережелер жаңартулары қалай жеткізілетінін анықтаңыз. Бірқатар халықаралық платформалардың негізгі өнімі бұлттық, ал локалды нұсқа бөлек немесе шектеулі ұсынылады: мысалы, Checkmarx One бетінде бұлттық платформа негізгі ретінде көрсетілген, ал on-premise SAST бөлек аталады. Болжамдамаңыз, жазбаша растау сұраңыз.

5. Талдау түрі: бастапқы код, бинарлық код, композиттік талдау

Егер сізде мердігерлердің коды көп болса немесе бастапқы кодсыз legacy бар болса, бинарлық талдау көмектеседі. Бүкіл AppSec контуры қажет болса, платформада SCA және DAST сол интерфейсте бар-жоғын бағалаңыз — бұл есептілік пен лицензиялауды жеңілдетеді, бірақ әр класс бойынша әрдайым ең жақсы шешім бола бермейді. DerScanner сияқты толық циклді платформалар SAST, SCA, DAST, мобильді және бинарлық талдауды біріктіреді.

6. Есептілік және талаптарға сәйкестік

Аудиторларыңыз тексеретін OWASP Top 10, PCI DSS және басқа стандарттар бойынша есептер бар ма, нәтижелерді SARIF немесе басқа машинада оқылатын пішімге экспорттауға бола ма, сұраңыз. Нарықтағы ресейлік шешімдерде ФСТЭК сертификациясы және отандық БЖ тізіліміне енгізу кездеседі; Қазақстан мен Өзбекстан компаниялары үшін бұл мәртебелер өздігінен міндетті емес, бірақ ресейлік серіктестермен жұмыс істесеңіз, сатып алу талаптарына әсер етеді.

7. Кеңейтілімділік: өз ережелері

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

8. Меншік құны

Лицензиялау моделі (әзірлеушілер, код жолдары, жобалар, сканерлеу серверлері бойынша) өсу кезінде әртүрлі әрекет етеді. Жария бағалар барлық вендорда жоқ, көптеген корпоративтік шешімдердің құны сұраныс бойынша анықталады. Тек лицензияны емес, инфрақұрылымды, табылған олқылықтарды талдауға кететін еңбекті және қолдауды да есептеңіз. Толығырақ — open-source немесе коммерциялық AppSec құралдары материалында.

Үміткерлерді салыстыруға арналған чек-лист

• Тілдер: барлық тілдеріңіз бен нұсқаларыңыз нақты кодта тексерілген.
• Дәлдік: эталондық іріктемеде табылғандар арасындағы расталған осалдықтардың үлесі есептелген.
• Өткізіп алулар: бұрынғы пентесттерден белгілі осалдықтары бар репозиторийде белгілі ақаулардың табылғаны тексерілген.
• CI/CD: pull request сканерлеуі рұқсат етілген уақытқа сыйады.
• Орналастыру: on-premise немесе бұлт құжат арқылы расталған.
• Есептер: пішім аудитке де, әзірлеушілерге де жарайды.
• Ережелер: өз ережелерін жазуға болады.
• Қолдау: техникалық қолдаудың тілі, уақыт белдеуі және әрекет ету мерзімі қанағаттандырады.
• Құны: 3 жылға есептелген коммерциялық ұсыныс алынған.

Талдағышты өз кодыңызда қалай тексеру керек

Тәжірибе көрсеткендей, вендорлардың таныстырылымдары мен интернеттегі шолулар пилотты алмастырмайды. Алгоритм қарапайым:

1. 3–5 репозиторий таңдаңыз: әртүрлі тілдер, әртүрлі командалар, белгілі осалдықтары бар бір жоба.
2. Оларды барлық үміткерлермен алдымен әдепкі параметрлермен, содан кейін баптаумен сканерлеңіз.
3. Табылғандардың кездейсоқ іріктемесін әзірлеушілермен бірге талдап, шынайы және жалған деп белгілеңіз.
4. Толық репозиторийді және pull request-ті сканерлеу уақытын өлшеңіз.
5. Орнатуға, баптауға және жаңартуға кеткен күшті бағалаңыз.

Мұндай тексеруді апталар бойынша қалай ұйымдастыру керегін «30 күнде SAST және SCA пилотын қалай өткізу керек» мақаласында сипаттадық. Нақты өнімдерді салыстырсаңыз, SAST шешімдерін салыстыруды қараңыз.

Таңдаудағы типтік қателер

• Ережелер немесе тілдер санына қарап таңдау. Маңыздысы — сан емес, сіздің стектегі сапа.
• Вендордың демо-жобасында тест жасау. Ол өнімнің күшті тұстарына арнайы таңдалған.
• Әзірлеушілерді елемеу. Олар таңдауға қатыспаса, құралды айналып өтеді.
• Барлық ережелерді бірден қосу. Осалдықтардың аса маңызды кластарынан бастап, жиынтықты бірте-бірте кеңейтіңіз.
• Процесс иесінің болмауы. Біреу табылғандарды талдап, түзетулерді тағайындауы тиіс, әйтпесе сканер шу көзіне айналады.

Таңдаудағы рөлдер: кім не үшін жауап береді

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

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

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

Дереккөздер

• OWASP DevSecOps Guideline: Static Application Security Testing
• Semgrep Docs: Semgrep Code overview
• GitHub-тағы Semgrep
• Checkmarx One: платформа шолуы
• Anti-Malware.ru: PT Application Inspector 4.0 шолуы