Когда стоит остановить релиз из-за находки безопасника, а когда нет

«Не ходи к эльфам за советом: они скажут и “нет”, и “да”».
— Джон Р. Р. Толкин, «Братство Кольца»

Безопасник останавливает релиз?

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

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

Если правила не определены заранее, каждый релиз превращается в переговоры. Команда разработки говорит: «Окно поставки согласовано, заказчик ждёт». Специалист по ИБ отвечает: «В сборке есть риск, выпускать нельзя». Бизнес задаёт закономерный вопрос: «Насколько этот риск критичен?» В такой ситуации решение часто принимается не по процессу, а по силе аргументов, авторитету участников или давлению сроков.

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

Безопасность как часть SDLC, а не финальная проверка

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

Именно в этом заключается DevSecOps-подход: безопасность становится частью инженерного потока, а не отдельной внешней процедурой. Команда не ждёт финального вердикта перед релизом, а постоянно получает обратную связь через автоматические проверки, ревью, security-отчёты и контрольные точки.

При этом важно использовать не один инструмент, а набор анализаторов, которые закрывают разные классы рисков. SAST помогает находить уязвимости в исходном коде до слияния изменений. DAST проверяет работающее приложение и выявляет проблемы, которые проявляются во время выполнения. SCA анализирует сторонние зависимости, библиотеки и open source-компоненты, которые попадает в продукт и могут стать источником риска для цепочки поставки.

Чем шире покрытие проверок, тем выше вероятность обнаружить проблему до production. Поэтому в зрелом процессе используются разные типы анализаторов: коммерческие, суверенные решения, представленные на российском рынке, внутренние корпоративные инструменты и open source-решения. Их не нужно противопоставлять друг другу. Практический подход заключается в том, чтобы комбинировать инструменты, сравнивать результаты, снижать число ложных срабатываний и выстраивать единый процесс обработки находок.

В такой модели важную роль играют Quality Gates — формальные контрольные точки качества и безопасности. Они определяют условия, при которых изменение может перейти на следующий этап: попасть в основную ветку, собрать артефакт, пройти в релиз-кандидат или быть выпущенным в production.

Quality Gate могут проверять разные условия: успешность тестов, отсутствие критичных SAST-находок, результат DAST-проверки, наличие уязвимых зависимостей по SCA, статус ревью, наличие approvals, отсутствие незакрытых обсуждений, корректность артефакта и подтверждение владельца риска.

Такой подход переводит безопасность из режима «ручного запрета» в режим управляемого процесса.

Роль безопасности в релизном процессе

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

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

Именно поэтому ключевой вопрос должен звучать не так:

«Нашли уязвимость — останавливаем релиз?»

Правильная формулировка другая:

«Попадает ли эта находка в наши критерии блокировки релиза?»

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

Такой подход снижает субъективность. Он позволяет команде не спорить о том, «кто прав», а работать с понятными критериями: критичность, вероятность эксплуатации, влияние на данные, доступность компонента, наличие временной защиты и стоимость задержки релиза.

Когда релиз действительно нужно остановить?

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

Рассмотрим типовую ситуацию. Команда готовит релиз личного кабинета для корпоративных клиентов. В новой версии появляется функция выгрузки отчётов: пользователь может скачать данные по своей организации. На финальном этапе проверки специалист по безопасности обнаруживает проблему в проверке прав доступа.

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

Это уже не рядовая находка из отчёта сканера. Это риск утечки данных.

В такой ситуации выпускать релиз в исходном виде нельзя.

Почему это блокер

Здесь одновременно сходятся несколько факторов:

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

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

Когда проблема находится не только в коде

Важно учитывать, что современный релиз — это не только исходный код. В production попадает результат всей цепочки поставки: код, зависимости, контейнеры, пакеты, конфигурации, CI/CD-сценарии, секреты, артефакты и окружения.

Поэтому блокирующей может быть не только классическая уязвимость в приложении. Релиз также стоит остановить, если обнаружены:

