Software supply chain security has become a critical concern for financial institutions and public sector organizations worldwide. Following the 2020 SolarWinds hack, the industry realized just how crucial transparency in software components really is.

The software you use contains hundreds or thousands of open-source libraries and third-party components. If even one vulnerability is exploited, your entire system could be at risk. This is precisely why SBOM, VDR, and VEX have emerged as essential concepts.

Today, I’ll break down these three concepts in detail so you can apply them directly in your work.

 

 

01. Why Has Supply Chain Security Become So Critical?

The software development landscape has changed dramatically. In the past, we wrote all our code from scratch. Now, 70-90% consists of open-source or third-party libraries.

Remember the Log4Shell vulnerability (CVE-2021-44228) from 2021? Millions of applications worldwide were affected, and many companies couldn’t even determine if their software contained the vulnerable library.

This state of “not knowing what’s in our systems” is no longer acceptable. The Biden administration’s Executive Order 14028 mandated SBOM submissions, and governments worldwide are strengthening software supply chain security guidelines.

 

 

 

02. What is SBOM? The Software Ingredient List

Definition and Purpose

SBOM (Software Bill of Materials) is literally a “software parts list.” Like a nutrition label on food products, it’s a document that details every component, library, and module that makes up your software.

An SBOM includes:

Item	Description	Example
Component Name	Library or package name	Apache Log4j
Version	Exact version number	2.14.1
Supplier	Developer/distributor	Apache Software Foundation
License	Usage terms	Apache License 2.0
Dependencies	Relationships with other components	slf4j-api 1.7.25
Hash Value	Integrity verification	SHA-256: a1b2c3…

Practical Applications

How is SBOM used in real-world scenarios?

Rapid Vulnerability Response
When a critical vulnerability like Log4Shell is announced, having an SBOM lets you identify the impact scope within 5 minutes. Without it, the process could take days.

License Compliance
Mistakenly including GPL-licensed open source in commercial software can create legal issues. Reviewing licenses through SBOM prevents these risks.

Supply Chain Transparency
It provides objective evidence to prove “our software is secure” to customers or regulatory agencies.

 

 

03. SBOM Standard Formats

SBOM can be written in several formats, with three industry standards leading the way.

SPDX (Software Package Data Exchange)

An ISO/IEC 5962 international standard developed by the Linux Foundation.

Features:

• Longest history and most mature standard (started 2010)
• Supports multiple formats: JSON, XML, YAML, RDF
• Particularly strong in license information

Example (JSON format):

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "MyApp-SBOM",
  "packages": [{
    "name": "log4j-core",
    "SPDXID": "SPDXRef-Package-log4j",
    "versionInfo": "2.17.1",
    "licenseConcluded": "Apache-2.0"
  }]
}

Official site: https://spdx.dev/

CycloneDX

Managed by OWASP (Open Web Application Security Project), specialized for security.

Features:

• Integrated support for vulnerability information (including VEX)
• Extensible to Service BOM (SaaSBOM), Hardware BOM
• Supports JSON, XML formats
• Popular among security professionals

Example (JSON format):

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [{
    "type": "library",
    "name": "log4j-core",
    "version": "2.17.1",
    "purl": "pkg:maven/org.apache.logging.log4j/[email protected]"
  }]
}

Official site: https://cyclonedx.org/

SWID (Software Identification Tag)

ISO/IEC 19770-2 standard, focused on software asset management.

Features:

• Easy integration with enterprise IT asset management
• XML-based
• Strong in tracking installed software

In practice, CycloneDX and SPDX dominate. Choose CycloneDX if security is your focus, SPDX if license management is paramount.

 

 

04. What is VDR? Vulnerability Disclosure Report

The Concept

VDR (Vulnerability Disclosure Report) is a document that details security vulnerabilities discovered in software. It links with CVE (Common Vulnerabilities and Exposures) information and includes:

Component	Content
Vulnerability ID	CVE-2021-44228
Severity	CVSS Score (0-10)
Affected Versions	Log4j 2.0-beta9 ~ 2.14.1
Description	JNDI Injection remote code execution
Disclosure Date	2021-12-09
Patched Version	2.15.0 and above

Practical Use

Vulnerability Prioritization
Critical vulnerabilities with CVSS scores of 9.0 or higher require immediate patching. VDR clarifies which vulnerabilities to address first.

