Порівняння чотирьох методик оцінювання безпечної розробки показало: універсального інструмента, який однаково добре дає оцінку, рекомендації та готовий план робіт, немає. Практична різниця суттєва: одні підходи допомагають порівняти процеси з іншими компаніями, інші — побудувати план розвитку, а стандарт ГОСТ краще підходить для перевірки відповідності вимогам.

Автор дослідив BSIMM, DSOMM, OWASP SAMM і ГОСТ Р 56939-2024 на одному умовному прикладі. Це була імітація аудиту, а не оцінювання реальної організації: для кожного підходу заповнювали офіційний або самостійно підготовлений опитувальник, визначали рівень зрілості, а потім перевіряли можливість сформувати рекомендації, дорожню та теплову карти. Результат залежить не лише від практик компанії, а й від того, чи дає методика зручний спосіб перетворити відповіді на подальші дії.

Чотири різні способи подивитися на процеси

BSIMM — Building Security In Maturity Model — описує практики безпечної розробки, які трапляються у компаніях, і показує, як часто їх застосовують. У BSIMM15 дослідження охоплює 121 організацію. Модель не встановлює обов’язкового шляху впровадження: її сильна сторона — можливість зіставити себе з даними учасників дослідження. Практики розкладено за чотирма доменами та трьома рівнями зрілості. Раніше звіт випускав Synopsys, тепер — Black Duck.

DSOMM, або DevSecOps Maturity Model, розроблена OWASP для оцінювання інтеграції безпеки в DevOps. Вона містить п’ять доменів і п’ять рівнів зрілості, зосереджена на технічних практиках і має допомагати знаходити прогалини та способи їх усунути. Для оцінювання існує офіційний онлайн-інструмент, хоча під час описаної імітації автор не зміг ним скористатися й підготував власний опитувальник в Excel. За його спостереженням, окремі практики можуть бути надто дорогими або не відповідати можливостям багатьох російських компаній; також модель не охоплює деякі етапи життєвого циклу розробки.

OWASP SAMM охоплює життєвий цикл програмного забезпечення через п’ять бізнес-функцій — від управління до експлуатації. Кожну практику оцінюють за шкалою від нуля до трьох, причому можна зафіксувати як поточний, так і цільовий рівень. На відміну від самостійно складених таблиць для BSIMM і DSOMM, SAMM має офіційний інструмент оцінювання в Excel і посібник. У ньому можна сформувати дорожню карту. Водночас частина практик автору здалася нечітко сформульованою, надто затратною або малопридатною для місцевого контексту, а деякі етапи SDLC залишилися поза охопленням.

ГОСТ Р 56939-2024 «Захист інформації. Розроблення безпечного програмного забезпечення. Загальні вимоги» формально не є методикою оцінювання зрілості. Це стандарт із 25 процесами та вимогами до розробників на різних стадіях — від проєктування до виведення програмного забезпечення з експлуатації. Для перевірки важливі артефакти: виконання вимог потрібно підтверджувати документами, звітами, записами в трекерах або системах контролю версій. Стандарт розширив вимоги попередньої редакції 2016 року й адаптований до російського ринку, але офіційного механізму розрахунку рівня зрілості в ньому немає.

Оцінювання на умовній компанії

Для порівняння автор змоделював ООО «Лиса и лосЬ» — компанію, що на замовлення розробляє переважно CRM-системи для внутрішніх і зовнішніх клієнтів. Її конвеєр працює на GitLab, артефакти зберігаються в Nexus, а код перевіряють за допомогою SonarQube та OSV-scanner. Регламент безпечної розробки існує, однак спирається на ГОСТ Р 56939-2016. Навчання з безпечної розробки, пентестів і WAF у змодельованому профілі немає.

Автор використав п’ять критеріїв із загальним максимумом у 47 балів. Перші чотири стосувалися зручності визначення зрілості, можливості отримати рекомендації, побудувати дорожню карту та теплову карту. Для перших критеріїв передбачалося до десяти балів; зручність оцінювали суб’єктивно, а наявність інструментів для рекомендацій і карт — за шкалою від відсутності такої можливості до готового відкритого або авторського рішення. Окремо оцінювали покриття семи етапів SDLC: збору й аналізу вимог, планування та аналізу ризиків, проєктування, розробки, тестування, розгортання і підтримки.

Інструмент BSIMM автор не знайшов, а офіційний вебзастосунок DSOMM у його спробі не запрацював, тож для обох моделей опитувальник і підрахунок було зроблено самостійно в Excel. Для ГОСТу застосували внутрішній інструмент компанії «Бастіон», який не доступний публічно. Це обмеження важливе під час інтерпретації балів: оцінка ГОСТу не відтворюється за відкритим офіційним калькулятором. Технічна частина оцінювання часом починається не з аналізу процесів, а зі створення таблиці, яка мала б допомагати цей аналіз проводити.

Що показали результати

Зрілість умовної компанії за BSIMM оцінили у 18%, за DSOMM — на рівні 2 із 5, за SAMM — 0,55 із 3, а за ГОСТ Р 56939-2024 — 29%. Ці значення не можна безпосередньо зіставляти між собою: методики користуються різними шкалами, а сама оцінка залежить від їхнього устрою. Це радше профіль за кожним окремим підходом, а не чотири результати єдиного стандартизованого тесту.

За сумою балів у порівнянні лідирував ГОСТ із 35 балами з 47, а SAMM набрала 34. Різниця в один бал не робить одну методику безумовно кращою: їхні цілі відрізняються. ГОСТ докладно задає вимоги та критерії підтвердження артефактами, охоплює етапи SDLC і дає основу для глибокої перевірки процесів. Але оцінювачеві доведеться самостійно забезпечити розрахунок і побудову дорожньої карти, якщо готовий інструмент потрібен саме в такому форматі.

SAMM має іншу перевагу: офіційний опитувальник допомагає оцінити зрілість і сформувати гнучку дорожню карту в одному інструменті. Тому автор вважає її доречною, коли компанія планує AppSec-стратегію та хоче бачити напрям розвитку. Компроміс — практики, що можуть бути дорогими або не відповідати умовам російських компаній, а також неповне покриття окремих етапів життєвого циклу.

DSOMM має сенс розглядати, коли основний фокус — DevSecOps і технічні практики. Пояснення до питань допомагають трактувати їх однозначніше, а модель підтримує спільнота. Проте в цій оцінці її офіційний онлайн-механізм не вдалося використати. Автор зауважує, що на профільних форумах є повідомлення про можливість роботи з ним, тож його досвід не варто трактувати як доказ загальної несправності інструмента. Окремо слід врахувати обмежене покриття SDLC та вартість або непридатність частини практик.

BSIMM найкраще відповідає завданню порівняти власні практики з даними інших компаній: серед розглянутих методик саме вона має відкриті дані для такого зіставлення, зокрема щорічні звіти й добірку популярних практик. Для внутрішньої самооцінки модель менш зручна, оскільки офіційного алгоритму розрахунку немає. До того ж практики доводиться адаптувати до місцевих умов, а деякі з них, на думку автора, можуть бути непридатними для багатьох російських організацій.

Практичний вибір, отже, варто прив’язувати до мети: ГОСТ — для підготовки до перевірки за вимогами, SAMM — для AppSec-стратегії та дорожньої карти, DSOMM — для технічного боку DevSecOps, BSIMM — для порівняння з компаніями з дослідження. Жоден підхід не закриває всі задачі одночасно. Для комплексного аудиту автор рекомендує поєднувати кілька методик і адаптувати критерії до конкретної організації, пам’ятаючи, що оцінка зрілості — лише початок роботи, а не готовий план впровадження.