Swift 6.4 SwiftPM SBOM: How to Add It to macOS CI (2026)

Swift 6.4 was released on September 15, 2026, with SwiftPM support for generating SBOMs in SPDX and CycloneDX formats, according to the Swift 6.4 release notes. For a manifest tied to the dependencies used in a build, start by evaluating build-time generation and archive the result with that build. Use the standalone package command when a package dependency graph is the scope you need. Neither output is a vulnerability scan or proof of compliance.

Swift package maintainers: publish a dependency list for a package or product.
Apple platform CI engineers: add SBOM generation and artifact retention to a macOS pipeline.
Security and release leads: verify the SBOM’s format, scope, and delivery limits.

Last updated October 26, 2026; checked against the Swift 6.4 release notes, Swift 6.4.1 announcement, and SE-0509.

Swift 6.4 SwiftPM SBOM generation starts with scope

An SBOM is a structured inventory of software components. It can help a team understand what a project declares or what a build depends on. It does not, by itself, establish that a dependency is safe, that licenses have been satisfied, or that an audit requirement has been met. SPDX and CycloneDX are distinct SBOM formats with their own specifications: see the SPDX specification list and the CycloneDX specification overview.

Before adding a command to CI, decide what the file must describe:

• The package dependency graph: useful when the deliverable is a reusable Swift package and the inventory should describe package dependencies.
• A product or build context: useful when the release team needs the dependency view associated with a particular build invocation.
• The artifact delivered to users: requires a clear relationship between the SBOM, the built output, and the source revision. A package-level inventory alone may not capture every detail of an actual build.

This distinction determines the command path. SE-0509 describes a build-command path that can use the SwiftBuild dependency graph and a standalone swift package generate-sbom command that uses the package dependency graph. Those graphs can differ, so the output should not be described as “the complete dependencies” without specifying which graph it represents. Review the SE-0509 command and scope definitions before choosing flags.

The SBOM format is a separate decision from scope. Choose SPDX or CycloneDX based on the consuming tool or delivery requirement, then verify that the generated file identifies the expected format and contains the package information your downstream process needs. Do not assume a format choice changes which dependency graph the command reads.

Select the generation path for the inventory you need

SwiftPM provides two routes, but they answer different questions. Use the build command when you need to assess dependencies in the context of a build. Use the standalone command when the package dependency graph is the intended inventory. The table summarizes the distinction described in SE-0509.

The names and flags supported by the installed toolchain matter. Start with the command help for the exact runner rather than copying a flag from an article written for a different Swift release:

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

Then use the documented SBOM options shown by that toolchain to select the required format and output location. The official SwiftPM SBOM proposal and SwiftBuild command documentation are the references for the command surface and build integration. Avoid treating an option copied from one release’s help output as a stable interface until it has been checked in the target runner.

Prepare the macOS CI job before generating anything

A generated file is only useful when it can be traced back to a reproducible project state. Confirm that the CI job uses the intended Swift toolchain, starts in the package root, and resolves dependencies in the same way as the build job. Swift’s macOS toolchain installation instructions provide the official starting point for installing a Swift toolchain; record the selected version in the job log so a later review can distinguish toolchain changes from project changes.

Keep dependency resolution and build context together. For a project that commits Package.resolved, preserve the file used by the job and associate it with the SBOM. If dependencies are resolved dynamically, retain enough job context to identify the resolved versions. Otherwise, a future reviewer may see a valid SBOM but be unable to tell which source revision or dependency resolution produced it.

A useful preparation pass is to check each of these conditions:

• [ ] Confirm the installed Swift version in the CI log and verify that it includes the SwiftPM SBOM functionality described in the Swift 6.4 release notes.
• [ ] Run the project’s normal dependency-resolution and build steps from the intended working directory.
• [ ] Preserve the applicable Package.resolved file or another record of the dependency resolution used for the job.
• [ ] Choose whether the deliverable describes a package graph or a build graph.
• [ ] Select SPDX or CycloneDX based on the consumer’s requirement, and confirm the format option in the installed command’s help.
• [ ] Choose a stable output directory that the CI system can archive with the build.
• [ ] Define whether a missing or invalid SBOM blocks release, and make that decision explicit in the pipeline.

