What is an SBOM?

A Software Bill of Materials (SBOM) is a comprehensive inventory of all components that make up a software product. Just as a traditional bill of materials lists every part used to manufacture a physical product, an SBOM catalogs every software component, library, framework, and dependency used to build a software application.

Think of it as an ingredient list for software—a complete, machine-readable catalog of everything that goes into your product, including:

• Direct dependencies you explicitly include (libraries, packages, frameworks)
• Transitive dependencies your dependencies rely on
• Version information for each component
• License information
• Supplier/author details
• Known vulnerabilities and security status
• Component relationships and dependency tree

A Simple Example

Consider a WordPress plugin that uses these components:

my-wordpress-plugin/
├── WordPress Core (5.9+)
├── PHP (7.4+)
├── guzzlehttp/guzzle (7.5.0) ← HTTP client library
│   ├── guzzlehttp/psr7 (2.4.0)
│   ├── guzzlehttp/promises (1.5.0)
│   └── psr/http-client (1.0.1)
├── firebase/php-jwt (6.3.0) ← JWT authentication
└── monolog/monolog (2.8.0) ← Logging library
    └── psr/log (3.0.0)

Your SBOM would list not just the three direct dependencies (Guzzle, JWT, Monolog), but also all their transitive dependencies (PSR-7, PSR promises, PSR log, etc.), complete with version numbers, licenses, and security information.

Why Does the CRA Require SBOMs?

The EU Cyber Resilience Act mandates that manufacturers provide SBOMs to improve supply chain security and transparency. Here's why:

1. Vulnerability Management

Modern software supply chain attacks like Log4Shell affected millions of products because organizations didn't know they were using vulnerable components. An SBOM lets you instantly identify whether your product contains a vulnerable dependency when new vulnerabilities are disclosed.

Example: When a critical vulnerability in the PHP library "league/flysystem" was announced in 2023, organizations with SBOMs could search their inventory in minutes to find affected products. Those without SBOMs spent days manually checking codebases.

2. License Compliance

SBOMs document the licenses of all components, helping ensure you comply with open source license obligations and don't inadvertently violate licensing terms.

3. Supply Chain Transparency

SBOMs reveal your complete software supply chain, allowing customers, auditors, and regulators to understand exactly what's in your product without accessing source code.

4. Incident Response

When security incidents occur, SBOMs enable rapid assessment of impact. You can quickly determine which products are affected and need updates.

5. Procurement and Risk Assessment

Enterprise customers increasingly require SBOMs before purchasing software, using them to assess security risk, verify no prohibited components are included, and ensure ongoing vulnerability management.

SBOM Formats: SPDX vs. CycloneDX

Two primary SBOM formats dominate the landscape, and both are widely accepted for CRA compliance:

SPDX (Software Package Data Exchange)

SPDX is an open standard originally created by the Linux Foundation. It's an ISO/IEC standard (5962:2021) focused on license compliance and software composition.

SPDX Strengths:

• Mature standard with broad industry adoption
• Excellent license compliance documentation
• ISO/IEC standardization provides regulatory certainty
• Strong tooling ecosystem
• Designed for legal and compliance professionals

SPDX Example:

{
  "SPDXID": "SPDXRef-DOCUMENT",
  "spdxVersion": "SPDX-2.3",
  "name": "example-wordpress-plugin",
  "dataLicense": "CC0-1.0",
  "documentNamespace": "https://example.com/sbom/plugin-1.0.0",
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-guzzle",
      "name": "guzzlehttp/guzzle",
      "versionInfo": "7.5.0",
      "downloadLocation": "https://packagist.org/packages/guzzlehttp/guzzle",
      "licenseDeclared": "MIT",
      "copyrightText": "Copyright (c) 2011 Michael Dowling"
    }
  ]
}

CycloneDX

CycloneDX is a lightweight SBOM standard created by OWASP specifically for application security and supply chain risk management.

CycloneDX Strengths:

• Purpose-built for security use cases
• Excellent vulnerability tracking integration
• Comprehensive security metadata support
• Smaller file sizes for large projects
• Strong integration with security tools
• Built-in support for VEX (Vulnerability Exploitability eXchange)

CycloneDX Example:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata": {
    "component": {
      "type": "application",
      "name": "example-wordpress-plugin",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "guzzlehttp/guzzle",
      "version": "7.5.0",
      "purl": "pkg:composer/guzzlehttp/guzzle@7.5.0",
      "licenses": [{"license": {"id": "MIT"}}],
      "hashes": [{
        "alg": "SHA-256",
        "content": "a7..."
      }]
    }
  ]
}

Which Format Should You Use?

For CRA compliance, either format is acceptable. Choose based on your needs:

• Choose SPDX if: License compliance is your primary concern, you need ISO standard compliance, or you work in highly regulated industries
• Choose CycloneDX if: Security and vulnerability management are priorities, you need VEX support, or you use OWASP security tools

Many organizations generate both formats to maximize compatibility with different tools and customer requirements.

Required Information in CRA-Compliant SBOMs

While the CRA doesn't mandate a specific SBOM format, it does require certain information be included:

• Component identification: Unique identifier for each component (name, version, package URL)
• Component supplier: Who created/maintains each component
• Dependencies: Relationships between components (dependency tree)
• License information: Applicable licenses for each component
• Version information: Precise version numbers for reproducibility
• Component hashes: Cryptographic hashes to verify integrity
• Metadata: SBOM creation date, author, tools used
• Known vulnerabilities: Reference to known CVEs (optional but recommended)

How to Generate SBOMs for WordPress Plugins

