How VEX leverages SBoMs and CVE scan results for an efficient vulnerability assessment

With VEX, SBoMs, and CVE scan results, Tanzu Application Catalog provides as a centralized source of truth where you can, not only get customizable, trusted and verified OSS applications and components to build applications, but also get all the information required to efficiently manage and assess the vulnerabilities that may pose risk to your software supply chain.

While building modern applications, developers often use third-party open source software (OSS) components as building blocks, which brings flexibility and efficiency to their software development processes. On the other hand, however, these applications end up being a highly complex mixture of components and dependencies that are often beyond the control and visibility of security teams and platform engineers. The Log4Shell vulnerability demonstrates how a supply chain vulnerability can put your entire environment at risk if you are not able to quickly identify where the affected dependencies are. So understandably, most businesses are still skeptical about using open source software for mission-critical production use cases as they do not want to fall prey to the ever-increasing software supply chain vulnerabilities.

Software bill of materials (SBoM) are beginning to play an increasingly prominent role in mitigating the supply chain risks posed by OSS. They provide a comprehensive inventory of all ingredients that make up a software application, shedding light on critical details like a software’s composition, dependencies, provenance, etc. In the ever-evolving landscape of OSS, this transparency is invaluable. Having a list of components with extensive information about their origin is a good beginning, but oftentimes, SBoMs alone may not be enough to efficiently manage supply chain vulnerabilities.

Common vulnerabilities and exposures (CVE) scan reports are an essential tool for OSS users as they provide a list of vulnerabilities that could expose their products and platforms to known risks. However, the drawback is that the mere act of scanning an OSS application often generates a long list of vulnerabilities, which can be overwhelming, given that not all vulnerabilities in a CVE scan report are always exploitable. Oftentimes, a given vulnerability can be exploited only under certain configurations or circumstances. So the mention of a vulnerability in your CVE scan report does not automatically mean that your software is at risk. Furthermore, CVE notices are difficult to read without some level of expertise in cybersecurity. So it becomes important to have some kind of support documentation that could help you understand the exploitability of the vulnerabilities in your CVE scan reports. That is exactly what vulnerability exploitability eXchange (VEX) documents do.

The National Telecommunications and Information Administration (NTIA) of the U.S. Department of Commerce describes VEX as a companion document that lives side by side with SBOM and CVE scan results. VEX leverages the strategic value of SBoM and CVE scan reports by providing context to vulnerabilities and clarity of potential remediation measures. Thus, SecOps teams can reduce the noise and prioritize their efforts to remediate what matters the most.

In this blog post, you will learn how VMware Tanzu Application Catalog (formerly known as VMware Application Catalog) supports its users with SBoMs, CVE scan reports, and VEX documentation, how they complement each other, and how VEX statements provide an accurate risk assessment.

Differences between SBoMs, CVE scan reports, and VEX documents

The OSS applications in Tanzu Application Catalog undergo a thorough validation process before they are pushed to customers' private registries. As a result, users receive multiple build time reports through the user interface. These reports provide information on functional and integration tests, as well as crucial metadata related to the asset's build process. (For more details on these reports, please refer to our documentation).

Amongst these build time reports, you will find three key documents

SBoM (in software package data eXchange (SPDX) format) report
CVE scan result report
Common Security Advisory Framework (CSAF) VEX document

The UI of Tanzu Application Catalog shows the Build Time Reports section with the CSAF VEX document, CVE Scan Result ,and SBoM (SPDX) reports highlighted.

Let’s look at each of these reports in detail to better understand how they complement each other.

SBoM (SPDX)

NTIA defines the SBoM as “a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships.” In April, we announced that all applications in Tanzu Application Catalog will be delivered with a corresponding SBoM report in SPDX format allowing organizations to track application changes and have comprehensive information about author, supplier, and component names, as well as version details.

SPDX format is the de facto standard for SBoM approved by the International Standardization Organization (ISO). It has been utilized for several years by prominent companies like Microsoft, RedHat, Intel, or Synopsys.

This report is available not only for container images, but also for Helm charts and virtual machines. It can be downloaded from the Tanzu Application Catalog and also visualized in a graphical format thanks to the SPDX viewer. This allows customers to

View and inspect relationships between all level packages in an easy way
Check properties, licenses, and versions into multiple format and resources
Learn how packages are connected and which packages are included in which resources

Apache Spark SBoM report displayed as a graphic view.

CVE scan result

The applications in Tanzu Application Catalog are continuously scanned using Trivy and Grype scanners to detect vulnerabilities. As a result, we provide customers with a report that contains a list of the latest detected security vulnerabilities for a given component, a reference to their CVE-ID number, a description of the issue and which versions of the software are affected, the Common Vulnerability Scoring System (CVSS) score, and more. This report is delivered in the Common Vulnerability Reporting Framework (CVRF) standard format as well.

