Swift 6.4 SwiftPM: как подключить SBOM к macOS CI? 2026

В официальном объявлении указано, что Swift 6.4 вышел 15 сентября 2026 года и включает генерацию SBOM в SwiftPM (объявление о выпуске Swift 6.4). Если нужен список компонентов, связанный с фактическим процессом сборки, сначала проверьте генерацию через команду сборки и сохраняйте SBOM вместе с артефактами macOS CI. Для описания только графа зависимостей пакета подходит отдельная команда SwiftPM. SBOM перечисляет компоненты, но сам по себе не сканирует уязвимости и не доказывает соответствие требованиям.

Кому пригодится: сопровождающим Swift-пакеты, которым нужно публиковать сведения о зависимостях; инженерам Apple-платформенной CI, отвечающим за сборки и хранение артефактов; специалистам по безопасности и выпуску, которым нужно проверять область и формат SBOM.

Последняя проверка: 26 октября 2026 года. Даты выпусков, команды и различия в графах сверены с объявлением Swift 6.4.1 и предложением SE-0509. Перед внедрением повторно проверьте справку именно установленного инструментария.

Контрольная точка: чему должен соответствовать SBOM

До настройки CI решите, на какой вопрос должен отвечать итоговый файл. «Список зависимостей пакета», «компоненты продукта» и «состав, использованный при сборке» — не всегда одно и то же. Выбор влияет на команду генерации, содержание SBOM и пригодность результата для аудита конкретной поставки.

В SwiftPM 6.4 поддерживаются форматы SPDX и CycloneDX. Оба представляют сведения о компонентах, но сам факт создания файла не означает, что его данные полны для выбранной цели. Предложение SE-0509 различает граф зависимостей пакета и граф, полученный в контексте SwiftBuild-команды.

Требуемый ответ	Ориентир для генерации	Что проверить до публикации
Какие зависимости объявлены в пакете?	Граф зависимостей пакета и отдельная команда SwiftPM	Попали ли в список нужные продукты и транзитивные зависимости
Какие компоненты связаны с продуктом?	Выбор продукта, если соответствующий режим поддерживается командой	Совпадает ли охват с продуктом, который команда выпускает
Какие зависимости были учтены при сборке?	Генерация SBOM в контексте `swift build`	Совпадают ли конфигурация сборки и фактически разрешённый граф
Нужен формат для передачи другому инструменту?	SPDX или CycloneDX согласно требованиям получателя	Принимает ли принимающая сторона именно выбранный вариант формата

Если политика организации называет обязательный формат, используйте её, а не выбирайте формат по привычке. Для общего описания спецификаций доступны официальные материалы SPDX и CycloneDX. Это стандарты обмена сведениями о компонентах, а не заключение о безопасности проекта.

Подготовка CI и рабочей копии

Первая задача — гарантировать, что SBOM и сборка относятся к одной и той же ревизии проекта и одному состоянию зависимостей. Если CI обновляет зависимости между этапами или запускает генерацию из другого каталога, файл может быть корректно сформирован, но не соответствовать тому, что было собрано и доставлено.

Версия Swift здесь существенна: в ветке Swift 6.4 после первоначального выпуска появилась версия 6.4.1. Зафиксируйте в логах фактически используемый toolchain, а не только значение, указанное в настройках проекта. Инструкции по установке и доступным toolchain для macOS приведены в официальной документации Swift.

Проверка перед генерацией	Действие в macOS CI	Почему это важно
Версия инструментария	Записать вывод `swift --version` в лог задачи	Позволяет выяснить, каким SwiftPM был создан SBOM
Рабочий каталог	Перейти в корень пакета с нужным `Package.swift`	Исключает генерацию списка для другого пакета или подпроекта
Состояние зависимостей	Сохранить файл разрешения зависимостей, если проект его использует	Помогает связать результат с набором выбранных версий
Ревизия исходников	Записать идентификатор ревизии, переданный CI	Позволяет отличить артефакты разных запусков
Команды и результаты	Сохранить команды, код завершения и путь к SBOM в логах	Упрощает повторную проверку сбоя или спорного результата

Не подменяйте проверку версии догадкой, основанной на образе CI. Сначала получите фактический вывод swift --version, затем сравните его с требованиями проекта и справкой SwiftPM. Если установленная версия не предоставляет нужную SBOM-команду или флаг, остановитесь и выберите поддерживаемый toolchain: обходной вызов неизвестного параметра не создаст проверяемый результат.

