Безопасная разработка сейчас — одна из самых горячих тем в российском ИТ. Чаще всего к ней подталкивают внешние обстоятельства: требования регуляторов, предстоящие проверки или инцидент, после которого процессы приходится пересматривать. Самый редкий, но самый честный повод — руководство действительно хочет разрабатывать безопасное ПО.
Но прежде чем внедрять новые для компании практики безопасной разработки, нужно честно посмотреть на текущие процессы: что из практик уже внедрено и работает, где пробелы и какие есть проблемы. Только тогда станет понятно, в каком направлении двигаться и как строить план внедрения.
Как же оценить зрелость процессов? На глаз? По одной из западных методологий? По ГОСТу? Если звать внешнего аудитора не хочется, вариантов, на самом деле, четыре: BSIMM, DSOMM, SAMM и ГОСТ Р 56939-2024. Какому из них отдать предпочтение, не очевидно: методологии по-разному устроены, по-разному ложатся на российские реалии, и не каждая доводит от оценки до понятного плана действий. Где-то есть готовый опросник с расчетом, где-то его придется собирать самому, а где-то практики рассчитаны на очень зрелые компании и для большинства российских слишком затратны.
Я прогнал все четыре методологии через имитацию аудита на одной вымышленной компании и проверил, с какой проще пройти весь путь — от оценки зрелости до рекомендаций и дорожной карты.
Материала набралось на три статьи. В этой сравню все четыре методологии, разберу их преимущества и недостатки и сделаю вывод, для каких задач годится каждая. Во второй на примере BSIMM, DSOMM и SAMM покажу, как провести оценку, какими инструментами воспользоваться и с какими ограничениями придется столкнуться. В третьей разберу оценку по ГОСТ Р 56939-2024.
Заваривайте кофе и устраивайтесь поудобнее — отправляемся в путешествие по внутреннему аудиту!
Дисклеймер. Компания ООО «Лиса и лосЬ» и ее процессы вымышлены, любые совпадения случайны. Всё, что вы прочитаете в цикле, — моя субъективная и выстраданная точка зрения, которая может не совпадать с позицией моего текущего или бывших работодателей.
Четыре кандидата
BSIMM (Building Security In Maturity Model) — ежегодный отчет о том, какие практики безопасной разработки встречаются в реальных компаниях и как часто. В BSIMM15 таких организаций 121. Это описательная модель: она ничего не предписывает, а позволяет сравнить себя со средними показателями по компаниям из исследования. Раньше отчет выпускал Synopsys, сейчас — Black Duck. Практики разложены по четырем доменам и трем уровням зрелости.
DSOMM (DevSecOps Maturity Model) — модель зрелости от OWASP для встраивания безопасности в DevOps. Она помогает оценить зрелость конкретных процессов, найти недостатки и понять, как их закрыть. В DSOMM пять доменов и пять уровней зрелости. Для расчета есть официальный онлайн-инструмент, но на практике чаще пользуются самодельными опросниками.
OWASP SAMM (Software Assurance Maturity Model) — еще одна модель OWASP. Она охватывает весь жизненный цикл ПО через пять бизнес-функций, от управления до эксплуатации. Зрелость каждой практики оценивается от 0 до 3, причем фиксируется и текущий уровень, и целевой. У SAMM есть официальный инструмент оценки в Excel и руководство на owaspsamm.org.
ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» — национальный стандарт, который заметно расширил требования версии 2016 года. Строго говоря, это не методология оценки, а набор требований к разработчикам: 25 процессов на всех стадиях, от проектирования до вывода из эксплуатации. Но как основа для оценки он подходит. Тем более что стандарт требует подтверждать выполнение требований артефактами — документами, отчетами, записями в трекерах и системах контроля версий.
Коммерческие методологии я сознательно оставил за скобками. Российские компании тоже разрабатывают собственные методологии оценки зрелости безопасной разработки — и любезно проводят по ним платные аудиты. Бастион, естественно, в их числе, а я участвовал в создании нашего подхода к оценке с самого начала и разрабатывал внутреннюю методологию анализа процессов. Так что оценивать чужие коммерческие методологии было бы не совсем честно.
Подопытный: ООО «Лиса и лосЬ»
Чтобы сравнение было предметным, я придумал компанию и подробно описал ее процессы разработки. ООО «Лиса и лосЬ» делает ПО на заказ, в основном CRM-системы, для внутренних и внешних заказчиков. Конвейер собран на GitLab, артефакты хранятся в Nexus, код проверяют SonarQube и OSV-scanner.
Регламент безопасной разработки у компании есть, но написан по старой версии стандарта — ГОСТ Р 56939-2016. Обучения по безопасной разработке, пентестов и WAF нет. Краткая выжимка профиля с тремя продуктами, командами и требованиями к релизам — на картинке.
Как я проводил оценку
Аудит процессов безопасной разработки — это детальное изучение процессов создания ПО в компании, чтобы оценить их зрелость, найти системные проблемы и сформировать рекомендации. Проводить его можно своими силами или с привлечением внешних специалистов. Я провел имитацию: заполнил опросные листы по профилю ООО «Лиса и лосЬ» и прошел с каждой методологией один и тот же сценарий.
Сначала заполняю опросник — официальный или собранный самостоятельно — и рассчитываю уровень зрелости. Потом проверяю, получится ли сформировать рекомендации, построить дорожную карту и тепловую карту процессов. Формальная возможность использовать методологию меня не интересует. Важно другое: годится ли она на практике для самооценки в российской компании.
Таблица 1. Критерии оценки методологий
Критерий | Как оценивается | Максимум |
|---|---|---|
Удобство определения уровня зрелости | Субъективно, с точки зрения специалиста, проводившего оценку: 0 — неудобно, 10 — удобно | 10 |
Формирование рекомендаций по исправлению недостатков | 0 — возможности нет; 5 — по материалам методологии можно собрать свой инструмент; 10 — инструмент сделали авторы методологии или он есть в открытом доступе | 10 |
Построение дорожной карты внедрения процессов | По той же шкале, что и рекомендации | 10 |
Построение тепловой карты процессов | По той же шкале, что и рекомендации | 10 |
Полнота охвата этапов SDLC | Балл за каждый покрытый этап из семи: сбор и анализ требований, планирование и анализ рисков, проектирование, разработка, тестирование, развертывание, поддержка | 7 |
Итого | 47 |
Официального инструмента оценки у BSIMM нет, а онлайн-инструмент DSOMM мне использовать не удалось. Поэтому для обеих методологий опросники и расчет я собрал сам в Excel.
Официальной методики оценки соответствия ГОСТ Р 56939-2024 тоже нет, и для него я использовал внутренний инструмент Бастиона. В открытом доступе его нет — это стоит держать в голове, глядя на баллы ГОСТа.
Что получилось
Уровень зрелости ООО «Лиса и лосЬ» по каждой методологии — в таблице 2. Методологии считают его в разных шкалах: в процентах, в уровнях из пяти и в баллах из трех.
Таблица 2. Уровень зрелости ООО «Лиса и лосЬ» по каждой методологии
Методология | Уровень зрелости | Максимум |
|---|---|---|
BSIMM | 18% | 100% |
DSOMM | 2 | 5 |
SAMM | 0,55 | 3 |
ГОСТ Р 56939-2024 | 29% | 100% |
Сами методологии я оценил по пяти критериям из таблицы 1. Итог — в таблице 3.
Таблица 3.Оценка методологий
Критерий | Максимум | BSIMM | DSOMM | SAMM | ГОСТ Р 56939-2024 |
|---|---|---|---|---|---|
Удобство определения уровня зрелости | 10 | 4 | 5 | 7 | 8 |
Формирование рекомендаций | 10 | 3 | 5 | 7 | 10 |
Построение дорожной карты | 10 | 3 | 5 | 10 | 5 |
Построение тепловой карты | 10 | 5 | 5 | 4 | 5 |
Полнота охвата этапов SDLC | 7 | 7 | 5 | 6 | 7 |
Итого | 47 | 22 | 25 | 34 | 35 |
Ниже — плюсы и минусы, которые я увидел у каждой методологии в ходе оценки.
Таблица 4. Плюсы и минусы методологий
Методология | Плюсы | Минусы |
|---|---|---|
BSIMM | • Открытые данные для сравнения своей зрелости с другими компаниями • Практики покрывают все этапы SDLC • Отчет выходит ежегодно, в нем есть топ-10 популярных практик | • Нет официального механизма расчета зрелости • Часть практик не подходит большинству российских компаний • Есть спорные практики, которые вряд ли повысят уровень зрелости |
DSOMM | • Вопросы снабжены пояснениями, которые помогают трактовать их однозначно • Фокус на технических практиках • Есть поддержка сообщества | • Официальный онлайн-механизм расчета на деле не функционален. • Часть практик слишком дорога или не подходит большинству российских компаний • Некоторые этапы SDLC не покрыты |
SAMM | • Официальный механизм расчета в открытом доступе • Вопросы снабжены пояснениями • Гибкая дорожная карта • Есть поддержка сообщества | • Часть практик слишком дорога или не подходит большинству российских компаний. • Некоторые практики сформулированы непонятно. • Некоторые этапы SDLC не покрыты |
ГОСТ Р 56939-2024 | • Практики покрывают все этапы SDLC • Стандарт написан под российский рынок • Позволяет глубоко оценить процессы | • Нет официального механизма расчета зрелости |
Итоги сравнения и основные выводы
По сумме баллов ГОСТ Р 56939-2024 и SAMM идут почти вровень: 35 и 34 из 47. Поэтому выбирать между ними стоит не по итоговой цифре, а по задаче.
Нужно подготовиться к проверке по требованиям — берите ГОСТ Р 56939-2024. Стандарт написан под российский нормативный контекст и покрывает все этапы SDLC. Требования и критерии для артефактов описаны подробно, так что рекомендации по нему формируются легко. Главное неудобство — официального механизма расчета и анализа нет, инструмент оценки придется собрать самому. Отсюда и сложности с дорожной картой: очередность в требованиях прослеживается, но готового инструмента для построения дорожной карты нет.
Нужна AppSec-стратегия с дорожной картой — подойдет SAMM. Из четырех методологий только у нее есть рабочий официальный опросник с расчетом зрелости, и дорожная карта строится в нем же — гибко и наглядно. Минус в том, что SAMM ориентирована на зарубежные компании и требует высокого уровня зрелости: часть практик для российских компаний слишком дорога или неуместна.
Нужно подтянуть DevSecOps — смотрите на DSOMM. Она сосредоточена на технических практиках и дополняет SAMM. Официальный онлайн-инструмент у DSOMM есть, но у меня с ним не сложилось, хотя на профильных форумах пишут, что работать с ним можно.
BSIMM нужна, если важно сравнить себя с другими компаниями: открытые данные для такого сравнения есть только у нее. Для самооценки она неудобна: механизма расчета нет, а практики нужно переводить с английского и примерять на российскую действительность.
Ни одна из четырех методологий не закрывает все задачи сразу. Поэтому для комплексного аудита разумно сочетать несколько подходов и адаптировать критерии под конкретную компанию. Так устроена и сводная методология, по которой мы в Бастионе проводим аудиты безопасной разработки.
Что дальше
Во следующем материале разберу, как прошла оценка по BSIMM, DSOMM и SAMM: где опросник пришлось собирать самому, что показала оценка и откуда взялись баллы. Затем — то же для ГОСТ Р 56939-2024.
PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикадt.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес‑ориентированной защиты от специалистов Бастиона
Комментарии 0