🎉 We are proud to announce that we were selected to receive funding as one of the participants in the recent “Contribute Back” challenge organized by the Sovereign Tech Fund (STF).
In our application, we participated in category two: Securing FOSS Software Production
For those who may not be familiar with the STF, here’s a brief overview:
The Sovereign Tech Fund supports the development, improvement, and maintenance of open digital infrastructure. Its goal is to sustainably strengthen the open source ecosystem, focusing on security, resilience, technological diversity, and the people behind the code.
Our specific goal within this endeavor is for Rust projects to improve the generation of SBOMs (Software Bill of Materials) in the CycloneDX format. For those not familiar with the technical details, let’s first delve into the main parts involved:
1 – Rust
Rust is a programming language that prioritizes safe memory management and fosters secure software development. For years, Stack Overflow has conducted regular user surveys and Rust has consistently ranked as the most “admired” or “wanted” language. While it doesn’t eliminate human error entirely, Rust effectively mitigates certain types of bugs from arising in the first place.
This particular feature has gained recognition not only within the tech community but also from entities like the US government. Currently, the US government is in the midst of a Request for Information (RFI) regarding memory-safe languages, and public comments are welcome until November.
As you continue reading this post, keep the term “cargo” in mind — it serves as Rust’s integrated package manager and will be relevant later on in this post.
2 – Software Bill of Materials
The concept of a Software Bill of Materials (SBOM) is gaining significance among IT professionals and is expected to play a pivotal role in the future. Essentially, an SBOM serves as a language and ecosystem-agnostic description of an application or library’s dependencies.
The primary objective of an SBOM is to facilitate the swift identification of products reliant on specific dependencies. It enables organizations to readily answer critical questions such as, “Which of our company’s software products could potentially be affected by vulnerabilities like Log4Shell?” While there are additional use cases, like license management, this stands as one of the most prominent.
Notably, SBOMs are already obligatory in certain contexts, such as for suppliers to the US government or certain large corporations. Furthermore, the EU may mandate SBOMs for specific products under the Cyber Resilience Act in the future.
3 – CycloneDX
Multiple technical formats exist for creating Software Bill of Materials (SBOMs), with SPDX and CycloneDX (a project of the OWASP Foundation) being among the most prevalent. However, for reasons not covered in this blog post, we have opted for CycloneDX as our preferred format.
To facilitate the generation of CycloneDX SBOMs, the CycloneDX project offers a cargo plugin, which can be found at https://github.com/CycloneDX/cyclonedx-rust-cargo.
Putting it all together or “why this now?”
At Stackable, we are building an open source data platform based on Kubernetes. As crucial components of this platform, we’ve been developing Rust-based operators. Furthermore, a key objective on our roadmap is to deliver Software Bill of Materials (SBOMs) to strengthen the software supply chain security for our customers. However, while testing the cargo plugin from the CycloneDX project, we encountered several issues, including bugs, certain missing features, and unexpected functionality.
It was around this time that we became aware of the STF challenge, submitted our application, and are now very pleased to share the news of this funding for our upcoming work.
Our application emphasized the importance of Rust in securing critical infrastructure and the importance of SBOMs. Enhancing this plugin will have a positive impact on the industry as a whole, and we are pleased that the STF recognizes this and shares our vision.
The technical details
For those interested, here’s what we’ll be working on:
- Enhancing Multi-Package Dependency Lists: We want to ensure that the plugin accurately generates dependency lists for multi-package projects.
- More than one SBOM per Package Issue: Currently, the plugin creates one SBOM per package, but packages can have multiple targets, such as a library and multiple binaries/applications. We are actively working on a draft pull request (PR) to address this issue.
- Support for CycloneDX 1.4 and 1.5: We thank Tobias Mucke for submitting a pull request for CycloneDX version 1.4 support. Once reviewed, we’ll ensure its’ integration and subsequently proceed to implement support for CycloneDX 1.5.
- Introducing Dependency Graphs: The current plugin offers a flat list of dependencies. We aim to merge the functionality to incorporate a dependency graph. There is an existing pull request from Șerban Robu for this, which will require significant updates after previous changes have been merged.
- Including Dependency Hashes for Integrity: SBOMs should include dependency hashes to enable integrity verification. Currently, these hashes are missing from the cargo metadata command output. We are planning to add the necessary support upstream, and fortunately, the required changes have already been discussed and provisionally approved.
- Stretch Goal, Rust Feature Resolver Version 2 Support: As a stretch goal, we aim to enhance cargo metadata to support the Rust Feature Resolver version 2, which it currently lacks. As a result, if a dependency is used as both a normal and a dev dependency with different features enabled, the cargo metadata may report slightly inaccurate dependencies
Phew… that’s a lot of work. There is no way we can do it on our own, and it’s also not our core business either. That’s why we’re very proud to have found a capable team to do some of the the heavy lifting for us:
Sergey “Shnatsel” Davidoff is going to implement all the tasks related to the plugin itself.
For those not familiar with him:
- He is the author of cargo auditable, which operates in the same domain and could potentially benefit from our upstream efforts
- He currently leads the Rust Secure Code working group
- He is also a maintainer of the RustSec Advisory Database
Talk about a perfect match? Thank you Sergey!
For the upstream parts in cargo itself, we have secured the support of Ferrous Systems.
In the unlikely event that you have never heard of them:
- They are a Rust consultancy with a collective 100 years of Rust experience
- They are the on-call team for crates.io
- They are active in the Rust Foundation
- Have you heard of sudo-rs? The sudo rewrite in Rust. Yup, they are also co-contributors there as well
- Organizers of various Rust conferences and much more
- They are the builders of Ferrocene, the qualified (and open source!) Rust compiler for the safety-critical space
This collaboration is a dream come true for us!
The work has already started, but as of today: It’s full steam ahead.
Follow our progress
We’ll provide an update here on the blog in a future post at the end of the project. You can get interim updates on the CycloneDX Slack or on GitHub, and if you’re interested in what we’re doing at Stackable, feel free to drop by our homepage, try one of our demos, meet us in Discord, or just contact us.
Our thanks go to…
To close, we would like to thank the STF for giving us this opportunity and to Sergey and the team at Ferrous for their invaluable help in achieving our goal.
We would also like to thank Steve Springett of the CycloneDX SBOM standards group for making us maintainers on the GitHub project, which will prove immensely helpful.
And finally, we would also like to thank Amy and all the other contributors whose work we will build upon.