Процессы безопасной разработки — это не просто набор инструментов для проверки кода. Основная концепция в том, чтобы все процессы работали как единый механизм, а безопасность была не просто дополнением, а неотъемлемой частью разработки. Фреймворк Building Security in Maturity Model (BSIMM) предлагает смотреть на процессы безопасной разработки с точки зрения зрелости, как на измеримую систему действий и результатов, а не просто как на чек‑лист практик.

В этом году Synopsys не обделил нас новым отчетом и представил BSIMM 15, который мы с вами разберем. Не буду углубляться, что такое BSIMM и как его применять на практике, об этом вы можете прочесть в статье про BSIMM 14, но стоит отметить, что BSIMM дает ежегодную оценку применимости различных практик. На этом и сосредоточимся, посмотрим, какие появились новые активности и какие сейчас в тренде.

Топ-10 активностей 

В обновлении BSIMM ежегодно публикуется топ-10 активностей — статистический срез того, что компании действительно применяют и что популярно среди участников исследования. Такой срез показывает направление тренда, а также может быть полезен как пример для бенчмарка. Но все же не стоит забывать, что нет идеального шаблона для внедрения практик безопасной разработки, а представленные активности — это всего лишь ориентир.

1. На этот раз первое место заняла активность CMVM1.1 Реагирование на инциденты.

   91,7% против 90% по сравнению с предыдущим отчетом

   Быстрое и организованное реагирование на инциденты позволит оперативно восстанавливать работоспособность и корректное функционирование приложения или инфраструктуры. Ведь нарушение доступности, целостности и конфиденциальности влечет за собой не только репутационные, но и материальные риски.

2. Активность SM1.4 Внедрение и контроль quality gates.

   90,1% против 90,8% по сравнению с предыдущим отчетом

   Постепенный подход к внедрению контрольных точек безопасности позволит командам на начальном этапе определять, что является критически опасным в разработке и как этого не допускать, не блокируя конвейер.

3. Третье место занимает активность CR1.4 Использование инструментов автоматического анализа исходного кода.

   87,6% против 86,2% по сравнению с предыдущим отчетом

   Must have в безопасной разработке. Ведь применение SAST‑инструментов позволит выявлять уязвимости еще до того, как артефакты попали в сборку.

4. Следом идет активность CP1.2 Обеспечение конфиденциальности.

   86,8% против 87,7% по сравнению с предыдущим отчетом

   Суть: тут все понятно, квадратное не катим, круглое не носим, конфиденциальные данные защищаем.

5. Активность PT1.1 Привлечение внешних специалистов для поиска уязвимостей.

   86% против 87,7% по сравнению с предыдущим отчетом

   Одна из активностей, которые помогут определить, насколько ваше приложение безопасно. Очень важно смотреть на безопасность с разных векторов.

6. Активность ST1.1 Тестирование граничных значений в ходе QA.

   84,3% против 84,6% по сравнению с предыдущим отчетом

   Команда QA, помимо функционального тестирования, проводит базовые тесты, имитирующие простые атаки злоумышленника, чтобы проверить условия, которые выставляются в рамках конвейера разработки. Например, при вводе специальных символов приложение не должно выдавать пользователю чувствительные данные.

7. Активность SE1.2 Обеспечение базовой безопасности сети.

   84,3% против 86,9% по сравнению с предыдущим отчетом

   Пункт, без которого построение безопасной инфраструктуры абсолютно невозможно.

8. Активность AA1.1 Реализация проверки безопасного проектирования.

   81,8% против 83,1% по сравнению с предыдущим отчетом

   Не секрет, что при проектировании архитектуры должны быть заложены функции безопасности (например, шифрование, контроль доступа).

9. Активность CP1.1 Стандартизация требований регуляторов.

   81% против 79,2% по сравнению с предыдущим отчетом

   Суть: комплексный подход к требованиям регуляторов поможет не упустить нормативные нюансы и заложить все требования еще на начальных этапах жизненного цикла.

