You’ve likely heard of an SBOM – a software bill of materials. It’s an accounting of the libraries and dependencies in your application.

You might be aware of its two companions:

1. Vulnerability Disclosure Report (VDR)
2. Vulnerability Exploitability eXchange (VEX)

Let’s learn what each of these are and how they keep our supply chains secure.

What is a Vulnerability Disclosure Report?

NIST’s Software Supply Chain Security guidance covers “(ix) attesting to conformity with secure software development practices;” and provides further guidance on how to accomplish that with a Vulnerability Disclosure Report.

It’s a pretty simple concept: alongside your SBOM, show that you’ve scanned and understand the known vulnerabilities attached to each software dependency.

What format is this report? NIST has another document (SP 800-161 R1 requirement RA-5) for that, but a quick summary is to do the following:

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.

Each SBOM sent to EdgeBit is scanned, so we already have all of the relevant information to produce a VDR automatically.

Guidance is also provided to publish this information to your customers for their consumption:

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.

For internal consumption, things can get more interesting. One of our future goals is to use this information as the foundation for a trust score or trust fingerprint of a running system or application instance. Other services could trust or not trust the service, like today’s service meshes do, but backed by security state rather than identity alone.

What is a Vulnerability Exploitability eXchange report?

A VEX report goes alongside an SBOM and VDR to communicate if and how a vulnerability can impact the security of the software when it’s running.

• Is it active or dormant?
• What components or configuration should I pay more attention to when assessing the risk of this version?
• What is the plan to fix this?

A VEX report can be summed up in the statements section of its structure:

"statements": [
{
    "vulnerability": {
    "@id": "CVE-2019-1010022"
    },
    "timestamp": "2023-09-18T14:07:00.1097922Z",
    "products": [
    {
        "@id": "pkg:deb/debian/libc6@2.36-9?arch=amd64&upstream=glibc&distro=debian-12",
        "identifiers": {
        "purl": "pkg:deb/debian/libc6@2.36-9?arch=amd64&upstream=glibc&distro=debian-12"
        }
    }
    ],
    "status": "affected",
},

CVE reports have some of this same metadata about whether it will be fixed or not, and which version is known to be safe. A VEX report is one layer higher because it’s augmented with the knowledge of how it’s used within a project or product.

EdgeBit uniquely connects “build” and “run” for SBOMs

EdgeBit understands the build pipeline of your software, so it can produce and analyze the SBOM for each release and has all of the facts for a VDR at the same time.

EdgeBit also uniquely can connect the build-time SBOM to the live state of your infrastructure, so it can also make an automated determination about the impact of vulnerabilities inside of dormant dependencies.

Using this context, the VEX answer is easy:

"statements": [
{
    "vulnerability": {
    "@id": "CVE-2019-1010022"
    },
    "timestamp": "2023-09-18T14:07:00.1097922Z",
    "products": [
    {
        "@id": "pkg:deb/debian/libc6@2.36-9?arch=amd64&upstream=glibc&distro=debian-12",
        "identifiers": {
        "purl": "pkg:deb/debian/libc6@2.36-9?arch=amd64&upstream=glibc&distro=debian-12"
        }
    }
    ],
    "status": "not_affected",
    "justification": "vulnerable_code_not_in_execute_path",
    "impact_statement": "EdgeBit automated analysis indicates that the vulnerable code is dormant and not executed"
},

Of course, this doesn’t cover active dependencies that requires application-specific knowledge to make a security determination.

Try out EdgeBit

Try out EdgeBit to start using SBOMs to secure your supply chain and simplify your vulnerability management by focusing on code that’s actually running. I think you’ll be surprised by the ratio of active to dormant dependencies - we’re seeing about 20-40% are actually active.

Our engineers would love to chat with you about your plans for producing Vulnerability Disclosure Reports (VDR) and Vulnerability Exploitability eXchange (VEX) reports.

Get Started with EdgeBit

Here’s a quick 1 minute teaser: