Привет, Хабр!

На связи Илья Виссарионов, директор департамента «Аппаратно‑системная платформа» компании «Диасофт».
 
Про DevSecOps написаны тонны текстов, но почти все они – про инструменты: какой SAST выбрать, куда «воткнуть» Trivy, как подружить сканеры с GitLab. Реальная проблема 2026 года в другом. Сканеры давно стоят на всех стадиях пайплайна, базы уязвимостей обновляются ежедневно, а криты все равно доезжают до заказчика. Проблема сместилась в другую плоскость: как приоритизировать, чинить и ретестить находки, когда у тебя 2000+ развертываний в день и больше сотни команд. Проще говоря – как управлять security-долгом на конвейере.

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

«Если есть critical – это не пройдет никогда»: рынок ужесточил контроль входа

За последний год входной контроль у крупных заказчиков изменил экономику поставки сильнее, чем любой внутренний регламент. Коллеги, которые внедряют наши продукты «в полях», приносят с рынка простую и жесткую картину. У зрелых игроков – банков, госструктур, крупных корпораций – на входе стоит автоматическая проверка: docker-образ хотя бы с одной критической уязвимостью в реестр заказчика не принимается. По high еще можно договориться. На medium пока закрывают глаза – образ считается «нестабильным», но хотя бы попадает в контур. Critical – это стена.

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

Теперь применим эти правила к реальному масштабу. Наши low-code платформы в экосистеме Digital Q – это порядка 215 микросервисов, то есть 215 образов. По последнему срезу сканирования критические уязвимости есть в каждом. Не в половине, не в «отдельных устаревших компонентах» – в каждом. И это не потому, что кто-то плохо работает: уязвимости размазаны по всем слоям. Часть живет в базовых образах – и это зона ответственности вендора ОС, и здесь мы ничего исправить не можем. Часть – в серверах приложений и фреймворках. Часть – в библиотеках и прикладном коде. Чтобы пройти входной контроль, нужно раскрутить всю эту цепочку сверху вниз и пересобрать ее целиком.

Разово это очень дорого. Но «разово» – это иллюзия. Заказчик с таким входным контролем уже не один, версии продукта у всех разные, и работа, проделанная под одного клиента для одной версии, не переносится на следующего. Пришли ко второму заказчику с другой версией – повторяем все заново. Именно в этой точке безопасность перестает быть строкой в бэклоге и становится вопросом экономики производства: либо мы выстраиваем планомерный процесс, который удешевляет безопасную поставку с каждой итерацией, либо каждый раз оплачиваем аврал по полной.

Вектор рынка при этом очевиден, и обратного хода нет. После громких инцидентов прошлого года – когда взломы инфраструктуры компаний федерального масштаба выходили в публичное поле и оборачивались многодневными сбоями – входной контроль безопасности у крупных игроков будет только ужесточаться. И здесь есть риск, который серьезнее упущенного тендера. Представим гипотетическую ситуацию: инцидент уровня тех, что гремели в новостях, происходит не из-за древней ОС во внутреннем контуре заказчика, а по причине критической уязвимости в поставленной вендором системе. Для вендора – это репутационный удар, после которого о тебе вспоминают именно в связке с чужой катастрофой. Ставки выросли настолько, что полагаться на равнодушие заказчика к безопасности – стратегия с истекающим сроком годности: даже те, кому сегодня «и так нормально», после первого собственного инцидента повернутся спиной за одну ночь.

Так выглядит давление снаружи. Но прежде чем рассказывать, что мы с этим делаем, нужна честная точка отсчета: а что вообще происходит с находками сканеров внутри конвейера сегодня. Спойлер: проверки есть на всех стадиях – и именно поэтому разговор о зрелости будет не про инструменты.

Информировать – не значит чинить: где мы находимся на кривой взросления

Давление рынка понятно. А теперь честная точка отсчета: что происходит с находками сканеров внутри нашего конвейера сегодня. И вот тут начинается разговор, который на Хабре почти никто не ведет от первого лица, потому что признаваться в таком неловко. Мы попробуем.

