Как подключить SBOM Swift 6.4 к корпоративному CI? Руководство по приёмке 2026

В CI появился SBOM, но служба безопасности не может установить, к какому приложению и сборке он относится.

Быстрое решение: сначала проверьте генерацию в изолированном конвейере. Предпочтительно создавать SBOM во время сборки и архивировать вместе с артефактом. Если документ создаётся отдельной командой после сборки, дополнительно подтвердите, что граф зависимостей не изменился. Разрешайте продвижение только после проверки успешной генерации, содержимого и связи с артефактом. Swift 6.4 добавил SwiftPM генерацию SBOM в форматах SPDX и CycloneDX — это подтверждает официальное сообщение о выпуске Swift 6.4.

Материал адресован специалистам по безопасности и соответствию требованиям, которым нужно включить перечень компонентов в доказательства поставки.
Руководителям CI-платформы, подключающим SBOM Swift 6.4 к существующим macOS-конвейерам.
Техническим руководителям iOS и macOS, которым нужно проверить, соответствует ли перечень пакетов фактически собранному продукту.

Последняя проверка документации: 7 октября 2026 года. Дата выпуска и сведения о форматах сверены с объявлением Swift 6.4 и описанием реализации SE-0509.

[ SECTION_01 ] Этап подготовки. Уточните, что именно должна доказывать SBOM

SBOM — это машинно-читаемый перечень компонентов в определённом контексте. Сам факт создания файла не доказывает полноту состава приложения, безопасность каждой зависимости или соответствие перечня выпущенному бинарному файлу. До настройки CI зафиксируйте, к какому объекту относится документ: пакету SwiftPM, продукту проекта или конкретной сборке.

Сначала согласуйте три решения:

• Формат документа. Выберите SPDX, CycloneDX или оба формата, если этого требуют разные внутренние процессы. Поддержку обоих форматов в SwiftPM для Swift 6.4 подтверждает официальный материал о выпуске. Это подтверждение функции, а не гарантия, что конкретная политика компании принимает любой из форматов.
• Объект описания. Определите, требуется ли перечень для одного пакета или для продукта, который команда собирает и публикует. Не называйте SBOM проекта полным перечнем приложения, пока не проверены все источники зависимостей и выпускаемые артефакты.
• Связь с выпуском. Установите, какие идентификаторы связывают документ с исходным состоянием и результатом: ревизия исходного кода, запись CI, входные параметры сборки и ссылка на артефакт.

Различайте перечень зависимостей, граф, использованный сборочной задачей, и прослеживаемость опубликованного результата. Эти понятия связаны, но не взаимозаменяемы. SBOM, созданная по известному SwiftPM графу, может быть полезна для проверки пакетов, однако сама по себе не подтверждает, что весь состав приложения учтён или что каждый компонент попал в конечный продукт.

Границы особенно важны, если приложение использует бинарные зависимости, компоненты вне SwiftPM, вспомогательные инструменты сборки или несколько видов поставляемых файлов. Инвентаризируйте такие элементы отдельно. Документация SwiftPM о структуре пакетов помогает определить сущности, которые следует сопоставить с внутренней моделью поставки. Но она не устанавливает охват конкретного конвейера: его подтверждают журналы и результаты вашей сборки.

Распределите ответственность до пилота:

• команда приложения подтверждает ожидаемые пакеты, продукты и правила фиксации Package.resolved;
• команда CI-платформы отвечает за инструментальную цепочку, условия запуска, хранение файлов и реакцию на сбой;
• команда безопасности утверждает формат, необходимые сведения, допустимые исключения и свидетельства, требуемые перед выпуском.

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

[ SECTION_02 ] Этап инвентаризации. Зафиксируйте проект, зависимости и границы продукта

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

Укажите в карточке:

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

Сверьте фактическое использование SwiftPM с декларациями проекта. Документация Swift PackageDescription описывает структуру, применяемую для объявления пакетов и целей. Материал SwiftPM о подключении зависимостей помогает разобраться, откуда зависимости попадают в граф. Эти документы объясняют модель, но не доказывают, что конкретный запуск CI получил ожидаемый граф. Это нужно проверять на своей сборке.

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

Перед переходом дальше зафиксируйте исключения. Например: «учитывается SwiftPM», «требует отдельной инвентаризации», «не входит в эту поставку». Такая запись позволяет службе безопасности оценивать покрытие с понятными ограничениями, а не трактовать отсутствие компонента в документе как доказательство его отсутствия в продукте.

[ SECTION_03 ] Этап выбора. Сопоставьте генерацию при сборке и отдельную команду

SwiftPM поддерживает два сценария, которые нельзя считать одним и тем же: создание SBOM в ходе сборочного процесса и отдельную генерацию по сведениям о пакете. В описании реализации SE-0509 приведена команда swift package generate-sbom и описана поддержка генерации при сборке. Конкретные параметры и значения формата следует сверять со справкой установленной версии инструментария и самим документом.

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

Отдельная команда swift package generate-sbom удобна для диагностики или процесса, которому нужно создать перечень отдельно от основного шага сборки. Однако самостоятельный запуск описывает доступный ему граф пакетов и не гарантирует, что именно этот граф применялся при создании бинарного результата. Чтобы использовать такой документ как доказательство сборки, подтвердите совпадение входных данных и состояния разрешения зависимостей.

