AppSec бюджетін басшылық алдында қалай негіздеу керек

Басшылық қолданбалар қауіпсіздігіне бюджетті құралдар тізімін емес, нақты тәуекелдердің ақшалай өлшемдегі азаюын, реттеушілік міндеттемелерді және нәтиженің түсінікті метрикаларын көргенде бекітеді. AppSec-тегі «ROI»-ды қатаң есептеу қиын, өйткені әсер — болдырылмаған оқиғалар; сондықтан негіздеме шығын сценарийлеріне, әр кезеңде түзету құнына және өлшенетін ілгерілеуге құрылады.

Қауіпсіздіктегі «ROI» неге басқаша есептеледі

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

1-қадам. Тәуекелдерді бизнес тілінде сипаттаңыз

«Бізде N сыни осалдық бар» дегеннің орнына олардың қандай бизнес-үдерістерге әсер ететінін көрсетіңіз:

• қандай жүйелер төлемдерді, клиенттердің дербес деректерін, коммерциялық құпияны өңдейді;
• бұзылған немесе тоқтап қалған жағдайда не болады: сервистің тоқтауы, айыппұлдар, клиенттер мен әріптестердің талаптары, беделге зиян;
• қандай сыртқы талаптар қазірдің өзінде қолданылады: реттеуші, стандарттар (мысалы, PCI DSS — төлем беттерінің скрипттеріне қойылатын талаптарды қараңыз), әріптестер алдындағы шарттық міндеттемелер.

Ең сыни 3–5 жүйеден бастаңыз. Басшылыққа «жалпы қауіпсіздік» бойынша емес, нақты активтер бойынша шешім қабылдау оңайырақ.

2-қадам. Тексерілетін сыртқы деректерге сүйеніңіз

Оқиғалар құны бойынша ең танымал ашық дереккөз — IBM және Ponemon Institute-тың жыл сайынғы Cost of a Data Breach есебі. 2026 жылғы есептің бетінде IBM деректер ағып кетуінің әлемдік орташа құнын 4,99 млн АҚШ доллары деп көрсетеді (рекордтық көрсеткіш, алдыңғы жылмен салыстырғанда 12% өсім) және қауіпсіздікте ЖИ мен автоматтандыруды белсенді қолданатын ұйымдар оларды қолданбайтындармен салыстырғанда 1,93 млн доллар үнемдейтінін атап өтеді.

Аудиторияның сенімін жоғалтпау үшін өзіңіз айтқан жөн маңызды ескертпелер:

• бұл ұйымдар іріктемесі бойынша әлемдік орташа мәндер; сіздің компанияңыз үшін нақты сан төмен де, едәуір жоғары да болуы мүмкін;
• есеп тек қолданбалардағы осалдықтардан туындаған оқиғаларды емес, жалпы деректердің ағып кетуін қамтиды;
• әрдайым есептің жылы мен сілтемесін көрсетіңіз — «дереккөзсіз сан» бар презентацияны бірінші сұрақтың өзі-ақ талқандайды.

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

3-қадам. Түзету құнындағы айырмашылықты көрсетіңіз

«Осалдық неғұрлым ерте табылса, оны жою соғұрлым арзан» деген дәлел басшылыққа түсінікті және тәжірибеде расталады. Бірақ дереккөзсіз «әдемі» коэффициенттерді, мысалы «100 есе арзан» дегенді келтірмеңіз — олардың шығу тегі жиі тексерілмейді. Өз деректеріңіз бойынша есептеген сенімдірек:

• пентестте немесе продта табылған 5–10 соңғы осалдықты алыңыз;
• түзетуге кеткен еңбек шығындарын бағалаңыз: талдау, түзету, қайта тестілеу, жоспардан тыс релиз, коммуникациялар;
• оны pull request кезеңінде ұқсас осалдықты түзетуге кеткен еңбек шығындарымен салыстырыңыз — мұндай деректерді SAST/SCA пилотында аласыз.

4-қадам. Әсер формуласын тұжырымдаңыз

Презентация үшін қарапайым және ашық модель жеткілікті. Жылдық күтілетін шығындарды (ALE) пайдаланыңыз:

• ALE дейін = жылына оқиға ықтималдығы × шығын мөлшері;
• ALE кейін = шараларды ескергендегі сол ықтималдық × шығын;
• Әсер = ALE дейін − ALE кейін − AppSec бағдарламасының жылдық құны.

Барлық параметр — болжамды, сондықтан диапазондарды (оптимистік, базалық, консервативті сценарийлер) көрсетіп, жорамалдарды ашық атаңыз. Басшылық қорғау мүмкін емес «нақты» сыннан гөрі ескертпелері бар адал модельді жоғары бағалайды.