Сначала о том, что есть. Проверки безопасности встроены во все стадии пайплайна: статический анализ кода, проверка зависимостей, сканирование собранных образов. Базы уязвимостей обновляются ежедневно. Все находки фиксируются и классифицируются по уровням critical, high, medium, команда видит их прямо в пайплайне на каждой сборке. На критичные уязвимости заводятся задачи по устранению. Есть и жесткие правила, которые уже сегодня работают как блокирующие: например, команда обязана держаться на базовом образе второй-третьей версии от текущей – не старше. Ведешь разработку на устаревшем базовом образе – сборка дальше не пройдет, точка. Это осмысленное правило: базовые образы обновляются часто, и исправление крита на этом уровне автоматически «уезжает» во все продукты, которые пересобираются поверх.

То есть по инструментам у нас все хорошо. Инженер, который посмотрит на схему нашего пайплайна, увидит вполне зрелый DevSecOps: shift-left проверки, ежедневная актуализация баз, автоматическая фиксация находок. А теперь неудобная часть. Подавляющее большинство этих проверок носит информирующий характер. Отчет о найденном крите не останавливает сборку. Задача на устранение заводится, но сроки у нее, скажем прямо, вольготные: это не день и не два, и даже не неделя. Производство едет дальше, а security-долг копится параллельным потоком.

Почему так? Не потому, что кто-то не понимает рисков. Ответ лежит в арифметике потока. При 2000+ развертываний в день и постоянно растущей базе уязвимостей жесткий блокирующий gate на все проекты сразу означает одно: конвейер встает. Не замедляется, а именно встает, потому что новые CVE появляются быстрее, чем команды успевают закрывать старые. Об этой арифметике мы подробно поговорим в следующей части, но важно зафиксировать: информирующий режим – это не халатность, а осознанный (пусть и вынужденный) компромисс между скоростью поставки и security-долгом. Другое дело, что компромисс, заключенный несколько лет назад, устаревает вместе с рынком.

Ключевой момент, который отличает нашу ситуацию от картинки «сканеры для галочки»: gate у нас настраиваемый, и рычаги существуют уже сейчас. На проектах, где безопасность признана критичной, найденный крит настраивается как стопер, и с неисправленными критическими уязвимостями наружу не уходит ничего. Такие проекты есть, они живут по этим правилам прямо сейчас, и опыт показывает: схема работает. Раньше такой проект был один, сейчас их несколько. Мало? Мало. Но динамика важнее абсолютных цифр: заказчиков, которые ставят безопасность в верхние строчки продуктовых критериев, становится больше с каждым кварталом, и каждый громкий инцидент в отрасли ускоряет этот процесс.

Управляют рычагами те, кто отвечает за процесс: менеджеры проектов и владельцы продуктов. И здесь – главный вопрос зрелости, который куда важнее выбора сканера: кто принимает риск, когда крит «уезжает» в релиз? Сегодня ответ выглядит так: риск принимают проектные команды с двух сторон. Наша команда должна понимать, что риск допустим и исправление гарантированно приедет. Команда заказчика должна осознанно принять артефакт с известной уязвимостью на свои контуры, понимая сроки устранения. Когда обе стороны делают это осознанно – это нормальная, взрослая работа с риском, ровно так живут даже вендоры операционных систем: часть исправлений штатно уходит в следующий плановый релизный цикл, просто эти циклы должны быть короткими. Проблема начинается там, где риск принимается по умолчанию, просто потому что скорость передачи кода приоритетнее и никто не задал вопрос.

Если разложить все это по шкале, получается классическая кривая взросления DevSecOps, по которой идет вся индустрия. Уровень первый: сканеры стоят, отчеты складываются в архив, никто не читает. Уровень второй: находки видны командам в пайплайне, заводятся задачи, но релиз ничего не блокирует – информирующий режим. Уровень третий: gate настраиваемый, блокировка включается точечно там, где риск того требует, – risk-based подход. Уровень четвертый: блокирующие правила становятся дефолтом, а исключения – управляемыми и объяснимыми, а их количество планомерно движется к нулю. Мы сейчас на третьем уровне и смотрим на четвертый. И важно проговорить: «ноль исключений» – это ориентир, а не лозунг на ближайший квартал. Потому что попытка перепрыгнуть с третьего уровня на четвертый одним волевым решением заканчивается всегда одинаково.

