Представьте, что вы построили неприступную крепость. Стены из титана, рвы с акулами, а стража проходит проверку на полиграфе. Звучит надежно? Да. Только чертежи этой крепости были скомпрометированы еще на этапе проектирования, а ключи от ворот выдает стажер по первому требованию всем без разбора.

В безопасной разработке мы часто совершаем похожую ошибку: фокусируемся на защите продукта (кода, его архитектуры и инфраструктуры), совершенно упуская из виду процесс его создания. Да, методологии вроде STRIDE или PASTA отлично отвечают на вопрос «Как взломают нашу систему?». Но что делать, если угроза кроется не в баге, а в том, как этот баг попал в релиз.

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

Это статья для тех, кто хочет строить безопасность не вокруг кода, а вокруг всего пути кода от проектирования до продакшена.

Роль классического аудита: фундамент безопасной разработки

Аудит процессов безопасной разработки — это важнейший этап зрелости любой компании. Его главная ценность заключается в формировании системного взгляда, который позволяет зафиксировать текущее состояние процессов (AS-IS), определить целевую модель (TO-BE) и на основе стандартов и лучших практик составить стратегическую дорожную карту. Аудит отлично структурирует хаос, выявляет очевидные пробелы в регламентах и задает вектор развития.

Где классический аудит достигает своих границ?

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

1. Отсутствие оценки критичности актива

   Аудит оценивает, как организована разработка в целом, но редко углубляется в анализ того, насколько критично то, что мы защищаем. Без понимания ценности актива для бизнеса и реализованных механизмов защиты в нем сложно оценить адекватность применяемых мер.

2. Сложность приоритизации для бизнеса

   Дорожная карта по результатам аудита часто предлагает комплексное внедрение практик «с нуля». С точки зрения ресурсов, это может означать 2–3 года плотной работы команды и значительные бюджеты. Бизнесу бывает сложно обосновать такие инвестиции без четкой доказательной базы — «почему мы должны внедрять эту конкретную практику прямо сейчас, а не через год?».

3. Риск «универсальных» рекомендаций

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

4. Субъективность оценки критичности

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

Как превратить рекомендации в точечный план действий?

Важно понимать: моделирование угроз не заменяет аудит, а дополняет его, переводя фокус с соответствия чек-листам на управление реальными рисками.

Если аудит дает нам список того, что в принципе стоит сделать, то моделирование угроз позволяет:

• определить актуальные угрозы, которые могут возникнуть в процессе разработки ПО и оценить их влияние на активы компании;

• оценить реализованные меры защиты от угроз безопасности в процессе разработки ПО и определить слабые места;

• определить меры по нейтрализации угроз безопасности процессов РБПО.

Именно такой симбиоз позволяет трансформировать общий отчет в прагматичный, экономически обоснованный план защиты, который бизнес готов поддерживать и финансировать.

Анатомия процесса: на чем фокусируемся и как действуем

В отличие от классического моделирования угроз, где мы ищем уязвимости в архитектуре самого приложения, здесь наша «система» — это процессы разработки. Мы переносим фокус с кода на «фабрику», которая этот код производит.

Угрозы процессов РБПО рассматриваются в разрезе:

1. этапов жизненного цикла разработки ПО:

• анализа требований к ПО;

• проектирования архитектуры ПО;

• разработки;

• тестирования;

• внедрения и развертывания;

• сопровождения и поддержки.

2. обеспечивающих и управляющих процессов:

• менеджмента документации и конфигурации ПО;

• менеджмента инфраструктуры среды разработки ПО;

• менеджмента человеческих ресурсов.

Моделирование угроз процессов РБПО состоит из следующих этапов.

Фундамент методологии: синтез регулирования и лучших мировых практик

Наш подход к моделированию угроз процессов РБПО не изобретает велосипед, а грамотно адаптирует проверенные стандарты и фреймворки под реалии современной разработки. В его основе лежит методика оценки угроз безопасности информации ФСТЭК России (утверждена 5 февраля 2021 года).

Однако классическая методика ФСТЭК России ориентирована на информационные системы в целом. Чтобы сделать ее применимой к процессам разработки, мы расширили базовый перечень угроз из ГОСТ Р 58412-2019 («Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»), дополнив угрозами, характерными именно для процессов разработки и поставки ПО.

При этом сами процессы, которые мы оцениваем и защищаем, опираются на актуальный ландшафт стандартов:

• ГОСТ Р 56939-2024: как современный российский базис для построения процессов безопасной разработки;

• международные фреймворки зрелости: SLSA (для защиты цепочек поставок), BSIMM и OWASP SAMM (для оценки зрелости практик), а также OWASP DSOMM (как практическое руководство).

Такое сочетание позволяет нам говорить на одном языке как с регуляторами, так и с инженерными командами, внедряющими передовые DevSecOps-практики.

Ключевые выводы: почему защита процессов — это новая норма

Моделирование угроз процессов РБПО меняет парадигму: мы перестаем искать только «дыры» в коде и начинаем укреплять «фундамент», на котором этот код создается. Вот четыре принципа, на которых держится этот подход.

1. Безопасность процесса = безопасность продукта

   Уязвимость в CI/CD или репозитории неизбежно ведет к компрометации конечного ПО, какими бы надежными ни были защиты на уровне приложения.

2. Непрерывность, а не галочка

   Моделирование угроз — это не разовое мероприятие перед релизом, а итеративный цикл, который эволюционирует вместе с вашим SDLC.

3. Shift Left в действии

   Найти и устранить угрозы на этапе написания кода стоит в десятки раз дешевле, чем расследовать инцидент и выпускать экстренные патчи в продакшене.

4. Люди важнее инструментов

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

Что это дает бизнесу?

• снижение критических рисков: проактивная защита от Supply Chain атак, утечек через репозитории и других угроз;

• комплаенс: соответствие требованиям регуляторов, российским и международным стандартам;

• оптимизация бюджета: перенос расходов с реактивного «тушения пожаров» и расследований на предсказуемое плановое развитие;

• Time-to-Market: автоматизированные проверки безопасности не тормозят релизы, а делают их стабильными и предсказуемыми.

Что дальше?

В этой статье мы заложили концептуальный фундамент: разобрались, почему защита процессов разработки не менее важна, чем защита самого кода, как адаптировать строгую методологию ФСТЭК под реалии безопасной разработки, и какие 11 этапов включает в себя моделирование угроз процессов РБПО.

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

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

Автор:

Дьяконова Анастасия, аналитик по безопасной разработке