{
  "index": 171,
  "slug": "editorial-2023-04-practice-dependency-security",
  "title": "Advisory зависимости: как доказать, что сигнал относится к вашему выпуску",
  "excerpt": "Совпадение package и версии с advisory ещё не доказывает риск в приложении. Разбираем lockfile, SBOM, достижимость, обновление и критерий готовности без выдуманных production-выводов.",
  "contentHtml": "<p>Сканер сообщает: пакет совпал с advisory. Команда видит имя и версию, ставит задачу «срочно обновить» и меняет dependency. Через час lockfile разрастается, сборка падает, а никто не может ответить на главный вопрос: этот пакет попал в поставленный артефакт и был ли достижим уязвимый код? Цена ошибки двойная. Ложная тревога задерживает релиз и создаёт шум. Непроверенный сигнал оставляет настоящий риск без владельца.</p>\n<p>Тезис простой: advisory — это вход для расследования, а не вердикт о приложении. Сначала разделите четыре факта: внешний advisory, точную запись в lockfile, компонент в SBOM и путь от entry point до нужного кода. Потом проверяйте обновление отдельными gates. Пока связь между этими фактами не доказана, корректный статус — «требует проверки», а не «безопасно» и не «уязвимо в production».</p>\n<h2>Что именно фиксирует каждый артефакт</h2>\n<p>Advisory сообщает, какие имена и диапазоны версий описывает источник. Он не знает конфигурацию вашего сервиса. Manifest показывает намерение автора: прямую зависимость и допустимый range. Lockfile показывает дерево, которое resolver выбрал для конкретного состояния проекта. Это важный снимок, но не журнал уже запущенного процесса.</p>\n<p>SBOM описывает компоненты и связи выбранного артефакта. Он отвечает на вопрос «что заявлено в этом build», если документ действительно связан с commit и digest. Runtime evidence отвечает на другой вопрос: что загрузил конкретный процесс. Эти слои можно сопоставить, но нельзя заменить один другим. Наличие строки в lockfile не доказывает наличие строки в образе. Наличие компонента в SBOM не доказывает вызов уязвимой функции.</p>\n<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>Advisory совпал с package@version</td><td>Внешний сигнал приняли за факт о сервисе</td><td>Сохранить URL, дату, диапазон и источник</td><td>Открыть triage, не объявляя production-уязвимость</td></tr><tr><td>Пакет есть в lockfile</td><td>Resolved tree смешали с deployed artifact</td><td>Найти путь в дереве и сверить build identity</td><td>Проверить SBOM того же артефакта</td></tr><tr><td>Пакет есть в SBOM</td><td>Inventory приняли за runtime trace</td><td>Сверить компонент с образом и режимом запуска</td><td>Проверить импорт или загрузку в нужной конфигурации</td></tr><tr><td>Прямого импорта нет</td><td>Забыли транзитивный, optional или dynamic path</td><td>Проверить graph, plugin registration и feature flag</td><td>Описать достижимость как гипотезу с методом проверки</td></tr><tr><td>После update изменилось много записей</td><td>Resolver пересобрал дерево, а scope не зафиксировали</td><td>Разобрать lockfile diff и peer/optional branches</td><td>Сузить изменение или отдельно подтвердить совместимость</td></tr></tbody></table>\n<h2>Минимальная цепочка доказательств</h2>\n<p>Начните с exact package и version. Запишите commit, в котором возник сигнал, и место записи в lockfile. Если пакет транзитивный, сохраните parent path: без него невозможно понять, какая прямая зависимость привела компонент в дерево. Затем найдите SBOM, созданный для candidate build. У него должен быть устойчивый идентификатор: commit, image digest или иной идентификатор артефакта. Файл с названием <code>sbom.json</code> без такой связи — только неподтверждённый документ.</p>\n<p>После этого сформулируйте путь достижимости. Не пишите «пакет используется». Пишите: «entry point A при конфигурации B импортирует модуль C, который вызывает ветку D». Для статического графа это возможная связь. Для теста — путь выбранного сценария. Для trace — наблюдение одного запуска. У каждого метода есть границы. Ни один метод сам по себе не перечисляет все платформы, флаги и входы.</p>\n<pre><code>advisory URL\n  -&gt; package@version\n  -&gt; lockfile path\n  -&gt; SBOM component + artifact digest\n  -&gt; entry point + configuration\n  -&gt; reachability evidence\n  -&gt; decision with owner</code></pre>\n<p>Если звено отсутствует, обозначьте его как unknown. Не заполняйте пробел догадкой. Такой формат помогает review: следующий человек видит не только вывод, но и место, где доказательство заканчивается.</p>\n<h2>Учебный пример: совпадение строк не равно уязвимости</h2>\n<p>Ниже приведён ограниченный учебный пример. Имена <code>demo-service</code>, <code>demo-parser</code> и <code>SYNTHETIC-ADVISORY-001</code> вымышлены. Они не взяты из registry, scanner, lockfile, SBOM или production trace. Код только сравнивает заранее заданные значения в памяти. Он не устанавливает пакет, не строит image и не запускает приложение.</p>\n<pre><code>const input = {\n  advisory: { id: 'SYNTHETIC-ADVISORY-001', package: 'demo-parser', version: '1.0.0' },\n  lockfile: [{ package: 'demo-parser', version: '1.0.0' }],\n  sbom: [{ package: 'demo-parser', version: '1.0.0' }],\n  entryPoint: 'demo-http-handler',\n  path: 'demo-http-handler -&gt; demo-shell -&gt; demo-parser'\n};\n\nconst listedInLockfile = input.lockfile.some((x) =&gt;\n  x.package === input.advisory.package &amp;&amp; x.version === input.advisory.version\n);\nconst listedInSbom = input.sbom.some((x) =&gt;\n  x.package === input.advisory.package &amp;&amp; x.version === input.advisory.version\n);\n\nconsole.log({ listedInLockfile, listedInSbom,\n  reachability: 'not-assessed-by-example',\n  vulnerability: 'not-determined-by-example'\n});</code></pre>\n<p>Даже если обе проверки вернут <code>true</code>, пример доказывает только совпадение полей в двух массивах. Он не доказывает, что <code>demo-parser</code> попал в образ, был загружен процессом или достиг уязвимой функции. Отрицательный путь важнее положительного: отсутствие записи в lockfile не доказывает отсутствие компонента в другом build, а наличие записи не доказывает runtime-достижимость. Учебный PASS нельзя прикладывать к production ticket как результат сканирования.</p>\n<figure><img src=\"/assets/editorial/2023/dependency-security-2023-advisory-triage.svg\" alt=\"Схема разбора advisory через lockfile, SBOM и проверку достижимости\" loading=\"lazy\" /><figcaption>Схема разделяет внешний advisory, инвентарь компонентов и гипотезу достижимости. Иллюстрация не содержит данных production и не заменяет evidence проекта.</figcaption></figure>\n<h2>Порядок проверки</h2>\n<ol><li><strong>Зафиксируйте сигнал.</strong> Сохраните advisory URL или идентификатор базы, дату, package, точную версию и затронутый диапазон. Не переписывайте формулировку источника в более сильный вывод.</li><li><strong>Найдите baseline.</strong> Назовите commit и lockfile, которые относятся к проверяемому build. Для транзитивного пакета сохраните полный путь от direct dependency.</li><li><strong>Сверьте инвентарь.</strong> Найдите SBOM candidate artifact и проверьте его provenance: commit, digest, формат и генератор. Если связь с артефактом не доказана, статус SBOM — «не подтверждён».</li><li><strong>Опишите путь.</strong> Укажите entry point, режим, feature flag, dynamic import или plugin registration. Для каждого утверждения назовите метод: граф, тест, trace или ручная проверка.</li><li><strong>Проверьте отрицательную ветку.</strong> Убедитесь, что пакет не только отсутствует в прямом импорте, но и не приходит через другой parent, optional dependency, build-time branch или старый образ.</li><li><strong>Сформируйте candidate update.</strong> Запишите from/to version, ожидаемый lockfile diff, peer dependencies, optional branches, lifecycle scripts и rollback на baseline.</li><li><strong>Пройдите gates.</strong> Выполните чистую установку по lockfile, targeted tests и контролируемый runtime smoke в названном окружении. Сохраните ссылки на результаты каждого gate.</li><li><strong>Примите решение.</strong> Закройте задачу только с доказанными границами: исправлено и проверено, не найдено в конкретном артефакте или требует дополнительного project review.</li></ol>\n<h2>Почему быстрое обновление часто не является исправлением</h2>\n<p>Изменение одной строки в manifest может перестроить транзитивное дерево. Меняются peer dependencies, optional packages, integrity, module format и lifecycle scripts. Поэтому смотрите не только на целевую версию, но и на весь lockfile diff. Если diff неожиданно широк, сначала объясните каждое изменение. Большой diff не делает update неправильным, но увеличивает объём доказательств.</p>\n<p>Команда чистой установки проверяет install contract для конкретного lockfile. Она не доказывает старт сервиса, работу native addon, browser bundle или вызов нужной функции. Тест проверяет выбранные сценарии. Smoke показывает поведение названного окружения. Только вместе эти результаты дают основание принять выпуск. Если smoke выполнить нельзя, это ограничение процесса, а не доказательство совместимости.</p>\n<h2>Ограничения</h2>\n<p>Описанная схема не вычисляет exploitability и не заменяет security research. Она не знает private registry, ОС-зависимости, контейнерные слои, generated code, runtime flags и все возможные входы. SBOM может быть неполным. Статический граф может включать недостижимую ветку. Trace может пропустить редкий сценарий. Поэтому вывод всегда должен содержать scope: какой commit, build, режим и метод проверены.</p>\n<p>Не закрывайте alert фразой «пакет не импортируется напрямую». Не закрывайте его и фразой «версия обновлена». В первом случае остаются транзитивные и динамические пути. Во втором остаются новый graph, совместимость и факт выпуска. Если доказательств не хватает, оставьте владельца и следующий проверяемый шаг.</p>\n<h2>Критерий готовности</h2>\n<p>Разбор готов, когда другой инженер без устного контекста может восстановить цепочку: advisory → exact package@version → lockfile path → SBOM и immutable artifact → entry point/configuration → evidence достижимости → результаты install, tests и smoke → решение и rollback. Каждый результат имеет ссылку или явно отмечен как unknown. Ни один учебный PASS не выдан за production-факт. Если хотя бы одно звено не подтверждено, задача не закрыта как безопасная: она остаётся ограниченным расследованием с назначенным владельцем.</p>\n<h2>Проверяемые источники</h2>\n<ul><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><li><a href=\"https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json/\" target=\"_blank\" rel=\"noopener noreferrer\">npm Docs: package-lock.json</a> — официальное описание lockfile как точного дерева зависимостей, созданного установщиком.</li><li><a href=\"https://doi.org/10.6028/NIST.SP.800-218\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-218, Secure Software Development Framework</a> — официальный документ о практиках безопасной разработки и управлении рисками компонентов.</li></ul>"
}