Чем именно заканчивается, почему «давайте просто заблокируем все с критами» не работает на потоке – разберем на конкретном примере CVE.

Почему «заблокировать все с критами» останавливает конвейер, и что мы делаем вместо этого

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

Начнем с живого примера, который многое объясняет про природу security-долга на потоке. Берем свежий образ на базе отечественной ОС, сканируем: чисто по нашей зоне ответственности, есть известные проблемы в базовом слое, но это зона вендора, за которого мы исправить не можем. Через неделю сканируем тот же самый образ еще раз. В нем появилась новая CVE с рейтингом 9.8 из 10. Уязвимости пять дней от роду. Образ не менялся ни на байт, изменилась база уязвимостей. И это штатная ситуация, а не аномалия: базы пополняются ежедневно, и любой артефакт, который вчера проходил проверку, сегодня может ее не пройти, просто потому что мир узнал о дыре, которая в нем была всегда.

Теперь совместим это с блокирующим gate'ом на всем потоке. 2000+ развертываний в день, сотня команд, три сотни приложений. Новые критические CVE «прилетают» непрерывно и непредсказуемо, попадая в уже собранные, уже оттестированные, уже готовые к передаче артефакты. Жесткий стопер на все сразу означает, что конвейер начинает останавливаться в случайных местах в случайное время, и релизный цикл растет у большинства команд одновременно. Причем растет не на фиксированную величину, которую можно заложить в план: команды, которые раньше успевали в свои сроки делать кодинг, сборку, тестирование и выкатку, теперь должны в тот же релизный контур вместить еще и закрытие всех критов, включая те, что появились вчера. Сроки «едут вправо», и для большинства проектов, где заказчик ждет фичи к дате, этот компромисс сегодня решается не в пользу тотальной блокировки. Это не значит, что он решается правильно. Это значит, что переход должен быть управляемым, а не шоковым.

Поэтому вместо отключения рубильника мы идем волнами. Первая волна: проекты, где входной контроль заказчика уже стоит стеной, там блокирующий gate включается полностью, и с критами наружу не уходит ничего. Этот режим уже работает, и он дал неожиданно ценный побочный эффект: качество разговора с заказчиком изменилось. Когда поставляешь артефакты, проверенные по жесткому правилу, а заказчик через неделю своим сканером находит новый крит (та самая изменившаяся база), это уже точечное, объяснимое исключение. Стороны спокойно договариваются о сроке поставки обновленного компонента, и вопрос считается решаемым. Совсем другая ситуация, когда заказчик подсвечивает десятки критов во всем, что ему передали: тут договариваться не о чем, тут только краснеть.

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

Третье: приоритизация «сверху вниз» с пониманием динамики. Логика такая: чиним criticals, потом highs и не забываем, что сегодняшняя medium завтра может быть переклассифицирована в critical, когда для нее появится публичный эксплойт. Пока она medium, чинить ее проще и дешевле. К тому же уязвимости редко живут поодиночке: типичная атака – это цепочка, где одна некритичная дыра дает точку входа, вторая – повышение привилегий, и по отдельности «незначительные» находки складываются в рабочий вектор. Поэтому оценивать находки только по CVSS-рейтингу в отрыве от контекста – плохая практика; risk-based подход то и означает, что смотрим на эксплуатируемость в нашем окружении, а не только на цифру в отчете.