Сравнивайте способы не по удобству запуска, а по назначению:

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

Инструмент решения: выберите путь генерации по условиям проекта

Пройдите пункты по порядку. Отмечайте условие только тогда, когда его можно подтвердить журналом CI, зафиксированными входами или результатом проверки.

• [ ] Нужна SBOM именно для конкретной сборки, а установленный SwiftPM поддерживает генерацию в ходе сборочного процесса. Выберите генерацию во время сборки и архивируйте документ вместе с результатом того же задания.
• [ ] Генерация выполняется отдельной командой, но сохранены ревизия исходного кода и состояние Package.resolved. Используйте swift package generate-sbom как отдельный этап; перед приёмкой подтвердите, что граф до сборки и до генерации совпадает.
• [ ] Состояние зависимостей между сборкой и отдельной генерацией не сохранено либо изменилось. Не принимайте этот SBOM как доказательство сборки; повторите процесс с фиксированными входами или перенесите генерацию в сборочный этап.
• [ ] Продукт содержит компоненты за пределами SwiftPM. Добавьте отдельную инвентаризацию этих компонентов или явно ограничьте вывод областью SwiftPM. Не утверждайте, что документ охватывает весь продукт.
• [ ] Поведение параметра или команда в установленной версии не подтверждены. Остановите настройку и проверьте справку SwiftPM и SE-0509; не переносите аргументы из примера для другой версии без проверки.

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

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

[ SECTION_04 ] Этап пилота. Включите генерацию в изолированном задании

Не меняйте все production-сборки одновременно. Создайте отдельное задание на небоевой ветке либо изолированный этап, который использует тот же репозиторий, но не имеет права публиковать продукт. Оно должно воспроизводить нужные для выпуска действия и сохранять входные данные вместе с результатами.

Проведите проверку последовательно:

• Зафиксируйте инструментальную цепочку. Запишите версию Swift, среду выполнения и способ выбора SwiftPM. Проверьте эти сведения в журнале именно того задания, которое создало SBOM.
• Зафиксируйте состояние пакетов. Сохраните исходную ревизию и Package.resolved, если проект его использует. Не допускайте скрытого обновления зависимостей между генерацией и сборкой.
• Выберите один основной путь. На пилоте не запускайте оба способа так, будто это одно и то же доказательство. Если вы сравниваете их, назовите результаты по-разному и отдельно сопоставьте содержимое.
• Назначьте каталог результата. Убедитесь, что SBOM сохраняется как артефакт CI, а не остаётся во временном рабочем каталоге узла.
• Проверьте формат. Убедитесь, что файл соответствует выбранному формату и может быть обработан предусмотренными в компании средствами. Успешного кода завершения команды недостаточно.
• Определите реакцию на сбой. Заранее решите, остановит ли ошибка генерации выпуск, передаст ли задачу на ручную проверку или заблокирует только публикацию SBOM. Политика должна быть одинаково ясной владельцам CI и безопасности.

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

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

[ SECTION_05 ] Этап проверки. Подтвердите соответствие SBOM конкретному продукту

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

Для каждого пробного запуска сохраняйте вместе:

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

Чтобы подтвердить соответствие SBOM фактическому продукту, проверяйте ту же ревизию исходного кода и тот же запуск CI, а затем сопоставляйте граф пакетов с объявленным продуктом и сохранённым артефактом. Если файл создан после сборки, сравните состояние зависимостей непосредственно до сборки и перед генерацией. Изменение разрешённого пакета, отсутствие фиксации или отличающийся граф означают, что совпадение не подтверждено. Один и тот же репозиторий сам по себе не является доказательством неизменности состояния.

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

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

[ SECTION_06 ] Этап приёмки. Решите, можно ли распространять настройку

Перед подключением остальных репозиториев проверьте три условия. Каждое должно подтверждаться сохранёнными материалами, а не устным подтверждением:

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

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

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

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

Размещение CI тоже влияет на проверяемость. Собственные локальные Mac позволяют команде контролировать узлы и порядок действий, но требуют самостоятельно поддерживать инструментарий, хранение результатов и права доступа. Удалённую среду следует оценивать по тем же критериям: учётные записи, сетевой доступ, хранение артефактов и управление секретами. Для знакомства с вариантами размещения можно посмотреть информацию NOVAKVM, а при предварительном сравнении конкретного сценария — страницу заказа Mac mini. Эти страницы не подтверждают соответствие вашей политике безопасности; его устанавливают только требования компании и результаты пилотных заданий.

Если CI сейчас выполняется на универсальных агентах, возможны вполне конкретные ограничения: сложнее стандартизировать macOS-среду, доступность требуемого инструментария нужно проверять отдельно, а архивирование и права на результаты остаются ответственностью команды. Собственные Mac оправданы, когда узлы нужны постоянно и важен физический контроль, однако компания берёт на себя управление устройствами и их жизненным циклом. Для пилота или временного расширения macOS-пула аренда Mac от NOVAKVM может быть альтернативой для сравнения. До переноса CI подтвердите на тестовом задании доступы, сохранение SBOM, привязку к артефакту и действия при сбое — решение о среде выполнения не заменяет доказательство корректной сборки.