Identification of Vulnerable Images and Files Using SBOM With Trivy

As we embrace the era of digital progress and transition to utilizing containers for our applications, we encounter a diverse range of core images that serve as the foundation for our apps. These images vary depending on our app's requirements, given the various methods we employ in building them. Unfortunately, in companies with a moderate level of DEVOPS experience (maturity levels 2 to 3), the emphasis often leans heavily towards expeditiously releasing new features, occasionally at the expense of security.

For developers like us, the challenge lies in keeping pace with the ever-evolving realm of software. This encompasses the additional components they require (dependencies), the fundamental elements (components), and the tools (libraries) that facilitate their integration across our entire system. The amalgamation of all these elements is referred to as the Software Bill of Materials (SBOM). To address this, it is imperative to comprehend the SBOM of each image before utilizing it as a groundwork for our apps. However, manual execution of this process is intricate and time-consuming. Moreover, with every update to a newer image version, we must repeat the entire process, impeding our ability to deliver products promptly.

The solution? Automation. By leveraging automation, we can navigate the intricate process of understanding the SBOM. It assists in creating organized lists of all components, identifying any known issues, and proposing solutions — all accomplished with tools such as Trivy. Before delving into the detailed steps, let's ensure that we are all aligned on the definition of SBOM.

What is SBOM?

SBOM stands for Software Bill of Materials, akin to a detailed inventory of all components constituting our software. This includes tools from external sources, building blocks, and even the regulations governing their usage, all with precise version details.

SBOM holds significance as it provides a comprehensive view of all the disparate components converging to create a specific software. This aids our DevSecOps teams in identifying potential risks, understanding their implications, and taking proactive measures to address them, fortifying the security of our software.

Why create SBOM?

1. Finding and Managing Outside Parts: SBOM allows us to visualize all externally-sourced software, presenting different versions and highlighting potential security issues. Armed with this information, we can make informed decisions, particularly concerning libraries and tools from external origins.
2. Securing Our Supply Chain: SBOM functions as a detailed map for our software, ensuring its safety and guarding against any subterfuge or attacks on our software supply chain. It serves as a tool to verify if our software sources adhere to robust security practices.

SBOM Format

1. Software Package Data Exchange (SPDX): An open standard serving as a software bill of materials, identifying and cataloging components, licenses, copyrights, security references, and other metadata related to software. While primarily enhancing license compliance, it also contributes to software supply-chain transparency and security improvement.
2. Software Identification Tags (SWID): Tags containing descriptive details about a specific software release, including product and version information. They also specify the organizations and individuals involved in producing and distributing the product, establishing a product's lifecycle.
3. CycloneDX (CDX): The CycloneDX project establishes standards in XML, JSON, and protocol buffers. It offers an array of official and community-supported tools that either generate or work with this standard. While similar to SPDX, CycloneDX is a more lightweight alternative.

In addition to creating SBOM, Trivy has the capability to scan the SBOM generated either by Trivy or other tools to identify the severity of the problem. Alongside vulnerability detection, it suggests possible fixes for identified vulnerabilities.

SBOM with TRIVY

Trivy, a comprehensive security scanner maintained and built by the Aqua Security team, is reliable, fast, and equipped with several in-built scanners for detecting various security issues across different targets. It can be employed for scanning OS packages and software dependencies in use (SBOM), known vulnerabilities (CVEs), IaC misconfigurations, and sensitive information and secrets.

Today, our focus will be on the SBOM scanning capabilities of Trivy. In this tutorial, we will:

1. Create the SBOM using Trivy
2. Analyze the created SBOM to scan and identify vulnerabilities

For the demonstration, we will utilize one of the most widely used Docker images, NGINX, specifically nginx:1.21.5, sourced from its Docker Hub image. We will run the scanner to generate the SBOM, and once generated, use it to obtain the list of vulnerabilities and potential fixes.

Generating SBOM

To generate the SBOM, ensure that Trivy is installed on your workbench. If not, you can install it using the commands provided in this link. In my case, my PC is Debian-based, so I installed it using the following command:

sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - <https://aquasecurity.github.io/trivy-repo/deb/public.key> | gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] <https://aquasecurity.github.io/trivy-repo/deb> $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy

If you are using any flavour of debian, you might face issue with “lsb_release -sc” in the command. To overcome the issue you can use one of the following values: wheezy, jessie, stretch, buster, trusty, xenial, bionic.

Once installed you should see the following, when you run

trivy --version

Once the trivy is installed, we can scan the vulnerabilities in two ways, either for image, for the whole directory containing the files or an single file.

• For a folder containing group of language specific files

  trivy fs --format cyclonedx --output result.json /path/to/your_project
  

• For a specific file

  trivy fs --format cyclonedx --output result.json ./trivy-ci-test/Pipfile.lock
  

• For a container image

trivy image --format spdx-json --output result.json nginx:1.21.5

Upon completion, the scanner will analyze the files or image to identify the programming language used in the application. Once identified, it will retrieve the database specific to that language, extracting the roster of libraries associated with it. The scanner then cross-references this list with the libraries utilized in the current context.

The resulting compilation of these libraries, along with OS-level libraries, is presented in a Software Bill of Materials (SBOM), formatted according to our specified requirements.

Listing Vulnerabilities of SBOM

Once the SBOM are generated, we can create the list of known vulnerabilities of the dependencies in the image/files such as libraries, OS packages etc. In addition to identifying these, trivy also suggests the version in which these vulnerabilities are fixed, making it not an effective tool to identify the vulnerabilities but also to resolve them.

In order for us to generate this list, we use the following command

trivy sbom results.json

This will generate the following list

As you can observe, we get the name of the library, the CVE vulnerability Number, Its Severity (HIGH,MEDIUM,LOW), The status of Vulnerability fix( fixed, not fixed or will_not fix) , if its fixed then the fixed version and along with the details on the vulnerability.

Based on this information ,we can upgrade the fixed vulnerable libraries, understand the vulnerability level in not fixed libraries and remove them if they are not required. In-addition to that, we would have the opportunity to look into the alternatives to the vulnerable libraries.

For more information and documentation, visit this site.