Microsoft opens up code for its SBOM tool

Thinking of helping organizations to have more control over the dependencies between the elements present in their supply chains, Microsoft recently announced that it will open the source code of its internal tool used to generate SBOMs (Software Bill of Materials). Called Salus, the solution is based on the Software Package Data Exchange (SPDX) standard and can be used with Windows, Linux and Mac platforms.

According to Microsoft, Salus can be easily integrated into build workflows and automatically detects NPM systems, NuGet, PyPI, CocoaPods, Maven, Golang, Rust Crates, RubyGems, containerised Linux packages, Gradle, Ivy and GitHub public repositories via the component detection feature.

The SBOMs generated by Salus contain four main sections based on the SPDX specification:

• Information about the creation of the document: General data such as the name of the software, SPDX licence, SPDX version, who created the document and when it was created, etc.
• Files section: List of files that compose the software, each file having some properties.
• Packages section: List of packages used in software development. Each package has other properties like name, version, vendor, hashes (SHA-1, SHA-256) and Package URL (purl) software identifier.
• Relationships section: List of relationships between different SBOM elements, such as files and packages.

Salus can also reference other SBOM documents to maintain a complete tree of dependencies.

Microsoft’s decision to release access to Salus’ source code comes on the heels of the US president’s executive order aimed at improving the country’s cybersecurity by May 2021. One of the required measures has to do precisely with SBOM. Moreover, Microsoft claims to have been involved with the issue for years. For instance, in September 2019, it led the Consortium for Information & Software Quality (CISQ) cross-industry working group to define a new scheme for SBOM. The company then decided to join the group’s efforts with the Linux Foundation’s work and use the Software Package Data Exchange (SPDX) on all SBOMs generated, embracing the mission to do this for all software packages produced.

Now, with the release of Salus, Microsoft intends to work with the open source community to help everyone follow the US federal government’s guidelines. In the company’s view, this is an important step in promoting collaboration and innovation in the community and will allow more organisations to run SBOMs, thus contributing to their development.

The US Department of Homeland Security itself, along with the US Cybersecurity and Infrastructure Security Agency (CISA), is calling on technology companies to develop automated tools to deal with SBOMs through a contract opportunity.

“Vulnerabilities in software pose a major risk to cybersecurity and are the primary avenue for malicious actors to cause a range of damage. By using SBOMs as key elements for securing software packages, we can mitigate risks in the software supply chain and respond to new threats more quickly and efficiently,” says Allan Friedman, senior consultant and strategist at CISA.

The programme will have four phases and an optional fifth that will include testing in operating environments and use cases. Applicants must submit applications requesting $50,000 to $200,000 in funding to develop a minimum viable product (MVP) within three to nine months. Selected MVPs will move to phase 2 for prototype development.

Looking to the future, but also to the past

Having more visibility over software development lines and reducing the chance of vulnerabilities causing major damage along important supply chains is an important role for SBOMs, but they can go further.

In organisations with large, troubled legacy environments and potentially a huge list of cybersecurity gaps, SBOMs can help create formalised records of the legacy software estate, with details and relationships between components used in development. According to a Forbes article, it could be a way to start modernising security schemes in older infrastructures.

Unfortunately, creating SBOMs is often a more challenging task for organisations with older environments compared to those with modern technology infrastructures. However, it is not impossible. The idea is to bring together older software products and components that are part of the critical infrastructure. It should also not be forgotten that these software components may continue to change over time, depending on the application, and this should be taken into account in the SBOM generation process.

In any case, SBOMs can be a good path on the journey to modernise the security of legacy environments, they help to better identify vulnerabilities and consequently reduce risks.