Nowadays, software rarely consists of purely proprietary components that have all been developed in-house. Even if it is proprietary software, open source components are mostly used, as for example in program libraries. In addition, libraries can themselves use other libraries via transitive dependencies.
Insecure supply chains can allow security vulnerabilities such as Log4J or Spring4Shell to enter a product and cause it to become insecure. Incidents such as the compromise of Solarwinds Orion, which infected thousands of companies with malware via compromised updates, illustrate how companies are dependent on their suppliers, especially in terms of information security.
It is therefore important to better understand the “supply chain” of the software in software projects and to make it transparent; because security gaps or even backdoors can easily have been built into external libraries. These gaps can then affect the entire software project.
Often, developers do not have an overview of all the components used and, in particular, are not aware of transitive dependencies.
The software supply chain harbors various risks and points of attack:
Risks of the Software Supply Chain
Risk minimization through software composition analysis (SCA)
Continuous vulnerability scans in application development can identify vulnerable components as quickly as possible and automatically
SCA tools inspect the used packages, manifests and binaries of a software, container images and more and identify the used components.
Continuous inspection of all components
The identified components are then continuously checked against vulnerability databases to detect vulnerabilities, such as CVEs. SCAs detect vulnerabilities in components before the software is shipped and recognize it when new vulnerabilities affect older releases. Likewise, licenses are checked to ensure that only those are used that comply with your license model.
There are several SCA tools available on the market, all of which have their specific strengths and weaknesses. OTARIS provides vendor-independent advice and finds the tool that fits your specific requirements and projects.
Interoperability through SBOMs
Many SCA tools can then also compile the results of the scans into an SBOM, enabling further processing by numerous other open source tools and commercial tools.
SBOMs as a solution for an automated software inventory
How software bills-of-materials (SBOMs) help you gain visibility into your supply chain
Software Bills of Material (SBOMs) are lists of the software libraries used, their versions, their origin, the (transitive) dependencies and the relations of the components to each other. This is comparable with parts lists, which contain information about individual parts, which are installed in a machine.
Advantages of SBOMs
* SBOMs make it possible to have an overview of used components in a software
* This means that vulnerabilities can be detected automatically and products affected by vulnerabilities can be identified quickly
* Data is stored in machine-readable and standardized formats, which enables automation
* An SBOM enables transparency without disclosing source code or intellectual property
SBOMs are more relevant than ever
SBOMs have gained significant relevance in the context of security vulnerabilities such as Log4J or Spring4Shell, which have affected millions of systems around the world – especially in the context of the US government’s Executive Order 14028, which stipulates that suppliers to certain critical sectors of the US must provide an SBOM. It can thus be assumed that more and more major software manufacturers and also government agencies will decide to demand transparency from their contractors through SBOMs.
Our services
OTARIS offers you consulting services in the subject area of software supply chains and SBOMs. For example, we support you in setting up a process for secured software supply chains, in setting up software composition analysis (SCA) and in using tools for creating and processing SBOMs. OTARIS provides you with vendor-independent and individual advice.
Contact us today
We advise you in a non-binding conversation
Häufig gestellte Fragen (FAQ):
Do SBOMs provide an advantage to hackers by exposing the components of a software? Do SBOMs expose internal data about in-house programs and libraries?
No – because only the names and versions of third-party components used are listed in an SBOM, but no details of internal implementations. If an attacker wants to find out which software components are used in an application, this is possible anyway using automated reverse engineering tools.
What are the SBOM formats?
Most SBOM tools work mainly with the SPDX and CycloneDX formats, which have established themselves as standards. Both SPDX and CycloneDX can each be expressed in different data description languages (e.g. JSON or XML).
What does an SBOM refer to? What does an SBOM contain?
In general, an SBOM refers to a concrete software product. This can be an application, but also a container, concrete machines (e.g. a build server) or something else.
The SBOM contains information about the components it contains as well as their relations to each other. Which information this means exactly, depends among other things on the format. In any case a SBOM must contain names and versions of the components.