Безопасная разработка и релиз программного обеспечения

Что включает услуга по безопасной разработке и релизу ПО?

РБПО — это не разовая проверка перед релизом, а встроенный в сам процесс разработки контроль безопасности: анализ исходного кода, контроль зависимостей, поиск уязвимостей и секретов, а также контроль сборки и релиза ПО на каждом этапе жизненного цикла.

Главное отличие от классического тестирования безопасности (например, разового пентеста) — момент и периодичность проверки. Пентест смотрит на уже готовый продукт «снаружи», как это сделал бы злоумышленник, и проводится эпизодически — раз в квартал или перед крупным релизом. РБПО работает «изнутри» процесса: проверки встроены в CI/CD и запускаются на каждом коммите или сборке, поэтому уязвимость находят не через месяцы после того, как код попал в продакшен, а в течение минут после того, как её написали.

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

На каком этапе разработки лучше внедрять контроль безопасности?

Контроль безопасности внедряют не на одном этапе, а на всех этапах жизненного цикла ПО — от проектирования и разработки до тестирования, сборки и выпуска релиза.

Смысл в том, что на каждом этапе проверяются разные риски, и один инструмент не заменяет другой: на этапе проектирования проводят моделирование угроз, чтобы заранее определить, какие проверки и в каком объёме понадобятся конкретному продукту; в процессе разработки код проверяют статическим анализом (SAST) и ищут секреты, попавшие в репозиторий; при сборке и тестировании подключают анализ состава зависимостей (SCA) и динамический анализ (DAST); перед релизом и в проде — проверку контейнеров, инфраструктуры как кода и формирование актуального SBOM. Чем раньше на этом пути находят уязвимость, тем дешевле и быстрее её исправить — переписать несколько строк кода до релиза стоит на порядок меньше, чем экстренно патчить уже работающий продукт.

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

Можно ли внедрить безопасную разработку в уже действующий процесс?

Да, РБПО можно внедрять поэтапно, без полной перестройки существующего процесса разработки и без остановки текущих релизов. На практике это означает, что не нужно сразу подключать все виды проверок (SAST, DAST, SCA, поиск секретов) на всей кодовой базе. Обычно начинают с одного пилотного проекта или наиболее критичного сервиса, встраивают в него один-два инструмента контроля, и только после того как процесс обкатан — команда привыкла к находкам, настроены пороги критичности, — расширяют охват на остальные репозитории и добавляют следующие виды проверок. Такой подход снижает риск того, что внедрение безопасности застопорит текущие релизы или потребует останавливать разработку для «генеральной уборки» кода.

Какие инструменты используются для проверки ПО?

Как правило, применяются SAST, DAST, SCA, анализ секретов, контроль зависимостей и другие средства анализа безопасности.

Каждый инструмент закрывает свою часть риска, и они не заменяют, а дополняют друг друга: SAST (Static Application Security Testing) анализирует исходный код без его запуска и находит уязвимости на уровне логики и синтаксиса ещё до сборки; DAST (Dynamic Application Security Testing) проверяет уже запущенное приложение «снаружи», как это сделал бы злоумышленник, и находит проблемы, которые видны только во время работы программы; SCA (Software Composition Analysis) анализирует сторонние библиотеки и зависимости, которые использует продукт, и выявляет в них уже известные уязвимости; анализ секретов ищет в коде и конфигурациях случайно закоммиченные пароли, токены и ключи доступа. К этому набору часто добавляют проверку контейнеров и инфраструктуры как кода (IaC), а также моделирование угроз — чтобы заранее определить, какие из этих инструментов и в каком объёме нужны конкретному продукту.

Использование только одного инструмента — типичная ошибка: например, SAST не увидит уязвимость в чужой библиотеке, а SCA не найдёт ошибку в собственном коде команды. Поэтому в РБПО инструменты применяют в связке, а состав проверок подбирают под конкретный проект по итогам моделирования угроз, а не берут «универсальный» набор для всех.

Что такое SBOM и зачем он нужен?

