Патч был готов за считанные дни. На его внедрение ушли месяцы. Почему?
Я слышу этот вопрос почти в каждом разговоре с клиентами об управлении уязвимостями. Честный ответ редко звучит как «Мы не знали об этом». Обычно это: «Мы знали, но внедрение в промышленную среду заняло больше времени, чем окно эксплуатации уязвимости».
Эта задержка — время между выпуском патча и моментом, когда он начинает работать в промышленной среде во всех уязвимых приложениях, — является одним из наиболее часто упускаемых из виду показателей при управлении корпоративными рисками. ИИ сокращает время до эксплуатации уязвимости до часов, в то время как многим организациям по-прежнему требуется от 40 до 90 дней на пересборку, проверку и повторное развертывание. Руководителям не должно приходиться выбирать между состоянием уязвимости и риском сбоя в работе сервиса, приносящего доход. Это проблема не только службы безопасности. Это проблема бизнес-риска, которая затрагивает всю организацию.
Переход от реактивного исправления к проактивному доверию к цепочке поставок
Red Hat и IBM помогают снизить эту нагрузку непосредственно на уровне цепочки поставок.
Благодаря Lightwell мы не ждем, пока сообщество open source выпустит исправление и передаст его нам. Наши инженерные команды активно занимаются бэкпортом, тестированием и подписанием патчей для наиболее важных зависимостей, включая исправления уязвимостей, которые еще не были устранены в исходном проекте.
Вместо того чтобы каждое предприятие самостоятельно исследовало, пересобирало и тестировало одно и то же исправление для одной и той же библиотеки, Red Hat и IBM выполняют эту работу один раз у источника. Мы поставляем в конвейер исправленный компонент, специфичный для конкретной версии. В критических случаях мы гарантируем, что исправление вообще существует.
Но подписанная библиотека в репозитории не уменьшает поверхность атаки. Исправление бесполезно до тех пор, пока оно не запущено и пока вы не можете это доказать.
Перенос патча в промышленную среду
Lightwell предоставляет доверенный патч. Red Hat OpenShift — это платформа приложений, которая доставляет его в промышленную среду быстро и под контролем.
Этот путь наиболее эффективен, когда между ними находится доверенная «фабрика программного обеспечения» (software factory): пересборка, подпись, аттестация и контроль политик для исправленного артефакта, чтобы неподписанный или непроверенный код никогда не попал в промышленную среду. Lightwell устраняет разрыв в получении патча для конкретной версии. OpenShift и доверенная цепочка поставок устраняют разрыв в обеспечении работы исправления во всей гибридной инфраструктуре, центре обработки данных, облаке и на периферии, не требуя полной замены уже используемых вами инструментов доставки.
Устранение CVE — это только первый шаг. Настоящая устойчивость достигается за счет ускорения пути от доступности патча до проверенного развертывания в промышленной среде. Цель проста: доверенные патчи в промышленной среде за дни, а не месяцы.
На уровне инфраструктуры исправление часто существует с того момента, как его публикует поставщик вашей операционной системы. Самое сложное — применить его везде, где это необходимо, и сделать это в масштабе, с соблюдением нормативных требований, без нарушения работы промышленной среды и с записью, которую можно предоставить аудитору. При правильном подходе многонедельные циклы исправления могут сократиться до часов, а доказательства соответствия требованиям становятся побочным продуктом рабочего процесса, а не суматошной работой задним числом.
На уровне приложений исправление — это не просто обновление, это рабочий процесс управления. Без автоматизированных шлюзов доверия каждый патч заставляет руководителей служб безопасности идти на компромисс между скоростью и операционной стабильностью. Для вашей команды разработчиков это означает, что исправление нельзя просто установить: его нужно пересобрать в новый артефакт, пройти ту же проверку доверия, что применяется к любому релизу, и безопасно развернуть. Исторически это означало ожидание того, когда разработчик заметит оповещение, найдет безопасную версию и протолкнет изменения через непрерывную интеграцию и непрерывную доставку (CI/CD), когда в спринте появится свободное место. Этот процесс и так был слишком медленным. Теперь он находится под новым давлением, поскольку ИИ-агенты для написания кода быстро генерируют коммиты и сборки, попадающие в конвейеры быстрее, чем любая команда может проверить их вручную.
Больше оповещений здесь не помогут. Поможет готовый, проверенный, подписанный компонент, проходящий через автоматизированный программный конвейер — доверенную фабрику программного обеспечения. Изменения должны внедряться постепенно с использованием прогрессивной доставки, чтобы рабочий трафик безопасно проверял патч. Результатом должно быть не просто исправленное приложение. Это должно быть криптографическое доказательство того, что именно изменилось. Это совсем другие доказательства для регулятора, чем фраза «мы полагаем, что мы защищены».
3 вопроса, которые стоит задать своей команде
Наиболее устойчивые организации перестали спрашивать: «Уязвимы ли мы?». Каждый надежный поставщик может ответить на это сейчас; это базовое ожидание. Ведущие компании задают 3 более острых вопроса:
- «Исправлено ли это?»
- «Работает ли это?»
- «Можем ли мы это доказать?»
Создание патчей решает первую часть проблемы. Сокращение времени между «исправление существует» и «исправление защищает клиентов» — это то, что действительно снижает подверженность уязвимостям и сбоям. Это работает только тогда, когда доверенное исправление встречается с платформой приложений, созданной для быстрой доставки с контролем и доказательствами.
Готовы сократить разрыв между патчем и промышленной средой с месяцев до дней? Запланируйте интерактивную сессию с Red Hat Services, чтобы выявить «узкие места» и построить оптимизированный путь исправления. Тем временем поделитесь этой демонстрацией со своей командой, чтобы пройти процесс устранения CVE с помощью Lightwell и Red Hat.
/)