Для осмотра доступных параметров подойдут встроенные команды справки:

swift --version
swift build --help
swift package generate-sbom --help

Ориентируйтесь на справку той версии, которая будет выполнять задачу, а синтаксис сверяйте с документацией SwiftPM и предложением SE-0509. Не переносите параметры из примера в pipeline, пока не убедились, что установленная команда их принимает.

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

Выбор генератора в SwiftPM

Чем отличаются генерация через сборку и отдельная команда?

Вызов генератора отдельно удобен, когда нужен SBOM на основе графа зависимостей пакета, например для проверки или публикации описания самого пакета. Генерация внутри swift build привязывает получение SBOM к контексту сборки и её графу зависимостей. Именно поэтому для поставляемого бинарного продукта разумно сначала оценить сборочный вариант, а затем убедиться, что он отражает нужный продукт и настройки.

Способ	Граф, на который следует ориентироваться	Когда рассматривать	Основной риск неверной интерпретации
`swift package generate-sbom`	Граф зависимостей пакета	Нужен перечень зависимостей пакета вне конкретного шага сборки	Принять пакетный граф за точное описание фактически собранного продукта
SBOM, созданный при `swift build`	Граф SwiftBuild в контексте команды сборки	SBOM должен сопровождать сборку, которую выпускает CI	Не учесть, что выбранные параметры сборки влияют на релевантный состав
Список, подготовленный внешним сканером	Зависит от входных данных сканера	Требуется дополнительный анализ или проверка политики	Считать внешний результат эквивалентом SBOM SwiftPM без проверки происхождения

Названия и значения параметров следует брать из --help установленного SwiftPM. Формы ниже показывают, где находится различие, но перед использованием замените заполнители на варианты, перечисленные в локальной справке:

swift build --sbom-format <значение-формата-из-справки>
swift package generate-sbom --format <значение-формата-из-справки>

Не предполагайте, что любой допустимый формат будет доступен с любой комбинацией дополнительных флагов. Проверьте поддерживаемые значения формата, область продукта и возможность задать путь вывода. Точные варианты и поведение должны соответствовать SE-0509 и справке соответствующей версии SwiftPM.

Как сформировать SPDX или CycloneDX в Swift 6.4?

Сначала определите формат, который ожидает потребитель SBOM. Если требования не задают его заранее, создайте пробный файл обоих поддерживаемых типов в тестовом запуске и сравните структуру и потребительские требования. Названия «SPDX» и «CycloneDX» не означают, что любой инструмент автоматически примет все варианты сериализации или все поля.

В выбранной команде укажите формат, который перечислен в локальной справке. Затем выполните генерацию на том же commit и при том же наборе зависимостей, что и сборку. Если команда позволяет явно задать продукт, формат вывода или путь файла, передавайте эти параметры явно: так проще обнаружить ошибку, чем полагаться на значение по умолчанию. Если нужной опции нет в справке, не имитируйте её другим флагом — зафиксируйте ограничение и используйте поддерживаемый способ.

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

Включение генерации в этап macOS CI

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

Практический порядок для конвейера:

Загрузите исходный код нужной ревизии и установите предусмотренный проектом Swift toolchain.
Перейдите в корень пакета и проверьте версию Swift в логах задачи.
Выполните сборку с нужными параметрами. Если SBOM должен быть связан с графом этой сборки, используйте поддерживаемый сборочный вариант генерации.
Если требуется пакетный граф, отдельно запустите swift package generate-sbom с форматом и параметрами, доступными в установленной версии.
Проверьте код завершения, наличие файла и его формат. Не считайте отсутствие явной ошибки доказательством наличия пригодного SBOM.
Сохраните файл, лог, файл разрешения зависимостей и идентификатор ревизии как связанные результаты одного запуска.
Загрузите артефакты в принятую в организации систему хранения с теми же правилами доступа и сроком хранения, что действуют для соответствующей сборки.

Решение в pipeline	Допустимый вариант	Критерий выбора
Генерация завершилась ошибкой	Прервать доставку либо пометить запуск как неуспешный для SBOM	Зависит от того, является ли SBOM обязательным условием выпуска
SBOM создаётся успешно, но проверка содержимого не пройдена	Не публиковать артефакт до выяснения области и графа	Файл может быть синтаксически корректным, но описывать не тот объект
Используется отдельная генерация по пакету	Сохранить её как отдельный результат, не смешивая с SBOM сборки	У разных файлов различается смысловой охват
Публикуется несколько форматов	Сопоставить каждый файл с одним исходным запуском	Исключает потерю связи между результатом и ревизией