10. Активность SR1.2 Создание внутреннего портала.

    79,3% против 79,2% по сравнению с предыдущим отчетом

    Суть: внутренний портал по безопасности поможет всем заинтересованным быстро найти нужную информацию, изучить подходы к безопасности и поделиться чем‑то полезным.

    

BSIMM — не единственная методология в сфере безопасной разработки. Мы в Positive Technologies выпустили собственную — AppSec Table Top. Наша методология помогает систематизировать известные практики и понять, что есть AppSec и как повысить защищенность создаваемых приложений с учетом требований регуляторов, интересов сотрудников и бизнеса. Всем рекомендую!

Активности. Что изменилось?

Governance

SM1.7 Соблюдение контрольных точек ИБ в процессе разработки ПО (Enforce security checkpoints and track exceptions)

Активность переместилась со 2-го уровня зрелости на 1-й уровень, что говорит нам о ее популярности и фундаментальном значении. Причина: эта активность позволяет сделать риск управляемым. На каждом этапе жизненного цикла ПО должны быть обязательные условия безопасности. Проект проходит дальше только при выполнении определенных условий (например, нет уязвимостей уровня critical или high).

Intelligence

SR 3.5 Стандарты и руководства внедрения новых технологий

В версии BSIMM 14 было упоминание про защиту LLM, но скорее в контексте того, что был виден рост интереса к внедрению AI/ML‑технологий и обеспечению их безопасности. В BSIMM 15 уже появилась полноценная активность.

Deployment

SE1.4 Определение критериев безопасного развертывания

Эта активность также переместилась со 2-го уровня зрелости на 1-й. Причина — рост использования облачных технологий (SaaS, PaaS и тому подобное) и контейнерной инфраструктуры. Теперь это не модная практика, а необходимость.

CMVM1.4 Экстренное реагирование и внесение изменений

Активность также переместилась со 2-го уровня на 1-й. С учетом регуляторных требований, теперь план реагирования на инциденты — это обязательный процесс для каждой компании.

CMVM2.4 Организация процесса ответственного разглашения уязвимостей

Активность переместилась с 3-го на 2-й уровень зрелости. Исследования показали рост ее популярности почти на 25%.

Почему эта практика стала более актуальной? С развитием платформ для исследования безопасности и каналов обратной связи она стала доступней для небольших компаний.

SE3.10 Обеспечение безопасности рабочих станций разработчика

Рабочие станции разработчиков — одна из ключевых зон риска. Если злоумышленник получает к ним доступ, тогда, например, угроза модификации исходного кода или кражи секретов становится критически опасной.

Что можно сделать в рамках данной активности: обеспечить актуальность ОС, реализовать контроль за правами доступа, использовать MFA для доступа к различным системам, а также контролировать установленное ПО.

Какой итог?

Подсвечу основные тезисы всего BSIMM 15.

1. Массовое внедрение мер безопасности цепочки поставок. Популярность практики SCA выросла на 67%.

2. AI/ML — новая область риска. Компании вынуждены сами создавать правила для AI/ML, так как индустриальные best practices еще формируются. Добавлена новая активность SR 3.5 Стандарты и руководства внедрения новых технологий.

3. Добавилась активность SE3.10 Обеспечение безопасности рабочих станций разработчика. Если раньше компании делали упор на защите пайплайнов и артефактов, то теперь индустрия осознала: компрометация рабочей станции разработчика = компрометация всего supply chain.

4. Смена фокуса с традиционных мероприятий по обучению безопасности. Вместо этого растет спрос на security champions и практическую интеграцию знаний в команды.

BSIMM 15 еще раз подтверждает, что безопасность перестала быть отдельной факультативной задачей и превратилась в обязательный элемент инженерной культуры. Но сам BSIMM не предлагает универсального шаблона: каждая компания должна адаптировать практики под свой контекст, свою зрелость и регуляторные требования. Однако сам факт, что различные компании делают похожие шаги, дает ценные ориентиры для построения и совершенствования программ безопасной разработки.