SBOM (Software Bill of Materials) — это перечень программных компонентов и зависимостей продукта. Он позволяет контролировать состав ПО и быстро выявлять уязвимые компоненты.

По сути, SBOM — это «состав продукта» на упаковке, только для кода: полный список всех библиотек, фреймворков и сторонних модулей, из которых собрано приложение, с указанием версий. Без такого перечня компания часто даже не знает точно, что именно используется в её продукте, особенно если он собирался годами и через десятки рук. Практическая польза проявляется, когда где-то в мире находят критическую уязвимость в популярной библиотеке (классический пример — история с Log4j): с готовым SBOM компания за минуты проверяет по списку, используется ли эта библиотека в её продуктах и в каких именно, вместо того чтобы вручную поднимать зависимости во всех репозиториях.

SBOM также нужен и по формальным причинам: актуальный перечень компонентов входит в доказательную базу при сертификации и оценке соответствия ПО требованиям безопасной разработки — заказчики и регуляторы всё чаще запрашивают его как обязательный артефакт наряду с отчётами SAST, DAST и SCA.

Можно ли встроить проверки безопасности в CI/CD?

Да. Большинство проверок можно автоматизировать и запускать при commit, merge, сборке или перед выпуском релиза.

На практике это означает, что проверки не требуют отдельного ручного этапа «отправить код на аудит и подождать» — инструменты подключаются как шаги в уже существующий конвейер: SAST и поиск секретов чаще всего запускают на каждый commit или pull request, чтобы разработчик видел проблему сразу, пока помнит контекст изменений; SCA — на этапе сборки, когда фиксируется финальный набор зависимостей; DAST и проверку контейнеров — перед выпуском релиза, на уже собранном и развёрнутом в тестовой среде приложении. При обнаружении критичных уязвимостей конвейер можно настроить так, чтобы сборка блокировалась автоматически, а некритичные находки просто фиксировались для последующего исправления, не останавливая релиз.

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

Будут ли проверки безопасности замедлять разработку?

При правильной настройке — минимально. Проверки распределяются по этапам и не обязательно выполняются полностью при каждом изменении кода.

Опасение понятное: если запускать весь набор проверок целиком на каждый commit, конвейер действительно может замедлиться. Поэтому на практике проверки разносят по этапам и по глубине — на commit и pull request запускают быстрые, «лёгкие» проверки (например, точечный SAST-анализ изменённых файлов и поиск секретов), которые занимают секунды-минуты и не блокируют работу разработчика; более ресурсоёмкие проверки — полный SAST по всей кодовой базе, DAST на развёрнутом приложении — переносят на ночные сборки, отдельные ветки или этап перед релизом, где время выполнения уже не мешает текущей работе команды.

Плюс к этому влияет и то, что находки на раннем этапе (в момент, когда разработчик ещё держит в голове контекст своих изменений) исправляются в разы быстрее, чем те же уязвимости, найденные через месяцы при разовом аудите перед релизом. Поэтому в первые недели после внедрения РБПО темп может немного снизиться — команда донастраивает пороги срабатывания и разбирается с накопленным техдолгом, — но дальше проверки идут параллельно с разработкой и не становятся отдельным узким местом.

Что происходит при обнаружении критической уязвимости?

Уязвимость фиксируется, определяется ее критичность, назначается ответственный и контролируется устранение до выпуска релиза.

Процесс выстроен так, чтобы находка не «терялась» между отчётом сканера и реальным исправлением в коде. Сначала уязвимость регистрируют в реестре с описанием, где именно она обнаружена и каким инструментом. Затем её приоритизируют — критичность оценивают не только по формальному уровню (CVSS и аналогичным шкалам), но и по контексту: доступен ли уязвимый компонент извне, обрабатывает ли он чувствительные данные, насколько легко его эксплуатировать. Дальше уязвимость закрепляют за конкретным ответственным — обычно это владелец соответствующего сервиса или компонента — с чёткими сроками устранения: для критичных находок сроки минимальны, и релиз с неисправленной критической уязвимостью, как правило, не выпускается.

