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

  • Licensing issues
    If components with restrictive licenses such as GPL sneak into your code, you may be in violation of the license law if you do not open source your software.
  • Vulnerabilities
    If a software library or transitive dependency in use contains a security vulnerability, it can also render your software vulnerable and insecure..
  • Backdoors and malware
    Third-party software can be used to create backdoors and malicious code, which can infect your software and be used as a gateway for attackers.
  • Compliance
    With so many external dependencies, it's easy to lose track of where each component comes from. If you pay attention to key data such as geographical origin or company blacklists when choosing your suppliers, this can become a problem.
  • Compromises
    By compromising the development process, e.g. by compromising update servers, CI/CD pipelines or version control systems, your products and systems can be directly infected. If sufficient digital signatures are not used, packages and files can be modified by attackers without being noticed.
  • End-Of-Life
    If software is no longer maintained, whether due to the insolvency of a company or a lack of commitment to open source projects, new security vulnerabilities are usually no longer patched. Dependencies on end-of-life software projects are therefore to be regarded as a security risk.

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.