Fortress Information Security is releasing three Vulnerability-Exploitability eXchange (VEX) advisories for Fortress products File Integrity Assurance (FIA), Asset to Vendor Network (A2V), and Fortress Platform covering the Log4j vulnerabilities CVE-2021-44228 and CVE-2021-45046.

On December 9, 2021, a 0-day exploit in the popular Java logging library Log4j version 2 was discovered which allows an attacker to perform Remote Code Execution (RCE) by logging a certain string. This is a critical vulnerability and could allow for full server control. A Fortress Threat Intelligence Report with threat identification and technical analysis is available here.

Explanation of Advisory Information

For both FIA and A2V, neither product is affected by the Log4Shell vulnerabilities as the Log4j component is not present in either product. Both products do not contain any java components. SBOMs were reviewed for direct dependencies and transitive dependencies to confirm the absence of the Log4j component. Transitive dependencies are the dependencies of a component’s direct dependencies. These added components have their own lifecycle, licenses and copyrights, bugs, and vulnerabilities.

Fortress Platform is affected by Log4Shell but not vulnerable due to default configuration. A third-party application shipped as part of on-premises installations of Fortress Platform, VMware vCenter, is affected. However, the application is configured by default so that it is not exposed externally and cannot be exploited by an attacker.

What is a VEX?

Vulnerability-Exploitability eXchange (VEX) was developed to fill vulnerability management needs around the use of software bills of materials (SBOMs). SBOMs explain what software components are contained within a product. VEXs are companion documents that explain if a product is affected by a newly discovered vulnerability, like Log4j.

Its primary use case is for software producers to inform users on whether a product is affected by a specific vulnerability in a component and provide remediation instructions. VEX’s are designed to be machine-readable to enable automation and to integrate with existing tools and vulnerability management processes. Combined with the component information from an SBOM, users can quickly get an up-to-date view of their exposure to component vulnerabilities, instead of expending significant resources and time on a manual analysis.

VEXs are flexible and can be used to inform users of the status of a specific product vulnerability investigation. Statuses include:

  • Under Investigation, meaning the issue is being researched, and it is not known if the product is affected by the vulnerability. A subsequent VEX can be used to update the status
  • Known Not Affected, meaning no remediation is required
  • Known Affected, actions may need to be taken to address the vulnerability, such as performing a configuration change
  • Fixed, meaning a new product version contains a fix for the vulnerability

VEXs also contain an impact statement to clearly explain why a product is or is not affected. In many cases, a vulnerability in an upstream component will not be exploitable in the final product due to the vulnerable code not being present, or if the vulnerable code cannot be controlled by an attacker due to protections elsewhere in the product.

How to Read a VEX Document

VEX documents currently have one format, Common Security Advisory Framework (CSAF), version 2. OASIS Open, an open standards body, develops and maintains CSAF. A CSAF based VEX document has a few major sections:


This section has metadata about the document’s publisher, revision history, and release date.

Includes product identifying information, for example, vendor name, product family, product name, and product version. A VEX document can contain information on one or multiple products from the same company.
This section has information on the specific vulnerability the advisory is about, such as:

  • CVE (Common Vulnerabilities and Exposures) ID number
  • CWE (Common Weakness Enumeration), which is a listing the software or hardware weakness type
  • Description of the vulnerability
  • An impact statement detailing why a product is or is not affected by the vulnerability
  • Remediation instructions

A VEX can inform on one or more vulnerabilities. This section may also include CVSS score information and external links to for more information, for example, the National Vulnerability Database (NVD).