NodeSource раскрыла механизм оценки CVE в N|Solid — OpenVEX уточняет риски для Node.js

8 октября 2026 года NodeSource объяснила, как её среда выполнения N|Solid использует OpenVEX, чтобы сообщать о реальной применимости известных уязвимостей к конкретным сборкам Node.js. Механизм помогает отличать случаи, когда уязвимый компонент присутствует в составе продукта, от ситуаций, в которых опасный код действительно доступен, и показывает сведения об уже перенесённых исправлениях. Поддержка OpenVEX появилась в N|Solid 6.3.7 ещё 24 сентября; новая публикация раскрывает её работу на примерах реальных CVE.

Обнаруженная уязвимость в зависимости Node.js требует проверки контекста

Сканер безопасности может обнаружить известную уязвимость в библиотеке, которая входит в состав среды выполнения или поставляется вместе с npm. Обычно сигнал строится на совпадении имени пакета и его версии с базой уязвимостей. Такой результат полезен для поиска проблем, но сам по себе ещё не описывает, как именно этот пакет используется внутри конкретного продукта.

Представим серверный проект, в котором инструмент проверки сообщает об уязвимости библиотеки для проверки цифровых подписей. Для понимания риска возникает следующий вопрос: вызывает ли поставляемый с Node.js инструмент тот участок библиотеки, где обнаружена ошибка? Ответ зависит от фактических вызовов и настроек, а сведения о версии пакета этого не раскрывают.

Именно этот пробел призван закрыть формат VEX (Vulnerability Exploitability eXchange). Он позволяет производителю программного продукта публиковать проверяемые утверждения о том, затрагивает ли определённая CVE конкретную версию продукта. OpenVEX представляет такие сведения в машинно-читаемых документах JSON-LD.

N|Solid 6.3.7 получил OpenVEX в сентябре — 8 октября NodeSource разобрала реальные случаи

N|Solid — среда выполнения на основе Node.js, которую развивает компания NodeSource. По её сообщению от 8 октября, поддержка OpenVEX появилась в выпуске N|Solid 6.3.7 от 24 сентября 2026 года. Поэтому речь идёт об опубликованном техническом разборе уже выпущенной возможности, а не о новом релизе основной среды Node.js.

В пакетах N|Solid производитель размещает сведения по пути share/doc/nsolid/nsolid.openvex.json, а в исходном репозитории — в tools/vex/nsolid.openvex.json. В документах связываются идентификатор CVE, программный компонент, конкретный продукт и оценка последствий. Для некоторых записей предусмотрены пояснения, почему проблема недоступна для эксплуатации или каким способом устранена.

Доступны четыре основных статуса OpenVEX:

Статус	Смысл
`affected`	Уязвимость затрагивает указанную версию продукта.
`not_affected`	Производитель установил, что указанная версия не подвержена данной проблеме, и приводит обоснование.
`fixed`	В указанном продукте или версии содержится исправление.
`under_investigation`	Проверка влияния уязвимости ещё продолжается.

Статусы относятся к продуктам и версиям, перечисленным в записи. Их нельзя автоматически переносить на любые приложения, отдельные установки npm или все ветки Node.js.

CVE-2026-48815 в sigstore — почему N|Solid указывает not_affected

Один из примеров NodeSource касается CVE-2026-48815 в пакете sigstore. Уязвимость связана с параметром certificateOIDs: при проверке подписей библиотека принимала это ограничение, но не применяла его. Программа, которая рассчитывает на обязательную проверку определённых расширений сертификата, могла получить результат без требуемого контроля. Исправление самой библиотеки выпущено в sigstore 4.1.1.

В опубликованном файле OpenVEX для ветки N|Solid на базе Node.js 22 присутствует оценка компонента sigstore@3.1.0. Для продукта с идентификатором node-v22.23.2-nsolid-v6.3.6 указан статус not_affected и техническое обоснование vulnerable_code_not_in_execute_path — уязвимый путь выполнения не используется.

NodeSource объясняет это поведением поддерживаемых сценариев командной строки npm. Связанные компоненты pacote и libnpmpublish не передают в вызов проверки подписи ограничение certificateOIDs, с которым связана CVE. Поэтому для описанного сценария N|Solid не обнаруживает возможности задействовать ошибочную проверку.

Это ограниченная по охвату оценка поставляемого продукта и его способа использования зависимости. Она не устанавливает безопасность любого приложения, которое самостоятельно вызывает уязвимую версию sigstore с другими параметрами.

CVE-2026-9496 показывает, как OpenVEX фиксирует перенесённое исправление

Второй пример связан с CVE-2026-9496 в пакете pacote, который участвует в получении npm-пакетов. Проблема относится к обработке специально подготовленных входных данных: ресурсоёмкая операция со строкой могла вызвать чрезмерное потребление процессорного времени и нарушить работу процесса.

В опубликованном документе N|Solid эта CVE отмечена статусом fixed. Производитель поясняет, что исправление из исходного проекта перенесли в собственную кодовую базу. Уязвимую операцию с регулярным выражением заменили обработкой строки на основе indexOf() и slice().

Оба примера показывают разные причины появления уязвимого компонента в отчёте сканера. В случае с sigstore компания описывает условия, при которых обнаруженная проблема не затрагивает конкретную поставку N|Solid. Для pacote опубликована информация об устранении опасного поведения. В обоих случаях объяснение проверяется по техническому содержимому VEX-документа, а не по одной отметке о статусе.

Оценки безопасности различаются между ветками N|Solid

В репозитории NodeSource данные OpenVEX опубликованы в ветках исходного кода N|Solid. В просмотренном документе для ветки на базе Node.js 22 есть записи о нескольких CVE, включая CVE-2026-48815 и CVE-2026-9496. В доступном документе ветки на базе Node.js 24 массив statements пуст.

Пустой список не является подтверждением отсутствия уязвимостей в Node.js 24. Он показывает лишь то, что в данном файле на момент проверки нет опубликованных VEX-утверждений. Данные о конкретной сборке N|Solid применимы в пределах продукта и версий, обозначенных в соответствующей записи.

Это ограничение существенно для систем, где одновременно используются несколько веток Node.js. Совпадающий номер CVE может встречаться в отчётах по разным сборкам, но оценка её применимости требует отдельного подтверждения для каждой из них.

SBOM, сканер и OpenVEX дают три разных уровня информации

В инфраструктуре Node.js эти источники решают связанные задачи. SBOM (Software Bill of Materials) перечисляет компоненты, входящие в программный продукт. Сканер сопоставляет их с известными уязвимостями. OpenVEX добавляет заключение производителя о том, как обнаруженная проблема влияет на обозначенный продукт.

Пример с sigstore показывает границу такого подхода. Библиотека может фигурировать в списке зависимостей и совпадать с уязвимой версией в базе CVE, а производитель N|Solid при этом обосновывает отсутствие затронутого пути выполнения в поддерживаемых сценариях npm. Пример с pacote показывает другой случай: кодовое исправление уже перенесено, и VEX фиксирует этот факт.

Публикация NodeSource от 8 октября делает устройство OpenVEX в N|Solid более понятным: раскрыты пути к документам, формат оценки и конкретные примеры. Открытым остаётся вопрос о том, насколько полно такие записи будут покрывать разные ветки и выпуски N|Solid. Сам механизм даёт сведения о конкретных проверенных уязвимостях; полнота этих сведений зависит от работы сопровождающей продукт команды.