Безопасность внутри конвейера разработки

Задача

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

Что сделано

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

Внутри системы

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

Как устроено

Ставится спринтом: сначала разбор текущей зрелости и приоритетов, затем проверки в сборке, затем конфигурация облака и разграничение доступа, в конце — разбор угроз и порядок действий при инциденте, с передачей команде.

Результат

Ставится спринтом и дальше живёт в процессе команды, а не в отчёте на полке.