Introducing Vulnerability Exploitability eXchange (VEX): A Solution for False Positives

In the rapidly evolving realm of software development, robust security measures are vital to safeguard valuable data and protect companies from potential threats. However, the prevalence of false positives inundates software providers with inquiries regarding flagged vulnerabilities that pose no actual risks. Fortunately, there exists a groundbreaking solution called Vulnerability Exploitability eXchange (VEX), which is integrated with the Software Bill of Materials (SBOM)to address these concerns effectively.

The Challenge of False Positives

Imagine this: You’ve being blessed and highly favoured you have solved a common modern-day problem by developing a very useful application. You have been in the business long enough to know that shirking your security responsibilities is not profitable, so you diligently scanned your application throughout the whole development process by using the MergeBase SCA tool.

As it uncovered vulnerabilities you looked them up in the NVD database, sometimes even going so far as downloading the component’s source code in order to really get a sense of whether or not the library’s vulnerability touched the specific component you used. Depending on what you found you either switched out the library, decided that the vulnerability did not apply to your application, or then decided to live with it as there is no other viable choice & it is exploitable only under very specific conditions.

You release your application to the wild, and people love it! Someone makes a funny video on TikTok using it, and suddenly you’re getting thousands of downloads a week. All is good, and you have captured the brass ring.

Then comes the day when a very solemn president declares that security in open-source libraries a needs to become more of a priority for all, and that as a result software providers should be “providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website”. No worries, you think to yourself, you will just use the MergeBase SBOM tool to create one for your application and provide it to every user. What a great idea, you think to yourself, transparency is key!

However, you are not the only person keeping an eye on open-source vulnerabilities by using an SCA tool, and you are getting more and more emails each week asking you about the vulnerabilities being flagged, and asking if you can patch it. You explain to each that you are aware of these vulnerabilities & explain why they are not to be worried about, but as time goes on the volume of people asking you these same questions starts to drain your resources. What is a developer to do?

The Power of Software Bill of Materials (SBOM) and VEX

The good thing is that you are not the only software provider in this predicament, and so an interesting solution has been proposed: the VEX (Vulnerability Exploitability eXchange) document which tags along with your SBOM.

What is interesting about the VEX document is that it is the yang to your SCA tool finding’s yin. That is, instead of pointing out the vulnerabilities you should worry about, it points out the vulnerabilities you shouldn’t worry about. It takes your user’s hand and gently lets them know that yes, the software provider is aware that it uses a certain vulnerable library, but the vulnerability does not affect their product for a clearly specified reason.

This VEX document, which is standardized & machine-readable, replaces the need to have a human reply to all concerned parties about certain vulnerabilities, making your user more comfortable in using your product & freeing up your own time to go outside and maybe touch grass once again.

Having said all of that, VEX implementation is still nascent as it still requires human intervention. As much as we would like to delegate all of the boring tasks to the ghost in the machine, this is very much a task in which people need to check the work of the automated tool in order to save the user’s own precious time.

MergeBase has decided to help its users create this VEX document by integrating the MergeBase dashboard UI with the SBOM creation tool.

Creating a VEX Report with MergeBase

A VEX json document looks like this:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata" : {
    "timestamp" : "2022-03-03T00:00:00Z",
    "component" : {
      "name" : "ABC",
      "type" : "application",
      "bom-ref" : "product-ABC"
    }
  },
  "vulnerabilities": [
    {
      "id": "CVE-2021-44228",
      "source": {
        "name": "NVD",
        "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228"
      },
      "ratings": [
        {
          "source": {
            "name": "NVD",
            "url": "https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI
            :N/S:C/C:H/I:H/A:H&version=3.1"
          },
          "score": 10.0,
          "severity": "critical",
          "method": "CVSSv31",
          "vector": "AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
        }
      ],
      "analysis": {
        "state": "exploitable",
        "response": ["will_not_fix", "update"],
        "detail": "Versions of Product ABC are affected by the vulnerability. 
        Customers are advised to upgrade to the latest release."
      },
      "affects": [
        {
          "ref": "product-ABC",
          "versions": [
            {
              "version": "2.4",
              "status": "affected"
            },
            {
              "version": "2.6",
              "status": "affected"
            },
            {
              "range": "vers:generic/>=2.9|<=4.1",
              "status": "affected"
            }
          ]
        }
      ]
    }
  ]
}  

The part that is relevant to the software provider is the analysis node seen above in bold as all other parts are automatically generated by the SBOM creation tool. MergeBase dashboards allow the developer to generate these analysis fields through the vulnerability panel.

Step-by-Step Guide to Generating an SBOM + VEX Report

Let’s look at how we can do this:

1. Go to your main dashboard and select a project you want to generate an SBOM + VEX report.

2. From the project page, navigate to the list of components found in the project.

3. Select a vulnerability that you would like to exclude in the VEX JSON. Here is an example component panel:

4. Click on the change link which will bring you to this panel.

5. Fill in the fields as needed:

• First choose the status of the vulnerability from the dropdown.

• Choose the justification from the dropdown.

• Fill in the details section with more information about your justification.

6. Once these fields have been filled for all of the appropriate fields download the CycloneDX SBOM + VEX report to see your work.
7. Within the SBOM json look for the analysis field.

And there you have it! You have now generated your SBOM + VEX report with MergeBase, helping your user to understand the false positives that they will not have to spend time resolving.

Elevate Your Software Security with VEX and MergeBase

In an era where false positives can burden software providers, Vulnerability Exploitability eXchange (VEX) emerges as a powerful solution. By integrating VEX functionalities seamlessly into the MergeBase, developers can enhance their software security measures and effectively address user concerns regarding flagged vulnerabilities.

Don’t let false positives impede your software development process—leverage the power of VEX with MergeBase and embark on a safer and more reliable software journey.