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

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

В этот момент дискуссия уже идёт не столько о риске.

Она идёт о том, кто оплатит пересмотр принятого ранее решения.

Поэтому я не согласен с тезисом, что ИБ сама по себе делает разработку дорогой.

Дорогой её делает запоздалое подключение.

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

В этом контексте Shift Left часто понимают слишком инструментально.

Компании переносят SAST и dependency scanning в CI/CD, но продолжают принимать ключевые решения без анализа риска.

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

Для этого нужны threat modeling, требования безопасности, архитектурный анализ и понятный владелец решения.

На мой взгляд, зрелость ИБ проявляется не в количестве остановленных релизов.

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

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

Shift Left — это перенос решений по риску, а не только инструментов контроля.

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

Нужно менять сам процесс принятия продуктовых решений.

Как устроено у вас: безопасность влияет на архитектуру или получает готовый продукт на согласование?