Patch Planning
When vulnerabilities are found, you might patch immediately or apply updates gradually after testing for system stability. VDR provides the foundation for these decisions.

Regulatory Compliance
When regulatory agencies request vulnerability management status, VDR records enable systematic responses.

 

 

05. What is VEX? The Key to Determining Vulnerability Impact

Definition

VEX (Vulnerability Exploitability Exchange) takes the concept one step further than VDR.

It documents the assessment that “while a vulnerability exists, it cannot actually be exploited in our system.”

Consider this example: Your application includes Log4j 2.14.1, which contains the Log4Shell vulnerability. However, your code never uses that functionality, or firewall rules block external access.

In these cases, VEX can specify “Not Affected” or “Mitigated.”

VEX Status Classifications

VEX categorizes vulnerability status as follows:

Status	Description
Not Affected	Vulnerable code path is not used
Affected	Actually exploitable and requires action
Fixed	Patch applied
Under Investigation	Analyzing impact

Real-World VEX Example

Right after the Log4Shell disclosure, countless organizations were confused: “We have Log4j, but are we really at risk?”

With VEX, they could have documented:

{
  "vulnerability": {
    "id": "CVE-2021-44228",
    "status": "not_affected",
    "justification": "vulnerable_code_not_in_execute_path",
    "statement": "Log4j is included, but JNDI lookup is disabled in configuration and no external input is accepted."
  }
}

 

 

06. The SBOM-VDR-VEX Integration Process

Let’s examine how these three concepts connect in actual workflows, step by step.

Step 1: SBOM Generation

First, automatically generate the SBOM during software build.

Methods:

• Java/Maven: Use CycloneDX Maven Plugin
• JavaScript/npm: Use SPDX-SBOM-Generator
• Python/pip: Use cyclonedx-python
• Container: Use tools like Syft, Trivy

For a Maven project, add the plugin to pom.xml:

<plugin>
  <groupId>org.cyclonedx</groupId>
  <artifactId>cyclonedx-maven-plugin</artifactId>
  <version>2.7.10</version>
  <executions>
    <execution>
      <goals>
        <goal>makeAggregateBom</goal>
      </goals>
    </execution>
  </executions>
</plugin>

The target/bom.json file is automatically generated during build.

Step 2: Vulnerability Scanning and VDR Generation

Cross-reference the SBOM with vulnerability databases (NVD, OSV, etc.) to generate VDR.

Tools:

• Dependency-Check: Free tool from OWASP
• Grype: Open-source scanner from Anchore
• Trivy: Container/SBOM scanner from Aqua Security

Example command:

# Scan SBOM with Grype
grype sbom:./bom.json -o json > vdr.json

Step 3: VEX Creation and Distribution

Security or development teams review the VDR, assess actual impact of each vulnerability, and create VEX.

Creation Tools:

• CycloneDX CLI tools
• Manual creation (JSON/XML)
• Automation scripts (Python, Go, etc.)

Complete Process Flow

[Source Code] 
    ↓
[Build System]
    ↓ (SBOM Generation)
[SBOM File]
    ↓ (Vulnerability DB Query)
[Vulnerability Scanner]
    ↓ (VDR Generation)
[VDR File]
    ↓ (Security Team Analysis)
[VEX Document]
    ↓ (Distribution)
[Customers/Regulators]

 

 

 

07. Recommended Tools: Get Started Today

Free Open-Source Tools

1. Syft + Grype (Anchore)

The most popular combination.

Installation (Linux/Mac):

# Install Syft (SBOM generation)
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Install Grype (vulnerability scanning)
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

Usage:

# Generate SBOM for Docker image
syft nginx:latest -o cyclonedx-json > nginx-sbom.json

# Scan SBOM for vulnerabilities
grype sbom:./nginx-sbom.json

Official docs: https://github.com/anchore/syft

2. OWASP Dependency-Check

Supports Java, .NET, Python, and more.

Installation:

# Homebrew (Mac)
brew install dependency-check

# Or direct download
wget https://github.com/jeremylong/DependencyCheck/releases/download/v8.4.3/dependency-check-8.4.3-release.zip

Execution:

dependency-check.sh --scan ./my-project --format JSON --out ./reports

Official site: https://owasp.org/www-project-dependency-check/

3. Trivy (Aqua Security)

Can scan container images, filesystems, and Git repositories.

Installation:

# Linux
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy

Usage:

