What is VEX

VEX and connection to vulnerability reports.

VEX (Vulnerability Exploitability eXchange) is a document format that allows vendors and operators to indicate whether a specific vulnerability (CVE) is applicable in a given product, component, or image. The goal is to reduce noise in scan reports: not all CVEs found are actually exploitable in your context (package version used, disabled feature, sandbox, etc.).

The VEX document links the artifact (for example, a container image), the vulnerability (CVE identifier) and the applicability status (affected / not_affected / fixed, and others), optionally with a justification. This helps:

• focus on really applicable vulnerabilities;
• reasonably exclude false positives in reports and policies (for example, “banning pods with critical vulnerabilities” taking into account VEX).

The VEX specification is developed within CISA and is associated with SBOM (Software Bill of Materials) formats. VEX support in scanning tools (including Trivy) allows such documents to be taken into account when generating reports and filtering vulnerabilities.

Use in the Shturval platform #

In the platform, image scanning is based on Trivy (Container Image Scanning Module, shturval-scanner). For every unfixed vulnerability in a platform component, the Shturval release ships a VEX report that explains why that CVE cannot be exploited in Shturval. Marked vulnerabilities are removed from the active list so that the GUI and policies (for example, blocking pods with critical CVEs) only count vulnerabilities that actually apply.

When the module is enabled, the cluster creates VulnerabilityReports. They are shown in the Security section on the Image Analysis page.

Platform VEX is enabled with a ShturvalServicePatch (SSP) on shturval-scanner: the operator reads documents from the VEX repository during the scan.

What you see in the GUI after enabling VEX #

After you enable VEX, the Image Analysis page keeps only the CVEs that still need to be handled. Vulnerabilities that Shturval marked as not applicable disappear from the table — the Critical / High / Medium / Low summary does not count them either. That is expected: they were removed because they are not exploitable on the platform, not because the scanner missed them.

To see which vulnerabilities were excluded, you can set trivy.showSuppressed: true in the SSP. It is off by default, and excluded CVEs are not stored anywhere. When suppressed vulnerabilities are enabled, the report contains data in report.modifiedFindings. Each entry has the CVE identifier, status, exclusion reason, and source (VEX).

kubectl get vulnerabilityreports -A

kubectl get vulnerabilityreport <name> -n <namespace> -o jsonpath='{.report.modifiedFindings}'

Enable VEX with SSP #

Set shturval-scanner to Auto before applying the SSP, otherwise it may not take effect. How to create an SSP: How to manage CustomValues.

Manifest parameters:

If the repository requires authentication, set vexRepo.username and vexRepo.password, or vexRepo.token.

apiVersion: ops.shturval.tech/v1beta2
kind: ShturvalServicePatch
metadata:
  name: shturval-scanner-vex
spec:
  shturvalServiceConfigName: shturval-scanner
  patchOrder: 100
  customvalues:
    trivy:
      showSuppressed: true
    vexRepo:
      enabled: true
      baseUrl: https://public.shturval.tech/repository/shturval_bin_public
      release: "2.15.0"
      name: shturval
      insecure: false
      skipUpdate: false
      preload: false

apiVersion: ops.shturval.tech/v1beta2
kind: ShturvalServicePatch
metadata:
  name: shturval-scanner-vex
spec:
  shturvalServiceConfigName: shturval-scanner
  patchOrder: 100
  customvalues:
    trivy:
      showSuppressed: true
      "-registry": {}
      configFile:
        registry:
          mirrors:
            r.shturval.tech:
              - mirror.example.com
        insecure: true
    vexRepo:
      enabled: true
      baseUrl: https://mirror.example.com/repository/shturval_bin_public
      release: "2.15.0"
      name: shturval
      insecure: true
      skipUpdate: false
      preload: true

1. Prepare an SSP manifest for shturval-scanner using the example above. Set the platform version in vexRepo.release and the repository address in vexRepo.baseUrl.

2. Import the manifest through Importing manifests.

   Screenshot: importing SSP

   

3. Open Services and repositories → Installed services → Container image scanning module (shturval-scanner). The Applied ShturvalServicePatch tab should show the SSP shturval-scanner-vex. When it is applied, the Service tab status is Patched.

4. Connect to the cluster in the CLI and delete previously created VulnerabilityReport objects:

   kubectl get vulnerabilityreports -A -o json | jq -r '.items[] | "\(.metadata.namespace) \(.metadata.name)"' | while read ns name; do kubectl delete vulnerabilityreport "$name" -n "$ns"; done
   

   Screenshot: deleting VulnerabilityReports

   

   Container image scanning restarts automatically.

5. Check that scanning starts and new VulnerabilityReports appear:

   kubectl get vulnerabilityreports -A
   

   Screenshot: new VulnerabilityReports

   

6. In the cluster GUI open Security → Image Analysis and confirm that marked vulnerabilities are gone from the main list.

   Screenshots: report before and after enabling VEX

   

   

   If the SSP sets trivy.showSuppressed: true, you can check excluded vulnerabilities in the resource:

   kubectl get vulnerabilityreports.aquasecurity.github.io -A -o json | jq -r '.items[] | select((.report.modifiedFindings // []) | length > 0) | "\(.metadata.namespace)/\(.metadata.name)\tmodified=\(.report.modifiedFindings | length)\tvulns=\((.report.vulnerabilities // []) | length)"'
   

Additional #

• CISA - VEX - description of format and use.
• Scanning container images - reports, criticality, marking of vulnerabilities in the platform.
• Container Image Scanning Module (shturval-scanner) - service parameters.
• How to manage CustomValues - creating and checking SSP.