«Нам нужен VEX по этому результату сканирования» — готов ли запрос к разговору с продавцом?
Результат сканирования в групповом сообщении ещё не является запросом на услугу VEX. Сначала нужно узнать продукт, версию, CVE, путь к компоненту, статус, ответственного за обоснование и дату выпуска. Это руководство помогает руководителю по развитию бизнеса в сфере безопасности продуктов отделить начало разговора от квалифицированной возможности с помощью пяти вопросов.
Короткий ответ: пока нет. Результат сканирования, вставленный в групповое сообщение, — это начало разговора, а не квалифицированный запрос на услугу. Прежде чем назначать разговор с продавцом, нужно собрать пять конкретных сведений, которых в исходном сообщении почти наверняка нет.
Что означает каждый термин, прежде чем вы квалифицируете запрос
Почти в каждом запросе VEX фигурируют три основных понятия. Специалист, квалифицирующий лид, должен понимать их достаточно хорошо, чтобы заметить недостающие данные.
Vulnerability Exploitability eXchange (VEX) — это структурированная аттестация, указывающая, затрагивает ли известная уязвимость конкретный продукт. Она связывает статус — например, affected, not_affected или under_investigation — с обоснованием причины (CISA, Минимальные требования к Vulnerability Exploitability eXchange, опубликовано 21 апреля 2023 года). Без точного продукта и версии документ VEX подготовить невозможно.
Software Bill of Materials (SBOM), или ведомость состава программного обеспечения, — это иерархический перечень компонентов программного продукта (CISA, центр ресурсов SBOM, по состоянию на 3 августа 2026 года). Фраза «нам также нужен SBOM» указывает только на категорию артефакта. Из неё неясно, нужен ли доступ к существующему файлу, создание нового, нормализация формата или регулярные обновления. Определяйте объём работ по SBOM отдельно.
Идентификатор Common Vulnerabilities and Exposures (CVE) — это уникальная метка публично раскрытой уязвимости. Если выходные данные сканера не содержат CVE, команде, которая пишет VEX, нечего оценивать.
Квалификационная цепочка из пяти вопросов
Проработайте эти вопросы по порядку. Каждый зависит от ответа на предыдущий.
1. Сохраните результат сканирования без изменений
Попросите потенциального клиента вставить необработанный результат сканирования — не скриншот и не пересказ. Важны название инструмента, дата сканирования, цель и полный текст находки. Перефразированный запрос вроде «сканер показал высокий риск в OpenSSL» не даёт ни пути к компоненту, ни CVE, ни диапазона версий. Сохраните исходную находку, прежде чем задавать следующие вопросы.
2. Определите точный продукт, версию и путь к компоненту.
Именно здесь останавливается большинство запросов из групповых сообщений. «Наше веб-приложение» — ещё не точное название продукта. Нужны коммерческое название, идентификатор версии или сборки и путь к уязвимому компоненту внутри продукта — например, acme-portal v4.2.1 / lib/openssl.so. OWASP CycloneDX описывает VEX как оценку эксплуатируемости «в контексте продукта, в котором используется компонент» (страница возможностей CycloneDX VEX, по состоянию на 3 августа 2026 года). Без этого контекста нельзя определить достижимость уязвимого компонента.
3. Выберите поддерживаемый статус VEX.
Минимальные требования CISA перечисляют четыре признанных статуса: not_affected, affected, fixed и under_investigation. Каждый требует обоснования. Не выбирайте статус по уровню серьёзности сканера: «критическая» находка может иметь статус not_affected, если уязвимая функция недостижима в сборке продукта.
4. Получите подтверждённое доказательствами обоснование и назначьте ответственного
Обоснование отвечает на вопрос, почему применяется данный статус. Допустимые варианты включают component_not_present, vulnerable_code_not_in_execute_path, inline_mitigations_exist и vulnerable_code_cannot_be_controlled_by_adversary. Спросите, кто в организации потенциального клиента или у поставщика продукта может задокументировать доказательства и утвердить их. Обоснование без ответственного автора не имеет веса в процедуре подтверждения безопасности для клиента.
5. Запишите решение о выпуске и дату.
Для документа VEX требуется датированное решение о выпуске — даже при статусе under_investigation с назначенной датой повторной проверки. Без даты получатель не сможет оценить актуальность документа. Подтвердите, кто и когда опубликует заявление.
Иллюстративное групповое сообщение
Следующий составной пример показывает, как поступает типичный запрос и что он не учитывает. Каждая деталь иллюстративна.
[Собирательное иллюстративное сообщение из Telegram] «Всем привет! Клиент запустил сканирование Nessus и получил критическую находку по Apache Log4j. Ему нужен VEX к пятнице. Кто-нибудь может взяться?»
В сообщении названы сканер и семейство компонентов, но не указаны продукт, версия, CVE, путь к компоненту, статус эксплуатируемости, ответственный за обоснование и дата выпуска. Это потенциальный лид, а не согласованный проект. В ответ нужно запросить исходный результат сканирования и контекст продукта, а затем направить запрос в нужную очередь.
Небольшая таблица маршрутов
Как только вы соберете столько, сколько потенциальный клиент может предоставить, направьте запрос к как можно более короткому следующему шагу.
| Что у тебя есть | Маршрут к |
|---|---|
| Только необработанные данные сканирования, без контекста продукта | Сбор доказательств — запросите продукт, версию и путь к компоненту. |
| Контекст продукта присутствует, нет CVE или обоснования. | Сбор доказательств — запросите CVE и анализ достижимости |
| Продукт, CVE, обоснование и ответственный подтверждены | Подготовка VEX |
| Нестандартный продукт или нормативный вопрос | Обзор специалиста |
Результат сканирования без подтверждённого статуса affected | Наблюдение — вернитесь к запросу, когда появится рекомендация поставщика или новые данные об эксплуатации |
Ключевые факты из официальных источников
- Минимальные требования CISA к VEX (21 апреля 2023 года): документ определяет минимальные элементы VEX, включая идентификаторы продукта и уязвимости, статус воздействия, обоснование и дату выпуска. Это базовые поля совместимости, а не дополнительные опции.
- Центр ресурсов CISA по SBOM (по состоянию на 3 августа 2026 года): SBOM определяется как иерархический перечень компонентов программного обеспечения. На странице VEX отдельно описывается как аттестация о том, затрагивают ли известные уязвимости продукты. Запрос SBOM без уточнений показывает тип артефакта, но не объём работ.
- Возможности VEX в OWASP CycloneDX (по состоянию на 3 августа 2026 года): VEX передаёт оценку эксплуатируемости в контексте продукта. Общий результат сканирования сам по себе не устанавливает достижимость или статус воздействия.
- Политика конфиденциальности Telegram (по состоянию на 3 августа 2026 года): боты — независимые сторонние сервисы, которые могут работать с доступом к сообщениям или без него, что отображается в интерфейсе. Разработчикам следует запрашивать разрешение перед доступом к данным. Поэтому автоматическую проверку нужно ограничивать группами, которые пользователь намеренно подключил и имеет право читать.
Почему это важно: рабочий пример
Представьте, что потенциальный клиент пересылает предупреждение сканера: «CVE-2024-3094 в xz Utils — критично, нужен VEX». После пяти вопросов выясняется, что внутренняя панель управления включает xz, но никогда не вызывает уязвимый путь сжатия. Анализ достижимости показывает vulnerable_code_not_in_execute_path. Статус VEX — not_affected, обоснование задокументировано, а внутренняя служба безопасности отвечает за выпуск с плановой датой 15 августа 2026 года.
Без квалификационной цепочки тот же запрос могли бы сразу направить на подготовку VEX со статусом affected. В результате появился бы документ, искажающий реальный риск, а специалист потратил бы время впустую.
После квалификации остаётся неизвестным, как часто сканер ошибочно срабатывает на этот CVE в данной версии продукта, актуален ли анализ пути компонента для последней сборки и принимают ли клиенты потенциального заказчика статус not_affected с обоснованием по пути выполнения кода или требуют дополнительных доказательств. До передачи запроса на подготовку VEX у каждого неизвестного должен быть назначенный ответственный.
Часто задаваемые вопросы
Нужен ли мне полный SBOM, прежде чем я смогу создать документ VEX?
SBOM описывает перечень компонентов, на которые ссылается документ VEX. Существующий SBOM ускоряет определение пути к компоненту, но не является строгим обязательным условием: минимальные поля VEX, определённые CISA 21 апреля 2023 года, требуют указания продукта, версии и идентификатора уязвимости, а не SBOM. Если потенциальный клиент не может предоставить ни SBOM, ни путь к компоненту, сначала направьте запрос на сбор доказательств.
Может ли оценка серьёзности сканера заменить статус VEX?
Нет. Сканер присваивает CVE общий уровень серьёзности, а статус VEX показывает, затрагивает ли CVE конкретный продукт в его реальном применении. OWASP CycloneDX (страница возможностей, по состоянию на 3 августа 2026 года) подчёркивает, что эксплуатируемость нужно оценивать в контексте продукта. «Критический» результат сканирования может иметь статус not_affected в конкретной сборке. Если принять оценку сканера за статус VEX, этап проверки контекста продукта будет пропущен, а аттестация окажется вводящей в заблуждение.
Кому принадлежит решение о выпуске, если VEX предназначен для стороннего компонента?
Решение о выпуске принимает поставщик продукта или организация, которая собирает и распространяет готовый продукт. Разработчик исходного компонента может выпустить собственную рекомендацию, но за статус VEX и дату публикации отвечает организация, поставляющая продукт потенциальному клиенту. Если запрос поступил от конечного пользователя, а не от поставщика, сначала уточните, может ли внутренняя служба безопасности выступить ответственным владельцем или нужно привлечь поставщика, и только затем направляйте запрос на подготовку VEX.
Когда метод работает в масштабе
Приведенная выше квалификационная цепочка работает для одного запроса за раз. Когда команда служб безопасности отслеживает несколько групповых каналов — отраслевые форумы, сообщества пользователей, партнерские каналы — по ним повторяется одна и та же картина неполных запросов от сканера к VEX. Распознавание недостающих полей и маршрутизация каждого запроса до начала разговора о продажах становятся узким местом.
TOP Prospect считывает только Telegram-группы, которые пользователь намеренно подключил и имеет право читать. Он подготавливает кандидатов для проверки, а не подтверждает факты, оставляет решение о квалификации человеку и не связывается с участниками группы автоматически. Команды, отслеживающие обсуждения результатов сканирования, могут использовать его вместе с методом сохранения происхождения сигнала и системой оценки уверенности в бизнес-сигналах, чтобы находить неполные запросы VEX до того, как они затеряются в активном канале. Основная страница продукта — анализ бизнес-сигналов из Telegram.
Следующий шаг: возьмите три последних сообщения с результатами сканирования из ваших групповых каналов и перечислите, чего не хватает в каждом. Если в каждом сообщении отсутствуют хотя бы три из пяти квалификационных полей, добавьте короткий шаблон «что нам нужно» в процедуру первого ответа.
Часто задаваемые вопросы
Нужен ли мне полный SBOM, прежде чем я смогу создать документ VEX?
SBOM описывает перечень компонентов, на которые ссылается документ VEX. Существующий SBOM ускоряет определение пути к компоненту, но не является строгим обязательным условием: минимальные поля VEX, определённые CISA 21 апреля 2023 года, требуют указания продукта, версии и идентификатора уязвимости, а не SBOM. Если потенциальный клиент не может предоставить ни SBOM, ни путь к компоненту, сначала направьте запрос на сбор доказательств.
Может ли оценка серьезности сканера заменить статус VEX?
Нет. Сканер присваивает CVE общий уровень серьёзности, а статус VEX показывает, затрагивает ли CVE конкретный продукт в его реальном применении. OWASP CycloneDX (страница возможностей, по состоянию на 3 августа 2026 года) подчёркивает, что эксплуатируемость нужно оценивать в контексте продукта. «Критический» результат сканирования может иметь статус `not_affected` в конкретной сборке. Если принять оценку сканера за статус VEX, этап проверки контекста продукта будет пропущен, а аттестация окажется вводящей в заблуждение.
Кому принадлежит решение о выпуске, если VEX предназначен для стороннего компонента?
Решение о выпуске принимает поставщик продукта или организация, которая собирает и распространяет готовый продукт. Разработчик исходного компонента может выпустить собственную рекомендацию, но за статус VEX и дату публикации отвечает организация, поставляющая продукт потенциальному клиенту. Если запрос поступил от конечного пользователя, а не от поставщика, сначала уточните, может ли внутренняя служба безопасности выступить ответственным владельцем или нужно привлечь поставщика, и только затем направляйте запрос на подготовку VEX.
Источники и дополнительное чтение
- CISA, Минимальные требования для обмена уязвимостями (VEX) (21 апреля 2023 г.)
- CISA, ресурсный центр спецификации программного обеспечения (SBOM) (по состоянию на 3 августа 2026 г.)
- OWASP CycloneDX, возможность обмена уязвимостями (по состоянию на 3 августа 2026 г.)
- Telegram Политика конфиденциальности (по состоянию на 3 августа 2026 г.)
Как обнаруживается Signal, заслуживающий внимания
Методика показывает, как Top Prospect находит и упорядочивает Signals, которые стоит проверить, сохраняет исходный контекст Telegram, удаляет дубли и помогает определить порядок просмотра. Решение о дальнейших действиях остаётся за вами.