Әсердің екінші бөлігі — есептеуге оңайырақ: қолмен тексеруге кететін еңбек шығындарын қысқарту, «апаттық» кері қайтарусыз релиздерді жеделдету, дайын есептермен аудитке дайындық. Формуланың бөлімі үшін шығындар құрылымын «DevSecOps енгізу құны қанша» мақаласы талдайды.

5-қадам. Ілгерілеуді көрсететін метрикаларды таңдаңыз

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

• Қамту: сканерлеуге қосылған қолданбалар мен репозиторийлер үлесі;
• Жою уақыты: сыни осалдықтарды түзетудің орташа уақыты (MTTR);
• Жиналған қарыз: ашық сыни және жоғары осалдықтар саны және динамикасы;
• Бұғаттау үлесі: quality gate қанша құрастыруды тоқтатты және олардың қаншасы мерзімінде түзетілді;
• Тәуелділіктер: белгілі осалдықтары бар компоненттер үлесі, SBOM болуы (SBOM деген не);
• Анықталу: продакшенге дейін табылған осалдықтар үлесі пентестте немесе пайдалану кезінде табылғандармен салыстырғанда.

Басшылықпен 6–12 айға арналған мақсатты мәндерді келісіңіз — бұл бюджетті түсінікті міндеттемеге айналдырады.

6-қадам. Кезең-кезеңімен жоспар мен пилот ұсыныңыз

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

1. 1–2 сыни қолданбадағы пилот; мақсаты — табылғылар мен еңбек шығындары туралы өз деректеріңізді алу.
2. Қалған сыни жүйелерге кеңейту, quality gates қосу.
3. Бүкіл әзірлеуге масштабтау, тұрақты есептілік.

Келесі кезең туралы шешім пилот метрикаларына қарай қабылданады — басшылық үшін бұл сәтсіз сатып алу тәуекелін шектейді.

Негіздемедегі жиі қателіктер

• Сансыз үрейлендіру. Жалпы қорқынышты мысалдар бір рет қана жұмыс істейді; кейін сіздің жүйелеріңіз бен сіздің тәуекелдеріңіз қажет.
• Техникалық тіл. Басшыға осалдық кластарының атаулары керек емес, оған бизнес үшін әсер қажет.
• Кезеңсіз бір «үлкен» бюджет. Оны кейінге қалдыру оңайырақ.
• Адамдарға және түзетуге кететін шығындарды елемеу. Қаржы директоры оларды кейін байқап, қалған есептеулерге күмәндана бастайды.
• Расталмаған деректер. Кез келген сыртқы санға есеп атауын, жылын және сілтемені тіркеңіз.

Презентацияның өзін қалай құру керек

Басшылық алдындағы сөйлеу құрылымы, тәжірибеде жақсы жұмыс істейтіні, бес слайдқа сияды:

• Жағдай. Қандай жүйелер сыни, олардың осалдықтары туралы қазір не белгілі (пентест, аудит, пилот нәтижелері бойынша).
• Тәуекел. 3–5 актив үшін шығын сценарийлері және дереккөзі көрсетілген сыртқы бағдарлар.
• Ұсыныс. Нені және қандай ретпен енгізбексіз — құралдар функцияларын тізбелемей.
• Құны. Лицензиялар, енгізу, мамандар, оқыту, қолдау жылдар бойынша; кезеңдер бойынша бөлу.
• Нәтиже. Метрикалар, мақсатты мәндер және шешім қабылдау нүктелері: келесі кезеңге қашан қайта келесіз.

«Ештеңе сатып алмасақ ше» деген сұраққа жауапты бөлек дайындаңыз: стандарттар мен шарттар бойынша қандай міндеттемелер орындалмай қалатынын және реттеушілердің қандай талаптарын жаппайтыныңызды сипаттаңыз. Көбіне шешуші болып дәл осы жауап шығады.

Қарсылықтармен қалай жұмыс істеу керек

• «Бізді ешқашан бұзған емес». Анықталған оқиғалардың болмауы осалдықтардың жоқтығын білдірмейді. Деректер алу үшін пилот немесе қорғалғандықты бағалауды ұсыныңыз.
• «Әзірлеушілер баяулайды». Басында «тек ақпараттандыру» режимін көрсетіңіз және пайплайн уақытын өлшеңіз; бұғаттаулар біртіндеп қосылады.
• «Қымбат». Жалпы сомадан кезең-кезеңімен жоспарға және сыни жүйелеріңіз бойынша ықтимал шығындармен салыстыруға көшіңіз.
• «Тегін құралдар бар». Бар, бірақ қолдауға уақыт қажет; лицензия бағасын емес, иелену толық құнын салыстырыңыз.

Бюджет бекітілгеннен кейін не істеу керек

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

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

Дереккөздер

• IBM: Cost of a Data Breach Report
• PCI SSC Blog: 2025 жылғы 31 наурызда күшіне енетін PCI DSS e-commerce талаптары