13.11.2024
Leoni Tischer
Open Source
Imagine you could search through every single component of your software like a map – identify risks at a glance, track down hidden dependencies and effortlessly expose vulnerabilities. This is exactly what a software bill of materials (SBOM) makes possible! This article explains why this “list of ingredients” is indispensable for modern software projects today, especially as open source now accounts for a lion’s share of development. Even better: in an innovative research project with the Bonn-Rhein-Sieg University of Applied Sciences, supported by the Federal Ministry for Economic Affairs and Climate Protection, a new type of visualization was developed. This not only allows risks to be identified, but also simulated, so that even complex licensing and compatibility problems become visible. Immerse yourself in the world of SBOM – an exciting journey of discovery through the hidden layers of your software!
Put yourself in the shoes of an IT security manager in a hospital. You receive an SBOM for a new patient management system that you are to implement. This SBOM is several hundred pages long and lists thousands of software components, libraries and dependencies. How do you proceed?
This question is more difficult than expected, but first: where does an SBOM even come from?
Experienced developers do not write their code from scratch, but use existing software, commercial packages and open source for development. The reasons for using open source are to improve productivity, shorten development time and reduce development costs. AI is providing more and more support in the creation of software. High-quality code can be generated at lightning speed using code from open source repositories.
We see this across all industries (automotive, embedded, IoT, healthcare, finance,…), and also across different technologies (Linux, Windows, embedded, containers, SaaS). Even a simple electric toothbrush or a cooking appliance like the Thermomix contain a large amount of open source. Meanwhile, open source has a share of 70%-90% in an average project.
It is important to consider a number of risks here: cyber security, respect for intellectual property, licensing requirements (such as publication of code or naming of authors), export restrictions, avoidance of incompatibilities, future-proofing. For legally compliant use, all open source components in a software must be known and continuously checked for security gaps or changes.
A software bill of materials (SBOM) specifies the inventory of components used to create a software artifact such as a software application. It is comparable to an ingredient list on a food package: just as one can consult a label to avoid foods that may cause allergies, SBOMs can help organizations or individuals avoid consuming software that could harm them.
The concept of the bill of materials is well established in traditional manufacturing as part of supply chain management. A manufacturer uses a bill of materials to track the parts it uses to manufacture a product. If defects are later found in a particular part, the affected products can be easily located using the BOM.
A software bill of materials (SBOM) is a formal data set that contains the commercial and free software components included in software products. It makes dependencies on third-party components transparent and thus helps manufacturers, security researchers and users to monitor vulnerabilities and much more.
The German Federal Office for Information Security (BSI) has published a technical guideline on the minimum requirements for an SBOM. It lists some minimum elements, for example: Supplier details, author and timestamp, version, other unique identifiers (CPE, Purl, etc.), dependency relationship and license.
Normal software systems now contain an average of over 3000 open-source components. On average, mind you. Our previous experience in software quality analysis has shown how much visualizations can help to present complex issues in a simple way. So it made sense to do the same for the structure of open-source components.
Our goal of the visualization is ultimately a simple overview with filters and simulations to simplify evaluation. A graphical representation of an SBOM is extremely useful to make the complexity and structure of software components understandable.
Some advantages of the graphical representation are:
- Clarity and clarity through simple navigation
- Recognition of dependencies and risks
- Easier communication and collaboration
- Basis for maintenance and further development
Consequently, the visualization of the SBOM is like a detailed map that shows the terrain of the software landscape in a clear and understandable way. Just as a map shows different geographical elements, such as cities, roads, rivers and mountains, an SBOM shows the different components, dependencies and relationships within the software. It makes it easier to navigate through the complexity of the software, supports the identification of dependencies and risks and promotes communication and collaboration within the team.
User-friendliness and clarity were of paramount importance to us during development and design. Through a lot of communication between designer, developer and law firm, we tried to make the visualization as intuitive as possible in order to keep the user experience frustration-free.
Let’s start with the basic form: components are shown as a rectangle, name in the title, connector as a small circle. If it is a code snippet, it is shown as a truncated rectangle.
We can map the risk using the color of the frame. The different license types mentioned at the beginning are identified by a colored frame according to their priority. We proceed according to the traffic light principle.
- Red means that you must comply with special conditions.
- Yellow means that caution is advised and a thorough check is necessary.
- Green means that you have the freedom to go ahead and use the code as you wish.
Just like a traffic light, this color code system helps you to make the right decisions when using software licenses.
Additional information such as security vulnerabilities or export restrictions are highlighted as symbols to the left of the component.
The following points may also be important:
- Impact on patents: e.g. Apache: Can be important if company holds patents, or software and hardware together make a product
- Operational risks: For example, a small community, few updates, no support: Here you either have to provide support yourself or look for alternative components
- Another very important point: How are components connected to each other? Static is indicated here by a solid line, dynamic by a dotted line.
Now we won’t keep you in suspense any longer and give you an overall impression of an open-source project: Google Chromium (with some extensions to show all graphical elements).
As you can imagine, navigating with the help of filters and zoom is essential to be able to take in all the important information. Here is a zoomed-in detailed view with legend:
A view based on a folder structure is also possible, which is sometimes helpful in the detailed view. Furthermore, filters can be used in the application to identify weak points. These filters can be combined and the search also facilitates orientation.
Another very important feature is the simulation. Direct effects of copyleft licenses can be tracked, which is very difficult to detect in an SBOM in text form.
Here is an example of a copyleft infection:
Incompatibilities can also be clarified with the help of the simulation:
As you can see, visualization offers a number of advantages over text form and quickly makes even large systems clearer. Common tools such as Flexera SCA, ORT, ScanCode, Fossology or Black Duck can generate all kinds of SBOMs that can be read out with our tool.
Our tool will soon be published as open source, we will then provide the corresponding link and hope for a lot of help in testing and trying it out. As part of our FOSS analyses, we will make this visualization available to all customers in the future.