WordPress plugins present unique challenges for SBOM generation. Here's how to create comprehensive SBOMs for your WordPress products:

Step 1: Inventory Your Dependencies

WordPress plugins can have multiple types of dependencies:

• PHP dependencies (Composer): Listed in composer.json
• JavaScript dependencies (npm): Listed in package.json
• Bundled libraries: Third-party code copied directly into your plugin
• WordPress core: Minimum WordPress version requirement
• PHP version: Minimum PHP version requirement
• Other plugins: Plugins your plugin depends on or integrates with

Step 2: Use Automated Tools

Manual SBOM creation is error-prone and unsustainable. Use automated tools:

For PHP/Composer Dependencies

# Install CycloneDX Composer plugin
composer require --dev cyclonedx/cyclonedx-php-composer

# Generate SBOM
composer make-bom

# Output: bom.json or bom.xml

For JavaScript/npm Dependencies

# Install CycloneDX npm plugin
npm install --save-dev @cyclonedx/bom

# Generate SBOM
npx cyclonedx-bom -o bom.json

For Complete WordPress Plugins

# Using CRA Compliance Suite (easiest option)
# Upload plugin ZIP file
# Automatically scans:
# - composer.json/composer.lock
# - package.json/package-lock.json
# - Bundled third-party code
# - WordPress and PHP requirements
# Generates complete SBOM in CycloneDX and SPDX formats

Step 3: Include Bundled Libraries

Many WordPress plugins bundle libraries directly without using package managers. You must manually document these:

// Document bundled libraries in plugin header
/**
 * Plugin Name: Example Plugin
 * Description: Demo plugin with bundled libraries
 * Version: 1.0.0
 *
 * Third-Party Libraries:
 * - jQuery ColorPicker v1.2.3 (MIT) - bundled in assets/colorpicker/
 * - Select2 v4.0.13 (MIT) - bundled in assets/select2/
 * - FontAwesome v6.0.0 (CC BY 4.0, SIL OFL 1.1) - bundled in assets/fonts/
 */

Modern SBOM tools can detect some bundled libraries automatically, but manual verification is essential.

Step 4: Document WordPress/PHP Requirements

Your SBOM should include WordPress Core and PHP as dependencies:

{
  "components": [
    {
      "type": "framework",
      "name": "WordPress",
      "version": "5.9+",
      "description": "Minimum WordPress version required"
    },
    {
      "type": "platform",
      "name": "PHP",
      "version": "7.4+",
      "description": "Minimum PHP version required"
    }
  ]
}

Step 5: Keep SBOMs Updated

SBOMs must be regenerated whenever dependencies change:

• Every time you update a dependency (composer update, npm update)
• When you add or remove dependencies
• For each new version of your plugin
• When security updates require dependency changes

Integrate SBOM generation into your build process to ensure it's never forgotten:

# Example GitHub Actions workflow
name: Build and Generate SBOM

on: [push, release]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install dependencies
        run: composer install --no-dev
      - name: Generate SBOM
        run: composer make-bom
      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v2
        with:
          name: sbom
          path: bom.json

Tools for SBOM Generation

SBOM Best Practices

1. Automate Generation

Manual SBOM creation is impractical for modern software with hundreds of dependencies. Always use automated tools and integrate SBOM generation into your CI/CD pipeline.

2. Version SBOMs with Products

Each product version should have its own SBOM. Archive historical SBOMs so you can respond to vulnerability disclosures affecting old versions.

3. Validate SBOM Accuracy

Periodically verify your SBOMs are complete and accurate. Spot-check that listed dependencies match actual code, and ensure no unlisted dependencies exist.

4. Make SBOMs Accessible

Publish SBOMs in a standard location where customers and tools can find them:

https://example.com/sbom/[product-name]-[version].json
https://example.com/sbom/my-plugin-1.0.0.json
https://example.com/sbom/my-plugin-1.0.0.xml (SPDX)

5. Include Security Metadata

Modern SBOM formats support vulnerability information. Include CVE references and security status where known.

Common SBOM Challenges and Solutions

Challenge: Bundled/Vendored Dependencies

Problem: Libraries copied directly into your codebase aren't detected by package manager tools.

Solution: Use filesystem scanners like Syft, or document bundled libraries manually. CRA Compliance Suite automatically detects common bundled JavaScript and PHP libraries.

Challenge: Transitive Dependency Explosion

Problem: Modern projects can have thousands of transitive dependencies, making SBOMs huge and unwieldy.

Solution: This is expected and correct. Complete SBOMs necessarily include all transitive dependencies. Use SBOM analysis tools to navigate large dependency trees.

Challenge: Keeping SBOMs Current

Problem: Dependencies change frequently, and manual SBOM updates are forgotten.

Solution: Automate SBOM generation in your build pipeline. Every build should produce an updated SBOM.

Challenge: License Identification

Problem: Not all dependencies clearly specify licenses, or use non-standard license identifiers.

Solution: Use tools that normalize licenses to SPDX identifiers. Manually review unclear cases and document your findings.

Conclusion: SBOMs as Security Foundation

While generating SBOMs may initially seem like a compliance checkbox, they quickly become invaluable security tools. Organizations with comprehensive SBOMs can respond to vulnerabilities in hours instead of days, understand their security posture clearly, and make informed decisions about dependency updates.

The CRA's SBOM requirement transforms this best practice into a legal obligation—but that's ultimately positive for the entire software ecosystem. Better transparency leads to better security, benefiting manufacturers and customers alike.

Start generating SBOMs today. The process is simpler than you think, especially with the right tools.