# Generate SBOM
trivy image --format cyclonedx nginx:latest > sbom.json

# Scan vulnerabilities
trivy sbom sbom.json

Official docs: https://trivy.dev/

Commercial Platforms

For larger organizations, consider commercial solutions:

• Snyk: Developer-friendly UI, easy CI/CD integration
• JFrog Xray: Powerful scanning integrated with Artifactory
• Sonatype Nexus Lifecycle: Enterprise-grade policy management
• Black Duck (Synopsys): Specialized in open-source governance

 

 

08. Enterprise Implementation Case Study

In my experience working at financial institutions, we’ve built SBOM management systems since 2023. Here’s how we approached implementation.

Pre-Implementation Challenges

• Over 500 open-source libraries managed only in Excel
• Days of manual checking after vulnerability disclosures
• Weekend emergency work during Log4Shell incident

Implementation Process

Phase 1: Pilot Project (2 months)

• Selected 10 key applications
• Tested with Syft + Grype combination
• Built automated SBOM generation pipeline

Phase 2: Enterprise Rollout (6 months)

• Added SBOM generation to CI/CD pipeline
• Conducted developer training
• Built SBOM repository (Nexus Repository)

Phase 3: Operational Establishment (Ongoing)

• Monthly full SBOM rescans
• Automatic alerts on vulnerability discovery
• Established VEX creation process

Implementation Results

Metric	Before	After
Vulnerability Identification Time	3-5 days	Under 30 min
Patch Cycle	1-2 months	Within 2 weeks
Audit Response Time	2 weeks	2 days
License Violations	3-4/year	0

During the March 2024 XZ Utils backdoor incident, SBOM enabled us to immediately identify impact scope and respond proactively.

 

 

09. Frequently Asked Questions (FAQ)

Q1. Who should create the SBOM?
A. Software developers or suppliers should create it. Integrating automated generation tools into your build system eliminates manual work.

Q2. Doesn’t SBOM contain confidential information?
A. SBOM only includes public component lists, not source code or configuration. However, since library versions are exposed, exercise caution during distribution.

Q3. Can we create SBOM for legacy systems?
A. Yes. Even without source code, tools exist for analyzing binaries or executables (Black Duck Binary Analysis, Revenera Flexera, etc.).

Q4. Which SBOM standard should we choose?
A. CycloneDX for security focus, SPDX for license management. Conversion between formats is possible, so start with one.

Q5. Is VEX creation mandatory?
A. Not for all vulnerabilities. Create VEX for Critical/High severity vulnerabilities or when regulatory compliance requires it.

 

 

10. 2026 Outlook and Preparation

Regulatory Trends

Following the U.S. and EU, software supply chain security regulations are intensifying globally.

United States:

• NIST SP 800-218: Secure Software Development Framework
• CISA’s SBOM mandate roadmap

European Union:

• Cyber Resilience Act (CRA): Passed 2024, full enforcement 2027
• 24-hour ENISA reporting requirement upon vulnerability discovery

Global Adoption:

• Countries worldwide developing similar frameworks
• Industry-specific requirements emerging (finance, healthcare, critical infrastructure)

What to Prepare Now

1. Build Automated SBOM Generation: Integrate into CI/CD pipeline
2. Establish Vulnerability Monitoring: Set up daily/weekly scanning
3. Develop Team Capabilities: DevSecOps training, security tool proficiency
4. Manage Suppliers: Require SBOM from external developers and SI vendors

Future Trends

AI-Based Automation
Tools supporting AI-assisted vulnerability impact analysis and VEX creation are emerging.

SaaSBOM, HardwareBOM Expansion
BOM concepts extending beyond software to SaaS services and hardware components.

Blockchain-Based Verification
Experiments using blockchain to verify SBOM integrity are underway.

 

 

Software supply chain security is no longer optional—it’s essential. Understanding and applying the three core concepts of SBOM, VDR, and VEX can elevate your organization’s security maturity significantly. It may seem complex at first, but using open-source tools makes getting started easier than you think. Install Syft or Trivy today and apply it to one of your projects.

 

 

---

References:

• CISA SBOM Guide: https://www.cisa.gov/sbom
• NIST Software Supply Chain Security: https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security
• OWASP CycloneDX: https://cyclonedx.org/
• Linux Foundation SPDX: https://spdx.dev/
• Anchore Syft: https://github.com/anchore/syft