Приёмка релиза службой ИБ: что блокирует выпуск
Команда проходит свой чек-лист и нажимает «выложить». Служба ИБ решает другое: этот выпуск вообще имеет право идти в продуктив или его останавливают. Зафиксируйте блокеры и случаи, когда ИБ смотрит релиз глазами, а не только автоматикой. Минутный чек-лист разработчика — отдельно: безопасность релиза перед выкладкой.
Статья опирается на логику направления «Управление изменениями» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Какие работы ИБ согласует до окна — в перечне изменений; карточка и откат — здесь. Не смешивайте три документа в один.
Когда ИБ смотрит сама
| Тип выпуска | ИБ | Срок ответа |
|---|---|---|
| Обычный релиз с зелёным конвейером и без блокеров ниже | Не смотрит вручную: достаточно автоматики и чек-листа команды | — |
| Первый выход продукта, смена способа аутентификации, новый контур с ПДн, открытие наружу | Смотрит до продуктив | Один рабочий день; срочный hotfix — в тот же день, оформление следом |
| Исключение из порога SAST/SCA или из брифа проекта | Смотрит | До выкладки, не «потом в понедельник» |
| Откат уже выложенного релиза | Запись после факта, если откат штатный; смотрит, если откат ломает журналы или доступ | По факту |
Если «ИБ смотрит каждый тег», очередь умрёт через месяц, и её начнут обходить. Если «ИБ не смотрит никогда» — первый релиз с админкой в интернете пройдёт как «обычный». Критерии, с которых проект вообще живёт, лежат в брифе: требования на старте.
Что блокирует выпуск
| Блокер | Как увидеть | Исключение |
|---|---|---|
| Секрет в образе, в артефакте или в репозитории | Конвейер, Trivy, gitleaks | Нет. Сначала отзыв: секреты в git |
| Красный порог SAST/SCA на новом коде без строки в исключениях | Конвейер | Только с датой пересмотра: процесс SAST и SCA |
| Нет плана отката на изменение данных | Карточка пустая | Нет для миграции; для текста на сайте — не блокер |
| Боевые ПДн на тестовом стенде, который едет вместе с релизом | Стенд, дамп | Нет |
| Админка или новый вход в интернет без согласованного контура | Схема, MR с ingress | Только решением руководителя, не чатом |
Не блокер сам по себе: низкие находки сканера, отсутствие идеального покрытия тестами, «не успели написать runbook». Их не притворяйте блокерами — иначе команда перестанет звать ИБ.
Риск: устное «давайте выложим, потом закроем». Если выпускаете с открытой высокой находкой — строка в исключениях и дата, иначе приёмки не было.
Как оформить
Обычный релиз: ссылка на зелёный pipeline и заполненный чек-лист команды в карточке изменения. Релиз, который ИБ смотрит: короткая отметка в той же карточке (или в MR) — «блокеров нет / блокер такой-то». Не заводите отдельный «акт приёмки ИБ» на каждый тег: его не будут заполнять.
Кто ставит отметку: ответственный за ИБ или человек, которому это поручено приказом. Разработчик не принимает свой релиз «за ИБ». Подрядчик не принимает сам себя.
Диагностика
| Симптом | Причина и что делать |
|---|---|
| ИБ ставит подпись на каждый hotfix в три ночи | Слишком широкий перечень «смотрим сами». Сузьте до таблицы выше, остальное — автоматика |
| Релиз ушёл в обход, потому что «ИБ не ответила» | Нет срока. Запишите рабочий день / тот же день и дежурного |
| Чек-лист команды и приёмка ИБ — один файл | Команда начинает врать в галочках. Разведите: они подтверждают шаги, ИБ — блокеры |
| Блокеров десять, как политика | Их не соблюдают. Оставьте пять из таблицы, остальное верните в бриф проекта |
Где это в модели зрелости
Материал относится к направлению «Управление изменениями» (хаб: изменения, карта: карта зрелости). Для SSDLC это ворота в продуктив: автоматика и редкий взгляд ИБ, а не подпись на каждом коммите. Это не пентест перед релизом и не архитектурная проверка уже собранной системы перед первым запуском.
Как проверить
- Есть таблица «когда ИБ смотрит / не смотрит» и список блокеров не длиннее одной страницы.
- Последний обычный релиз в продуктиве имеет ссылку на зелёный pipeline, без пустой «подписи ИБ ради подписи».
- Последний релиз с исключением имеет дату пересмотра, не вечный mute.
- Срок ответа ИБ известен команде и совпадает с фактическим (посмотрите два последних запроса).
- Чек-лист перед выкладкой и эта приёмка — разные документы.
Источники
- NIST SP 800-218 (SSDF) 1.1, практики выпуска и проверки: csrc.nist.gov.
- OWASP SAMM: owasp.org/www-project-samm.
