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

Автор исследовал 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 — для сравнения с компаниями из исследования. Ни один подход не решает все задачи одновременно. Для комплексного аудита автор рекомендует сочетать несколько методик и адаптировать критерии к конкретной организации, помня, что оценка зрелости — лишь начало работы, а не готовый план внедрения.