The SBOM (short for “Software Bill of Materials”) gets a bad rap in IT. As full (and often enormous) inventories of components, libraries and packages, SBOMs are complicated to set up and therefore no one is a big fan of them. Instead, many IT managers try to avoid them altogether. This is unfortunate as SBOMs come with benefits to many areas, including, but not limited to, security. For instance, SBOMs can be used for the strategic planning of upgrades; the removal of unused or unnecessary libraries and packages; software licensing and compliance with export controls; and the proliferation of restricted software components.

Indeed, SBOMs are becoming a key asset for modern research institutions that require machine-readable “ingredient lists” of the software components, libraries and packages used in a system. Because they can be automatically generated and analysed, SBOMs reduce the time spent manually identifying vulnerable components, planning upgrades and checking licence compliance. In addition, SBOMs offer a very practical benefit for research: since they provide a detailed list of the components and versions contained in a piece of software, they support the reproducibility of experiments and thus advance the goal of open science.

Let’s have a look at the steps being taken towards a better understanding of software component usage at CERN.

There are already several SBOM initiatives at CERN; for instance, CERN’s GitLab service offers dependency and security scans, and the listing of (vulnerable) components is available as part of any OpenStack-managed container*. In addition, the Accelerators and Technologies Sector uses a very advanced inventory for software succession and roll-out planning to avoid any software component becoming obsolete during a data-taking run. CERN is now developing an overall SBOM strategy and, this autumn, an external researcher from Ruhr University Bochum will take an inventory of the different areas where SBOMs are (or are planned to be) deployed. The aim of this inventory will be to understand the benefits and drawbacks of SBOMs and what support may be needed during the deployment process. These are small but important steps in the right direction.

Alongside this, CERN has hired a technical student to investigate technical means of creating SBOMs. It is possible to use the aforementioned GitLab dependency-scanner and the OpenStack registry, but there are also commercial tools such as Artifactory, JFrog, Nexus and Snyk, or the open-source standard for SBOMs, CycloneDX. What tool would be best suited for CERN? And how can an initial level of software visibility be established? A software gateway, acting as a proxy, could provide a log of which software component has been downloaded when, by whom, and from where. It could also act as a cache, introduce quarantines for 12/24/48 hours and, later on, provide an initial analysis of inherent dependencies, potential copyright issues, and a rating on its level of security (high vs critical).

So, while SBOMs might be a nuisance and will surely require some initial effort, the benefits outweigh the effort and provide any CERN software developer with better visibility of the software components being used, along with a wealth of other information:

• components’ security level
• dead-weight components not being executed at all
• opportunities to declare and license software as open source (export restrictions permitting)
• dependency on already-copyrighted components (which you should have paid for…).

Interested? Get in touch with us!

* Go to your project and open the “Artefacts” tab. There, you can generate an SBOM or start a new, full-fledged scan for vulnerabilities.

________

Do you want to learn more about computer security incidents and issues at CERN? Follow our Monthly Report. For further information, questions or help, check our websiteor contact us at Computer.Security@cern.ch.