In the rapidly evolving realm of software development, robust security measures are vital to safeguard valuable data and protect companies from potential cyber threats. However, the prevalence of false positives inundates software providers with inquiries regarding flagged vulnerabilities that pose no actual risks.
Fortunately, there is a groundbreaking solution exists called Vulnerability Exploitability eXchange (VEX).
What is the Vulnerability Exploitability eXchange (VEX)?
VEX is an essential tool for managing vulnerabilities and works alongside theSoftware Bill of Materials (SBOM) to handle security concerns effectively. It helps software vendors to find and prioritize important threats and evaluate security weaknesses effectively.
In this article:
The Challenge of False Positives
Imagine this: You’ve been blessed and highly favored; you have solved a common modern-day problem by developing a useful application. You have been in the business long enough to know that neglecting 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 vulnerability 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 needs to become more of a priority for all and that as a result software providers should be “providing a purchaser an 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 person that you are aware of these vulnerabilities and why they should not worry about them. However,as time contnues, the volume of people asking you these same questions starts to drain your resources. What is a developer to do?
The Power of SBOMs 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 SBOMs.
What is interesting about the VEX document is that it is the yang to your SCA tool finding’s yin. 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 the software provider is aware that it uses a certain vulnerable library. Still, 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 using your product & freeing up your own time to go outside and 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 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.
Diving Deeper: Components and Structure of a VEX Report
A comprehensive VEX report typically comprises several key components, including:
- Vulnerability ID: A unique identifier for the vulnerability in question.
- Product ID: The identifier for the product or component being assessed.
- Exploitability Status: A clear status indicating whether the vulnerability is exploitable in the given context.
- Justification: A detailed explanation providing the rationale behind the exploitability status, which may include information on the configuration, usage, or mitigations in place.
So, 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 relevant to the software provider is the analysis node seen above, as all other parts are automatically generated by the SBOM creation tool. MergeBase dashboards allow developers to generate these analysis fields through the vulnerability panel.
Creating a VEX Report with MergeBase
Step-by-Step Guide to Generating an SBOM + VEX Report
Generating a VEX report with MergeBase is straightforward. Let’s look at how we can do this:
1. Go to your main dashboard and select a project 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 to 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 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 users understand the false positives that they will not have to spend time resolving.
Elevate Your Software Security with VEX and MergeBase
Vulnerability Exploitability eXchange (VEX) is a powerful solution for managing vulnerabilities and false positives, working hand-in-hand with the Software Bill of Materials (SBOM). It offers a unique approach, aiding software vendors in identifying and assessing security vulnerabilities effectively.
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 prevent your software development process. Leverage the power of VEX with MergeBase and embark on a safer and more reliable software journey.
