Между публикацией критической уязвимости и её устранением на всех ваших инстансах лежит окно экспозиции. Чем оно длиннее, тем больше времени у атакующего. В традиционной модели патчинга «сервер за сервером» это окно измеряется днями или неделями. В хорошо автоматизированной модели неизменяемых образов — часами.
Ключ в том, чтобы относиться к реакции на CVE как к воспроизводимому инженерному процессу, а не к ручному забегу в последнюю минуту.
Архитектура автоматического ответа
Цель: при критической CVE, которая вас касается, новый пропатченный образ рождается, проходит проверку и готов к развёртыванию с минимальным участием человека. Контур состоит из четырёх частей.
1. Обнаружение
- Непрерывное сканирование ваших действующих образов с Amazon Inspector, Trivy или Grype.
- Ленты уязвимостей — NVD, бюллетени поставщика ОС, — питающие оповещения.
- SBOM каждого образа, чтобы за секунды понять, присутствует ли уязвимый компонент.
2. Запуск
- Оповещение критической или высокой серьёзности запускает конвейер пересборки — например, через EventBridge в CodeBuild или вебхуком в вашу CI.
- Для продакшена можно потребовать человеческое одобрение, оставив сборку и проверку полностью автоматическими.
3. Пересборка и проверка
- Конвейер — Packer или EC2 Image Builder — пересобирает образ из обновлённой базы,
применяя
dnf/apt updateи привычное усиление. - Новый образ пересканируется: публиковать бессмысленно, если CVE осталась.
- Прогоняются тесты: загрузка, smoke-тесты, InSpec — чтобы ничего не сломать.
4. Раздача и развёртывание
- Новый AMI версионируется, копируется в нужные регионы, а указатель в SSM Parameter Store обновляется.
- Обновляется Launch Template, и Auto Scaling Group выполняет rolling update либо blue/green-развёртывание.
- Уязвимые образы помечаются устаревшими, чтобы никто не запустил их по ошибке.
Ключевая метрика: MTTR патчей
Измеряйте среднее время от публикации критической CVE до того, как ваш парк работает на исправленном образе. Это показатель, который резюмирует вашу зрелость. Снижение его с недель до часов — одна из самых больших отдач от вложений в конвейер образов.
| Уровень зрелости | Типичный MTTR | Как патчат |
|---|---|---|
| Вручную | Дни или недели | SSH, сервер за сервером |
| Полуавтоматически | Часы — один-два дня | Ручная пересборка и rolling |
| Автоматически | Часы | Триггер, пересборка и деплой |
Автоматизация конвейера резко сокращает окно экспозиции.
Хорошие практики
- Проведите учения: проверьте контур на смоделированной CVE до того, как он реально понадобится.
- Постепенное развёртывание: canary или rolling, чтобы поймать регрессии, не роняя сервис.
- Откат наготове: сохраняйте предыдущую версию и держите план немедленного возврата.
- Коммуникация: фиксируйте, какая CVE вызвала каждую пересборку; это свидетельство соответствия.
Часто задаваемые вопросы
Нужно ли пересобирать образ при любой CVE?
Нет. Расставляйте приоритеты по серьёзности и эксплуатируемости, а также по тому, есть ли затронутый компонент в вашем образе: здесь ключ — SBOM. Критические и эксплуатируемые высокие оправдывают срочную пересборку; остальное подождёт регулярного цикла.
Как не сломать продакшен при выкатке нового образа?
Автоматическая проверка — smoke-тесты, InSpec — до публикации плюс постепенные развёртывания: canary, rolling или blue/green, с готовым откатом.
Можно ли автоматизировать это вне AWS?
Да. Шаблон — обнаружение, запуск, пересборка, развёртывание — работает в Azure и GCP с их аналогами; Packer добавляет переносимость на этапе сборки.
В imaxe.cloud мы быстро пересобираем и пересканируем образы при появлении новых уязвимостей, чтобы вы стартовали с актуальной базы.
