Безопасность npm-зависимостей: уязвимости и достижимость кода

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

Никакой npm audit не запускался. Файл advisory.fixture.json написан автором, содержит fictional:true и не ссылается на настоящий CVE. Это позволяет изучать метод анализа без приписывания уязвимости реальному пакету.

Наличие компонента и достижимость условия

Учебная запись относится к lab-parser старой модели. Условие — специально подготовленный вход при обработке определённого формата. Сначала проверим наличие выбранной версии в графе. Затем выясним, используется ли соответствующая возможность, откуда приходит вход и с какими полномочиями работает код. Эти вопросы образуют путь воздействия, а не заменяются одним severity.

Для «Контура выпуска» ввод может быть собственным редакционным JSON. Это уменьшает одну область внешнего воздействия, но не делает всё безопасным: источник мог измениться, CI мог обрабатывать предложенный материал, а зависимость могла исполняться при установке. Каждая стадия имеет свои условия. Нельзя назвать devDependency несущественной лишь потому, что её нет в браузерном каталоге.

В reachability.csv записаны пакет, стадия, источник входа, используемая функция, привилегии и состояние доказательства. Для учебного parser путь отмечен как unknown, потому что настоящих исходников нет. Мы умеем задать нужные вопросы, но не утверждаем достижимость либо недостижимость. Это честный результат модели.

Npm audit использует сведения о зависимостях и известные сообщения сервиса. Отсутствие найденной записи не является доказательством отсутствия вредоносного кода или неизвестной ошибки. Напротив, найденная запись даёт конкретную работу: установить версию, условия и вариант исправления. Поэтому карточка сохраняет и источник advisory, и границу того, что он сообщает.

Не выполняем автоматическое исправление ради исчезновения сообщения. Оно может изменить дерево и API. Сначала определим подходящую версию либо альтернативу, затем продуктовую проверку и политику скриптов. Для нашей лаборатории обновление остаётся запланированным. Команды audit и fix в архиве не выдаются за фактические результаты анализа.

Решение с временной границей

Если условие не достижимо в текущем маршруте, это должно иметь основание: кодовая ссылка, закрытый источник входа или фактическая конфигурация. Одна интуиция автора недостаточна. Временное принятие требует владельца, причины и пересмотра при изменении входа. Заявление «не используется» без срока превращается в забытое исключение.

Если путь достижим, приоритет зависит от возможных последствий и доступных мер. Можно ограничить ввод, удалить возможность, обновить пакет либо остановить соответствующую стадию. Выбор привязан к механизму, а не только к цвету severity. Для чувствительного реального проекта потребуется собственный процесс реагирования; наш документ не проводит такие операции.

Покажем вариант: уязвимый код используется только для локального редакционного преобразования. Всё равно учитываем чтение исходников и возможные полномочия CI. Вред сборке может проявиться в публичном HTML даже без серверного пакета. Карта стадий из первого урока позволяет объяснить такой маршрут, не смешивая его с браузерной эксплуатацией.

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

Для отчёта полезно отдельно хранить факт наличия, факт достижения и решение. Они могут меняться в разные моменты. Пакет обновлён в модели, но установка ещё не выполнена; правило входа изменено, но выпуск ещё не создан. Одно поле fixed скрывает эти состояния. В лаборатории все фактические операции имеют not_run, а решение является планом.

Добавьте условие повторного рассмотрения: новый формат данных, внешний источник контента или новая стадия CI. Ранее недостижимый путь может стать доступным после продуктового изменения. История решения должна помогать заметить такую зависимость. Именно поэтому граф пакетов и граф данных важно читать вместе, а не хранить audit как отдельный случайный файл.

Вопрос	Основание для ответа
Версия присутствует?	Нужен конкретный выбранный узел дерева, а не только допустимый диапазон верхнего манифеста.
Условие достижимо?	Нужны используемая функция, источник входа и конфигурация, которых авторский fixture не подтверждает.
Последствие ограничено?	Рассматриваются права стадии и влияние на артефакт, даже когда пакет предназначен для разработки.
Решение завершено?	План обновления не является фактической установкой или подтверждённой проверкой нового состояния проекта.

Разбор учебного пути воздействия

Для строки parser откройте источник входа и стадию. Собственный редакционный JSON может отличаться от произвольного пользовательского файла. Это различие относится к достижимости заданного условия. Но оно не исключает другие пути исполнения, поэтому карточка не получает общий статус safe. В нашем fixture исходный код отсутствует, и достижимость остаётся неизвестной.

Попробуйте изменить только источник входа на external_submission. Теперь прежняя заметка о доверенном редакторе не подходит. Чтобы сохранить решение, потребовалось бы новое основание: ограничения формата, реальное поведение parser и обработка ошибки. Простое переименование столбца не реализует таких мер. Этот вариант показывает, почему вывод привязан к конкретному состоянию приложения.

В сообщении аналитика полезно назвать и абсолютную область: один вымышленный компонент, одна стадия, одна гипотеза. Фраза «у сайта критическая уязвимость» сильнее данных лаборатории. Мы не обнаруживали настоящую ошибку ProfessorWeb и не проводили сканирование. Содержание урока учит разбирать сообщение, а не приписывает событие рабочему проекту.

Для реального advisories нужно сохранить идентификатор источника и дату. Позднее диапазон либо описание условия может уточниться. Версия карточки помогает пересмотреть решение по новому знанию. Если использовать лишь цвет severity без самого основания, такое обновление трудно объяснить. Это ещё одна причина держать сообщение и решение раздельными документами.

Завершите разбор назначением следующего свидетельства. В нашем случае это просмотр настоящей функции и её использования, если появится отдельная авторизованная практика. Никакая команда audit не заменяет такого чтения автоматически. При этом инструмент остаётся полезным источником известных сообщений; его граница объясняется по задаче, а не превращается в утверждение, что автоматические отчёты бесполезны.

Полный основной артефакт reachability.csv выбранного состояния:

package,stage,input_source,function,privileges,evidence_state,fixture
lab-parser,build,own_editorial_json,unknown,source_read_output_write,unknown_no_real_code,fictional
lab-native,install,registry_archive_fixture,unknown,network_scope_not_verified,not_run,fictional

Все исходники серии: папка lesson-05 содержит полный самостоятельный снимок, собственный проект и авторские модели. Исполнение примеров, npm, установки, аудит, тесты, CI, настройки и публикация не выполнялись.

Первичные источники: audit.