• критичная уязвимость в зависимости, которая попадает в runtime;
• подмена или неподтверждённое происхождение артефакта;
• секреты, ключи или токены в репозитории, образе или сборке;
• непроверенный контейнерный образ;
• нарушение политики работы с пакетами и внешними источниками;
• возможность вмешательства в pipeline или процесс сборки;
• отсутствие связи между commit, pipeline, артефактом и релизом.

Такие ситуации относятся уже к защите цепочки поставки ПО. Если команда не может доказать, из какого кода собран артефакт, какие проверки он прошёл и кто разрешил выпуск, релиз становится плохо управляемым даже при отсутствии очевидной уязвимости в бизнес-логике.

Какие варианты есть у команды

В подобной ситуации у команды есть несколько допустимых сценариев.

• Первый — исправить проблему, повторно провести проверки и выпускать релиз только после подтверждения устранения риска.
• Второй — отключить новую функцию через feature flag, если архитектура продукта это позволяет, и выпустить релиз без рискованной функциональности.
• Третий — временно ограничить доступ к функции, если такая мера действительно закрывает сценарий эксплуатации и согласована владельцами продукта и информационной безопасности.
• Четвёртый — заблокировать прохождение Quality Gate до тех пор, пока не будут устранены критичные находки SAST, DAST или SCA, либо пока риск не будет формально принят ответственным владельцем.

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

Признаки блокирующей находки

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

• доступ к данным других пользователей или организаций;
• обход авторизации или аутентификации;
• повышение привилегий;
• удалённое выполнение кода;
• утечка секретов, ключей или токенов;
• критичная уязвимость в зависимости, которая используется в production;
• компрометация артефактов сборки или цепочки поставки;
• наличие публичного exploit или признаков активной эксплуатации;
• нарушение обязательных требований заказчика, регулятора или внутренней политики;
• отсутствие временных мер снижения риска.

Важно подчеркнуть: остановка релиза в такой ситуации не является провалом команды. Напротив, это показатель зрелости процесса. Риск был выявлен до production, команда приняла управляемое решение, а пользователи не получили опасную версию продукта.

Что же делать команде?

Чтобы решение о релизе не зависело от эмоций, команда должна заранее выстроить процесс работы с находками безопасности. Он должен быть понятен разработке, ИБ, владельцам продукта и бизнес-заказчикам.

1. Заранее определить критерии блокировки

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

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

Такие критерии превращают безопасность из ручного согласования в часть инженерного процесса.

2. Разделять severity и реальный риск

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

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

Поэтому рядом с технической критичностью необходимо оценивать:

• доступность компонента;
• наличие реального пути эксплуатации;
• тип и чувствительность данных;
• роль системы в бизнес-процессе;
• наличие публичного exploit;
• возможность временно ограничить риск;
• влияние задержки релиза на пользователей и бизнес.

Главный вопрос — не только «какой severity у находки?», а «какой риск она создаёт именно в нашей системе?»

3. Использовать несколько классов анализаторов безопасности

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

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

DAST отвечает на вопрос: как ведёт себя уже запущенное приложение и можно ли воспроизвести уязвимость в рабочем сценарии.

SCA отвечает на вопрос: какие сторонние зависимости, библиотеки и open source-компоненты используются в продукте, есть ли среди них уязвимые версии и попадают ли они в runtime.

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

Практически правильный подход — использовать несколько инструментов одновременно: российские и суверенные решения для контуров с требованиями импортонезависимости, коммерческие платформы, если они уже приняты в компании, и open source-инструменты для расширения покрытия и независимой проверки. Чем больше релиз зависит от внешних компонентов и автоматической сборки, тем важнее иметь несколько независимых источников сигналов безопасности.

При этом большое количество сканеров само по себе не решает проблему. Если результаты не связаны с merge request, pipeline, артефактом и релизным решением, команда получает не безопасность, а шум. Поэтому анализаторы должны быть встроены в единый процесс: находка должна иметь критичность, статус, владельца, связь с изменением и понятное влияние на прохождение Quality Gate.

4. Настроить Quality Gates

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

Например, можно определить, что изменение не может быть слито в основную ветку, если:

• pipeline завершился с ошибкой;
• не пройдены обязательные тесты;
• есть критичные SAST-находки;
• DAST обнаружил воспроизводимый риск во внешнем контуре;
• SCA выявил критичную уязвимость в зависимости, которая попадает в runtime;
• нет обязательных approvals;
• не закрыты обсуждения по merge request;
• не определён владелец принятого риска.

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

5. Собирать единый дашборд безопасности

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

Для зрелого процесса нужен единый ASOC-подход. ASOC — это Application Security Orchestration and Correlation: оркестрация и корреляция результатов прикладной безопасности. На практике это означает, что команда видит не отдельные отчёты сканеров, а общий дашборд риска по приложению.

Такой дашборд должен отвечать на простые вопросы:

• какие критичные находки есть сейчас;
• в каком компоненте они обнаружены;
• какой commit или merge request их принёс;
• какие зависимости затронуты;
• какие проблемы уже исправлены;
• какие риски приняты временно;
• какие находки блокируют релиз;
• какая динамика по безопасности от релиза к релизу.

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

6. Фиксировать решение и ответственность

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

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

Формулировка «исправим позже» не является управлением риском. Управление риском начинается там, где есть владелец, срок, критерии контроля и прозрачная история принятого решения.

7. Переносить проверки ближе к разработке

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

Проверки должны появляться раньше: на уровне merge request, pipeline, сборки артефакта и подготовки релиза. SAST помогает находить проблемы в коде до слияния, DAST — проверять поведение работающего приложения, SCA — контролировать зависимости и сторонние компоненты.

Такой подход снижает стоимость исправления и уменьшает конфликт между разработкой и информационной безопасностью.

8. Встраивать правила в инструменты

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

Критичные правила должны быть технически обеспечены: обязательные проверки, approvals, защищённые ветки, контроль pipeline, хранение отчётов, история решений и понятная связь между изменением, проверкой, артефактом и релизом.

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

9. Оставлять место для управляемых исключений

Не каждая находка должна автоматически блокировать релиз. Иногда риск низкий, иногда уязвимый код недостижим, иногда проблема не попадает в runtime, а иногда новый релиз закрывает более серьёзную уязвимость, уже присутствующую в production.

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

GitFlic — решение?

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

Изменение должно быть видно до релиза

В основе такого процесса лежит merge request. Именно там изменение впервые становится видимым для команды: что было изменено, кто автор, кто участвовал в ревью, какие проверки запущены, какие замечания обсуждались и какие решения были приняты.

Если проверки безопасности привязаны к merge request, находка появляется не в конце релизного цикла, а до попадания изменения в основную ветку. Это позволяет исправлять проблемы раньше и не превращать релиз в финальный спор между разработкой и ИБ.

Проверки должны быть частью CI/CD

Следующий уровень — CI/CD. В pipeline можно запускать тесты, сборку, линтеры, SAST, DAST, SCA, проверки секретов, контейнерных образов, конфигураций и другие автоматические контроли.

Для релизного процесса важно не только само наличие проверки, но и её связь с конкретным изменением. Команда должна понимать, какой commit проверялся, какой pipeline прошёл, какой анализатор сформировал отчёт, какой артефакт был собран и на каком основании изменение было допущено дальше.

Здесь важно не ограничиваться минимальным набором проверок. Для разных продуктов и стадий SDLC могут использоваться разные инструменты: open source-решения, суверенные анализаторы, внутренние скрипты, коммерческие AppSec-платформы. Чем выше критичность продукта и чем серьёзнее требования к цепочке поставки, тем более разнообразным должен быть набор проверок.

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

Quality Gates можно закрепить в процессе

В GitFlic можно выстроить Quality Gates вокруг merge request, pipeline и правил слияния. Например, команда может определить, что изменение не должно попадать в целевую ветку без успешного pipeline, обязательных согласований и выполненных проверок безопасности.

Такой подход особенно важен для команд, где релизы проходят часто, а число параллельных изменений растёт. Чем больше участников и компонентов, тем опаснее полагаться на ручную координацию. Quality Gates позволяют формализовать правила: если условия не выполнены, изменение не продвигается дальше.

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

ASOC-дашборд помогает видеть риск целиком