И четвертое – самый неочевидный узел, на который мы наткнулись: релизная политика и security-политика связаны жестче, чем кажется. У нас, как и у многих вендоров, есть стабильные релизы: срез фиксируется, квартал тестируется и стабилизируется, потом тиражируется заказчикам. Звучит надежно, но в этой схеме есть парадокс: стабильный релиз к моменту тиражирования оказывается максимально небезопасным. Пока срез квартала стабилизировался, база уязвимостей «уехала» вперед, и в замороженных версиях базовых образов, серверов приложений и библиотек накопились свежие находки. А исправить крит, прилетевший из базового образа, внутри стабильной ветки почти невозможно без нарушения самой идеи стабильности: обновление базового слоя тянет за собой версии системных библиотек, и на выходе получается по сути новая версия, а не патч. Правила конфигурационного управления (исправляем в мастере, переносим черри-пиком в стабильную ветку) закрывают прикладной слой, но против устаревания базового слоя они бессильны. Вывод, к которому мы пришли: нельзя проектировать security gate отдельно от релизного цикла. Либо циклы стабильных релизов становятся короче, либо для базового слоя нужен отдельный, более быстрый контур обновления. Этот вопрос у нас сейчас в проработке, и честного финального ответа пока нет.

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

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

Стратегия волн отвечает на вопрос, «где ужесточать». Но security-долг не гасится решениями комитетов, он гасится задачами в трекере, у которых есть исполнитель, срок и бюджет. Поэтому дальше – про операционку: четыре практики, которые мы внедряем или обсуждаем прямо сейчас, причем для каждой внутри команды есть не только аргументы «за», но и вполне конкретные «грабли», на которые мы либо уже наступили, либо успели заметить их у себя под ногами.

Автозаведение задач на уязвимости. Идея проста: сканер нашел уязвимость, задача автоматически создается в трекере, падает на команду, получает срок устранения в зависимости от severity; под этот поток работ заранее заложен бюджет. Без ручного посредничества, то есть без человека, который «когда-нибудь разберет отчет». Выглядит, как очевидный шаг, и мы в него идем. Но у нас есть поучительный анти-кейс из собственной практики. В одной из наших зрелых платформ давно «живет» инспектор кода: инструмент, который подсвечивает несоответствие кода правилам разработки и автоматически рекомендует завести задачу на исправление. Знаете, что с этими задачами происходит? Они получают низкий приоритет и копятся, потому что в спринте всегда есть что-то важнее. Механически прикрутить автозаведение к сканеру уязвимостей – значит, через полгода получить команды с несколькими сотнями автосгенерированных задач в бэклоге и выработанной по отношению к  ним слепотой. Вывод, который мы для себя сделали: автоматизация заведения задач работает только в связке с политикой приоритета. Задача по криту должна автоматически получать высший или следующий за высшим приоритет, а ее просрочка должна становиться стопером выпуска. Иначе это генератор шума, а не процесс.

Принцип 80/20 и работа от базовых слоев. Хорошая новость, которую показал анализ наших срезов: security-долг распределен крайне неравномерно, и примерно 20% усилий закрывают большую часть критов. Причина – в архитектуре: значительная доля критических находок «прилетает» не из прикладного кода, а из общих слоев, базовых образов, серверов приложений, разделяемых библиотек. Исправление крита в базовом образе автоматически «уезжает» во все продукты, которые пересобираются поверх него, и одна починка гасит находки в десятках образов разом. Поэтому порядок движения такой: сначала общие слои, где рычаг максимальный, потом прикладной код, где каждая починка закрывает ровно одну точку. Это скучная, совершенно не героическая инженерная работа, но именно она меняет картину срезов быстрее всего.

