{
  "index": 170,
  "slug": "editorial-2023-04-mechanism-dependency-security",
  "title": "Безопасность зависимостей: как связать advisory, lockfile и SBOM",
  "excerpt": "Совпадение имени пакета с advisory ещё не доказывает риск для выпуска. Разбираем, что фиксируют manifest, lockfile и SBOM, как проверить путь зависимости и когда обновление можно считать готовым.",
  "contentHtml": "<p>Сканер сообщает об advisory для транзитивного пакета. Команда меняет строку в <code>package.json</code>, получает зелёный pull request и закрывает задачу. Через день выясняется, что lockfile не изменился, SBOM относится к предыдущему образу, а пакет присутствует только в optional-ветке для другой платформы. Ошибка стоит времени на ложную аварию или, хуже, оставляет настоящий риск без владельца. В обоих случаях команда не может ответить на простой вопрос: какой компонент попал в конкретный артефакт и где он может быть достигнут?</p>\n<p>Тезис статьи прост: безопасность зависимости проверяют не по одному имени и не по одному файлу. Сначала связывают внешний сигнал с точной записью в resolved tree. Затем связывают эту запись с SBOM того же build. После этого отдельно проверяют достижимость и поведение в нужном runtime-сценарии. <code>package.json</code>, lockfile, SBOM и runtime evidence описывают разные границы. Совпадение двух списков полезно, но само по себе не закрывает риск.</p>\n<h2>Четыре вопроса вместо одного</h2>\n<p>Manifest отвечает на вопрос «что проект просит установить». Для прямой зависимости он хранит имя и допустимый диапазон версий. Запись <code>\"demo-shell\": \"^1.0.0\"</code> не говорит, какая версия окажется в текущем дереве.</p>\n<p>Lockfile отвечает на другой вопрос: какое дерево выбрал установщик при конкретных правилах разрешения. Для npm это точное представление дерева, созданного установкой. В нём видны транзитивные пакеты, версии, источники и integrity-поля. Но lockfile не является журналом уже запущенного процесса. Его нужно связать с commit, командой установки и артефактом, который действительно собирает pipeline.</p>\n<p>SBOM отвечает на вопрос «какие компоненты заявлены для named artifact и как они связаны». Он может быть независим от конкретного package manager и пригоден для анализа поставки. Но файл без build ID, digest или другой неизменяемой привязки не доказывает состав текущего образа. Runtime evidence отвечает на четвёртый вопрос: что загрузилось и выполнилось в выбранном сценарии. Ни один из этих слоёв не заменяет остальные.</p>\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><code>package.json</code></td><td>Какую direct dependency просит проект?</td><td>Diff manifest и review диапазона</td><td>Точное resolved tree</td></tr><tr><td><code>package-lock.json</code></td><td>Какое дерево выбрал installer?</td><td>Diff lockfile и clean install</td><td>Загрузку модуля в процессе</td></tr><tr><td>SBOM</td><td>Какие компоненты заявлены для артефакта?</td><td>Component records и artifact identity</td><td>Достижимость по коду и конфигурации</td></tr><tr><td>Runtime evidence</td><td>Что произошло в named scenario?</td><td>Тест, trace или controlled smoke</td><td>Все возможные пути приложения</td></tr><tr><td>Advisory</td><td>Какой внешний сигнал надо разобрать?</td><td>ID, источник, package и version scope</td><td>Воздействие на этот сервис</td></tr></tbody></table></div>\n<h2>Учебный graph: почему одного совпадения мало</h2>\n<p>Рассмотрим ограниченный fixture. <code>demo-service</code> зависит от <code>demo-shell</code>, а <code>demo-shell</code> — от <code>demo-parser</code>. Advisory указывает на <code>demo-parser@1.0.0</code>. В synthetic lockfile пакет есть. В synthetic SBOM есть запись для того же имени и версии. Это подтверждает пересечение двух заданных массивов. Это не подтверждает, что пакет установлен в production, достижим из реального entry point или уязвим именно в таком контексте.</p>\n<pre><code>const locked = packages.find(\n  (item) =&gt; item.name === advisory.packageName\n    &amp;&amp; item.version === advisory.affectedVersion,\n);\n\nconst recorded = components.some(\n  (item) =&gt; item.name === advisory.packageName\n    &amp;&amp; item.version === advisory.affectedVersion,\n);\n\nreturn {\n  lockfile: locked ? 'entry-matched' : 'entry-not-found',\n  sbom: recorded ? 'component-matched' : 'component-not-found',\n  reachability: 'not-assessed',\n  vulnerabilityStatus: 'not-determined',\n};</code></pre>\n<p>Код намеренно не читает настоящий lockfile, не запускает scanner и не строит call graph. Он показывает важную границу: найденная строка — это факт о входных данных, а не вердикт о безопасности. Если имя отсутствует в lockfile, вопрос меняется на provenance advisory или на несовпадение версии. Если имя есть в lockfile, но отсутствует в SBOM нужного build, нужно проверять генерацию и identity артефакта. Если оба списка совпали, всё ещё остаётся путь использования.</p>\n<figure><img src=\"/assets/editorial/2023/dependency-security-2023-lockfile-sbom.svg\" alt=\"Схема границ manifest, lockfile, SBOM и runtime evidence для проверки зависимости\" loading=\"lazy\" /><figcaption>Схема разделяет намерение проекта, resolved tree, инвентарь named artifact и наблюдение runtime. Это иллюстрация учебной модели, а не SBOM или запись production-запуска.</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>Изменился <code>package.json</code>, но lockfile остался прежним</td><td>Проверили намерение, но не разрешённое дерево</td><td>Сравнить direct range, lockfile entry и install command</td><td>Пересобрать candidate tree и review diff</td></tr><tr><td>Lockfile и SBOM показывают разные версии</td><td>SBOM создан из другого commit или build</td><td>Сверить source revision, artifact digest и время генерации</td><td>Сгенерировать SBOM для того же candidate artifact</td></tr><tr><td>Пакет есть в SBOM, но не найден в пути вызова</td><td>Состав поставки смешан с reachability</td><td>Проверить import, entry point, flags и optional branch</td><td>Оставить риск в review до доказанного исключения</td></tr><tr><td>После patch update изменилось много строк lockfile</td><td>Resolver обновил транзитивное дерево</td><td>Разделить added, removed, version и integrity changes</td><td>Проверить каждую существенную ветку и тесты</td></tr><tr><td>Fixture завершился PASS</td><td>PASS проверяет только synthetic contract</td><td>Посмотреть статусы provenance, runtime и deployment</td><td>Не прикладывать PASS как доказательство production safety</td></tr></tbody></table></div>\n<h2>Порядок проверки advisory</h2>\n<ol><li>Сохраните immutable источник сигнала: URL или ID advisory, имя пакета, affected range и дату получения. Не называйте совпадение имени подтверждённой уязвимостью.</li><li>Найдите exact package и version в lockfile того commit, из которого собирается candidate. Запишите путь в дереве: direct dependency, parent и транзитивная ветка.</li><li>Сопоставьте компонент с SBOM, сгенерированным для того же артефакта. Зафиксируйте format, generator, source revision и artifact digest.</li><li>Проверьте достижимость отдельным методом. Ищите entry point, imports, conditional exports, feature flags, optional dependencies и платформенные ветки. Если метод не покрывает часть пути, запишите unknown.</li><li>Сформируйте candidate update и просмотрите полный lockfile diff. Убедитесь, что изменение не добавило другой риск и не изменило дерево шире, чем ожидалось.</li><li>Выполните clean install с правилами pipeline, затем проектные тесты и короткий runtime smoke для сценария, где используется затронутая ветка. Результат должен ссылаться на конкретный build.</li><li>Запишите решение и rollback. Если доказательств не хватает, статус должен быть «требует проверки проекта», а не «ложное срабатывание» и не «безопасно».</li></ol>\n<h2>Почему обновление иногда увеличивает область риска</h2>\n<p>Patch update не ограничивается одной строкой manifest. Новый диапазон может выбрать другую транзитивную версию. Installer может иначе обработать optional dependency на другой платформе. Lifecycle script может изменить содержимое build. Поэтому после обновления смотрят lockfile diff, а не только diff <code>package.json</code>. Важны added и removed packages, version shifts, integrity и source fields.</p>\n<p>Отдельная ловушка — SBOM, который лежит рядом с репозиторием, но не рядом с выпуском. Такой документ может быть полезен для разработки и одновременно бесполезен для ответа о deployed image. Минимальный критерий свежести задаёт сам pipeline: SBOM создан из того же source revision и относится к тому же artifact digest, что и release candidate. Это инженерный критерий, который нужно реализовать, а не свойство любого файла с названием SBOM.</p>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Учебная модель не знает реальную advisory database, формат конкретного SBOM, private registry, зависимости ОС, native addons, bundle, generated source или runtime configuration. Она не вычисляет vulnerable range и не доказывает отсутствие эксплуатации. Даже реальный путь импорта не равен доказанной уязвимости: нужно понимать, достигается ли опасный код с контролируемыми входными данными и при каких настройках.</p>\n<p>Отрицательный путь обязателен. Advisory может не совпасть с exact resolved version. Компонент может быть в lockfile, но отсутствовать в named artifact. SBOM может быть старше образа. Достижимость может зависеть от выключенного по умолчанию флага. В каждом случае нельзя подменять неизвестность уверенным исключением. Укажите, что именно не проверено, каким методом это проверят и кто владеет следующим действием.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Обновление готово к решению, когда для одного candidate release можно восстановить всю цепочку: advisory → exact package@version → lockfile commit → SBOM → artifact digest → проверенный runtime-сценарий. Для каждого перехода есть ссылка или сохранённый результат. Lockfile diff просмотрен. Clean install и проектные тесты завершились ожидаемо. Неизвестные пути явно перечислены. Rollback описывает, какой артефакт и какую версию возвращают.</p>\n<p>Если хотя бы одно звено отсутствует, работа может быть готова к следующему этапу, но не к утверждению безопасности выпуска. Это не бюрократическая формальность. Такая запись позволяет отличить реальный риск от неполного inventory и не потерять его при следующем обновлении.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json/\" target=\"_blank\" rel=\"noopener noreferrer\">npm Docs: package-lock.json</a> — описание lockfile как точного дерева, созданного установщиком.</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 (SBOM)</a> — официальные минимальные элементы и границы SBOM.</li><li><a href=\"https://spdx.dev/use/specifications/\" target=\"_blank\" rel=\"noopener noreferrer\">SPDX: Specifications</a> — официальная спецификация и версии формата SPDX.</li></ul>"
}