Microsoft open source tool creates “Software Bill of Materials”
The SBOM tool Salus lists all components and dependencies of projects in order to detect potential weaknesses in the software supply chain.
With Salus, Microsoft has released an open source tool that creates a software bill of materials (SBOM) for software development projects. It serves as an inventory of all components of a project and in particular to identify early on whether packages with known vulnerabilities are being used.
Ingredient list for software projects
SBOMs list all the ingredients of a software project. In addition to the direct source code, this includes internal and external dependencies, for example to open source packages on npm or PyPI. Since the packages themselves often have dependencies on other projects, the complete list including the transitive dependencies must be included in the software bill of materials. If you compare the SBOM with a list of ingredients for a cooking recipe, it not only contains the “spice mixture”, but also its individual contents from salt to tarragon.
In view of the growing number of attacks on the software supply chain, the White House published an executive order to improve US cybersecurity in May 2021, which explicitly lists SBOMs as a method of securing the supply chain. Alongside this, the Bill Of Materials software helps avoid potential license violations by listing all licenses of external software used in a project.
Find dependencies
Salus is available for Windows, Linux and macOS. The tool evaluates the project path with the source code and looks for project files such as package.json *.csproj. The tool creates a hash for the files output during the build.
For the external dependencies, Salus knows packages and content from npm, NuGet, PyPI, CocoaPods, Maven, Gradle, Ivy, Go, Cargo (Rust Crates), RubyGems and public GitHub repositories. It examines external Linux packages using the SBOM tool syft. The separate Microsoft tool Component Detection is used to detect the components, which, like Salus, is available as an open source project on GitHub.
Inventory structure
For the inventory list, Salus uses the SPDX (Software Package Data Exchange) standard format, which was developed by a Linux Foundation working group. Salus creates four main areas for the output: general information about the SBOM, a list of all files in the project including their hashes, a list of all packages with their respective name, version, source and a hash, and a list of dependencies and relationships between the individual ones files and packages.
(Image: Microsoft)
If an SBOM file from the build of a sub-project already exists, Salus includes a reference in the list created and finally combines the individual lists into a final SBOM.
Malicious code in open source packages is one of the most common attacks on the software supply chain. Attackers publish supposedly useful packages on package managers that developers use in their applications. Common methods are typosquatting and brandjacking. The latter uses company names like Twilio to spoof a legitimate source.
With typosquatting, malicious code packages are given names similar to popular packages. On the one hand, the method relies on typos and, on the other hand, uses separators such as underscores and hyphens. Out of my-packet becomes my-paket, mypacket or my_packet. Someone will make a typing mistake, so the legitimate hope of the attackers.
Another attack vector are initially useful and harmless packages that only bring the malicious code with them when they have reached a certain distribution. The npm team had 2019 with them electron-native-notify discovered such a package. Finally, Dependency Confusion attempts to replace internally hosted dependencies with external packages of the same name containing malicious code. The latter are given a high version number because the package installation tools such as pip use the package with the highest number, which is supposed to be the most up-to-date, depending on the setting.
SBOMs help against the last two scenarios in particular. In the case of dependency confusion, the list shows that the package used is not the expected internal one. Against malicious code added afterwards, it is helpful to regularly check the list against entries in the CVE database (Common Vulnerabilities and Exposures). SBOMs also help to detect transitive dependencies that are not obvious at first glance. Many teams did not integrate Log4j directly into their project when the vulnerability was detected, but used an external package that relies on Log4j.
