SBOM и состав выпуска

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

В «Контуре выпуска» создадим components.fixture.json и artifact-manifest.json. Это авторские документы, не вывод npm sbom и не подписанная ведомость. Все реальные установки, сборки и проверки остаются невыполненными.

Перечень относится к конкретной стадии

Начнём с трёх областей. Дерево lockfile описывает выбранное разрешение зависимостей. Установленное окружение показывает фактически присутствующие экземпляры для данной платформы и опций. Готовый артефакт содержит HTML, CSS, JavaScript, изображения и, возможно, преобразованный чужой код. Эти области связаны, но не совпадают автоматически.

Команда npm sbom поддерживает форматы SPDX и CycloneDX. При --package-lock-only она читает сведения из lockfile, не node_modules, и некоторые данные package.json зависимостей могут отсутствовать. Следовательно, такой документ не является перечнем фактически опубликованных файлов сайта. В нашей статье режим назван рядом с областью, чтобы не потерять это ограничение при передаче файла.

В components.fixture.json каждому учебному компоненту назначены имя, версия, роль и scope. У lab-render роль build, у lab-native install/build, у собственного HTML — output. Это наша модель, не полный стандартный SBOM. Поле format_status: educational_model_not_validated_sbom не позволяет принять файл за документ, соответствие которого стандарту уже проверено.

В artifact-manifest.json перечислены ожидаемые index.html и site.css. У них пока actual_digest: null, потому что сборка не выполнялась. Нельзя заполнить настоящую контрольную сумму будущего результата произвольным примером. Связь с исходной ревизией и политикой сохраняется как планируемый контракт, а фактические байты будут отдельным результатом.

Если библиотека bundler попадает в один JavaScript-файл, исходное имя пакета может не присутствовать как отдельный каталог. Для связи состава понадобится способ анализа упаковки или корректное происхождение сборки. Отсутствие node_modules на хостинге не доказывает, что зависимости не влияли на результат. Поэтому ведомость входа и манифест выхода хранятся отдельно.

Версия ведомости и будущая проверка

Каждый документ получает собственный ID, время подготовки и scope. Условное описание дерева нельзя назвать deployed только потому, что файл находится рядом с планом выпуска. В нашей модели состояние planned. После фактической сборки понадобятся идентификатор артефакта, полученные отпечатки и проверка соответствия источнику. Это новые сведения, которые не дописываются задним числом в исходный fixture.

Для исключённых зависимостей тоже важна договорённость. Опция omit может повлиять на физическое окружение, но запись остаётся в lockfile. Если ведомость сформирована только по lockfile, её нельзя читать как свидетельство наличия каждого пакета на диске. В реальной процедуре mode и filters должны сохраняться вместе с результатом команды.

Список компонентов полезен для реагирования на advisory: он помогает найти версии, которые требуют разбора. Но он не определяет автоматически достижимость ошибки. Для этого остаётся таблица из прошлого урока. Аналогично, наличие полного перечня не подтверждает права install-скриптов или безопасность исходного кода. Каждый артефакт серии отвечает на свой вопрос.

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

При передаче ведомости укажите, какой вопрос она позволяет решить. Для обновления пакета важен выбранный version. Для проверки размещения — фактический output. Для поиска источника — связь артефакта с ревизией и стадией. Один документ может содержать несколько сведений, но их происхождение всё равно следует назвать. Это препятствует ложному выводу, будто любое упоминание компонента является доказательством его исполнения в браузере.

В собственной лаборатории вы можете начать с двух простых файлов, как здесь. Не требуется создавать фиктивные UUID аттестации или копировать большие примеры стандарта ради внешнего вида. Небольшой честный договор с обозначенным scope полезнее документа, который выглядит официальным, но не был сформирован и проверен соответствующим инструментом.

Документ	Область доказательства
lock-tree fixture	Учебная модель выбранных компонентов и отношений, которую нельзя использовать как настоящий npm lockfile.
components fixture	Авторская карта ролей и областей, не проверенный документ стандарта SPDX либо CycloneDX.
artifact manifest	Ожидаемые файлы результата без полученных отпечатков, потому что фактическая сборка не выполнялась.
Реальный SBOM позже	Должен иметь режим, источник, фильтры и связь с конкретным полученным артефактом или окружением.

Сопоставление входа и выхода

В components fixture найдите lab-render, затем откройте манифест ожидаемого HTML. Между ними описан путь влияния, но нет фактической сборки. Поэтому поле связи имеет planned. Если бы мы объявили это доказанным составом публикации, документ перестал бы соответствовать выполненной работе. В этой лаборатории исходники готовы, а результат исполнения честно отсутствует.

Для собственного проекта выберите, кому нужен перечень. Сопровождающий зависимости ищет выбранную версию, владелец хостинга — файлы размещения, расследующий инцидент — происхождение артефакта. Один общий документ может объединять эти сведения лишь с подписью их разных источников. Без области фраза «все компоненты перечислены» остаётся неопределённой.

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

Для статического сайта особенно важно различить сборочные инструменты и публичные байты. Перечень lockfile может быть большим, а выход состоять из двух файлов; это не противоречие. Но маленький выход не доказывает отсутствия влияния чужого кода. Путь преобразования нужно сохранять в записи выпуска. Именно такая связь помогает обновлять библиотеку и расследовать неожиданное изменение страницы.

При будущем формировании настоящего документа сохраните команду, опции и версию инструмента рядом с файлом. Тогда другой человек сможет понять выбранный режим и повторить допустимую операцию. В этой подготовке команда приведена лишь как пример интерфейса и не исполнялась, поэтому соответствующие поля имеют status not_run.

# Пример будущей команды в собственном настоящем проекте; здесь не запускалась.
npm sbom --sbom-format=cyclonedx --package-lock-only

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

{
  "fictional": true,
  "format_status": "educational_model_not_validated_sbom",
  "scope": "planned_dependency_roles",
  "components": [
    {
      "name": "contour-release",
      "version": "1.0.0",
      "stages": [
        "build"
      ]
    },
    {
      "name": "lab-render",
      "version": "1.4.2",
      "stages": [
        "build"
      ]
    },
    {
      "name": "lab-parser",
      "version": "0.8.0",
      "stages": [
        "build"
      ]
    },
    {
      "name": "lab-native",
      "version": "1.2.3",
      "stages": [
        "install",
        "build"
      ]
    }
  ],
  "generated_by_npm_sbom": false
}

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

Первичные источники: sbom, lockfile.