This preparation also catches a common mismatch: generating an SBOM from one checkout or resolution state, then attaching it to a binary produced by another job or revision. The artifact might parse correctly while describing the wrong build. Keep generation close to the build, or record a reliable link between the two jobs.

Wire generation and retention into the macOS CI timeline

Treat SBOM generation as a build deliverable rather than a file created manually after release. A maintainable workflow follows the same sequence each time:

Milestone: establish the build identity. Record the source revision, selected Swift toolchain, build configuration, and dependency-resolution state in the job’s normal metadata. Keep the package manifest and the applicable Package.resolved file available alongside the output. The goal is not to duplicate every CI log; it is to let a reviewer identify which project state the inventory represents.

Milestone: resolve and build. Run the project’s established dependency-resolution and build commands. If the intended scope is the build dependency graph, invoke the documented SBOM option as part of the build command. If the intended scope is the package graph, invoke swift package generate-sbom using the format and output options confirmed by the installed toolchain. Do not substitute the standalone command for the build path and then claim that it represents the exact dependency graph used by SwiftBuild.

Milestone: keep the output with the job. Direct the generated file to a known artifact directory, or copy it there after generation. Archive that directory with the build output using the CI system’s ordinary artifact mechanism. Keep the SBOM associated with the same source revision and job identity as the binary. A file saved only on a temporary runner is not retained evidence: it can disappear when that runner is removed.

Milestone: apply the release gate. SE-0509 describes SBOM generation as part of SwiftPM commands; a successful compile should not be treated as proof that a valid SBOM was produced and retained. Check the command result and verify that the expected file exists and can be parsed. If the project’s release policy requires an SBOM, make a missing or invalid file fail the release stage. If the SBOM is advisory, report the failure clearly and retain the build log, rather than silently publishing without the inventory.

The proposal and command help should be the source of truth for exact flags and failure behavior in the toolchain being used. Do not assume that a CI platform’s artifact-upload success means the SBOM content is valid. Generation, validation, and retention are separate checks.

Verify what the file contains before treating it as delivered

A first successful run is a starting point, not acceptance. Open the output with a parser that supports the selected format, and check that the document identifies the expected format and includes the package or product information required by the consuming workflow. Compare the listed dependencies with the project’s resolved dependency state and the chosen graph scope.

Pay particular attention to conditional dependencies. A package graph can describe dependencies declared by a package without necessarily matching the set that a particular platform build actually selects. Platform conditions, product selection, and build configuration can affect the build graph. Because SE-0509 distinguishes the package dependency graph from the SwiftBuild graph, an SBOM generated by one route should not be used to make an unsupported claim about the other.

For acceptance, confirm:

• The SBOM corresponds to the same source revision and dependency resolution as the build artifact.
• The selected command represents the intended package or build scope.
• The output is in the requested SPDX or CycloneDX format and can be parsed by the intended consumer.
• Conditional dependencies are interpreted in the context of the graph that produced the file.
• The file is stored with the build artifact and remains retrievable under the project’s retention policy.
• The release record does not describe the SBOM as a vulnerability scan, a license determination, or an automatic compliance certificate.

If an organization needs vulnerability analysis, license review, or evidence for a named audit framework, it must define those checks separately and map them to that framework’s requirements. An SBOM can supply component data to later processes; it cannot establish the result of those processes on its own.

For teams still deciding how to structure the remote build environment, the NowMini remote Mac guides can help compare setup approaches. If access details are the remaining operational question, review the remote Mac connection options before changing the pipeline.

When the workflow depends on Apple’s macOS toolchain, a Linux-only runner cannot replace the required macOS build environment. A developer’s local Mac can work for occasional builds, but it may be unavailable to scheduled jobs and can mix personal use with release operations. Buying and maintaining a dedicated Mac avoids those availability constraints, but commits the team to hardware ownership and upkeep. If the team needs a temporary, reproducible macOS environment rather than another permanent machine, renting a remote Mac from NowMini is worth evaluating against the project’s toolchain and artifact-retention requirements; teams with sustained, heavy workloads or a need for physical peripherals should assess owned hardware instead.