Security champions в командах. Здесь у нас внутри команд идет живой спор, и мы не будем изображать, что он решен. Аргументы «за»: выделенных специалистов по ИБ в компании единицы, и на потоке из трех сотен приложений они физически не могут выдать экспертизу для каждой команды. Практика security champions, когда в команде есть человек, который держит связь с ИБ, следит за находками в своих продуктах и продвигает эту тему внутри команды, снимает еще одну проблему, культурную: команды перестают воспринимать безопасников как врагов, которые приходят с проверкой, и начинают видеть в них союзников с общей целью: не улететь у заказчика на второй круг приемки. Аргументы «против» тоже честные: не каждый продукт требует безопасности на сто процентов, есть системы, взлом которых не дает атакующему ничего ценного, и заводить выделенную роль в каждой команде без оглядки на профиль риска – это раздувание штата, процесса ради процесса. Есть и третья позиция: часть рутинной проверки в перспективе заберет автоматика и AI-агенты, и человеческая роль нужна не везде. Рабочий компромисс, к которому мы склоняемся: компетенция обязательна, выделенная роль – по профилю риска продукта. И одно наблюдение, которое сильно сдвинуло наш спор: окно между публикацией уязвимости и ее эксплуатацией сузилось радикально, проэксплуатировать свежую CVE сегодня значительно проще, чем три-четыре года назад, инструментарий атакующих коммодитизировался. Асимметрия усилилась: находить дыры научились быстро, а вот закрывать их с той же скоростью – все еще организационная проблема защищающихся. Это аргумент за то, чтобы компетенция жила близко к коду, а не в отдельном кабинете.

Сканируй тем, чем сканирует заказчик. Практика, которая родилась не из методологии, а в результате «ожога». Один из крупных заказчиков выставил претензию по уязвимостям в поставке. Начали разбираться и обнаружили неприятное: наш пайплайн этих находок не видел. Не потому, что проверки не было, а потому, что заказчик сканировал другим инструментом, с другой базой и другими правилами анализа. Мы отдавали артефакты, которые честно считали чистыми, а на стороне приемки они чистыми не были. Разные сканеры дают заметно разные результаты на одном и том же образе. Это известный факт, но одно дело – знать это, другое – получить претензию. Теперь правило такое: инструменты, которыми проверяют наши поставки ключевые заказчики, должны стоять и в нашем пайплайне, на каждой сборке. В конкретном случае это означало добавление Grype к уже имеющимся сканерам. Вариативность проверок здесь – не паранойя, а способ увидеть поставку глазами приемки до того, как ее увидит заказчик. И отдельный вывод из этой истории: не ждать централизованного решения там, где улучшение можно сделать дешево и локально. Подключить дополнительный сканер на свои продукты – вопрос дней, а не кварталов.

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

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

Безопасность как аргумент продаж, а не строка затрат

Теперь о том, во что все это упирается на самом деле. Не в сканеры, не в gate'ы и даже не в культуру команд, а в то, как безопасность выглядит в финансовой модели. Десятилетиями она проходила по графе «затраты»: статья расходов, которая ничего не зарабатывает, а лишь страхует от потерь, которых, может быть, и не случится. В периоды экономии такие статьи режут первыми, потому что бюджеты и люди уходят туда, что генерит доход, а не туда, что предотвращает гипотетический ущерб.

Рынок эту логику поддерживает своим поведением. Скажем прямо: в большинстве тендеров примерно 80% веса имеет цена, и лишь оставшиеся 20% делят между собой функциональность, сопровождение и все остальное, включая безопасность. Когда защищенное решение стоит заметно дороже, многие выбирают дешевле, проговаривая риски в стиле «да-да, мы все понимаем, но тут в два раза дешевле». Работает и экономика штрафов: системы санкций за инциденты, как правило, прогрессирующие, каждый следующий штраф больше предыдущего, и на короткой дистанции первый штраф действительно дешевле, чем построение полноценной защиты. Добавим сюда легаси-фактор: заказчики используют решения, которые невозможно переписать, операционные системы, которые больше не поддерживаются и не обновляются. И менять это никто не будет, пока не придет регулятор или не случится инцидент. На чужих граблях в нашей отрасли учатся редко, предпочитают собственные.

