{
  "index": 169,
  "slug": "editorial-2023-04-field-dependency-security",
  "title": "Уязвимая зависимость в дереве: как доказать безопасное обновление",
  "excerpt": "Почему предупреждение сканера не равно доказанной уязвимости в runtime и как проверить обновление зависимости по дереву, окружению, сценарию запуска и откату.",
  "contentHtml": "<p>Сканер сообщает об уязвимой версии пакета. Пакет не указан в <code>package.json</code>, поэтому команда решает, что он не используется. Через несколько часов обновление ломает сборку: изменилось транзитивное дерево, peer-зависимость перестала разрешаться, а новый пакет требует другой Node.js. Цена ошибки — остановленный деплой, срочный откат и неясный ответ на вопрос, какой артефакт уже попал в окружение.</p>\n<p>Обратная ошибка тоже дорогая. Команда удаляет пакет из манифеста, получает зелёный install и закрывает предупреждение. Но уязвимый модуль остаётся в lockfile или в другом production-артефакте. Исправление должно отвечать на два разных вопроса: входит ли компонент в поставляемый артефакт и что изменится после его обновления.</p>\n<h2>Тезис: версия не является доказательством</h2>\n<p>Безопасное обновление — это не замена одной строки в манифесте. Это проверяемая цепочка: идентифицированный компонент, зафиксированное дерево, воспроизводимая установка, проверка приложения в целевом runtime и готовый путь возврата.</p>\n<p>Уязвимость обычно приходит через несколько уровней. Приложение зависит от <code>http-client</code>. Он зависит от <code>parser</code>. Advisory указывает на старую версию <code>parser</code>. Вызов метода может находиться далеко от корневого кода, но пакет всё равно входит в установленное дерево. Обратное также верно: запись в lockfile ещё не доказывает, что компонент вошёл в собранный образ или реально загружен процессом.</p>\n<h2>Как устроена проверка</h2>\n<p>Сначала отделите четыре объекта. Манифест описывает намерение проекта. Lockfile фиксирует разрешённое дерево и версии записей. SBOM описывает состав конкретного артефакта, если его построили из этого артефакта. Runtime-наблюдение показывает, что произошло при запуске. Эти источники отвечают на разные вопросы и не заменяют друг друга.</p>\n<p>Начните с baseline. Запишите commit, package manager, версию Node.js, команду установки и digest исходного артефакта. Затем назовите candidate: пакет, исходную версию, новую версию и advisory. Для транзитивной зависимости добавьте прямую цепочку родителей. Без baseline нельзя понять, удалил ли update уязвимый узел или только переставил его в другое место.</p>\n<div class=\"table-scroll\"><table><caption>Проверки безопасности обновления</caption><thead><tr><th scope=\"col\">Проверка</th><th scope=\"col\">Что она доказывает</th><th scope=\"col\">Что сохранить</th></tr></thead><tbody><tr><td>Dependency tree</td><td>Какие записи разрешил установщик и кто приводит к уязвимому пакету</td><td>Diff lockfile и команду получения дерева</td></tr><tr><td>Clean install</td><td>Что зафиксированный проект устанавливается в чистой среде</td><td>Версию инструмента, exit code и лог</td></tr><tr><td>Application tests</td><td>Что выбранные контракты приложения не изменились</td><td>Набор тестов и окружение запуска</td></tr><tr><td>Runtime smoke</td><td>Что сервис стартует и проходит важный сценарий</td><td>Запрос, ответ, лог и trace или метрику</td></tr><tr><td>Artifact scan</td><td>Что проверенный образ или архив не содержит запрещённую версию</td><td>Digest артефакта и результат сканирования</td></tr><tr><td>Rollback</td><td>Что команда может вернуть baseline без новой догадки</td><td>Старый digest, lockfile и условие остановки</td></tr></tbody></table></div>\n<h2>Пример с транзитивным пакетом</h2>\n<p>Следующий фрагмент — учебный. Он не читает настоящий lockfile и не устанавливает пакеты. Он показывает, почему проверка должна искать не только прямые зависимости. В реальном проекте результат нужно получить командой package manager и сопоставить с образом, который будет выпущен.</p>\n<pre><code>const tree = {\n  name: 'checkout-service',\n  version: '1.4.0',\n  dependencies: {\n    'http-client': {\n      version: '4.2.0',\n      dependencies: {\n        parser: { version: '1.0.0' }\n      }\n    }\n  }\n};\n\nfunction findPackage(node, name, path = [node.name]) {\n  if (node.name === name) return { version: node.version, path };\n\n  for (const [childName, child] of Object.entries(node.dependencies ?? {})) {\n    const found = findPackage(child, name, [...path, childName]);\n    if (found) return found;\n  }\n\n  return null;\n}\n\nconsole.log(findPackage(tree, 'parser'));\n// { version: '1.0.0', path: [\n//   'checkout-service', 'http-client', 'parser'\n// ] }</code></pre>\n<p>Результат примера означает только одно: узел найден в заданной структуре. Он не доказывает наличие CVE, достижимость опасного кода, состав production-образа или безопасность версии <code>1.0.1</code>. Чтобы сделать вывод о конкретной системе, добавьте источник advisory, реальный lockfile и digest артефакта.</p>\n<h2>Иллюстрация цепочки доказательств</h2>\n<figure><img src=\"/assets/editorial/2023/dependency-security-2023-safe-update-gate.svg\" alt=\"Цепочка проверки обновления зависимости: scope, diff дерева, чистая установка, тесты, runtime smoke, сканирование артефакта и отдельный rollback\" loading=\"lazy\" /><figcaption>Порядок проверок отделяет состав дерева от поведения приложения. Зелёный install не открывает выпуск без runtime smoke и проверки итогового артефакта.</figcaption></figure>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика типичных ложных выводов</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Пакет не виден в package.json</td><td>Он транзитивный</td><td>Построить дерево от production root</td><td>Обновить родителя или добавить безопасное разрешение с проверкой результата</td></tr><tr><td>Lockfile обновился, но advisory остался</td><td>Resolver выбрал другую ветку или копию пакета</td><td>Найти все записи имени и версии</td><td>Разобрать каждого родителя и пересчитать artifact contents</td></tr><tr><td><code>npm ci</code> зелёный, сервис не стартует</td><td>Не совпал runtime, peer range, native addon или module format</td><td>Запустить smoke в том же образе и с тем же Node.js</td><td>Остановить выпуск, сузить update или подготовить совместимый runtime</td></tr><tr><td>Сканер образа не находит старый пакет</td><td>Проверен не тот digest</td><td>Сопоставить digest скана и release candidate</td><td>Пересканировать именно публикуемый артефакт</td></tr><tr><td>Откат возвращает версию, но данные не читаются</td><td>Update изменил формат или внешний протокол</td><td>Проверить обратную совместимость миграции</td><td>Разделить изменение формата и замену зависимости</td></tr></tbody></table></div>\n<h2>Порядок действий</h2>\n<ol><li>Скопируйте advisory и укажите источник, пакет, затронутый диапазон и дату проверки. Не называйте компонент уязвимым для приложения, пока не проверили его путь в артефакте.</li><li>Зафиксируйте baseline: commit, lockfile, package manager, Node.js, platform и digest текущего кандидата на выпуск.</li><li>Постройте dependency tree для production-команды. Найдите прямой путь к каждой копии компонента и проверьте optional и peer-ветки.</li><li>Сформируйте минимальный candidate update. Измените только необходимые записи, затем прочитайте весь diff lockfile: версии, integrity, источники, scripts и соседние разрешения.</li><li>В чистом окружении выполните установку с теми же флагами, которые использует pipeline. Сохраните команду и exit code. Не превращайте warning о runtime в PASS.</li><li>Запустите тесты границ, которых касается пакет: startup, обработка входных данных, сетевой вызов, сборка, CLI или browser bundle. Название теста должно объяснять проверяемый контракт.</li><li>Сделайте smoke в образе-кандидате. Проверьте старт, один безопасный сценарий и отрицательный путь. Например, некорректный вход должен получить ожидаемый отказ, а не попасть в обработчик.</li><li>Сканируйте образ или архив по immutable digest. Сверьте состав скана с lockfile и SBOM, если SBOM создаёт ваш pipeline. Различие источников — сигнал к расследованию, а не повод выбрать удобный результат.</li><li>Перед публикацией проверьте rollback на уровне артефакта. Если изменение затрагивает миграцию, формат данных или внешний протокол, остановите независимый откат версии и подготовьте совместимый план.</li></ol>\n<h2>Почему engines и lockfile недостаточны</h2>\n<p>Поле <code>engines</code> выражает заявленный диапазон. Оно не запускает приложение, не проверяет native addon и не показывает, какая ветка разрешилась в конкретной платформе. При мягкой настройке package manager несовпадение может остаться предупреждением. Поэтому engine check полезен как ранний фильтр, но не как итог.</p>\n<p>Lockfile даёт воспроизводимую точку для установки. Он не является снимком уже работающего процесса. Сборка может исключить пакет, добавить его в другой слой, заменить optional dependency или использовать иной lockfile. Состав проверяйте на выходном артефакте, а поведение — в целевом runtime.</p>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Dependency scanner не знает автоматически, может ли атакующий достичь уязвимого вызова. Runtime smoke не доказывает отсутствие всех опасных путей. SBOM не доказывает, что его создали из того же digest, который публикуют. Результаты нужно связывать с конкретным commit и артефактом.</p>\n<p>Если компонент найден, но его путь не достигается в вашем сценарии, это не разрешение игнорировать advisory. Зафиксируйте границу утверждения: «путь не достигнут в проверенном сценарии». Затем проверьте другие entry point, worker, CLI, background job и режимы сборки. Если среда не позволяет выполнить нужный сценарий, статус должен остаться неизвестным. Не заменяйте его словом «безопасно».</p>\n<p>Если clean install не проходит, не чините результат добавлением случайного флага. Сначала сравните manifest и lockfile, peer range и runtime. Если smoke не проходит после установки, возврат к baseline предпочтительнее выпуска с неясной совместимостью. Если digest скана не совпадает с digest релиза, остановите публикацию.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Обновление готово к выпуску, когда команда может предъявить один набор связанных доказательств: advisory и scope, baseline и candidate, полный diff дерева, успешную чистую установку, тесты затронутого контракта, smoke в целевом образе, результат сканирования того же digest и проверяемый rollback. Каждый результат имеет команду, окружение и exit status или наблюдаемый ответ.</p>\n<p>Любой пропущенный элемент помечается явно: <code>not run</code>, <code>not applicable</code> с причиной или <code>unknown</code>. Слово <code>PASS</code> допустимо только для реально выполненной проверки. Если доказательства относятся к другому commit, образу или runtime, обновление не готово.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://docs.npmjs.com/cli/v8/commands/npm-ci\" target=\"_blank\" rel=\"noopener noreferrer\">npm Docs: npm ci</a> — официальное описание установки по существующему lockfile и её ограничений.</li><li><a href=\"https://docs.npmjs.com/cli/v8/configuring-npm/package-json\" target=\"_blank\" rel=\"noopener noreferrer\">npm Docs: package.json и engines</a> — официальное описание заявленного диапазона runtime и режима engine-strict.</li><li><a href=\"https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom\" target=\"_blank\" rel=\"noopener noreferrer\">NTIA: The Minimum Elements for a Software Bill of Materials</a> — официальный документ о назначении SBOM и его минимальных элементах.</li></ul>"
}