This week: confirm whether your Swift 6.4 SBOM comes from the resolved package graph or the build context, then compare its product scope and generation time with the artifact from the same commit. A valid SBOM file does not prove that it describes the thing you shipped. This process applies when you need a macOS CI build and its dependency inventory to be reviewable together.
Swift Package maintainers: you need to include a generated SBOM in dependency review or release delivery.
Apple-platform CI engineers: you need to check whether the SBOM covers the product your macOS build actually produced.
Security and compliance leads: you need evidence that generation, archiving, and traceability support your team’s review.
Last updated October 26, 2026. Swift 6.4’s SBOM support and the behavior discussed below were checked against the Swift 6.4 release notes, the SwiftPM SBOM documentation, and SE-0509. Recheck the current toolchain documentation before changing a production pipeline.
SECTION 01 Start with the mismatch, not the file format
Swift 6.4 adds SBOM generation support to SwiftPM, as confirmed by the release notes and the implemented SE-0509 proposal. That establishes that the feature exists; it does not establish that a particular SBOM represents a particular archived app, executable, or package product.
The useful comparison is not “Did the command write a file?” It is:
- Did the SBOM describe the dependency graph used for the build, or a package graph collected separately?
- Did it target the same product and targets that produced the delivered artifact?
- Did both operations use the same commit and dependency resolution state?
- Can you connect the SBOM to the archived artifact and CI run after they leave the build machine?
If any of those answers is unknown, treat the SBOM as generated but not yet verified against the delivery.
A common source of false confidence is a successful format parser. Parsing can establish that a document follows a supported serialization well enough for the validator. It cannot, by itself, prove which commit, build command, or application bundle the document describes.
SECTION 02 Compare the graph the SBOM sees with the graph the build uses
A Swift Package Manager SBOM can be generated from package information without being evidence that every listed component participated in a specific build. The distinction matters because package resolution, build planning, and the product selected for compilation answer related but different questions.
Package.resolved records resolved dependency state for a package’s dependency resolution. It is useful evidence for identifying the versions selected by the checkout, but it is not a receipt proving that every resolved dependency was compiled into a particular product. Review the PackageDescription documentation for package dependencies and resolved versions alongside the build record.
The build graph can be narrower than the package’s full dependency picture. Conditional dependencies, target relationships, product selection, and build conditions can affect what is relevant to a build. SE-0509 explains the relationship between SBOM generation and SwiftPM’s dependency information; use its documented options and subcommand behavior rather than assuming that a package-wide inventory is identical to one product’s build inputs.
What is the difference between swift package generate-sbom and an SBOM generated with swift build? The former is a package-manager generation command; a build-associated generation path is tied more directly to build context. That distinction is useful only if you confirm the exact behavior and available options in the SwiftPM documentation for the toolchain installed in CI. Do not infer from the command name alone that a generated document is bound to the build output.
Use the current SwiftPM SBOM guide to verify the supported formats and command options for your installed release. Then record which generation path you chose. If your pipeline runs generation as a separate step, treat it as a separate operation that needs its own evidence of matching commit, resolution state, and product scope.
A component count is not a completeness test. A larger list can mean that the SBOM covers more of a package graph, not that it more accurately represents the delivered product. A smaller list can reflect a narrower product scope, filtering, or a different graph. Compare component identities and dependency relationships against the intended build, not just the total number of entries.
SECTION 03 Check product scope before comparing component lists
A package can expose multiple products, while a CI job may build or archive only one. If the SBOM generation targets the whole package but the build job delivers a single product, you are comparing different scopes. If the SBOM targets one product while the release contains more than one executable or framework, the inventory may be incomplete for the delivery.
For each build job, write down the product name as it appears in the build configuration, the command that produces it, and the artifact path that CI archives. Then match the SBOM generation target to that product using the options documented for your SwiftPM release. The SwiftPM package description command documentation can help you inspect package structure; it does not replace checking what the CI job actually built.
How should you cover the dependencies of the product built in macOS CI? Make the build job’s product selection explicit, generate the SBOM with a scope that corresponds to that selection, and retain both outputs from the same run. If the toolchain cannot express the scope you need, document that limitation and do not label a package-wide file as a product-specific inventory.
For a project with several products, compare each product independently. A single package-wide SBOM may be suitable for package-level review, but it can hide which dependencies belong to which deliverable. Conversely, a product-level file should not be presented as the inventory for an application bundle that contains additional products or components.
Keep the comparison at the right boundary:
- Package-level review: check the declared and resolved package relationships relevant to the repository.
- Product-level review: check the selected product and the dependency relationships reported for it.
- Delivered-artifact review: check the actual archived application or executable, its build record, and any components introduced outside the Swift package graph.
These boundaries are not interchangeable. In particular, do not assume that an SBOM generated from SwiftPM automatically inventories every tool, system library, resource, or component that may affect the final delivery. Record what the inventory covers and what it does not.
SECTION 04 Use the timeline to find where the records diverged
The generation timestamp is evidence, not decoration. A separate SBOM step can run after dependency resolution, checkout state, or build inputs have changed. That makes it possible for a valid document to describe a different state from the artifact beside it.
Reconstruct the run in order:
Checkout: capture the commit identifier used by the CI job.
Resolution: save the Package.resolved file and confirm it belongs to that checkout.
Build: record the exact build or archive command, selected scheme or product, and toolchain identity.
Generation: record whether SBOM generation ran as part of the build context or as a separate command.
Archive: retain the artifact, SBOM, and CI run metadata together.
If the build and SBOM come from separate jobs, verify that both use the same commit and equivalent dependency-resolution state. A later job that resolves dependencies again may produce a different graph even if the repository checkout looks unchanged. Check the actual file and CI logs; do not rely on job names or a shared branch label as proof.
Why can the SBOM differ after a successful build? The build may have used a resolved graph that the later SBOM step did not share, or the generation step may have selected a different package or product scope. A successful compile confirms that the build command completed under its inputs. It does not certify the provenance of a separately generated inventory.
Keep the original
Package.resolved, build log, SBOM, and archived output from the same CI run. If you regenerate the SBOM later, label it as a later generation and preserve the original; otherwise, you can erase the evidence needed to explain the mismatch.
For an Xcode-managed application, distinguish SwiftPM’s package inventory from the app’s archive and distribution process. Apple documents how an application is archived and distributed in its Xcode release and beta-testing guidance. Use that record to identify the delivered app and its build context; do not imply that the archive workflow automatically signs an SBOM or binds it cryptographically to the binary.
SECTION 05 Validate the document, then validate its relationship to the artifact
Swift 6.4’s documented SBOM formats include CycloneDX and SPDX. These are serialization and data-model choices, not proof of build provenance. Select the format your receiving tools accept, then validate it using the appropriate format guidance: the CycloneDX SBOM validation guide or the SPDX serialization and validation material.
Treat verification as separate checks:
- Format: can an appropriate parser read the document?
- Content: are the expected product and dependency relationships present?
- Scope: does the document represent the package, selected product, or delivered app you intend to review?
- Traceability: can you connect it to the same source revision, dependency state, build invocation, and artifact?
- Retention: can a reviewer retrieve the matching files and run record later?
A parser can pass while scope or traceability fails. A component may appear in an SBOM but not be relevant to the product being delivered; an expected component may be absent because the generation path did not capture the intended graph. When comparing two documents, inspect component identifiers and relationships rather than treating formatting differences as dependency changes.
Do not claim that SwiftPM automatically signs an SBOM or cryptographically binds it to a binary unless your pipeline adds and verifies such a mechanism. The cited SwiftPM documentation describes SBOM generation; it is not a substitute for your organization’s artifact provenance or signing process.
SECTION 06 Run a same-commit acceptance pass
Use this checklist on a clean CI checkout or a controlled reproduction. Each item should leave a record that a reviewer can inspect.
- [ ] Record the source commit used by the macOS CI job.
- [ ] Save and inspect the checkout’s
Package.resolved; confirm the SBOM step uses the same dependency-resolution state. - [ ] Record the installed Swift toolchain and Xcode selection. Use the values from the build environment, not a developer’s local machine.
- [ ] Identify the exact product or application artifact the job intends to deliver.
- [ ] Record the build or archive command and its product selection.
- [ ] Confirm from the installed SwiftPM documentation whether the SBOM command uses package graph information, build context, or a documented product scope.
- [ ] Generate the SBOM without changing the checkout or re-resolving dependencies between the build and inventory steps.
- [ ] Validate the file using the applicable CycloneDX or SPDX guidance.
- [ ] Compare product identity, component identifiers, and dependency relationships with the expected scope.
- [ ] Archive the SBOM beside the build output and retain the commit, resolution file, toolchain details, and relevant CI log.
- [ ] Download the archived files in a separate review step and confirm they still map to the same build record.
This procedure requires an Apple toolchain for the macOS build or archive being accepted. Some document inspection and format validation can run in another environment if the required validator is available there, but that does not replace reproducing the Apple-platform build. Keep those activities separate in the record: “SBOM parses elsewhere” is not the same result as “this macOS artifact and this SBOM correspond.”
If you cannot make the generation path use the same product scope or build state, record the limitation and narrow the claim. For example, describe the file as a package-level dependency inventory rather than asserting that it completely represents the shipped application. That is more useful to reviewers than an unqualified “SBOM passed” status.
SECTION 07 Choose a generation path that fits the evidence you need
Use the table as a scoping decision, not as a claim that one command automatically certifies an artifact. Confirm command details against the SwiftPM documentation and implemented SE-0509 proposal cited earlier for your installed toolchain.
| Evidence you need | Package-generation path | Build-associated path | Acceptance check |
|---|---|---|---|
| Package-level dependency review | Useful when you want an inventory of package dependency information | May be more detail than a package review requires | State clearly that the document is package-scoped |
| One selected product in a multi-product package | Confirm that the documented generation options select the intended product | Tie the record to the build’s product selection where supported | Compare the SBOM scope with the actual product and artifact |
| A macOS release artifact | Generation alone does not identify which archive it accompanies | Better aligned with a build record when the documented workflow exposes that context | Retain the SBOM, archive, commit, resolution state, and build log together |
| Review by a downstream parser | Choose the documented format accepted by the receiving system | The generation context does not replace format validation | Validate the document, then separately verify scope and traceability |
Use standalone generation when package-level inventory is the intended result. Use a build-associated path when you need stronger evidence that generation used the build’s context. In either case, match the commit, dependency state, product, and retained artifact before treating the SBOM as release evidence.
If your current setup runs on a non-Apple host, it can still perform source review or document parsing, but it cannot stand in for the macOS/Xcode build whose output you are trying to reconcile. A local Mac may be the best fit when you need permanent access, physical interfaces, or a stable machine dedicated to sustained workloads. For a short reproduction, a CI investigation, or a temporary Apple-toolchain validation, operating an existing Mac may add access, maintenance, and scheduling work that is separate from the SBOM issue itself.
When the mismatch requires a controlled macOS reproduction, first check the VPSNIX help center for access and operating details. If you need a temporary environment rather than a permanent machine, review the VPSNIX Mac rental options only after confirming the required toolchain and artifact-retention process. A rented remote Mac can help you reproduce the workflow; it does not replace a same-commit CI record, and it is not the right choice when your team needs a permanently dedicated host or physical hardware. For related engineering material, browse the VPSNIX development guides.