Внедрение DevSecOps: как встроить проверки безопасности в CI/CD и не остановить релизы

Информирует, предупреждает, блокирует

• Информирует. Сборка проходит, отчёт сохраняется, находки видны в запросе на слияние. Так держим одну-две недели, пока не разобран первый отчёт.
• Предупреждает о новом. Красная отметка в комментарии, если находка появилась в изменённом коде. Старые замечания пока не трогаем.
• Блокирует серьёзное. Сборка останавливается при новой серьёзной находке. Остальное остаётся предупреждением.

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

Что блокирует всегда

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

Что с ложными срабатываниями

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

Проверки зависимостей и образов опираются на базы известных уязвимостей, которые обычно обновляются из внешних источников. Если ваш сервер сборки изолирован, мы настраиваем это иначе.

• Зеркало баз уязвимостей. Базы обновляются в одном месте через разрешённый канал и раздаются внутрь контура. В отчёте видна дата базы, чтобы никто не принимал устаревшую проверку за свежую.
• Внутренний репозиторий пакетов. Сборка скачивает библиотеки из внутреннего прокси, а проверка идёт по тем версиям, которые действительно используются.
• Раннеры внутри контура. Проверки запускаются на ваших серверах сборки: GitLab CI, Jenkins или другой системе, которая у вас уже есть.
• Облачные сканеры исключены. Исходный код не передаётся третьим сторонам. Для данных ограниченного доступа внешние сервисы проверки кода чаще всего не подходят по требованиям заказчика, поэтому используем открытые инструменты на вашем оборудовании.

Если контур строится на отечественных системах, список совместимых инструментов уточняем на обследовании; про сопутствующие задачи см. страницу импортозамещения ПО.

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

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

Если проблема не в коде, а в доступе сотрудников к системам, это единый вход и второй фактор. Если в разработке участвуют подрядчики, часть проверок записывается в договор и приёмку, подробности есть в статье «DevSecOps: с чего начать небольшой команде».