Система оценки общих уязвимостей (CVSS) долгое время служила отраслевым стандартом для определения степени критичности уязвимостей. Она стала одним из немногих «источников истины» для специалистов по кибербезопасности.
И вы знаете этот порядок действий. Появляется новая CVE, ей присваивается оценка CVSS, и команды бросаются устранять уязвимости с самыми высокими баллами.
Всё это кажется логичным, научным и даже объективным. Но на практике это часто нас подводит.
В случаях с Equifax, SolarWinds и Log4Shell проявился схожий паттерн: реальный ущерб проистекал не только из технической критичности уязвимостей, но и из того, как эти уязвимости распространялись по взаимосвязанным системам. Высокие баллы CVSS не всегда коррелировали с высоким операционным воздействием. Низкооценённые активы провоцировали каскадные сбои. Часто уязвимость со средней оценкой может иметь наиболее значительные последствия из-за её расположения и систем, с которыми она взаимодействует.
Оценки CVSS имеют огромную ценность как отправная точка. Они не улавливают реляционную динамику. Они не показывают, как эксплуатация одной уязвимости может усилить или распространить риск через зависимости, общие учётные данные или унаследованные конфигурации.
Исторически мы рассматривали уязвимости как изолированные точки в списке, тогда как реальный риск кроется в их связях.
Почему оценка CVSS — это не вся картина
Система рейтингов CVSS фокусируется на характеристиках одного актива — насколько легко эксплуатировать уязвимость, существует ли исправление и каково потенциальное воздействие на конфиденциальность или доступность. Это важно и является надёжной отправной точкой. Но она не учитывает нечто критически важное: контекст.
Уязвимость в строго изолированной «песочнице» может получить оценку 9.8, но никогда не затронуть ничего другого. В то же время, уязвимость с оценкой 5.2 в службе единого входа (single sign-on), системе, которой доверяет каждая другая система, может стать мультипликатором зоны поражения. Сама по себе оценка ничего не говорит о том, как эта уязвимость может распространиться по всему предприятию.
В реальном мире уязвимости не остаются на месте. Они перемещаются. Они наследуют привилегии. Они используют конвейеры (pipelines) как транспорт. Они попадают туда, куда никто не ожидал.
Риск — это не только критичность. Это распространение.
Иной взгляд на уязвимости
Именно здесь на сцену выходит унифицированная модель связей (ULM, unified linkage model) — именно в этом заключается суть ULM. Вместо того чтобы спрашивать: «Насколько плоха эта уязвимость сама по себе?», ULM спрашивает: «Что эта уязвимость может затронуть, как только начнёт распространяться?»
Она фокусируется на трёх типах взаимосвязей:
Смежность (Adjacency): Системы, расположенные рядом и способные влиять друг на друга, даже без прямого обмена данными.
Наследование (Inheritance): Уязвимости, которые распространяются по нисходящей — как дефект, скрытый внутри библиотеки с открытым исходным кодом, внедрённой в десятки приложений.
Доверие (Trust): Системы, которые зависят от целостности друг друга — например, провайдеры идентификации, службы обновлений или инструменты CI/CD.
Когда вы наносите на карту эти взаимосвязи, вы перестаёте видеть список уязвимостей и начинаете видеть сеть путей. Внезапно, казалось бы, незначительный дефект может раскрыть гораздо более масштабную картину.
Как на самом деле распространяются уязвимости
Современные конвейеры разработки невероятно упрощают незаметное распространение уязвимостей. Дефектная библиотека, загруженная в сборку, оказывается в образе Docker. Этот образ продвигается в продакшн. Контейнер получает новые разрешения. И в конечном итоге внешний конечный узел (endpoint) выставляет его в интернет. К тому времени, когда кто-то увидит уведомление о CVE, уязвимость, возможно, уже активна внутри критически важных систем.
Вопрос не только в «Какова оценка?», но и в «Куда это может попасть?»
Переосмысление Log4Shell через призму связей
Log4Shell не стала исторической, потому что обладала технической критичностью. Сотни уязвимостей ежегодно получают критическую оценку. Она стала исторической, потому что была повсюду. Log4j наследовалась через вложенные зависимости, была встроена в бесчисленное множество библиотек и вызывала доверие у систем, потреблявших недоверенные данные.
Это был идеальный шторм наследования, смежности и доверия.
Log4Shell научила нас тому, что истинная опасность уязвимости заключается не только в том, что она собой представляет, но и в том, где она находится.
Что происходит, когда мы оцениваем на основе связей?
ULM не заменяет оценки CVSS. Она их дополняет. Она заставляет нас думать о глубине, охвате и влиянии.
Уязвимость в устаревшей виртуальной машине для разработки может получить оценку 9.8. Однако, если ничто от неё не зависит, её реальный приоритет может быть низким.
Между тем, дефект в раннере GitHub, который питает продакшн-сборки, может получить гораздо более высокую оценку при анализе через призму связей. Он находится в доверенном конвейере, наследует учётные данные и может влиять на нижестоящие системы. В представлении ULM его срочность резко возрастает.
Одного числа может быть недостаточно для введения в заблуждение. Повествование раскрывает риск.
Как организации могут начать использовать ULM уже сегодня
Это не требует масштабного пересмотра. Всё начинается со смены мышления:
- Наносите на карту, как системы связаны, а не только то, какие системы существуют.
- Ищите общие компоненты, общие идентификаторы, общие конвейеры.
- Спрашивайте, каким системам доверяют другие, от каких они зависят или что наследуют.
Затем расставляйте приоритеты уязвимостей в зависимости от их положения в этой сети — особенно тех, что находятся рядом с системами идентификации, конвейерами CI/CD или широко используемыми общими сервисами. Это — безмолвные усилители.
Начните с малого. Сосредоточьтесь на системах с наибольшим влиянием на нижестоящие процессы. Картина быстро прояснится.
Главный вывод
Управление уязвимостями — это не игра чисел. Это игра взаимоотношений.
CVSS теоретически сообщает нам, насколько серьезна уязвимость. ULM помогает нам понять, насколько опасной она может быть на практике. И в мире ускоряющейся сложности, автоматизации и взаимосвязанных систем этот контекст больше не является опциональным.
Чтобы защитить наши среды, мы должны перестать видеть уязвимости как точки. Мы должны начать видеть линии между ними.
Именно там живёт реальный риск.
Эта статья публикуется в рамках Сети экспертных авторов Foundry.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Henry Sienkiewicz
