Команда тратит весь спринт на исправление уязвимости CVSS 9.8, скрытой в библиотеке, к которой в рабочей среде никто никогда не обращается. Тем временем уязвимость CVSS 6.5, обнаруженная в доступной через интернет конечной точке, остается открытой еще месяц, потому что она так и не попала в начало списка. Это не гипотетическая ситуация, это стандартный результат приоритезации уязвимостей, основанной исключительно на оценке серьезности, и это более распространенная ошибка, чем большинство программ обеспечения безопасности готовы признать.
Что на самом деле должна делать приоритезация уязвимостей?
Приоритизация уязвимостей — это процесс определения того, какие из обнаруженных уязвимостей следует устранить в первую очередь, из списка, который почти всегда слишком длинный, чтобы полностью его перечислить. При правильном подходе он отвечает на более узкий и сложный вопрос, чем «насколько серьезна эта уязвимость в теории»: он отвечает на вопрос «насколько устранение этой уязвимости прямо сейчас действительно снизит риск для этой конкретной системы». Это не один и тот же вопрос, и смешение этих понятий является причиной большинства ошибок в попытках приоритизации уязвимостей.
Почему одного лишь показателя тяжести недостаточно?
CVSS никогда не задумывался как самостоятельная полноценная система приоритезации, это оценка серьезности, описание того, насколько серьезной может быть уязвимость теоретически в общем контексте. Он ничего не говорит о:
- Доступность. Независимо от того, вызывается ли уязвимый фрагмент кода где-либо в приложении или он остается неактивным в какой-либо зависимости, ничего не происходит.
- Возможность эксплуатации. Независимо от того, существует ли работающая уязвимость в реальных условиях или же она носит теоретический характер за пределами лабораторных условий.
- Воздействие. Независимо от того, подключен ли затронутый компонент к интернету или находится на три уровня позади внутреннего сервиса без внешнего доступа.
- Контекст бизнеса. Независимо от того, затрагивает ли затронутая система данные клиентов или платежные потоки, или же это малоценный внутренний инструмент, от которого никто не зависит.
При ранжировании уязвимостей исключительно по CVSS уязвимость с рейтингом 9.8 считается более срочной, чем уязвимость с рейтингом 6.5, расположенная в доступном интернет-канале и имеющая известную уязвимость. Такой порядок является обратным и прямым результатом оценки серьезности без учета всего остального, что определяет реальный риск.
Скрытая цена неправильной приоритезации уязвимостей
Цена заключается не только в потраченном впустую инженерном времени, хотя это тоже реально: команды регулярно тратят ресурсы на серьезные уязвимости, не представляющие практической опасности, в то время как действительно уязвимые места остаются неиспользованными. Более тонкая цена – это доверие. Когда разработчиков неоднократно отвлекают от основной работы для исправления уязвимостей, которые оказываются недоступными или уже устраненными другими способами, они начинают игнорировать и следующее оповещение, и весь смысл приоритезации уязвимостей – исправление сначала нужных вещей – незаметно исчезает, даже несмотря на то, что список технически обрабатывается в порядке очереди.
Что на самом деле требуется для эффективной приоритизации уязвимостей
Эффективная приоритизация уязвимостей предполагает наложение нескольких сигналов поверх уровня серьезности, а не его полную замену:
- Анализ достижимости. Убедитесь, что уязвимая функция действительно вызывается из кода приложения, а не просто присутствует в дереве зависимостей.
- Доступность эксплойта. Проверьте, нацелено ли на конкретную уязвимость какое-либо публичное эксплойт-решение или активная кампания, а не только на семейство CVE.
- Удаление дубликатов данных между сканерами. Одна и та же основная проблема, выявленная тремя разными инструментами, не должна рассматриваться как три отдельных пункта, конкурирующих за внимание.
- Контекст бизнеса и степень риска. При оценке результатов учитывайте, с чем именно соприкасается затронутый актив, а не только общий балл CVE.
- Наглядная воронка продаж, а не плоский список. Возможность видеть, сколько результатов проходит каждый фильтр, от самых разных проблем до действительно уязвимых мест, делает приоритизацию обоснованной, а не превращает ее в «черный ящик».
Последний пункт важнее, чем кажется. Плоский список, отсортированный по степени серьезности, не дает команде представления о масштабе: 40% бэклога — это реальные проблемы или 2%? Представление в виде воронки, где сначала отображаются все обнаруженные проблемы, затем решаемые, затем проблемы с известной уязвимостью, а затем проблемы, которые действительно могут быть использованы в данной среде, превращает огромный список в короткий и обоснованный.
На что обращать внимание при выборе инструментов для приоритизации уязвимостей
Не каждая платформа, рекламируемая как инструмент для приоритизации уязвимостей, действительно выполняет описанную выше работу. При оценке инструментов приоритизации уязвимостей несколько вопросов позволяют быстро разобраться в маркетинговой информации:
- Это показывает доступность или просто сообщает о наличии уязвимого пакета?
- Проверяет ли система на наличие дубликатов результатов, полученных с помощью разных сканеров, включая уже используемые сторонние инструменты, или каждый источник добавляет отдельный, некоррелированный список?
- Может ли руководитель службы безопасности видеть воронку обработки запросов, сколько результатов было отфильтровано и почему, или только окончательный «приоритетный» список без понимания логики, лежащей в его основе?
- Учитывается ли при этом доступность эксплойтов, подтвержденная данными реальной разведки угроз, или только статическая оценка CVSS, опубликованная при раскрытии информации?
- Применяется ли принцип приоритезации в равной степени к результатам, полученным с помощью собственных сканеров и инструментов сторонних разработчиков, или только к результатам, полученным самим поставщиком?
Последний вопрос важнее, чем кажется. Многие инструменты приоритезации уязвимостей определяют приоритет только для того, что они сами обнаружили, оставляя всё, что поступает извне, без внимания. SAST, SCAили сканеры сторонних производителей, находящиеся в отдельной, неранжированной стопке.
Как компания Xygeni подходит к приоритизации уязвимостей
Ксигени ASPM Применяется четырехэтапная воронка: сбор данных от собственных сканеров и сторонних инструментов, обеспечение единой видимости полученного списка уязвимостей, а затем корреляция и приоритизация с использованием дедупликации, доступности и контекста, основанного на ИИ, прежде чем результаты попадут в очередь разработчика. На практике эта воронка сужает полный список обнаруженных уязвимостей до тех, которые можно исправить, которые доступны в коде приложения, для которых существует известная уязвимость, и, наконец, те, которые действительно могут быть использованы в данной конкретной среде, так что список, с которым фактически работает команда, достаточно мал, чтобы его можно было полностью обработать, а не просто бесконечно сортировать.
Поскольку этот уровень приоритезации уязвимостей применяется как к результатам, полученным от сторонних сканеров, так и к другим данным. собственные сканеры XygeniКоманде не обязательно всё переделывать. существующий инструмент для получения единого, взаимосвязанного представления. Логика приоритизации работает поверх уже имеющейся информации, устраняя пробел, который большинство инструментов приоритизации уязвимостей оставляют открытым, когда они ранжируют только собственные результаты.
FAQ
Почему одного только CVSS недостаточно для приоритизации уязвимостей?
CVSS измеряет теоретическую серьезность, а не фактический риск в конкретной среде. Он не учитывает, доступен ли уязвимый код, существует ли эксплойт в реальных условиях или насколько уязвима затронутая система, — все это существенно влияет на то, следует ли в первую очередь устранять обнаруженную уязвимость.
В чём разница между серьёзностью и возможностью эксплуатации уязвимостей при определении приоритетов?
Степень серьезности описывает, насколько разрушительным теоретически может быть уязвимость. Возможность эксплуатации описывает, действительно ли этот ущерб достижим прямо сейчас, при наличии работающего эксплойта и доступного пути выполнения кода. Обнаружение высокой степени серьезности и низкой возможности эксплуатации часто менее срочно, чем обнаружение средней степени серьезности и высокой возможности эксплуатации.
Должны ли инструменты приоритезации уязвимостей учитывать также результаты сканирования сторонними программами?
Да, иначе у команды окажется несколько отдельных, не связанных между собой списков приоритетов, по одному на каждый инструмент, вместо единого представления о том, что действительно наиболее важно во всей системе.
Насколько реально можно сократить список результатов с помощью анализа достижимости?
Ситуация варьируется в зависимости от кодовой базы, но обычно большинство отмеченных уязвимостей находятся в тех участках кода, которые фактически никогда не вызываются, а это значит, что одна только возможность их обнаружения часто исключает значительную часть обнаруженных уязвимостей из серьезного рассмотрения еще до оценки возможности их эксплуатации.
Является ли сокращение списка приоритетных задач признаком игнорирования рисков?
Нет, всё наоборот. Более короткий список, полученный в результате подлинной приоритезации уязвимостей, означает, что отфильтрован лишний шум, а не сам риск. Альтернатива — длинный, нефильтрованный список, который никто не может полностью обработать, — приводит к худшим результатам, поскольку реальный риск теряется в объёме информации.
