Аргументы в пользу системного устранения уязвимостей вместо точечных исправлений

В этом интервью для Help Net Security Алек Саммерс, руководитель проекта MITRE CVE/CWE, рассказывает о том, как CWE превращается из справочного инструмента в активный элемент процесса раскрытия уязвимостей. Всё больше записей CVE теперь содержат сопоставления с CWE, предоставленные уполномоченными номерационными органами (CNA), что позволяет получать более точные данные о первопричинах.

Инструменты автоматизации помогают аналитикам быстрее классифицировать недостатки, но могут закреплять ошибочные шаблоны, если обучены на некачественных примерах. Саммерс утверждает, что устранение шаблонов слабостей снижает повторяющуюся нагрузку на команды безопасности, даже работающие с ограниченным бюджетом. Ключевая проблема — в формулировках: отрасль по умолчанию говорит об уязвимостях, тогда как CWE предлагает сосредоточиться на том, что изначально сделало возможным негативный исход.

CWE уже давно интегрирован в процессы разработки ПО во многих организациях благодаря его использованию в инструментах статического анализа, руководствах по безопасному кодированию, а также во внутренних процедурах проверки и обучения для выявления и предотвращения уязвимостей (включая множество уязвимостей в собственном, непубличном ПО, которые никогда не получают идентификатор CVE). Изменение заключается в том, что CWE теперь становится более неотъемлемой частью самого процесса раскрытия уязвимостей, поскольку ценность прозрачного определения первопричины получает более широкое признание. По мере роста числа CVE недостаточно просто знать о существовании уязвимости; командам необходимо понимать, почему она возникла, чтобы правильно расставить приоритеты, устранить проблему и предотвратить её повторение.

Параллельно мы наблюдаем измеримое улучшение в применении CWE. Растущее большинство записей CVE теперь включает сопоставления с CWE, предоставленные CNA, которые, как правило, более ценны, поскольку исходят от лиц, обладающих непосредственными знаниями об уязвимости и контекстом продукта. Эта близость к проблеме способствует более точным и конкретным сопоставлениям, а не широким или предположительным классификациям, что делает данные гораздо более полезными для инженерных команд.

Наконец, происходит более масштабный переход к принципам «безопасности по умолчанию» и системного снижения рисков. CWE предоставляет общий язык для связи отдельных уязвимостей с лежащими в их основе проблемами разработки. CWE помогает командам перейти от исправления симптомов к устранению шаблонных причин.

Данные демонстрируют реальный прогресс, но также указывают на то, что мы всё ещё находимся в процессе перехода. Анализ последних данных CWE Top 25 за 2025 год показывает положительную тенденцию: стало меньше привязок к излишне абстрактным CWE и заметен сдвиг в сторону более конкретных, низкоуровневых записей. Мы наблюдаем рост использования CWE уровня Base и Variant для определения корневой причины — это более точные записи, отражающие конкретную причину и способствующие лучшему пониманию и устранению проблемы.

Всё ещё сохраняется некоторая вариативность в качестве, особенно когда привязки делаются без полного контекста. Одна из главных сложностей, с которой сталкиваются новые участники сообщества, — это различие между уязвимостью и её базовой слабостью. Иногда привязки определяются результатом или воздействием уязвимости, а не условием, которое её вызвало, что может приводить к более широким или менее точным классификациям — особенно когда аналитики и составители отчётов ещё не имеют глубокого опыта в формулировании уязвимостей с точки зрения корневой причины CWE.

В целом, тенденция обнадёживает: более точные привязки, лучшее соответствие руководствам и активное участие. Дальнейший акцент на определении корневой причины со временем усилит ценность данных CWE как на уровне отдельных организаций, так и в кросс-организационном контексте.

Автоматизация и инструментарий крайне важны для продвижения CWE и повышения точности привязок в больших масштабах. Во многих случаях эти возможности опережают обучение и руководства — они помогают аналитикам выявлять вероятные шаблоны слабостей, стандартизировать привязки и применять CWE более последовательно, чем при ручных процессах. При грамотном использовании они поднимают базовый уровень и делают CWE более доступным в повседневной работе.

Большие языковые модели продемонстрировали превосходную способность просеивать огромные массивы данных и выделять ключевые детали, которые было бы сложно или долго обнаружить аналитикам-людям. Однако, эффективность этих систем полностью зависит от качества данных и исходных допущений. Если модель обучена на абстрактных или некорректных сопоставлениях, она будет воспроизводить те же проблемы — только быстрее и в большем масштабе. Таким образом, автоматизация может закрепить неточности, если она не основана на надёжных примерах правильного определения первопричин. Модель также может с большей вероятностью использовать внешне схожие термины, имеющие в рамках CWE различное значение, или — подобно неопытным специалистам — иногда путать результат или последствие уязвимости с самой слабостью, которая её вызвала.

Наиболее эффективный подход — это сочетание инструментов с человеческим суждением, особенно тех, кто лучше всего знает продукт. Автоматизация может ускорить и направить процесс, но точное сопоставление с CWE по-прежнему зависит от контекста и экспертизы.

Это серьёзная проблема. Большинство команд работают в реактивном режиме, потому что именно там сосредоточен непосредственный риск. Однако, фокусировка на слабостях призвана не добавить больше работы, а сократить повторяющиеся задачи. Когда одна и та же глубинная проблема приводит к множеству уязвимостей с течением времени, продолжение обработки каждой из них как отдельного события становится дороже, чем устранение коренной причины.

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

Многократно доказано, что устранение проблем на более ранних этапах жизненного цикла разработки эффективнее и экономичнее, чем на поздних. С экономической точки зрения, речь идёт о переходе от повторяющегося реагирования на инциденты к более устойчивому снижению рисков. Исправление целого класса слабостей может устранить целые категории будущих уязвимостей, что напрямую снижает объём оповещений, циклы исправлений и операционную нагрузку в SOC. Даже небольшие улучшения на уровне коренных причин могут иметь значительный эффект в дальнейшем.

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

Самый большой разрыв заключается в том, как мы формулируем проблему. Десятилетиями индустрия строила свой язык вокруг уязвимостей и атак: что было использовано, как это было вызвано и как реагировать. CWE заставляет нас задуматься о том, почему плохой исход был вообще возможен. Сдвиг от описания последствий к пониманию базовых слабостей — это именно то место, где семантическое несоответствие всё ещё проявляется среди исследователей, поставщиков и защитников.

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

Язык важен, потому что он определяет поведение. Если мы продолжим формулировать кибербезопасность исключительно в терминах уязвимостей, которые нужно исправить, и атак, от которых нужно защищаться, мы останемся запертыми в реактивном цикле. Формулирование проблем как слабостей, которые нужно выявить и устранить раньше в жизненном цикле, меняет разговор. Это расставляет приоритеты в пользу профилактики, информирует о лучших проектных решениях и в конечном итоге сокращает объём уязвимостей, которыми нам приходится управлять на последующих этапах.

Скачать: Обзор угроз и защит идентификации SANS 2026