I'm Mitchell, and I'm currently a first year undergrad computer science student at Brown University. I've been learning Swift in my free time for the past year and I'm super excited to contribute! I just discovered GSoC, and this will also be my first experience contributing to an open-source community.
I'm interested in the Software Bill of Materials idea for SwiftPM (The potential mentors included @abertelrud@tomerd@NeoNacho). I haven't used SwiftPM in the past, but I've used Maven in some of my classes before for Java projects. Are there any suggested resources that would help me get more familiar with SwiftPM and its codebase?
Additionally, if the mentors have any more details to help contextualize this idea, I'd love to hear them. If my understanding is correct, would the new BOM type be a group of dependencies coupled together as a new dependency?
Thanks, and again looking forward to getting more involved.
Mitchell Salomon
You have it exactly right, SwiftPM is Swift’s dependency managment tool and plays a similar role to the one Maven and Gradle play in the Java ecosystem.
The BOM feature we are interested in adding is similar to Maven’s BOM. The goal of the feature is to allow a collection of separate packages to share centralized dependency version constraints which is important to large projects that are composed of multiple packages in separate repositories.
Essentially it would be a new dependency type that points to a remote spec file (JSON or similar) specifying packages at specific versions, SwiftPM will then need to process the BOM constraints before applying them to the concrete dependencies specified in the Manifest.
To anyone else interested in this topic, the NTIA has a lot of resources on SBOMs here that could be relevant.
You mentioned that the spec file defining the BOM could be in JSON or some other format. According to this source, it seems that three formats of SBOMs are used widely: SPDX, CycloneDX, and SWID.
Would it be within the scope of this project to support BOM files that use any of these three formats, or would it be more appropriate to use a single, more lightweight custom format in JSON (or the like) that only has information regarding each package's name/url and it's version number? It looks like Maven goes the second route of defining their own format as a special pom.xml file.
It seems as if the 3 industry formats have a lot of auxiliary information besides just package versions that may or may not be useful. For example, they have things like supplier name, licensing information, component name and hash, unique identifiers, etc. for each of the dependencies. Additionally, an argument can be made that there is value in standardizing the BOM formats used across software. Why introduce a new format when other standardized versions exist?
I also could envision a mix between these options, perhaps converting the different SBOM formats into one single format specific to SwiftPM that is then used directly by SwiftPM to ensure all the packages satisfy the BOM-specified version constraints. Thus a user could define a BOM either in the SwiftPM-specific format or any other supported format, in theory getting the best of both worlds.
Perhaps plugins could also come into play for providing the functionality to convert between the different SBOM formats (example spdx-maven plugin).
If anyone has any thoughts on this, I'd love to hear them.
hi @Mitchman215 that is interesting question. The SBOM formats mentioned have this auxiliary information to cater to another use case of BOMs: Producing a spec for what was included in a software product (e.g. what was included in a iOS application that uses packages) which is very useful when it comes to security and licensing aspect - e.g. it can help answer questions like "what software licenses are used by this application via its dependencies" and "are there any vulnerabilities in the application's dependencies".
While this is a very interesting aspect of SBOMs, it is not the focus of this specific project (maybe next year!) so we can start with something simpler that is focused on version constraints. If you think one of the formats mentioned above is good for that purpose, we can use it instead of a bespoke format.