Почему мы считаем, что бизнес уже меняет свое отношение к безопасности? Назовем три аргумента. Первый мы разобрали в самом начале: входной контроль крупных заказчиков превратил безопасность из пожелания в физическое условие поставки, и небезопасный продукт теперь означает не абстрактный риск, а конкретный несостоявшийся контракт. Второй: масштаб последствий изменился. Инциденты последних лет показали, что взлом крупной инфраструктуры – это уже не строчка в отчете ИБ, а остановленные бизнес-процессы федерального масштаба и новости на первых полосах. И если такой инцидент происходит по причине уязвимости в поставленном вендором решении, вендор получает удар, несоизмеримый с любыми экономическими затратами на безопасную разработку: о тебе теперь вспоминают в связке с чужой катастрофой. Третий аргумент оптимистичнее, и он из нашей собственной истории. Когда несколько лет назад была опубликована критическая уязвимость в Log4j, библиотеке, которую мы активно используем в ряде продуктов, исправления и рекомендации заказчикам ушли в течение одного-двух дней, на той же неделе. Никто не ссылался на загруженные спринты и отсутствие бюджета. Как только последствия стали очевидны всем, ресурс нашелся мгновенно. Этот кейс мы вспоминаем каждый раз, когда слышим, что «на безопасность нет ресурсов»: ресурсы есть, нет осознанной оценки риска. Значит, задача не в том, чтобы выбить бюджет кнутом, а в том, чтобы риск был просчитан и оценен до инцидента, а не после.

Отсюда практический вопрос, который нам регулярно задают: а можно ли продавать безопасность отдельно? Условно, базовая версия и «защищенная» версия продается по разным ценам. Внутри команды мы об этом спорили и пришли к двум выводам, которые звучат противоречиво, но противоречия в общем-то в них нет. Вывод первый: разводить разработку на две ветки, безопасную и небезопасную, бессмысленно с инженерной точки зрения. Сделать из небезопасного безопасное – это вторая полноценная работа поверх первой, дешевле сразу сделать безопасно и держать один процесс, а не два. Вывод второй: заказчику, тем не менее, нужно меню. Уровень гарантий, SLA на устранение уязвимостей, частота security-обновлений – это законные параметры коммерческого предложения, и мировая практика подписки на обновления существует ровно поэтому. Разница принципиальна: мы не продаем «заплатки к дырявому продукту», мы продаем скорость реакции и глубину сопровождения поверх единого безопасного производственного процесса. Продукт один, конвейер один – различаются обязательства.

И последний механизм, самый недооцененный: обратная связь при несостоявшихся продажах. Если продукт не прошел входной контроль, не попал в проект, проиграл тендер из-за безопасности, эта информация должна в структурированном виде доходить до тех, кто отвечает за продукт и его развитие, вплоть до продуктовых комитетов. «Вот три случая за квартал, где ИБ стала стопером продажи» – это аргумент, который переводит безопасность из религиозного спора в управленческое решение. Здесь должны синхронизировать свои действия три стороны: те, кто обеспечивает конвейер, те, кто выпускает продукты, и те, кто несет их заказчикам. Собственно, эта статья и выросла из такой синхронизации.

Куда идем: вместо заключения

Если сократить весь наш внутренний спор до одного абзаца, получится так. Инструментальная фаза DevSecOps закончилась: сканеры стоят у всех, и они больше никого не отличают. Отличает то, что происходит после сканирования. Наш ориентир на ближайшие годы – планомерно сокращать лаг между появлением критической уязвимости и ее устранением в поставке, потому что именно этот лаг, а не количество сканеров в пайплайне, определяет реальную защищенность бизнеса заказчика. Двигаемся волнами: жесткие gate'ы там, где рынок уже требует, единый быстро чинимый минимум для всех, автозаведение задач со стоперным приоритетом, экспертиза рядом с кодом и инструменты приемки в собственном пайплайне. А «ноль исключений» остается для нас ориентиром, а не лозунгом: мы хорошо понимаем, что путь туда займет не один квартал, и предпочитаем честное, управляемое  движение красивым обещаниям.

Нам очень интересен опыт тех, кто идет по такому же пути. Как у вас устроен переход от информирующих проверок к блокирующим? Что вы делаете со стабильными релизами, которые устаревают быстрее, чем стабилизируются? Работают ли у вас security champions и автозаведение задач, или бэклог победил? Расскажите в комментариях: похоже, индустрия проходит этот путь одновременно, и чужие грабли здесь – редкий шанс сэкономить на собственных.