When we talk about security related to the software supply chain and third-party software management, it’s key that the tools you use provide detailed reports on the known and unknown vulnerabilities inside applications along with the level of exploitability of those vulnerable components. Absent that, all you have is a listing of SBOM parts without much to act on.
Typically, you don’t want to co-mingle security information with an SBOM because it’s too dynamic—it’s always changing. You want an SBOM that has all of the composition and the licensing information (it’s static from version to version of your application) and then you want a separate document that’s a snapshot of the security state that cross-references the parts in the software bill of materials. To accomplish this, there are two approaches, both provided in the current release of SBOM Insights.
Vulnerability Disclosure Report (VDR)
A Vulnerability Disclosure Report (VDR) comes from either a software supplier or a third-party and is used to demonstrate proper and complete vulnerability assessments for components listed in an SBOM. NIST SP 800-161: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations defines VDR as:
Enterprises, where applicable and appropriate, may consider providing customers with a Vulnerability Disclosure Report (VDR) to demonstrate proper and complete vulnerability assessments for components listed in SBOMs. The VDR should include the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on a component or product. The VDR should also contain information on plans to address the CVE. Enterprises should consider publishing the VDR within a secure portal available to customers and signing the VDR with a trusted, verifiable, private key that includes a timestamp indicating the date and time of the VDR signature and associated VDR.
The VDR shows that you have done a proper job of disclosing all the vulnerabilities that exist for all the parts in your application(s). Think of a VDR as everything that has been reported against every single part in the application(s). It should contain the following:
- All vulnerabilities affecting a product or its’ dependencies (both direct and transitive)
- Analysis describing the impact (or lack thereof) that a reported vulnerability has on a product or dependency
- Mitigation plans to address the vulnerability
- A VDR signature with a trusted, verifiable, private key that includes a timestamp indicating the date and time of signing
A VDR should include two specific areas of information. The first is an enumeration of vulnerabilities that will give you the source, severity score, common weaknesses, and all the dates. The second bucket of data is a reference to the part(s) in the SBOM with which the vulnerability is associated.
A word of caution. A VDR report is most likely going to be fairly large and may contain irrelevant content. Just because some vulnerabilities are reported against a component, does not necessarily mean they ultimately impact your application or that there is impact to the components you’re using. It all depends on context and how the application is used. Each vulnerability really needs to be assessed for both impact and relevance to your application as it is used by your customers.
Vulnerability Exploitability eXchange
The Vulnerability Exploitability eXchange or VEX is the next artifact important to security transparency. VEX became popular with the NTIA Software Transparency initiative and now CISA picked up the ball and is running with it as an important element to the U.S. Executive Order (14028) issued back in May 2021:VEX became popular with the NTIA Software Transparency initiative and now CISA picked up the ball and is running with it as an important element to the U.S. Executive Order issued in 2021:
The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other parties to assert the status of specific vulnerabilities in a particular product.
Think of it as a negative security advisory. It’s used to explain what you’re going to do about a vulnerability or why a vulnerability does not impact your application. A VEX report should include:
- Analysis describing the impact (or lack thereof) that any vulnerability has on a product, product family, or organization
- Plans to address the vulnerability
- A VEX signature with a trusted, verifiable, private key including a timestamp indicating the date and time of the VEX signature
If we break up the VEX report into separate elements, it’s important to show the specific vulnerability information—similar to what’s in a VDR—as well as an analysis that provides the disposition of the vulnerability in your product.
VEX is a report your vendor or supplier will hand you if you’re embedding software or purchasing an application for enterprise use. Or, if it’s an SBOM for your product, your security or engineering team will annotate the vulnerabilities that are reported against your product to inform your downstream software supply chain and customers of true-positive risk in your application and your plans to address the false-positives.
Net, a VEX report is an opportunity for you to focus your analysis of reported security issues to only those items that are true positive and are actually exploitable via your application.
CISA recently released two new documents that might be of interest for further reading:
