CSP Academy Answers: Does That Software Package Contain Vulnerabilities?

In our previous post, we outlined what a software bill of materials (SBOM) is, how it is created, and what the benefits are of creating and using SBOMs. This is part of our series of blog posts about the security of the software supply chain.

In this post, we’re going to look at what to do with an SBOM, and how to establish whether there are any potentially damaging vulnerabilities (security flaws) lurking in the code that it catalogues.

You’ve received an SBOM. So what?

You’ve received an SBOM alongside a code package, or you’ve received an updated SBOM for a product already in use. You now have more information than you would have had before about the components of the code you are using (or are planning to use).

Ideally, you will want to check that code package for vulnerabilities. New vulnerabilities arise all the time, so this is likely to be an ongoing process. (Want to remind yourself about vulnerabilities?)

You could do it manually, comparing the components listed in the SBOM with publicly available lists of vulnerabilities (for example at www.cve.org ). This is likely to be both time-consuming and difficult, so you will probably do it automatically, using one of the many tools available; the SBOM is designed to be machine readable.

By doing this, you may discover that there are multiple vulnerabilities. Most of these, however, are likely to be irrelevant: for example, though there is an identified vulnerability (X) in component Y, the code package being considered is not affected by X. Unless you are very familiar with the structure of the code, you are unlikely to be able to quickly identify which are irrelevant, and which are problematic—and this could be a very significant task.

You might think at this point that all the SBOM is doing for you is making more work—but there is a way forward.

Vulnerability disclosures

Software suppliers can provide you with information about the vulnerabilities that their product is known to have, using a VDR, and about those that it is known not to have, using a VEX:

• A VDR (vulnerability disclosure report) is a list of known vulnerabilities within the associated code package and is published by the software vendor. There is no specified format, but it should list the vulnerabilities, details about them, the likely impact—what an attacker might be able to do as a result—and recommended actions to take.
• A VEX (vulnerability exploitability exchange), also provided by the software vendor, is intended to reduce the number of irrelevant alerts, so you can quickly identify and focus on those vulnerabilities that could be a problem for you.

Both have their place, but today we will focus on the VEX.

What is a VEX?

Where the SBOM is a list of what is in a package, the VEX indicates which vulnerable components in that package could, in practice, be used by an attacker.

Like the VDR, it is a security advisory issued by a software creator describing the vulnerability status of their product. Unlike the VDR, it is machine readable, built for integration into security management tools and vulnerability tracking platforms, and intended to support more effective use of SBOMs by clarifying whether the vulnerability identified by the SBOM is likely to affect your business.

Not every vulnerability in a package can be exploited by an attacker. The VEX shows which vulnerabilities are in the package and—importantly—the status of that vulnerability. This includes whether each vulnerability in that specific package can be exploited by an attacker—and therefore whether it is a risk to your business—and provides information about the actions the supplier is taking, and/or the action they recommend to you.

By removing the false positives from consideration, a VEX helps reduce the vulnerability management workload for your business and helps prioritise the actions needed.

What is in a VEX?

The VEX issued by the software supplier should contain the following types of information:

• The product name and version it applies to, with a product identifier, so that you should know exactly which product is relevant

• Vulnerability identifiers, and possibly descriptive information, so you can find out more about each vulnerability
• The status of each vulnerability listed: affected / not affected / under investigation / patched. This is so you know whether that vulnerability can be exploited in that product, or whether to expect more information from the supplier once investigation is complete
• If the status is ‘affected’, then an explanation of a potential mitigation for the vulnerability. For example, recommendations to upgrade, or where to find a patch.
• If the status is ‘not affected’, then an explanation of why the product is not affected. This might be, for example, because the vulnerable code is not executed by the product, cannot be triggered by an attacker, or there are mitigations already in place.
• A timestamp for the VEX.

There may be other information included, such as the related SBOM details.

What is the point of VEX?

The point of the VEX is to speed up the identification of vulnerabilities in reused components in code, to reduce false positives (and therefore reduce the workload).  

It provides actionable information to support the management of software supply chain risk.   

As you can see from the image below, the SBOM may provide you with more information, but you need more information to be able to do something useful with that information—and that is what the VEX is intended to provide. 

The SBOM + VEX together provide a list of exploitable vulnerabilities in your software package. This means you can assess the risks of each vulnerability to your business and decide what action you will take to mitigate each risk.

What are the benefits of SBOM / VEX?

The obvious benefits of implementing SBOM and VEX are:

• In general: the standardization of information about the components of software, and therefore also transparency for the consumer of the software.
• For the consumer: understanding what exploitable vulnerabilities are in the software you are using, and therefore what the risks are to your business. You can then establish how you will mitigate them.
• For the developer: the ability to identify and mitigate vulnerabilities in the code being developed—improving the security of the product.

Additional benefits include the potential for:

• Faster incident response (because you have more knowledge of the vulnerabilities)
• Improved vulnerability management / patch triage (because you can take a risk-based approach)
• Provision of evidence for stakeholders conducting due diligence into your business (because you have more information)
• Improvements in customer service
• Better completion of software licence tracking and verification
• And possibly the reduction of penetration testing required (or at least, the fine-tuning of testing) because you will have more knowledge of the vulnerabilities in the code.

In this series, we have discussed SBOMs and VEX to explain what they are and the purpose they are intended to serve in supporting security in your business:

• Blog 1: SBOMs, VDR and VEX for Business People 
• Blog 2: What’s in that Software Package? 

If you’d like more information, or to discuss how CSP could help you with the security of your supply chain—or any other cyber security issues that are worrying you—contact us on 0113 5323763 or via the webfor