SBOM Format Comparison: Which SCA/SBOM Format Is Best?

Imagine this conversation with your product manager:

Product Manager We need more security and we need it yesterday! I need engineering to produce SBOM reports showing we do security and that we do it Right (TM).

Engineer: Sure thing! What report format do you want? What SBOM requirements are you trying to meet?

PM: How am I supposed to know? You are the engineers. Just follow best industry practices. It should be easy. By the way, I need a solution by the end of the sprint.

‍

The "just" Pro tip, suggested by a friend and experienced engineer: Everything that comes after the word "just" in the description of a development task should be piped to /dev/null and you should fight for a better description.

‍

The exchange above may have never happened for you. If you're lucky, your PM/PO/CISO/Compliance Officer knew exactly what was needed, provided a complete specification, and understood the scope of the effort. 

If you are less fortunate, you may have been in multiple conversations like the above and come across numerous SCA and SBOM formats and acronyms in your search for solutions that meet requirements: SPDX, SARIF, CycloneDX, VEX to name a few.

Lots of great articles online explain what different SCA and SBOM formats are all about [1] [2] [3] [4].

But, what's the best format to use? Are there differences between the different SCA and SBOM formats? How strict are these standard formats and what can you expect? This is what we are covering in this article, with a few key points to help you decide:

‍

SCA vs. SBOM: Is there a difference?

Yes! The terms SCA and SBOM are sometimes used interchangeably online, which creates confusion. This confusion is exacerbated by the fact that some formats (e.g., CycloneDX) attempt to capture both SBOM and SCA reports. 

However, there are two key differences between SBOM and SCA:

1. SBOM is about contents, while SCA is about security/risk. 

• SBOM reports all the components of your software package. 
• SCA reports all the vulnerabilities included in your software package.

2. SBOM is static while SCA is dynamic. 

SBOM: The contents of your software package (SBOM) are determined at build/release, so the report is static/fixed. 

SCA: The vulnerabilities that affect your package:

1. change constantly across time 

Ex: Today you have a clean report, but tomorrow two new vulnerabilities are identified. 

2. are affected by security scanners 

Ex: Scanner A may report a finding scanner B missed.

‍

Do I need both SBOM and SCA reports?

Yes! Best practices recommend having both SBOM artifacts for supply-chain transparency and compliance, as well as SCA artifacts for security and risk management produced as part of your SDLC.

Don't have time to follow best practices and produce both? Try to weigh what is more important for your organization and stakeholders—is it supply-chain transparency/compliance or security/risk management?

‍

‍

SBOM Format Comparison: Which Format Should I Use?

At their core, all SBOMs are composed of the same three elements outlined in the NTIA report, though certain formats are more suitable for different industries and use cases.

Here are some considerations for when you should use different SBOM formats:

‍

If you need an SBOM artifact…

Use the SPDX SBOM Format. 

Why? SPDX:

• Communicates SBOM information, including components, licenses, copyright, and security references.
• Is an open standard, mature development process with the Linux foundation and an active team developing it.
• Has extensive tooling support.

‍

When to Not Use the SPDX SBOM Format

Your PM asked for a different format or has different requirements for what's needed out of the SBOM artifact.

‍

If you need to report vulnerabilities from scanners…

Use the SARIF SBOM Format 

Why Use SARIF:

1. Built to accommodate analysis results ranging from compiler warnings to security vulnerabilities.
2. OASIS standard with multiple organizations and an active team developing it.
3. Nearly all scanners support emitting SARIF reports. Significant ecosystem support [1] [2].

‍

When to Not Use the SARIF SBOM Format

Your PM asked for a separate format or perhaps something that combines security findings with SBOM like CycloneDX.

‍

If you want SPDX SBOM Format with security findings within the report…

Don’t worry - The SPDX team recently released v3.0 which provides direct support for including security findings within the SBOM report. No tools are currently producing v3.0 reports (yet!) but we expect that to change very very soon.

‍

Deciding Between Different SBOM and SCA Formats and Tools

Deciding between which SCA and SBOM formats and tools to use can be difficult. You might want to use multiple SCA and SBOM tools, then merge the data between them to create one report. 

But is that easy to do?

‍

Using Multiple SCA/SBOM Tools: Is the data easily mergeable?