Предложение SE-0509 описывает поведение генерации и реакцию на ошибку; проверяйте это для выбранного режима, прежде чем решать, должен ли pipeline блокировать доставку. Само решение — организационное: для обязательного контрольного документа сбой может запрещать выпуск, а для вспомогательного инвентарного файла команда может отдельно фиксировать ошибку и продолжать сборку. Главное — не скрывать пропуск SBOM за статусом успешной сборки.

Если требуется проверить саму организацию артефактов и доступ к удалённой macOS-среде, пригодится руководство по подключению к удалённому Mac. Настройка доступа не заменяет проверку того, что генератор и сборка использовали один и тот же граф зависимостей.

Проверка охвата и условных зависимостей

Условная зависимость может появляться в разных конфигурациях по-разному. Граф пакета и граф SwiftBuild не обязаны совпадать: первый отражает сведения пакета и его зависимости, второй связан с контекстом сборки. Поэтому на вопрос о включении условных зависимостей нельзя отвечать одним общим «да» или «нет» без уточнения выбранной команды, условий и конфигурации.

Содержит ли SBOM SwiftPM условные зависимости?

Проверьте результат на проекте и конфигурации, для которых он предназначен. Сопоставьте список компонентов с разрешённым графом зависимостей, а затем повторите проверку для значимых условий сборки, если проект выбирает зависимости в зависимости от платформы или конфигурации. Одного SBOM недостаточно, чтобы доказать присутствие всех возможных вариантов: файл описывает результат конкретного способа генерации, а не обязательно все комбинации проекта.

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

Проверку проводите по пунктам:

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

Если результат требуется для аудита, заранее уточните критерии у принимающей стороны: допустимый формат, обязательные поля, требуемый охват и способ подтверждения происхождения. SBOM не гарантирует отсутствие уязвимостей, не устанавливает автоматически соблюдение лицензий и не является универсальным доказательством соответствия требованиям. Для таких выводов нужны отдельные процедуры анализа, а также оценка того, какие данные и правила применяются.

В описании продукта SwiftPM используйте официальную документацию PackageDescription, а за деталями SwiftBuild — документацию SwiftPM по SwiftBuild. Эти источники помогают разбираться в моделях пакета и сборки, но проверку реального содержимого CI-артефакта они за команду проекта не выполняют.

Приёмка результата перед выпуском

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

[ ] В логах указан реально использованный Swift toolchain.
[ ] Генерация выполнена из корня ожидаемого пакета.
[ ] Выбранный способ соответствует требуемой области: пакет, продукт или сборка.
[ ] Формат подтверждён справкой установленного SwiftPM и требованиями получателя.
[ ] Файл существует, читается и описывает ожидаемый пакет или продукт.
[ ] Условные зависимости проверены с учётом применимой конфигурации.
[ ] SBOM, логи и состояние зависимостей связаны с одной ревизией и одним запуском.
[ ] Правило реакции CI на отсутствие или ошибку SBOM определено до выпуска.
[ ] Документация передачи не обещает отсутствия уязвимостей или автоматического соответствия требованиям.

Для повторяемой работы заведите отдельное описание этапа SBOM в документации проекта: укажите команду, версию toolchain, формат и путь к сохранённому результату. Если обновление Swift меняет доступные параметры или поведение, повторите пробную генерацию и сравните охват до того, как включать новый toolchain в обязательный выпускной pipeline.

Когда SBOM уже генерируется и сохраняется вместе с macOS-сборкой, остаётся выбрать подходящую среду исполнения. Linux-узел не заменит macOS для этапов, которым нужны Apple-инструменты, а локальный Mac не всегда удобен как постоянно доступный общий runner: он требует физического устройства и его обслуживания, а CI зависит от состояния конкретной машины. При нерегулярных тестах или временном расширении сборочной мощности аренда удалённого Mac может быть практичнее покупки отдельного оборудования; для постоянной тяжёлой нагрузки и задач с обязательными физическими интерфейсами собственное устройство может оказаться оправданнее. Условия и доступность удалённой среды можно оценить на странице NowMini, а затем проверить, подходит ли такой вариант под график сборок и требования к хранению артефактов.