Разработчикам обещают безопасную разработку, а получают дополнительную очередь перед релизом. Сканер находит сотни проблем, сроки никто не пересматривает, разобраться в отчёте должен автор ближайшего коммита. Через неделю команда ищет, как отключить проверку. У такого сопротивления есть рациональная причина. Работы прибавилось, правила выпуска стали менее понятными, а помощь не появилась.
В предыдущих статьях мы разобрали угрозы для CI/CD, возможности SAST, DAST и SCA, секреты, контейнеры и инфраструктуру как код. В заключительном материале соберём процесс для небольшой команды без штатного специалиста по безопасности. Кто отвечает за находки, какие проверки включать первыми, когда останавливать выпуск и как не превратить внедрение в ещё один незаконченный проект.
Ниже предложен план примерно на три месяца для команды из пяти-восьми разработчиков с тимлидом и владельцем продукта. Один человек может совмещать несколько ролей. Сроки и объём работ служат отправной точкой для планирования, а результатом должен стать работающий процесс на одном сервисе. Обещать полную защищённость к девяностому дню было бы странно.
Почему команда сопротивляется и что обсуждать сначала
Фраза «разработчикам плевать на безопасность» плохо объясняет конкретную задержку. Сканер может выдавать непонятные предупреждения, согласование может занимать несколько дней, а исправление старой зависимости может требовать миграции половины проекта. Начните с последнего неприятного случая. Что задержало работу, сколько времени ушло на разбор, кто мог принять решение и почему вопрос остался без ответа.
Конфликт скорости и безопасности нужно разложить на две части. Проверка занимает машинное время, а ожидание ответа занимает время команды. Если анализ завершился за несколько минут, но разработчик два дня искал человека, который объяснит результат, проблема лежит в организации работы. Новый сканер очередь согласований не исправит.
Сотрудник, который приносит требования безопасности, должен объяснять опасный сценарий и допустимый способ исправления. Разработчик должен предоставить технический контекст. Руководитель должен выбирать приоритет, если исправление конкурирует с обещанной функцией. Когда штатного безопасника нет, эти обязанности всё равно остаются, поэтому договориться о них нужно до включения блокировок.
Шаг 1. На первой неделе выделить время и назначить владельцев
Для старта нужен короткий договор внутри команды. Какой сервис берём первым, какие проблемы считаем недопустимыми, кто разбирает сообщения и сколько времени выделяем на настройку и исправления. Документ может занимать одну страницу. Если спринт уже заполнен полностью, руководитель должен убрать часть других задач. Формулировка «занимайтесь безопасностью, когда освободитесь» не создаёт свободного времени.
Назначьте координатора из разработчиков или тестировщиков, которому интересна тема. Подобная роль описана в OWASP SAMM как Security Champion. Координатор помогает разобраться в находках, поддерживает правила и собирает вопросы для команды. Для роли нужны обучение и выделенные рабочие часы. Человек не становится экспертом по всем видам атак после изменения названия обязанности.
| Роль | За что отвечает |
|---|---|
| Владелец продукта или руководитель | Выделяет время, меняет приоритеты и принимает решения о временно допустимом риске в пределах своих полномочий |
| Тимлид | Определяет технические требования, помогает проверить опасный сценарий и выбирает способ исправления |
| Координатор безопасности | Поддерживает проверки, разбирает первичные сообщения и следит, чтобы у задачи появился исполнитель |
| Владелец компонента | Исправляет код или конфигурацию и проверяет, что проблема устранена без поломки нужного поведения |
Как стартовый вариант можно выделить координатору два-четыре часа в неделю и отдельно запланировать конкретные исправления в спринте. Такая оценка не является отраслевой нормой или обещанием достаточности. Через первые недели команда увидит реальную нагрузку. Если время постоянно заканчивается на сортировке сообщений, нужно менять охват проверок, правила или доступные ресурсы.
Назначьте замену на отпуск и срочный случай. Не стоит отправлять каждый обычный коммит на личное одобрение координатору. Понятные изменения проходят по согласованным правилам, а ручной разбор нужен для спорной находки, исключения или существенного изменения доступа. Для технического подтверждения рискованного решения полезен второй участник, даже если руководитель совмещает несколько ролей.
Шаг 2. На второй неделе выбрать один сервис и две проверки
Пилотом должен стать реальный сервис с понятным владельцем, регулярными изменениями и доступным тестовым окружением. Заброшенный внутренний проект мало расскажет о реакции команды, а самая сложная система может поглотить весь срок внедрения. Подойдёт приложение, на котором команда сможет пройти путь от находки до исправленного выпуска.
За короткую совместную сессию набросайте схему. Где хранятся пользовательские данные, какие компоненты доступны извне, кто выпускает сборку, какие секреты получает CI и чем отличается обычный пользователь от администратора. Затем выберите несколько опасных сценариев. Например, чужой клиент читает документы соседа, украденный токен позволяет опубликовать образ, ошибка в шаблоне открывает административный интерфейс.
Первые проверки выбирают под эти сценарии. Во многих проектах разумной парой будут поиск секретов до коммита и в CI, а также анализ зависимостей. Если приложение почти не меняется, зато команда активно правит облачные шаблоны, проверка IaC может дать больше пользы, чем второй анализатор кода. Различия между методами проверки нужны именно для такого выбора.
Начать можно с доступных функций Git-платформы и открытых инструментов, например Gitleaks для секретов и подходящего сканера зависимостей. Но отсутствие платы за лицензию не отменяет время на настройку, обновление и разбор результатов. На старте полезнее две проверки с назначенным владельцем, чем набор инструментов, сообщения которых никто не читает.
Новые правила, которые ещё не настроены, сначала запускают в режиме наблюдения на ограниченный срок, например на одну-две недели. Команда измеряет длительность, разбирает типичные находки и исправляет ошибки конфигурации. Известные опасные проблемы не ждут окончания пилота. Подтверждённая утечка секрета требует отзыва доступа и разбора последствий сразу, даже если автоматическая блокировка ещё не включена.
Шаг 3. На третьей и четвёртой неделях превратить отчёты в задачи
Разработчику нужна задача с причиной и проверяемым результатом. Где находится проблема, какой сценарий возможен, что известно об условиях эксплуатации, кто исправляет и как подтвердить исправление. Ссылка на длинный отчёт без пояснения оставляет всю эту работу получателю. Сообщение «найдена уязвимость высокого уровня» ещё не отвечает на вопрос, что делать сегодня.
Используйте привычный трекер команды, добавив метку безопасности и нужные поля. Один дефект, найденный несколькими инструментами, должен оставаться одной задачей с несколькими источниками. Доступ к чувствительным деталям ограничивают, а рабочие токены в описание не копируют. Исправление выполняет владелец компонента, координатор помогает оценить находку и не даёт задаче потеряться.
Старые проблемы следует выделить в отдельную очередь с приоритетами и сроками. Для повседневной проверки новых коммитов можно использовать исходный список известных находок, baseline, чтобы каждое небольшое изменение не блокировалось всей историей проекта. Но baseline не является разрешением забыть старые уязвимости. Доступная извне опасная ошибка требует решения независимо от даты появления.
Есть ещё одна тонкость. Новая запись об уязвимости может относиться к давно установленной зависимости. Поэтому проверка только разницы между коммитами не заменяет повторный анализ текущего состава приложения. При появлении новых сведений старую задачу пересматривают, особенно если изменились условия эксплуатации или обнаружилась доступная атака.
Внутри задачи различайте ошибку сканера, неприменимость конкретного сценария и временное принятие реального риска. Если проблему решили пока не исправлять, нельзя закрывать сообщение как ложное срабатывание. У исключения должны сохраниться причина, владелец и дата пересмотра. Иначе через месяц команда уже не вспомнит, что именно было проверено.
Договоритесь о времени первого ответа на спорную блокировку. Например, в рабочее время координатор или его замена в течение дня сообщает результат первичного разбора либо срок, когда подключится нужный специалист. Для срочного восстановления сервиса нужен отдельный маршрут. Обещание ответить не следует путать с обещанием исправить сложную уязвимость за тот же день.
Шаг 4. На пятой и шестой неделях включить понятные запреты
Автоматическую блокировку включают для правил, смысл и качество которых команда уже проверила. Каждая остановка должна объяснять причину, указывать владельца решения и показывать следующий шаг. Если разработчик получает только красный значок, конфликт просто переезжает из переписки в интерфейс CI.
Начальный набор запретов может охватывать новые подтверждённые секреты, известные заражённые зависимости и конкретные опасные настройки. Для обычной уязвимости библиотеки учитывают затронутую версию, условия эксплуатации, роль компонента и доступное исправление. Одной оценки серьёзности из базы часто мало, чтобы принять решение о выпуске конкретного приложения.
Зафиксируйте разницу между быстрыми проверками каждого изменения и более продолжительным анализом. Быстрые результаты нужны в запросе на слияние. Полные проверки можно запускать отдельно, а выпуск изменений в критичных участках привязывать к завершению нужного анализа. Проверять следует конкретный выпускаемый код и артефакт. Старый успешный отчёт не подтверждает безопасность последующей сборки.
У процесса должен быть порядок действий на случай отказа самого сканера. Недоступная база и ошибка запуска означают отсутствие результата. Для обязательной проверки команда либо ждёт восстановления, либо использует заранее согласованное исключение для конкретного выпуска. Нельзя незаметно превращать технический сбой в успешную проверку.
Исключение оформляют до выпуска. В короткой записи указывают затронутую версию, причину срочности, известный сценарий угрозы, временные меры, ответственного за исправление и срок действия разрешения. Технический участник проверяет предпосылки, руководитель с соответствующими полномочиями принимает остаточный риск. Автор изменения не должен молча выдавать себе разрешение отключить проверку.
Например, требуется срочное исправление недоступности сервиса, а другая находка затрагивает функцию экспорта. Если функция действительно отключена и команда проверила, что опасный путь закрыт, можно рассмотреть ограниченное исключение на этот выпуск с задачей исправить зависимость. Если предположение об отключённой функции проверить не удалось, основания для такого решения нет. Формулировка «очень надо успеть» технический контекст не заменяет.
Ограничьте права на изменение обязательных проверок, правил и исключений. Срок исключения должен приводить к повторному решению, а не к автоматическому продлению. Частые аварийные обходы требуют разбора причин. Возможно, правила плохо настроены, исправления не получают времени или команда регулярно использует срочность как обычный способ выпуска.
Шаг 5. На седьмой и восьмой неделях упростить безопасную работу
После первых исправлений станет видно, где команда повторяет одни и те же ошибки. По результатам стоит подготовить несколько рабочих заготовок. Шаблон сервиса с получением секретов, поддерживаемый базовый образ, проверенный модуль облачных прав, общий фрагмент CI. У каждой заготовки должен быть владелец и понятный способ обновления. Необслуживаемый «безопасный шаблон» постепенно превращается в общий источник старых проблем.
Обучение удобно привязать к реальным изменениям проекта. Разберите один случай утечки токена, одну ошибку доступа и один опасный параметр развёртывания. Покажите причину, исправление и способ проверки. Разбор не должен превращаться в поиск виноватого. Цель состоит в том, чтобы следующий разработчик получил полезный пример и инструмент, который помогает не повторить промах.
Добавьте обсуждение угроз к изменениям, которые затрагивают права пользователей, изоляцию клиентов, внешние интеграции или доступ CI. Здесь полезны простые вопросы. Кто может вызвать операцию, какие чужие данные доступны, какое право выдаётся и что произойдёт при краже токена. Для обычной правки текста отдельное заседание не требуется.
На этом этапе полезно провести небольшую репетицию инцидента на стенде. Например, команда получает учебное сообщение об утёкшем токене сборки. Нужно найти владельца, отозвать тестовый доступ, определить затронутые запуски и проверить возможность собрать доверенный артефакт. Для сценария с базой отдельно проверяют восстановление тестовой копии. Результат репетиции покажет, какие инструкции и права отсутствуют.
Не ждите с ответом на эти вопросы до первого происшествия. Ответственного за срочную реакцию и способ связи назначают в начале пилота, а на седьмой-восьмой неделе проверяют процесс целиком. Координатор не обязан один расследовать любую компрометацию. Заранее определите, кого можно привлечь для сложного случая и кто вправе выделить на помощь деньги.
Шаг 6. К концу третьего месяца проверить результат и расширить охват
Количество установленных сканеров мало говорит о результате. Число найденных уязвимостей тоже неоднозначно. Рост может означать расширение охвата, а падение может быть следствием отключённого правила. Для пилота лучше сравнивать состояние одного сервиса с его же исходным состоянием и смотреть, что происходит с опасными находками и выпуском изменений.
| Что измерять | Какой вопрос помогает решить |
|---|---|
| Время первого разбора блокирующей находки | Получает ли разработчик помощь вовремя или простаивает в очереди |
| Возраст открытых опасных дефектов и время их устранения | Сокращается ли период реального риска, включая старые задачи |
| Долю ложных срабатываний среди разобранных блокировок | Какие правила требуют настройки, чтобы команда доверяла результатам |
| Добавленное время CI и ожидания решения | Что задерживает выпуск, выполнение проверки или организация работы |
| Количество просроченных исключений и повторных ошибок | Работают ли исправления и правила после первого обсуждения |
Для времени полезно смотреть не только среднее значение, но и отдельные долгие задержки. В небольшом пилоте данных может быть мало, поэтому разбор каждого затянувшегося случая окажется полезнее красивого графика. Дополнительно следите, что обязательные проверки действительно выполняются в выбранной области, иначе улучшение цифр можно получить простым сокращением охвата.
Рядом с метриками безопасности оставьте показатели выпуска продукта. Например, время от коммита до производственного развёртывания и долю выпусков, после которых пришлось срочно вмешиваться. Подобные показатели описывает DORA. Сравнивать стоит один сервис с самим собой, учитывая изменения нагрузки и сложности задач. Короткий пилот не доказывает, что все колебания вызваны именно DevSecOps.
Расширять процесс стоит, когда команда умеет пройти весь цикл. Находка получила владельца, опасный сценарий разобрали, исправление выпустили, результат проверили, исключения не потерялись. Если сообщения продолжают копиться без решения, подключение остальных репозиториев увеличит очередь. Следующим шагом может стать ещё один сервис или одна проверка под выявленный пробел.
Что делать, если ресурсов всё равно не хватает
Если даже пилот не помещается в рабочее время, уменьшайте одновременный объём изменений и оставляйте самый опасный сценарий первым. Например, сначала наладьте отзыв секретов и запрет их публикации, затем займитесь зависимостями. Уже известная серьёзная угроза требует отдельного решения руководителя о приоритетах. Отсутствие людей не делает риск меньше, зато прямо показывает цену следующего обещания бизнесу.
Для сложной проверки может понадобиться внешняя экспертиза. Особенно если команда не может уверенно оценить изоляцию данных клиентов, собственную схему авторизации, необычную криптографию или последствия компрометации сборки. Разовый разбор конкретной архитектуры или целевой пентест позволяют привлечь компетенцию без немедленного создания отдела. Результаты всё равно должны попасть к внутренним владельцам, которые смогут внести и проверить исправления.
Полезный результат первых трёх месяцев выглядит довольно буднично. Разработчик знает, почему остановилась проверка и к кому обратиться. Руководитель понимает, какое исправление вытеснило функцию из спринта. У срочного исключения есть срок, а у опасной находки есть исполнитель. С такого порядка команда может расширять DevSecOps, сохраняя связь между требованиями безопасности и ежедневной работой.