На каждом этапе фиксируется статус — от «обнаружено» до «исправлено и подтверждено повторной проверкой», — поэтому в любой момент видно, сколько уязвимостей открыто, кто над ними работает и что мешает закрыть релиз. Такой контролируемый цикл и отличает управление уязвимостями в РБПО от разового «прогнали сканер и получили отчёт»: отчёт без процесса устранения сам по себе безопасность не повышает.

Помогает ли услуга подготовиться к требованиям РБПО и ГОСТ Р 56939-2024?

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

Подготовка строится как последовательный переход от текущего состояния к требуемому, а не разовая проверка «соответствуем/не соответствуем». Сначала анализируют, как устроены процессы разработки в компании сейчас, и сравнивают их с требованиями ГОСТ Р 56939-2024 и связанных нормативных документов (в частности, приказов ФСТЭК России № 240 и № 117) — это и есть выявление несоответствий: где отсутствует моделирование угроз, где не хватает нужных видов проверок, где не формируется SBOM или не ведётся реестр уязвимостей. По итогам такого анализа формируют план мер — как организационных (регламенты, распределение ответственности, роли в процессе разработки), так и технических (встраивание конкретных инструментов SAST/DAST/SCA в CI/CD, настройка контроля устранения уязвимостей).

Результатом становится не только приведённый в соответствие процесс, но и доказательная база — комплект отчётов, реестров и заключений, которые предъявляются при оценке соответствия или сертификации. Это особенно важно для компаний, которым ГОСТ Р 56939-2024 и приказы ФСТЭК предписывают обязательное применение практик безопасной разработки, — услуга закрывает путь от «у нас пока этого нет» до готового пакета документов и работающего процесса.

Что получает заказчик по результатам работ?

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

Иными словами, результат — это не только отчёт «на бумаге», а рабочий контур безопасности, который остаётся у заказчика после завершения проекта. В комплект входят: модель угроз, составленная под конкретный продукт; отчёты по SAST, DAST, SCA и поиску секретов с описанием найденных проблем; результаты проверки контейнеров и инфраструктуры как кода; актуальный SBOM с полным составом компонентов продукта; реестр уязвимостей с приоритизацией и статусом устранения каждой из них; а также рекомендации по дальнейшему развитию процессов безопасной разработки. Отдельным блоком идёт доказательная база — комплект документов, который можно предъявить при сертификации или оценке соответствия ГОСТ Р 56939-2024.

Ключевая особенность в том, что заказчик получает не разовый «снимок» состояния безопасности на момент проверки, а встроенный в CI/CD, работающий на постоянной основе процесс контроля — то есть после завершения проекта проверки не прекращаются, а продолжают запускаться автоматически при каждом новом изменении кода.

Что регулирует ГОСТ Р 56939-2024?

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

Речь идёт именно о процессах, а не о требованиях к конечному продукту напрямую: стандарт описывает, что должно происходить на каждой стадии — от проектирования и написания кода до тестирования, сборки, выпуска релиза и последующей поддержки, — чтобы безопасность была встроена в разработку, а не проверялась постфактум. В частности, он задаёт требования к моделированию угроз, статическому и динамическому анализу кода, анализу состава сторонних компонентов, управлению уязвимостями и формированию сопроводительной документации (включая SBOM).

ГОСТ Р 56939-2024 действует не изолированно, а в связке с другими нормативными документами — в частности, с приказами ФСТЭК России № 240 и № 117, которые определяют, для каких категорий организаций и информационных систем применение практик безопасной разработки обязательно. Соответствие стандарту подтверждается не декларативно, а через доказательную базу — комплект отчётов и реестров, которые формируются именно в процессе работ по РБПО.

Обязательно ли применять ГОСТ Р 56939-2024 всем разработчикам ПО?

Нет. Обязательность зависит от требований регуляторов, назначения ПО, условий сертификации и требований заказчика.

