Разработка программного обеспечения не стоит на месте: меняется технологический стек, совершенствуются подходы к созданию ПО. Вместе с тем уточняются и требования к ПО и процессу разработки в целом. Все больше людей узнает о понятии SSDLC (Secure Software Development Life Cycle) или безопасный жизненный цикл разработки ПО. Как же построить такой цикл в команде? Как сформировать качественную стратегию построения безопасной разработки? Давайте разбираться!
Текущий статус
Прежде всего важно разобраться с текущим статусом реализации процессов безопасной разработки, увидеть картину as is. Каждый желающий может найти в Интернете популярный фреймворк, например, OWASP SAMM, и обнаружить там множество best practices, направленных на построение SSDLC, и проверить наличие таких практик в команде разработки. Но что делать дальше? Если методология OWASP SAMM включает в себя около 90 практик, то в методологии BSIMM их 128. Как из такого количества выбрать то, что подходит именно вам? С каких best practices начать?
В целом выбор практик безопасной разработки определяется (но не ограничивается) следующими факторами:
требования законодательства;
уровень зрелости процессов разработки;
желание команды внедрить конкретные практики и т.д.
Остановимся на каждом факторе подробнее.
Требования законодательства
При формировании стратегии построения безопасной разработки необходимо в первую очередь учесть требования законодательства. Требования к процессам разработки меняются в зависимости от типа программного обеспечения. Так, для объектов КИИ (информационных, автоматизированных систем управления технологическими процессами и информационно-телекоммуникационных сетей, которые функционируют в сфере здравоохранения, науки, энергетики, банковской сфере и иных ключевых отраслях экономики ) будут актуальны положения Приказа ФСТЭК России N 239. В частности, в соответствии с данным приказом в отношении объектов КИИ необходимо осуществлять моделирование угроз (п.11), статический анализ (п.29.3), фаззинг-тестирование (п.29.3), анализ угроз (п.29.3) и т.д. В то же время на разработку средств защиты информации (в частности, антивирусы, межсетевые экраны, SIEM-системы, DLP-системы и др.), содержащей сведения, составляющие государственную тайну или иную информацию ограниченного доступа, распространяется действие Приказа ФСТЭК России N 240. В данном приказе изложен порядок сертификации процессов проектирования и производства программного обеспечения на соответствие требованиям ГОСТ Р 56939-2024. Указанный стандарт включает в себя описание 25 процессов безопасной разработки ПО (БРПО), начиная с планирования таких процессов и заканчивая обеспечением безопасности при выводе ПО из эксплуатации. В отношении каждого процесса БРПО определены цели внедрения, требования к реализации и артефакты его выполнения. ГОСТ Р 56939-2024 был разработан с учетом мировых методологий Owasp SAMM, BSIMM и Microsoft SDL.
Уровень зрелости процессов разработки
Уровень зрелости процессов разработки (УЗ) ПО — это характеристика, отражающая полноту выполнения лучших практик по каждому процессу БРПО. В частности, в BSIMM в отношении каждой практики определен процесс, к которому она относится, и ее УЗ, первый, второй или третий. УЗ команды разработки определяется исходя из УЗ каждого реализуемого ей процесса. Например, в BSIMM, если все практики каждого из 12 процессов первого УЗ выполнены, то УЗ команды тоже первый. Количество УЗ, перечень процессов и входящих в их состав практик отличаются в разных методологиях. Так, в BSIMM определено 3 УЗ, 12 процессов и 128 практик, в OWASP SAMM 3 УЗ, 15 процессов и около 90 практик, а в DSOMM 5 УЗ, 19 процессов и почти 190 практик. Методологий оценки процессов много: они могут быть общедоступными, как OWASP SAMM, или закрытыми, как BSIMM. Кроме того, ряд компаний, занимающихся аудитами процессов безопасной разработки, могут использовать собственные фреймворки, учитывающие отечественное законодательство и мировые best practices. Вне зависимости от выбранной методологии при построении стратегии развития безопасной разработки (без учета требований законодательства) рекомендуется начать с практик, соответствующих невысокому уровню зрелости. Как правило, это практики, которые проще и быстрее внедрить. В частности, рекомендуется начать с применения статического и композиционного анализа и только потом переходить на динамический анализ и фаззинг. Для обеспечения системного подхода к повышению УЗ процессов БРПО рекомендуется сформировать дорожную карту с указанием сроков внедрения каждой практики как на фрагменте таблицы ниже .
Шаги построения безопасной разработки | 2026 год | 2027 год |
Внедрение инструментов для тестирования безопасности | Проводить статический и композиционный анализ | Проводить динамический анализ и внешнее тестирование на проникновение |
Документирование безопасной разработки | Разработать проект «Руководства по безопасной разработке ПО» | |
Обучение безопасности разработки | Разработать план обучения безопасной разработке | Развивать корпоративную базу знаний по безопасной разработке ПО |
Желание команды
Важно понимать, что если участники команды разработки по собственной инициативе хотят внедрить или уже внедряют конкретные best practices, вроде OSA, не стоит им мешать. Внутренняя мотивация сотрудников снижает сопротивление, ускоряет внедрение практик и формирует культуру безопасности без излишнего контроля со стороны. Также внутри каждой команды можно назначить чемпионов по безопасности (Security Champions), которые будут отвечать за реализацию практик БРПО, консультировать коллег по вопросам безопасной разработки и транслировать успехи команды руководству.
Рекомендации
В заключение отмечу, что советую провести аудит процессов БРПО всем командам разработки, вне зависимости от типа ПО, которое они создают, и нужно ли это по закону или нет. Такой аудит поможет выявить слабые места в процессах разработки и сформировать стратегию по их улучшению. К слову, оценка процессов БРПО сама по себе является best practice, которую рекомендуется осуществлять раз полгода или год. Данная проверка может быть реализована силами сотрудников организации-разработчика или с привлечением внешних аудиторов. Если вы решили проводить оценку самостоятельно, рекомендую ознакомиться с методологиями BSIMM, OWASP SAMM, DSOMM, а также — с ГОСТ Р 56939-2024. Больше best practices и требований регуляторов по безопасной разработке можно найти на этом сайте.
