Skip to main content

SBOM Overview

Learn how to generate and manage Software Bill of Materials (SBOM) with CXRay for enhanced supply chain security.

What is SBOM?​

A Software Bill of Materials (SBOM) is a comprehensive inventory of all software components, libraries, and dependencies used in an application. It provides transparency into your software supply chain and is essential for:

  • Vulnerability Management: Quickly identify affected components when new vulnerabilities are disclosed
  • License Compliance: Track and manage open source licenses
  • Supply Chain Security: Understand dependencies and transitive dependencies
  • Regulatory Compliance: Meet requirements from frameworks like NIST, NTIA, and EO 14028

SBOM Formats​

CXRay supports industry-standard SBOM formats:

SPDX (Software Package Data Exchange)​

Managed by the Linux Foundation, SPDX is an ISO standard for communicating SBOM information.

cxray scan --type sbom --format spdx --output sbom.spdx.json

CycloneDX​

OWASP-backed standard designed for application security contexts.

cxray scan --type sbom --format cyclonedx --output sbom.cdx.json

What's Included in an SBOM?​

A comprehensive SBOM generated by CXRay includes:

  • Component Name: Package or library name
  • Version: Specific version in use
  • Supplier: Publisher or maintainer
  • License: Software license information
  • Dependencies: Relationship between components
  • Hashes: Cryptographic checksums for verification
  • Package URL (PURL): Standardized component identifier

Generating an SBOM​

Basic Generation​

# Generate SBOM for current project
cxray scan --type sbom .

# Specify format
cxray scan --type sbom --format cyclonedx .

# Include development dependencies
cxray scan --type sbom --include-dev .

Advanced Options​

# Generate with license analysis
cxray scan --type sbom --license-check .

# Exclude specific paths
cxray scan --type sbom --exclude "test/**,docs/**" .

# Output to specific file
cxray scan --type sbom --output sbom.json .

SBOM Use Cases​

1. Vulnerability Response​

When a new CVE is published, quickly determine if your software is affected:

# Check SBOM against new CVE
cxray sbom check --cve CVE-2023-12345 sbom.json

2. License Compliance​

Ensure all dependencies comply with your organization's license policies:

# Audit licenses in SBOM
cxray sbom audit --licenses allowed-licenses.yml sbom.json

3. Supply Chain Analysis​

Understand your dependency tree and identify risks:

# Analyze dependency depth
cxray sbom analyze --depth sbom.json

# Find transitive dependencies
cxray sbom tree --component express sbom.json

4. Continuous Monitoring​

Integrate SBOM generation into CI/CD:

# Generate and upload to artifact repository
cxray scan --type sbom --output sbom.json .
curl -X POST -F "sbom=@sbom.json" https://sbom-repo.example.com/upload

SBOM Example​

Here's a simplified CycloneDX SBOM example:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata": {
    "component": {
      "type": "application",
      "name": "my-app",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ],
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "abc123..."
        }
      ]
    }
  ]
}

Best Practices​

  1. Generate SBOMs Regularly: Create SBOMs for every build or release
  2. Store SBOMs Centrally: Maintain a repository of SBOMs for all applications
  3. Automate Generation: Integrate into CI/CD pipelines
  4. Monitor for Changes: Track SBOM differences between versions
  5. Share with Stakeholders: Provide SBOMs to customers and partners

Next Steps​