Сам по себе ГОСТ Р 56939-2024 — национальный стандарт, и добровольное применение стандартов в России по умолчанию не является обязательным. Обязательным его применение становится в конкретных ситуациях: если разработчик работает с государственными информационными системами, значимыми объектами критической информационной инфраструктуры (КИИ) или другими категориями, для которых приказы ФСТЭК России (в частности, № 240 и № 117) прямо предписывают применение практик безопасной разработки; если ПО проходит сертификацию или оценку соответствия, где стандарт выступает одним из требуемых критериев; либо если применение стандарта закреплено в требованиях конкретного заказчика — например, в банковском или страховом секторе, где к поставщикам ПО часто предъявляют повышенные требования по безопасности разработки.

Для остальных компаний применение ГОСТ Р 56939-2024 остаётся добровольным, но на практике всё чаще становится конкурентным преимуществом: наличие выстроенного процесса РБПО и подтверждающей документации упрощает работу с заказчиками из регулируемых отраслей и снижает риск отказа на этапе due diligence или тендера.

Какие процессы необходимо внедрить для соответствия ГОСТ Р 56939-2024?

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

Если разложить это по сути, речь идёт о выстраивании полного контура, а не о добавлении одного-двух инструментов. Организационные меры — это регламенты и распределение ответственности: кто отвечает за безопасность на каждом этапе, как оформляются и согласуются решения. Управление безопасностью разработки — общая координация всех практик как единого процесса, а не набора разрозненных проверок. Анализ угроз — моделирование рисков конкретного продукта на этапе проектирования, определяющее, какие проверки и в каком объёме нужны именно ему. Контроль кода и компонентов — это статический анализ (SAST), поиск секретов и анализ состава сторонних зависимостей (SCA). Безопасная сборка — контроль целостности и настроек на этапе сборки и релиза, включая проверку контейнеров и инфраструктуры как кода. Тестирование — динамический анализ (DAST) уже работающего приложения. Работа с уязвимостями — регистрация находок, их приоритизация и контролируемое устранение с фиксацией статуса вплоть до подтверждённого исправления.

Важный момент: соответствие ГОСТ Р 56939-2024 оценивают именно по наличию и зрелости этих процессов в комплексе, а не по отдельным инструментам — можно использовать хорошие сканеры и всё равно не соответствовать стандарту, если, например, отсутствует моделирование угроз или устранение уязвимостей никак не контролируется.

Можно ли пройти оценку соответствия ГОСТ Р 56939-2024 только за счет SAST, DAST и SCA?

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

Это частое заблуждение: компания подключает сканеры SAST, DAST и SCA к своему CI/CD и считает, что тем самым закрыла требования стандарта. На деле инструментальный контроль — необходимое, но не достаточное условие. Оценка соответствия смотрит и на то, как устроен процесс вокруг этих инструментов: закреплены ли роли и ответственность за безопасность разработки в регламентах, проводится ли моделирование угроз на этапе проектирования, ведётся ли документация (включая SBOM и реестр уязвимостей), и главное — насколько эти процедуры реально выполняются на практике, а не существуют только «на бумаге». Наличие настроенных сканеров без регламентов и без подтверждённого контроля устранения уязвимостей будет квалифицировано как частичное, а не полное соответствие.

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

Как понять, соответствует ли текущий процесс разработки ГОСТ Р 56939-2024?

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

На практике GAP-анализ начинается с изучения того, как разработка устроена сейчас — какие инструменты уже используются, есть ли регламенты, кто и за что отвечает, ведётся ли документация по составу ПО и уязвимостям. Это сопоставляется пункт за пунктом с требованиями ГОСТ Р 56939-2024: по каждому требованию фиксируется, выполняется оно полностью, частично или не выполняется вовсе. Результатом становится не абстрактная оценка «соответствуем на 60%», а конкретный перечень несоответствий с указанием, чего именно не хватает — например, отсутствует моделирование угроз, не формируется SBOM, нет регламента по срокам устранения уязвимостей.

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