Most proprietary applications and many open source programs not only contain their own source code, but often also additional, external code for certain functions. Modern software applications are a complex mix of proprietary, open source and third-party components, communication APIs and protocols, and business logic. They all come from different sources and are brought together in build and release pipelines.

External code is often poorly documented

Unfortunately, this external code is not always documented. Open source projects in particular offer a high level of transparency. To take advantage of this, it makes sense to document important information about the open source components used. This helps to put the software supply chain on a stable footing.

However, the IT security of software supply chains is not limited to the documentation of the components they contain. A software bill of materials (SBOM) has a key function within the risk management concept for the entire software supply chain. Beyond documentation, SBOMs are a process that runs continuously and should be optimized.
Such a BOM can act as a management system that identifies and documents open source components and integrates their validation and updating into the pipeline. Workflow and notification functions are also included. Put simply, an SBOM ensures that appropriate measures are derived on the basis of the information obtained on the software components used.

Security gaps in software components

Companies that use software from different sources and components never know exactly where potential security gaps are and what they are. The risk is immense. One of the most recent examples is the gap in the open source Java library Log4j. Many companies are still unaware that they are using this library in their applications and are therefore unable to react correctly.

With a software bill of materials, there is a comprehensive list of external components for each application, including the various versions. This makes it possible to track exactly where rework, updates or improvements are due at any time. This not only makes the application more secure, but also the entire network.

Software must become more secure

When security gaps appear in open source libraries, in most cases it is not even known where this specific open source library is being used. A list of the applications used in the company is often missing, and in most cases also a list of the software components used.

However, there can only be a reliable security concept if it is clear which applications and application components are used, including the version used. If security gaps then become known, it is easier for those responsible to react immediately. Installing updates can only make sense if the components used in the network and software are clearly identified. The same applies to other security measures.

Eliminate loopholes

Software manufacturers should maintain a parts list for their applications in order to document all the components it contains. However, it is also important to create a catalog of measures and plan what will happen if a gap becomes known and how long it will take the developer to close the gap. Without action planning, the SBOM remains just a document.

Vulnerabilities in open source components are publicly available so that the community can react quickly and close the gaps in question. It is in the nature of things that attackers also have access to these vulnerabilities and exploit them, for example to introduce malware. In most cases, software developers use their own SBOM. They use it internally to document dependencies and risks and derive countermeasures. If companies make the SBOM available to their customers, they are better equipped to operate licensed software as securely as possible.

If possible, buyers of software obtain the SBOM from a third-party provider. This allows the components used to be inventoried and documented.

Software developers who use external code often also require the SBOM of a third-party provider. In the vast majority of cases, therefore, several SBOMs are used in such scenarios. The overarching aim of using an SBOM is to automate security processes and close security gaps. Various procedures support this, for example intelligent pipelines and AppSec tools.

Intelligent pipelines

Reliably documenting all components in a software supply chain and planning the closure of security gaps requires intelligent pipelines. They can be used to largely automate the very time-consuming application security (AppSec) and take intelligent measures. The aim is not only to document the gaps, but also to close them successfully.
AppSec tools in software projects and application security testing tools, together with corresponding development pipelines in DevOps environments, ensure that the delivered applications, including all components, are and remain as secure as possible. Integration into CI/CD pipelines is a further component in this respect. The AppSec scanners used run continuously in the pipeline and examine integrated components.

The author: Boris Cipot is a Senior Sales Engineer at Synopsys.

© Synopsys

Intelligent pipelines that focus on the security of software components therefore make extensive use of AppSec tools. Based on the data that a scanner transmits to the pipeline, it is possible to take automated measures. As part of DevSecOps, it makes sense to introduce SBOM with a standardized format such as SPDX (Software Package Data Exchange, developed by the SPDX workgroup, a working group of the Linux Foundation). This prevents redundant work, as different components can be used in several places. SPDX is currently becoming a popular standard for dealing with open source applications in companies. Not least because it can be used to guarantee licenses, copyright and the compatibility of various components.