Introduction

The OpenSSL project has rolled out fixes to contain two high-severity flaws in its widely used cryptography library that could result in a denial-of-service (DoS) and remote code execution. But are you confident to pinpoint the applications that are using outdated OpenSSL libraries in your software stack?

Before answering the question, let's review the applications using OpenSSL. What are they? How do they link to the OpenSSL library?

In general, there are two categories of such applications:

• Modern applications

These applications are written in high-level program languages such as Python, JavaScript, Ruby, etc. They invoke the OpenSSL library through native library bindings. These bindings are shipped as standalone libraries and managed by language-specific package managers. For example, the python package manager manages "PyOpenSSL," an OpenSSL library binding.

• Legacy applications

Legacy applications are those developed in system-level program languages (such as C/C++ and Rust) and shipped as standalone executables or packages of executables. These applications can statically link with the OpenSSL library. Or, they invoke the OpenSSL library installed system using on-demand loading.

Figure 1 SBOM: Supply chain relationships of various components in the software

SBOM-assisted upgrade

As shown in Figure 1, a Software Bill of Materials (SBOM) is a formal record containing the details and supply chain relationships of various components used in building software. For example, the SBOM (shown in the figure) contains the version and vulnerability information of the OpenSSL library. Deepbits Technology uses cutting-edge AI-powered technologies to identify software components and report SBOM information. Guided by the SBOM information, the information security practitioners upgrade the OpenSSL library accordingly.

Challenges in SBOM-assisted upgrade

However, SBOM doesn't capture the runtime environments of the target, including runtimes, native libraries, containers, system services, configurations, operating systems, and additional dependencies. The missing of such information creates a disconnection between different software layers (e.g. between application and operation system).

The SBOM-assisted upgrade is therefore facing below challenges:

• False positives. For example, there might be three different versions of OpenSSL native library instances in the system. All of them are outdated. However, the application only actively references one of the three instances.
• False negatives. For example, from the software manifest, we see a python application “foo” calls a library called “bar”. However, we do not know that library “bar” links with OpenSSL. Therefore, we do not upgrade the outdated and vulnerable OpenSSL.

Operation bills of materials (OBOM)

Operation Bill of Materials (OBOM) is a formal model to connect different layers of the software system and capture the knowledge of runtime environments. An OBOM details the components, dependencies, and other metadata for software in production.

Deepbits Technology uses dynamic analysis technique to gather the OBOM information. After the application is loaded and run, the dynamic analysis tool monitors the execution traces and system status changes to infer the dependencies between software components.

• Figure 2 shows one example of such analysis. For a Python application, the dynamic analysis tool can figure out the existence of language runtime, native library invocation, and other possible OS services libraries and other dependencies.

Figure 2: Dynamic analysis of software to figure out OBOM

A Running Example

from cryptography.fernet import Fernet
key = Fernet.generate_key()
f = Fernet(key)
token = f.encrypt(b"My message")
print(f.decrypt(token))

The above code snippet shows a simple Python application that performs simple encryption/decryption by invoking the cryptograph library. Deepbits Technology extracts the information of active components and dependencies between them (visualized in Figure 3). Guided by the information, the security practitioners can easily pinpoint the vulnerable cryptograph native library (libcrypto) that is being actively used by the application.

Figure 3: Example: The components dependencies of a simple python application

Summary

Combined SBOM and OBOM, we can get a complete and accurate dependency information on different software components.

As shown in Figure 4, with OBOM introduced, we are not only aware of all the high-level libraries used by a specific python application (green circles), but we are also aware of all the components in the software stack of that application.

• With augmented details of software dependencies, information security practitioners can pinpoint and control security risks more effectively and efficiently.

Figure 4: SBOM+OBOM: Augmented supply chain relationships.