Software Bill of Materials (SBOM)

What is a Software Bill of Materials (SBOM)?

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory that identifies and lists all software components, libraries, modules, and dependencies included in an application. Similar to how a list of ingredients appears on food packaging or a bill of materials is used in manufacturing, an SBOM provides transparency and visibility into the composition of software products.

SBOMs have emerged as a critical tool for software supply chain security, vulnerability management, license compliance, and overall risk reduction. They enable organizations to understand what's in their software, track vulnerable components, and respond quickly to newly discovered security issues.

Core Components of an SBOM

Component Identification

• Name: The name of the component
• Version: Specific version or version range
• Supplier: The creator or distributor of the component
• Unique Identifiers: Package URLs (PURLs), CPEs, etc.

Component Metadata

• Licenses: Associated license information
• Copyright: Copyright statements
• Hash Values: Cryptographic hashes for verification
• Origin: Where the component was sourced from
• Creation Information: When and how the component was built

Dependency Relationships

• Direct Dependencies: Components directly included by the application
• Transitive Dependencies: Components included by direct dependencies
• Dependency Tree: Hierarchical representation of dependencies

Vulnerability Information

• Known Vulnerabilities: CVEs and other vulnerability identifiers
• Vulnerability Severity: CVSS scores or other risk metrics
• Patch Status: Whether vulnerabilities have been addressed

SBOM Formats and Standards

CycloneDX

An OWASP Foundation project that provides a lightweight SBOM standard designed for application security contexts and supply chain component analysis.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "acme-library",
      "version": "1.0.0",
      "purl": "pkg:npm/acme-library@1.0.0"
    }
  ]
}

Software Package Data Exchange (SPDX)

A standard format for communicating software bill of materials information, including components, licenses, copyrights, and security references.

SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: example-app-1.0.0
DocumentNamespace: http://spdx.org/spdxdocs/example-app-1.0.0
Creator: Person: Jane Doe (jane.doe@example.com)
Created: 2021-07-01T09:00:00Z

Software Identity (SWID) Tags

ISO/IEC 19770-2 standard that provides identification and management information for software inventory.

<SoftwareIdentity name="Example App" 
                  version="1.0.0" 
                  tagId="example.com-Example-App-1.0.0">
  <Entity name="Example Corp" 
          regid="example.com" 
          role="softwareCreator"/>
</SoftwareIdentity>

SBOM Use Cases

Security and Vulnerability Management

• Vulnerability Detection: Quickly identify affected applications when new vulnerabilities are discovered
• Risk Assessment: Evaluate the security posture of applications based on their components
• Incident Response: Accelerate response to security incidents by immediately knowing affected systems
• Patch Prioritization: Focus remediation efforts on the most critical vulnerabilities

Compliance and Risk Management

• License Compliance: Track and manage open source license obligations
• Regulatory Compliance: Meet government and industry requirements for software transparency
• Export Control: Ensure software meets export regulations
• Supply Chain Risk: Assess and manage risks from third-party components

Operational Benefits

• Inventory Management: Maintain accurate records of deployed software components
• Obsolescence Management: Identify outdated or unsupported components
• Duplicate Reduction: Identify and eliminate redundant dependencies
• Procurement Decisions: Make informed decisions when acquiring software

SBOM in Government and Industry Requirements

Executive Order 14028

In May 2021, the U.S. Executive Order on Improving the Nation's Cybersecurity required SBOMs for software sold to the federal government, marking a significant shift toward SBOM adoption.

NTIA Minimum Elements

The National Telecommunications and Information Administration (NTIA) defined minimum elements for an SBOM:

• Supplier Name
• Component Name
• Component Version
• Unique Identifiers
• Dependency Relationship
• SBOM Author
• Timestamp

Industry-Specific Requirements

Various industries are adopting SBOM requirements:

• Healthcare: FDA guidance for medical device security
• Energy: Requirements for critical infrastructure
• Financial Services: Third-party risk management frameworks
• Automotive: Software transparency in modern vehicles

Creating and Maintaining SBOMs

Generation Methods

Automated Tools

• SBOM Generators: Tools like Syft, CycloneDX generators, and SPDX tools
• Build System Integration: Maven, Gradle, npm, and other build tools with SBOM generation
• Source Code Analysis: Static analysis tools that examine dependencies

Continuous Integration

• CI/CD Pipeline Integration: Automatically generating SBOMs during builds
• Version Control Integration: Creating SBOMs from source repositories
• Container Analysis: Generating SBOMs for container images

Verification and Validation

• Completeness Checking: Ensuring all components are included
• Accuracy Verification: Validating component information
• Format Validation: Checking compliance with SBOM standards

Distribution and Consumption

• Secure Transfer: Methods for securely sharing SBOMs with consumers
• Storage Solutions: Repositories for maintaining SBOM data
• Integration APIs: Interfaces for consuming and processing SBOM data

SBOM Best Practices

Implementation Strategy

1. Start Small: Begin with critical applications or a representative subset
2. Choose a Standard: Select an SBOM format that meets your needs (CycloneDX, SPDX)
3. Automate Generation: Integrate SBOM creation into your build process
4. Establish Governance: Define policies for SBOM creation and maintenance
5. Build Awareness: Educate teams about the importance and use of SBOMs

Depth and Breadth Considerations

• Component Depth: How deep into nested dependencies to document
• Metadata Breadth: What additional information to include beyond minimum requirements
• Frequency: How often to update SBOMs

Common Challenges

• Incomplete Information: Missing or incorrect component data
• Legacy Software: Generating SBOMs for older applications
• Third-Party Software: Obtaining SBOMs from vendors
• SBOM Management: Handling a large volume of SBOM documents
• Tool Limitations: Dealing with the limitations of SBOM generators

The Future of SBOMs

Emerging Trends

• SBOM Attestation: Cryptographically signed SBOMs with verifiable provenance
• Runtime Verification: Comparing running software against its SBOM
• AI/ML Component Tracking: Extending SBOMs to machine learning models and datasets
• Dynamic SBOMs: Real-time updates reflecting the current state of deployed software
• SBOM Exchanges: Centralized repositories for sharing and accessing SBOMs

Integration with Other Security Frameworks

• VEX (Vulnerability Exploitability eXchange): Contextualizing vulnerabilities in SBOMs
• SLSA (Supply chain Levels for Software Artifacts): Using SBOMs as part of broader supply chain security
• Zero Trust Architecture: SBOMs as a verification mechanism for software trustworthiness