Joseph Hejderup

In the world of manufacturing, a bill of materials (BOM) constitutes a quantified list of raw materials and components used to produce, for instance, a given refrigerator. The equivalent in the software world would be a list of all third-party libraries needed to compile, test, and release a software product. There is, however, a significant difference between the BOM for a refrigerator and a software product. Unlike for refrigerators, not all software products' ingredients (i.e., third-party libraries) are actually used!

In this talk, we will present findings from our recent academic research comparing SBOMs generated from different sources of abstraction (i.e., manifest data and call graph data) to highlight that potential inaccuracy can hamper the actionability of SBOMs. Evaluating the severity of security vulnerabilities in third-party libraries is one such example. Moreover, we will also demonstrate from a recent experiment that available tools generate different SBOMs for the same software product, showcasing that SBOMs are not trivial to standardize. Finally, we will wrap up the talk with a discussion on challenges and opportunities to establish a ground truth for SBOMs.

Which crates call a vulnerable function? Which deprecated functions are central to crates.io and should not be deleted? Am I breaking important clients and their dependencies with my new release? These are questions that package publishers and owners of package repositories crave for answers to. To solve this problem, we created RustPräzi: a call-based dependency network that represents a gigantic single large versioned call graph of all crates.io packages.

In this talk, I will describe how RustPräzi is developed, the challenges we faced while compiling the entire crates.io and the future directions. Our goal is to make RustPräzi a community effort that can help in maintaining the stability of crates.io. For example, bad releases which may negatively impact crates.io can be detected and avoided.