Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by email or DM. When contacting the review manager directly, please put "SE-0509" in the subject line.
Trying it out
If you'd like to try this proposal out, you can download a toolchain supporting it:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at:
Big +1 from me - fills an increasingly important gap in the security story for Swift applications, supports industry standard schemes and integrates nicely
I had a thought about future functionality. Currently, SBOM authors don't have a guaranteed way of confirming what SBOMs were generated by SwiftPM other than using --sbom-output-dir and ensuring the provided directory is empty.
In "Future Features" section, can we add functionality that would have SwiftPM provide a structured data of the SBOMs it generated, possibly via a --sbom-output-format <mode> CLI option
e.g.: (this is a sample JSON output)
$ swift build --build-system swiftbuild --sbom-spec cyclonedx --sbom-spec spdx --sbom-output-format json
<...SNIP...>
{
"cyclonedx": [
{ "version": "1.7", "output": "<absolute/path/to/generated/CycloneDX/SBOM>" }
],
"spdx": [
{ "version": "3.0", "output": "<absolute/path/to/generated/SPDX/SBOM>" }
]
}
## Text based output produced the existing output
$ swift build --build-system swiftbuild --sbom-spec cyclonedx --sbom-spec spdx --sbom-output-format text
<...SNIP...>
<current text based output>
I think that augmentation would coordinate well with some kind of flag that can toggle the SwiftPM logs. For example, some languages are able to output all logs as JSON objects that can be decoded line by line programmatically. I can see external tools or monitoring services streaming/being streamed the SwiftPM build logs, parsing each JSON object until the SBOM paths JSON object is reached, then extracting the paths from the SBOM paths JSON object.
+1. I think this proposal is an important part of Swift's supply chain security story, and I'm happy with the proposed interface of the feature.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, I think first class support for SBOMs is warranted. Many organizations and open source projects have begun relying on them as an important tool for auditing the dependencies of a final product or release. Shipping builtin support for them in SwiftPM allows them to evolve alongside future changes to the package model.
Does this proposal fit well with the feel and direction of Swift?
Yes, IMO the command line interface fits in with the rest of SwiftPM's build related functionality. Initially, I had some concerns that the env vars which may also be used to trigger SBOM generation could lead to confusing behavior if a user didn't realize they were set. I've since been mostly convinced that these are a useful tool for CI systems which want to be able to enforce that all builds produce/collect SBOMs.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
What is your evaluation of the proposal?
Very positive. I in particular like the clear arguments and support for both SBOM formats. That will help adoption a lot.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. If the corporate environment I work in is representative, creating SBOMs is becoming a mandatory activity.
Does this proposal fit well with the feel and direction of Swift?
Yes, because it emphasizes Swift as a general purpose language that is not only suited to client side applications, but well suited for backend and embedded systems development.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I don't really know about any third party libraries that support a similar feature. In addition, having SBOMs be a 'first class citizen' in the Swift ecosystem sends a strong message about the language intend to be a secure, general purpose language.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the thread and proposal. Unfortunately, I wasn't able to try the feature out myself. In particular, I'm curious to see it integrated in our Azure DevOps based CI. And how I can store the report as an 'artifact'. Getting Swift to work in CI outside of Swiftly is hard.
We now have a Windows toolchain available here to try out with this SBOM feature. We recommend uninstalling the version of Swift on your machine before installing the version with SBOM support, to prevent any toolchain conflicts.
