Elysia Tools
Навигация
Workflow Playbook
Зафиксируйте состав выпуска Node.js, проверьте внешнюю SBOM по утверждённой политике лицензий и передайте изменения, исключения и подтверждения решения.
Темы
Этот процесс предназначен для сопровождающих Node.js, которым нужен проверяемый комплект перед конкретной публикацией. Соберите точный артефакт, ревизию исходников, package.json, файл блокировки и внешнюю SBOM. Запишите генератор, настройки и включение зависимостей разработки. Рассчитайте хеш каждого оригинала и укажите сборку, которую он представляет. Блокировка описывает разрешение зависимостей; упаковка, исключение файлов, необязательные и платформенные пакеты могут менять поставку. Отсутствующую связь с артефактом нельзя исправить зелёным отчётом.
До загрузки частных имён пакетов или внутренних адресов проверьте разрешение. Не передавайте токены реестра. Очищенные рабочие копии храните отдельно, с собственными хешами и контролируемым соответствием оригиналам. Процесс не устанавливает пакеты, не создаёт SBOM, не исследует итоговый архив и не сканирует уязвимости.
Аудитор проверяет package.json и при необходимости строит дерево из npm package-lock.json или Yarn v1 yarn.lock. Для блокировок pnpm и Bun нужен внешний анализатор. Преобразование ради формы ввода не доказывает равное покрытие. Без пригодной блокировки выводы относятся только к декларациям. Сохраните источник дерева, ограничение глубины и предупреждения: пустой результат после ошибки разбора не означает отсутствие зависимостей.
Например, ^2.4.0 — объявленный диапазон, а 2.4.3 — конкретная разрешённая версия. Проверяйте через SemVer вторую запись, отдельно документируя ссылки Git, рабочие пространства и теги. Для JSON предоставьте соответствующую схему с поддерживаемым диалектом. Корректная структура не подтверждает полноту состава или достоверность лицензий. Аудитор политики принимает SPDX 2.3 JSON и CycloneDX 1.5 JSON/XML. Шаги проверки схемы и сравнения JSON не проверяют XML; сохраните его оригинал и используйте подходящие внешние проверки.
Запишите фактические настройки профиля, допустимость copyleft, списки разрешений и запретов, обработку неизвестных лицензий. Одного имени профиля недостаточно при смене версии. Сохраните Markdown или SARIF. Если нужны оба формата, выполните отдельные запуски с одинаковыми данными и настройками. Храните полное выражение лицензии, включая AND, OR и WITH, и организуйте проверку текстов и обязанностей. Нельзя подменять всё выражение удобным разрешительным фрагментом.
Разберите каждый отмеченный компонент и доступный путь зависимости. Отсутствие пути может означать неполные связи в SBOM, а не изолированность компонента. Сравните JSON с утверждённой базой и вручную сверьте идентичность, версию и выражение. Порядок массивов, сгенерированные идентификаторы и время создают шум; сравнение JSON не выполняет семантическое сопоставление пакетов. Объясните добавления, удаления и неожиданные изменения лицензий. Исключению нужны ответственный, обоснование, затронутый выпуск, область и срок, а не тихое расширение разрешительного списка.
Ведите отдельный журнал Markdown: идентификатор выпуска, хеши артефакта и SBOM, ревизия политики, компонент, версия, точное выражение, путь либо его отсутствие, доказательство, решение и ответственный. Это рекомендуемые поля ручной проверки, а не обещание автоматического заполнения отчётом. Недоказанные пункты остаются ожидающими или блокирующими. При изменении входных данных или политики повторите затронутые проверки, сохранив прежние отчёты.
Проверка Markdown улучшает читаемость, но не юридическую достоверность. В необязательном PDF проверьте таблицы, предупреждения, длинные идентификаторы и пути на обрезку. Сохраните полный источник и машиночитаемые отчёты независимо от качества визуальной копии. Архивируйте локальные файлы с итоговыми хешами: временная ссылка не заменяет архив. SARIF сам не настраивает блокировку CI. Вопросы Dockerfile и окружения относятся к процессу контейнерного выпуска, более широкие сравнения — к процессу различий, а подтверждение авторства вместо простого совпадения байтов — к проверке подписей.
Руководство по рабочему процессу
Запишите хеши, ревизию исходников и настройки генератора SBOM. Отделите декларации package.json от действительно поставляемых пакетов.
Проверьте манифест и поддерживаемую блокировку, конкретные разрешённые версии и JSON по его схеме. Сохраните предупреждения и пробелы покрытия.
Обработайте внешнюю SBOM с записанными настройками. Сохраните Markdown или SARIF, проверьте неизвестные лицензии, полные выражения и отсутствующие пути.
Сравните текущие и утверждённые JSON, затем сопоставьте компоненты вручную с учётом шума массивов. Повторите после исправлений; укажите владельца, область и срок исключений.
Необязательное дерево поддерживает npm package-lock.json и Yarn v1 yarn.lock. Для pnpm или Bun нужен внешний анализатор и запись о границах покрытия; пустое дерево после ошибки не доказывает отсутствие зависимостей.
Проверяйте JSON по предоставленной совместимой схеме и сравнивайте JSON-файлы. Аудитор принимает поддерживаемый CycloneDX XML, но проверка схемы и сравнение XML требуют другого пути, а не предположения о преобразовании без потерь.
Неизвестные лицензии, отсутствующие источники и нарушения остаются открытыми до решения указанного проверяющего или ограниченного исключения. Автоматический успех не означает юридическое соответствие или отсутствие уязвимостей.
Проверьте Markdown и при необходимости PDF, особенно таблицы и длинные пути. Рассчитайте итоговые хеши и сохраните отчёты, предупреждения и решение.