To quickly identify the number of vulnerabilities and their severity in each package, customers can navigate to the Tanzu Application Catalog Library section. To view, click on an application and check the CVE summary column before adding applications to their catalogs. This feature is only available for logged in users.

CVE summary accessible from the Tanzu Application Catalog Library for logged in users.

As mentioned earlier, SBoM and CVE scan results aim to paint a whole picture of your OSS supply chain but they do not provide context on the true risk you face from upstream vulnerabilities.

CSAF VEX document

A VEX document is a machine-readable type of security advisory developed by the NTIA. The primary use case of VEX, as defined by the NTIA is to provide users (e.g., operators, developers, and services providers) additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate.

The VEX documents provided by Tanzu Application Catalog follow CISA recommendations referred to in the use case "3.2.3 Single Product, Single Version, Multiple Vulnerabilities, Multiple Statuses", as you will see in the example below.

With SBoM and CVE scan results, customers have visibility into product changes and associated risks. However, it is a laborious task to investigate every vulnerability individually. Due to the elevated number of vulnerabilities that may be reported for a given OSS, without much context, security teams can be overwhelmed with data without any idea on how to prioritize those findings.

Some experts define VEX documents as a negative security advisory specifically designed to enumerate vulnerabilities that do not impact a product. From this perspective, VEX plays a pivotal role in boosting the efficiency of security teams by reducing the time spent investigating non-exploitable vulnerabilities that do not affect a given software product.

Let’s use the following vulnerability discovered in an Apache Cassandra container as an example to understand how VEX documentation can be used to reduce CVE noise.

Apache Cassandra VEX document showing CVE-2021-21489 details.

In the software supply chain, what usually happens is that an upstream supplier of the software (e.g., Netty) becomes aware of a vulnerability and starts analyzing it, after which they release a patch and advisory. The vendor of the software, Apache, who has Netty as one of the components of Cassandra, analyzes the vulnerability, finds that the vulnerability doesn’t meet the conditions to be exploitable, and so they neither release a patch nor an advisory, and close the issue in their project, marking it as “unaffected.”

The resolution for the above-mentioned CVE provided in Apache Cassandra’s official ticketing system.

However, vulnerability scanners still flag that vulnerability as critical. For users it would be a toilsome task to go back and forth between the SBoM file to check if that vulnerability affects any of the components of the application they use, check its criticality on the CVE scan result, and navigate through the upstream project issues dashboard trying to understand if they might be affected or not by that vulnerability.

Tanzu Application Catalog does that work for them. As a distributor of Cassandra, it creates a VEX document that provides a list of vulnerabilities that don’t affect the product as well as those that may affect it along with context and actions to minimize their impact.

VEX statement from Tanzu Application Catalog describing the resolution agreed by the upstream project highlighted.

This provides SecOps teams with the information to efficiently filter out false positives and enables them to focus on vulnerabilities that require immediate remediation.

This is a process that continuously repeats itself, so we can assert that VEX documents are dynamic while SBoM are more static documents. SBoM provides a fixed snapshot of application components, dependencies, licenses that are not meant to change and VEX relates to vulnerabilities, so it is constantly changing and evolving.

Learn more about VEX and how to gain actionable visibility into upstream vulnerabilities with VEX from Tanzu Application Catalog in this blog post and this demo video.

What’s next?

As you have learned, VEX documents serve as the perfect companion to SBoM and CVE scan results in helping you mitigate risks posed by upstream vulnerabilities. VEX documents enrich SBoMs with vulnerability details for each component and consolidate the CVE scan results to a focused list containing only those that require action.

Future versions of Tanzu Application Catalog will include even more functionality to enable users to manage application metadata. As a centralized database of SBoMs, CVEs, and VEX information, users will have the ability to perform catalog wide component searches and visualize component dependencies.

Furthermore, we are committed to promoting the adoption of the Common Security Advisory Framework (CSAF) format among third-party scanners and tools such as Trivy, working directly with them and with the CSAF team as well.

Learn more

As OSS plays an indispensable role in the software development processes of many businesses today, more and more enterprises are partnering with Tanzu Application Catalog to enable their developers to adopt OSS in a more secure and sustainable manner.

If you are interested in learning more about Tanzu Application Catalog in general, check out the product webpage, Tech Zone page, technical documentation, and additional resources. If you would like to get in touch, contact us.

Read about all the news announced by the VMware Tanzu team at VMware Explore 2023.