Отдельное значение имеет ASOC-дашборд безопасности. Для принятия решения о релизе команде недостаточно знать, что «где-то есть отчёт SAST» или «сканер зависимостей что-то нашёл». Нужна единая картина по приложению и релизу.

В GitFlic можно организовать такой подход через security-разделы и отчёты по SAST, DAST и SCA. SAST позволяет анализировать исходный код, DAST — проверять работающее приложение, SCA — контролировать сторонние зависимости и компоненты. Вместе эти проверки дают более полное представление о прикладном риске.

Преимущество такого подхода в том, что команда не привязана к одному конкретному анализатору. Можно подключать те инструменты, которые соответствуют требованиям организации: суверенные решения, представленные на российском рынке, open source-анализаторы, внутренние корпоративные инструменты или специализированные коммерческие продукты. Важно, чтобы результаты проверок попадали в общий инженерный контур и могли учитываться при принятии релизного решения.

ASOC-подход полезен тем, что объединяет результаты разных типов анализа в управляемую картину: какие находки критичны, какие уже исправлены, какие относятся к конкретному commit или merge request, какие зависимости затронуты, какие артефакты требуют проверки, какие находки блокируют релиз, а какие могут быть приняты как временный риск.

Для руководителя разработки, AppSec-инженера или релиз-менеджера это принципиально важно. Решение о выпуске принимается не по отдельному отчёту и не по субъективному впечатлению от сканера, а по сводному состоянию безопасности продукта.

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

Единый ASOC-дашборд позволяет связать результаты анализаторов с реальными объектами SDLC: merge request, commit, pipeline, артефактом, релизом и владельцем решения. Именно эта связность делает безопасность управляемой.

Важно проверять не только ветку, но и результат слияния

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

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

Правила слияния должны быть технически закреплены

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

Защищённые ветки, обязательные проверки и approvals позволяют превратить требования безопасности и качества в часть инженерной дисциплины. Изменение не проходит дальше не потому, что кто-то вручную запретил merge, а потому что оно не выполнило заранее определённые условия.

Цепочка поставки должна быть прослеживаемой

Для безопасного релиза важно понимать не только состояние кода, но и происхождение артефакта. Команда должна видеть, из какого commit собрана версия, какой pipeline выполнялся, какие проверки прошли, какие зависимости использовались и какой артефакт был передан дальше по цепочке поставки.

GitFlic помогает выстраивать такую связность: код, merge request, pipeline, отчёты проверок, артефакты и релизные решения находятся в едином инженерном контуре. Это снижает риск ситуации, когда в production уходит сборка, происхождение и качество которой невозможно быстро подтвердить.

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

Enterprise-контур требует доказуемости

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

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

GitFlic помогает выстроить единый контур, в котором код, merge request, ревью, CI/CD, security-отчёты, Quality Gates, правила слияния, защищённые ветки, артефакты, роли и аудит становятся частью одного процесса.

Что это меняет для команды

Такой подход снижает конфликт между разработкой и информационной безопасностью. Специалист по ИБ перестаёт быть человеком, который приходит в конце и запрещает релиз. Разработка перестаёт воспринимать безопасность как внешний тормоз. Бизнес получает предсказуемый процесс, где скорость поставки не покупается ценой неуправляемого риска.

Главное преимущество — прозрачность решения. Команда заранее понимает, какие находки являются блокерами, какие допускают выпуск с принятым риском, а какие уходят в плановое исправление.

Вывод

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

Зрелый подход к безопасности в разработке — это не бесконечные запреты и не выпуск «на авось». Это заранее определённые правила, встроенные в инженерный процесс: от merge request и автоматических проверок до артефактов, аудита и релизного решения.

DevSecOps-подход позволяет сделать безопасность частью SDLC, а не финальным барьером перед production. Quality Gates помогают формализовать условия прохождения изменений. ASOC-дашборд по SAST, DAST и SCA даёт команде общую картину прикладного риска. Контроль цепочки поставки помогает понимать, из какого кода, с какими зависимостями и после каких проверок собран релиз.

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

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

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

Кирилл Довгаль, руководитель продукта GitFlic (входит в «Группу Астра»)