Unfortunately not. Even though both SPDX and SARIF are standardized, the schemas they provide are too flexible and allow report producers to generate very disparate reports. 

‍

SBOM Format Example

For example, consider the following two reports for the exact same finding in the exact same package from two different tools (grype vs trivy):

{
    "id": "CVE-2016-3189-libbz2-1.0",
    "name": "DpkgMatcherExactIndirectMatch",
    "shortDescription": {
        "text": "CVE-2016-3189 medium vulnerability for libbz2-1.0 package"
    },
    "fullDescription": {
        "text": "Version 1.0.6-7+b3 is affected with an available fix in versions 1.0.6-7+deb8u1"
    },
    "helpUri": "https://github.com/anchore/grype",
    "help": {
        "text": "Vulnerability CVE-2016-3189\nSeverity: medium\nPackage: libbz2-1.0\nVersion: 1.0.6-7+b3\nFix Version: 1.0.6-7+deb8u1\nType: deb\nLocation: /usr/share/doc/libbz2-1.0/copyright\nData Namespace: debian:distro:debian:8\nLink: [CVE-2016-3189](https://security-tracker.debian.org/tracker/CVE-2016-3189)",
        "markdown": "**Vulnerability CVE-2016-3189**\n| Severity | Package | Version | Fix Version | Type | Location | Data Namespace | Link |\n| --- | --- | --- | --- | --- | --- | --- | --- |\n| medium  | libbz2-1.0  | 1.0.6-7+b3  | 1.0.6-7+deb8u1  | deb  | /usr/share/doc/libbz2-1.0/copyright  | debian:distro:debian:8  | [CVE-2016-3189](https://security-tracker.debian.org/tracker/CVE-2016-3189)  |\n"
    },
    "properties": {
        "security-severity": "6.5"
    }
}

‍

vs.

{
    "id": "CVE-2016-3189",
    "name": "OsPackageVulnerability",
    "shortDescription": {
        "text": "bzip2: heap use after free in bzip2recover"
    },
    "fullDescription": {
        "text": "Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start of the block."
    },
    "defaultConfiguration": {
        "level": "warning"
    },
    "helpUri": "https://avd.aquasec.com/nvd/cve-2016-3189",
    "help": {
        "text": "Vulnerability CVE-2016-3189\nSeverity: MEDIUM\nPackage: libbz2-1.0\nFixed Version: 1.0.6-7+deb8u1\nLink: [CVE-2016-3189](https://avd.aquasec.com/nvd/cve-2016-3189)\nUse-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start of the block.",
        "markdown": "**Vulnerability CVE-2016-3189**\n| Severity | Package | Fixed Version | Link |\n| --- | --- | --- | --- |\n|MEDIUM|libbz2-1.0|1.0.6-7+deb8u1|[CVE-2016-3189](https://avd.aquasec.com/nvd/cve-2016-3189)|\n\nUse-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start of the block."
    },
    "properties": {
        "precision": "very-high",
        "security-severity": "6.5",
        "tags": [
            "vulnerability",
            "security",
            "MEDIUM"
        ]
    }
}

‍

The two reports are similar, but far from identical. Crucially, the identifiers for the findings (CVE-2016-3189-libbz2-1.0 vs CVE-2016-3189) are not standardized and neither are the property contents. 

Beyond these differences, SBOM/SCA tools will report different sets of findings which creates follow up questions like "which SBOM tool should I be using?" - something we'll tackle in a follow up article.

‍

I have too many vulnerabilities in my SBOM/SCA report! What do I do now?

Possibly the most painful realization for engineers after they integrate SBOM and SCA solutions in their SDLC is the fact that they now have to deal with possibly thousands of newly identified vulnerabilities within their software. 

After all this work to produce SBOM/SCA artifacts, more work needs to be done to remediate them—a non-trivial task that may take weeks or even months!

‍

SBOM Management: Mayhem's Dynamic SBOM.

The good news? Over 60% of SBOM/SCA findings are in packages that are included in your software, but are entirely unused at runtime. 

Mayhem's Dynamic SBOM enables you to cut through the noise and automatically update your reports so that you can focus on vulnerabilities that are actually reachable and not waste time on findings that are not on your attack surface.

Mayhem also allows you to merge and filter the data between different scanning tools easily, so that you have all of the real vulnerability results in one place.

‍