Почему сканерам уязвимостей нельзя верить на слово: проблема разных результатов

Многие руководители по информационной безопасности вкладывают значительные средства в программы управления уязвимостями. На предприятиях регулярно запускаются сканеры, формируются спецификации программного обеспечения (SBOM), а аналитические панели демонстрируют обнадеживающие цифры. Однако, как отмечают эксперты, большинство подобных программ строятся на ошибочном предположении, будто результаты работы сканеров являются абсолютно точными. На практике это далеко не так.

Суть проблемы: один и тот же образ, разные результаты

В рамках недавнего исследования специалисты протестировали два популярных ИТ-инструмента на одном и том же образе операционной системы Red Hat 8. Результаты оказались противоположными: сканер Grype обнаружил 852 уязвимости (CVE), в то время как Trivy выявил 3719 угроз.

Разногласие в результатах составило более 80% для абсолютно идентичных исходных данных в один и тот же момент времени. При этом оба инструмента работают корректно. Проблема кроется в различных алгоритмах принятия решений, о которых конечные пользователи зачастую даже не подозревают. Это структурная проблема сопоставления уязвимостей, которую невозможно решить простой сменой поставщика ПО.

Почему сопоставление уязвимостей работает со сбоями

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

Для идентификации пакетов используются два основных формата: CPE (Common Platform Enumeration — общее перечисление платформ) и PURL (Package URL — стандартизированный URL-адрес пакета). Формат CPE необходим для работы с Национальной базой данных уязвимостей США (NVD), однако его поля заполняются в свободной форме, что часто приводит к путанице при создании ответвлений (форков) программного обеспечения. Формат PURL более современен, но правила его использования до сих пор не стандартизированы, и каждый сканер интерпретирует их по-своему.

Ситуацию усугубляют и сами базы данных. База NVD модерируется вручную, использует только формат CPE, а обновление информации в ней может запаздывать на недели или месяцы. Альтернативная база OSV обновляется быстрее, но имеет неравномерное покрытие. Базы данных самих разработчиков (например, Red Hat) наиболее точны, но эти сведения не всегда оперативно попадают в глобальные реестры.

Скрытые решения ИТ-инструментов

Различия в результатах Grype и Trivy не случайны. Они обусловлены заложенной логикой разработчиков, которая обычно скрыта от конечного пользователя:

• Для пакета заголовков ядра Trivy зафиксировал почти три тысячи уязвимостей, тогда как Grype не показал ни одной, поскольку по умолчанию игнорирует файлы заголовков, считая, что они не подвергают систему рискам ядра Linux.
• Для инструментов настройки Python сканер Grype выявил три уязвимости, а Trivy — ни одной, так как просто не внес эти пакеты в каталог во время сканирования.
• Для веб-сервера Tomcat сканер Trivy обнаружил 16 уязвимостей, в то время как Grype показал нулевой результат из-за ошибки в определении идентификатора группы в каталоге.

Проблема генераторов спецификаций (SBOM)

Если ИТ-департамент полагается на спецификации ПО (SBOM), проблема усугубляется еще на этапе подготовки данных. То, какой именно инструмент сгенерировал SBOM, напрямую влияет на последующие результаты сканирования.

Например, при сканировании одного и того же контейнера разница в результатах Grype составила 66% в зависимости от того, использовался ли SBOM от генератора Syft или от Trivy. Генератор Syft добавляет дополнительные спецификации в идентификаторы PURL, что позволяет сканеру находить уязвимости в родительских пакетах. Trivy эти данные опускает, из-за чего сканер Grype ничего не находит. Таким образом, уязвимость кроется не в самом сканере, а в метаданных, которые решил включить генератор.

Рекомендации для руководителей по безопасности

Для повышения надежности проверок эксперты рекомендуют предпринять три практических шага:

• Проверить совместимость инструментов. Необходимо сопоставить генераторы SBOM и используемые сканеры. Например, Syft оптимально работает в паре с Grype, а Trivy лучше использовать как единый инструмент для генерации и сканирования. Смешивание разных экосистем снижает точность анализа.
• Понимать происхождение оценок уязвимостей. Различные сканеры используют разные источники шкалы тяжести уязвимостей (CVSS). Grype ориентируется на оценки NVD, в то время как Trivy часто использует данные конкретных вендоров, учитывающие их собственные защитные меры. Из-за этого одна и та же уязвимость может оцениваться как критическая в одном отчете и как средняя — в другом.
• Создавать правила исключений. Вместо бесконечной борьбы с очередью предупреждений ИТ-командам следует кодифицировать и внедрять правила подавления ложноположительных срабатываний на уровне всей инфраструктуры.

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