Коротко: результаты сканирования показывают, что подвержено угрозам прямо сейчас, только если вы можете провести повторное сканирование в момент изменения риска, а большинство инструментов все еще ждут следующего запланированного цикла. Сканирование в реальном времени от Aqua позволяет командам запускать сканирование по требованию из Aqua Hub или через API, повторно сканировать только измененные части образа и использовать единую архитектуру для SaaS, гибридных, мультиоблачных, локальных и изолированных сред. Затем Aqua фокусирует внимание на находках, для которых доступны эксплойты, с учетом контекста выполнения запущенных рабочих нагрузок.
Что такое сканирование уязвимостей в реальном времени?
Сканирование уязвимостей в реальном времени — это возможность сканировать конкретный образ по требованию, а не ждать следующего запланированного цикла. Это важно, потому что результат сканирования может устареть двумя способами после его получения. Сам образ может измениться, когда команда пересобирает или исправляет его. Данные об уязвимостях также могут измениться, когда публикуется новый CVE для пакетов, которые уже содержатся в образе, что делает неизмененный образ уязвимым. В любом случае сканирование в реальном времени возвращает результат, который отражает как состояние образа, так и данные об уязвимостях на текущий момент.
Почему сканирование в реальном времени важно прямо сейчас?
Злоумышленники действуют быстрее, чем графики сканирования, поэтому ценность результата сканирования теперь зависит от его актуальности. В облачных средах новые рабочие нагрузки запускаются при каждом развертывании, а запущенные контейнеры могут отклоняться от того, что изначально сканировалось в конвейере.
Плановое сканирование точно описывает среду в момент его проведения, а каждое последующее изменение становится «слепой зоной». Когда обнаруживается новая уязвимость, команды в итоге отвечают на вопрос о текущем состоянии продакшена результатами из более раннего цикла, часто собирая их вручную из нескольких консолей.
В чем недостатки текущих подходов к сканированию уязвимостей?
Плановое сканирование остается правильной основой для обеспечения покрытия, а сканирование в конвейере выявляет риски до развертывания. Проблемы начинаются, когда вопрос не может ждать следующего цикла.
Повторное сканирование большого реестра после раскрытия информации обычно означает извлечение и полный анализ образов, которые не менялись, поэтому команды выбирают между медленным сканированием всего подряд или быстрым сканированием нескольких репозиториев. Покрытие также может различаться между публичными облачными аккаунтами, частными дата-центрами и изолированными площадками.
Шум усугубляет проблему. Когда уровень серьезности устанавливается непоследовательно в разных командах, а конвейеры блокируются находками, которые никогда не имели значения, разработчики перестают доверять результатам.
Как выглядит лучший подход к сканированию уязвимостей?
Каждое решение о сканировании должно помогать вашей команде быстро и точно отвечать на один вопрос: подвержены ли мы риску прямо сейчас?
Плановое сканирование и сканирование в реальном времени должны работать вместе. График поддерживает базовое покрытие всех реестров, а сканирование в реальном времени дает командам актуальный результат для конкретного образа в тот момент, когда раскрытие информации или пересборка меняют картину.
Модель сканирования также должна быть одинаковой везде, где живут образы. Когда реестры публичных облаков, частные дата-центры и изолированные площадки зависят от разных инструментов или консолей, кому-то приходится собирать ответ о подверженности рискам вручную. Единая архитектура, применяющая одни и те же политики везде, дает ответ, который команда может использовать сразу после его получения.
Повторные сканирования должны масштабироваться за счет выполнения только новой работы. Повторный анализ образа, который не изменился, увеличивает время без добавления информации, поэтому лучший подход — проверять неизмененные образы на соответствие новым данным об уязвимостях и оставлять более глубокий анализ для того, что действительно изменилось.
Находки должны ранжироваться по доказательствам, а не только по серьезности. Последовательная политика гарантирует, что критическая находка означает одно и то же в конвейере каждой команды, в то время как данные об эксплойтах и доказательства выполнения выводят находки, которые стоит исправить, на первое место. Когда разработчики видят, что заблокированная сборка отражает реальный риск, они снова начинают доверять результатам.
Как работает сканирование в реальном времени от Aqua?
Когда вы запускаете сканирование из Aqua Hub или нашего API, запрос отправляется сканеру Aqua, подключенному к соответствующему реестру. Сканеры могут находиться там, где живут ваши реестры, и они сравнивают содержимое образов с данными об уязвимостях CyberCenter перед возвратом результатов в консоль.
Перед сканированием мы проверяем, что изменилось. Неизмененный образ проверяется на наличие недавно опубликованных уязвимостей без повторного сканирования, у образа с новыми слоями сканируются только эти слои, а образ, который мы никогда не видели, извлекается и сканируется полностью. Та же архитектура работает на нашей SaaS-платформе и в самостоятельно развернутых средах, включая изолированные (air-gapped) среды, где консоль находится за вашим брандмауэром.
Например, разработчик исправляет образ, который не прошел проверку политики, нажимает «повторить сканирование» и видит обновленный статус соответствия, как только сканирование завершается. Затем мы ранжируем находки по наличию эксплойта, включая возможность удаленной эксплуатации, и добавляем контекст выполнения из запущенных рабочих нагрузок.
Что даст доступность во время выполнения (runtime reachability) для приоритизации уязвимостей?
Текущее сканирование говорит вам, что присутствует в образе, в то время как более сложный вопрос заключается в том, какие уязвимые пакеты действительно использует ваше запущенное приложение. Доступность во время выполнения — это запланированная возможность, которую мы добавляем для связи результатов сканирования образа с доказательствами того, какие пакеты загружает запущенное приложение.
Образ может содержать 100 уязвимостей, в то время как приложение загружает пакеты, связанные только с двумя из них. Эти две не являются автоматически доказанными как эксплуатируемые, но именно в них устранение рисков с наибольшей вероятностью снизит риск в продакшене. Сканирование образов по-прежнему формирует инвентаризацию, а доступность во время выполнения покажет, какие находки в ней важны для запущенного приложения.
Как сравниваются традиционные, современные и подходы Aqua?
Какие ошибки совершают команды безопасности при сканировании уязвимостей?
Отношение к последнему плановому сканированию как к текущей подверженности рискам. Каждый пересобранный образ или запущенная рабочая нагрузка после этого сканирования остаются невидимыми до следующего цикла, когда руководство задает вопрос.
Повторное сканирование всего после каждого раскрытия информации. Полное повторное сканирование неизмененных образов замедляет реакцию и подталкивает команды к сканированию только части репозиториев.
Отношение к каждому уязвимому пакету в образе как к одинаково срочному. Образ может содержать уязвимые пакеты, которые запущенное приложение никогда не загружает, поэтому ранжирование только по факту наличия заставляет разработчиков исправлять то, что может не снизить риск в продакшене.
Что вам следует сделать дальше?
Отрепетируйте следующее критическое раскрытие информации прямо сейчас. Измерьте, сколько времени потребуется вашей команде, чтобы сказать, какие запущенные рабочие нагрузки подвержены риску и сколько консолей требует этот ответ. Затем повторно отсканируйте недавно исправленный образ и проверьте, отражает ли результат изменение. Если любой из этих шагов зависит от цикла сканирования, этот период ожидания — то место, где вы теряете контроль над подверженностью рискам.
Посмотрите вебинар, чтобы увидеть сканирование в реальном времени от Aqua в действии:
Часто задаваемые вопросы
Заменяет ли сканирование в реальном времени плановое сканирование?
Нет. Aqua поддерживает плановое сканирование для регулярного покрытия и сканирование в реальном времени для моментов, которые не могут ждать, таких как новое раскрытие информации или свежеисправленный образ.
Почему важно сканирование в масштабе?
Крупные среды могут содержать тысячи или сотни тысяч образов. Эффективная архитектура позволяет сократить объем ненужной работы за счет использования имеющейся информации об образах, которые не изменились, и сосредоточения анализа на том, что было изменено.
Почему важно покрытие гибридных и мультиоблачных сред?
Многие организации запускают приложения у нескольких облачных провайдеров, на частной инфраструктуре и в локальных средах. Управление уязвимостями должно учитывать реально существующую среду, а не исходить из предположения, что рабочие нагрузки сосредоточены в одном месте.
Что дает информация о доступности во время выполнения?
Доступность во время выполнения связывает информацию об уязвимостях с доказательствами того, что соответствующий пакет или библиотека загружены работающим приложением. Это обеспечивает дополнительный контекст для приоритизации, но само по себе не доказывает возможность эксплуатации.
Почему управление уязвимостями должно быть связано с безопасностью во время выполнения?
Управление уязвимостями выявляет и приоритизирует потенциальные риски, но на устранение требуется время. Безопасность во время выполнения предоставляет точку контроля, где команды могут снизить риски, пока приложения продолжают работать.
Эрин Стефан — директор по продуктовому маркетингу в Aqua Security. Эрин обладает более чем десятилетним опытом продуктового маркетинга в сфере защиты данных и кибербезопасности. Она специализируется на стратегиях выхода на рынок, обмене сообщениями и запуске продуктов, помогая командам связать то, что они создают, с тем, почему это важно. В свободное от работы время она обычно планирует свое следующее путешествие.
