What is an SBOM? Software Bill of Materials Explained

A Software Bill of Materials (SBOM) is a comprehensive inventory of all components, libraries, and dependencies that make up a piece of software. Think of it as an ingredient list for your software - just as food packaging tells you what’s inside, an SBOM tells you exactly what code your application is built from.

SBOMs have moved from a nice-to-have security practice to a regulatory requirement. If you sell software to the US federal government, work with enterprise customers, or operate in the EU, understanding SBOMs is no longer optional.

Why SBOMs Matter Now

The concept of tracking software components isn’t new. What’s changed is urgency. Several high-profile supply chain attacks demonstrated how vulnerable modern software is - and how difficult it is to respond without knowing what’s in your software.

Supply Chain Attacks Changed Everything

Two incidents in particular accelerated the SBOM movement:

SolarWinds (2020): Attackers compromised the build system of SolarWinds, a widely-used IT management tool. Malicious code was inserted into software updates that thousands of organizations downloaded and installed. Victims included Fortune 500 companies and US government agencies. The attack succeeded because no one had visibility into the compromised component.

Log4Shell (2021): A critical vulnerability (CVE-2021-44228) was discovered in Log4j, a Java logging library used by millions of applications. Organizations scrambled to determine whether they were affected. Those with good dependency tracking could answer in hours. Others spent weeks manually auditing codebases.

In both cases, the same question emerged: “Are we affected?” Organizations with comprehensive component inventories could answer quickly. Those without faced painful manual investigation.

Regulatory Requirements Are Here

Governments responded to these incidents with regulation. Software supply chain security is now a compliance requirement in multiple jurisdictions.

US Executive Order 14028 (May 2021): Requires software vendors selling to the federal government to provide SBOMs. The order directed NIST to develop SBOM guidelines and gave agencies 180 days to require SBOMs from vendors.

EU Cyber Resilience Act (2024): Requires manufacturers of products with digital elements sold in the EU to maintain and provide SBOMs. This affects a broad range of software and connected devices.

FDA Cybersecurity Guidance (2023): Requires medical device manufacturers to include SBOMs with premarket submissions. This covers devices containing software, including firmware.

Beyond government mandates, enterprise customers increasingly require SBOMs as part of vendor security assessments. The question “Can you provide an SBOM?” is becoming as common as “Do you have SOC 2 certification?”

What’s in an SBOM?

An SBOM documents every component in your software, along with metadata about each component. A comprehensive SBOM includes:

Component Identity

Every component needs clear identification:

• Component name: The official name (e.g., “spring-core”, “lodash”, “requests”)
• Version: The specific version in use (e.g., “6.2.1”, “4.17.21”, “2.31.0”)
• Supplier: Who created or maintains the component
• Unique identifier: A standard identifier like a Package URL (purl)

Dependency Relationships

Software dependencies form a tree structure:

• Direct dependencies: Components you explicitly include
• Transitive dependencies: Components your dependencies depend on
• Dependency depth: How many levels deep a component sits

License Information

For each component:

• License type: MIT, Apache 2.0, GPL, proprietary, etc.
• License compliance: Whether usage complies with license terms
• License obligations: Requirements you must fulfill

Additional Metadata

Depending on your needs:

• Hash/checksum: Cryptographic verification of component integrity
• Source location: Where the component was obtained
• Build information: How and when the component was built
• Known vulnerabilities: CVEs associated with the component version

Example SBOM Entry

Here’s what an SBOM entry looks like in practice (CycloneDX JSON format):

{
  "type": "library",
  "bom-ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
  "name": "log4j-core",
  "version": "2.17.1",
  "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
  "licenses": [
    {
      "license": {
        "id": "Apache-2.0"
      }
    }
  ],
  "supplier": {
    "name": "Apache Software Foundation"
  },
  "hashes": [
    {
      "alg": "SHA-256",
      "content": "a3..."
    }
  ]
}

SBOM Formats

Three primary formats have emerged for representing SBOMs. Each has different strengths and adoption patterns.

CycloneDX

Originally developed by OWASP for security use cases, CycloneDX has become the most widely-adopted format for software security.

Strengths:

• Designed specifically for security and vulnerability tracking
• Native support for vulnerability references
• Lightweight and easy to generate
• Strong tooling ecosystem
• Supports multiple output formats (JSON, XML, Protocol Buffers)

Best for: Security-focused teams, vulnerability management, CI/CD integration

<bom xmlns="http://cyclonedx.org/schema/bom/1.5" version="1">
  <components>
    <component type="library">
      <name>spring-core</name>
      <version>6.2.1</version>
      <purl>pkg:maven/org.springframework/spring-core@6.2.1</purl>
    </component>
  </components>
</bom>

SPDX (Software Package Data Exchange)

Developed by the Linux Foundation, SPDX is the oldest SBOM format and focuses heavily on license compliance.

Strengths:

• ISO/IEC 5962:2021 international standard
• Comprehensive license expression support
• Strong adoption in open-source communities
• Required by some government contracts
• Detailed relationship modeling

Best for: License compliance, open-source projects, government/defense contractors

{
  "spdxVersion": "SPDX-2.3",
  "packages": [
    {
      "name": "spring-core",
      "versionInfo": "6.2.1",
      "downloadLocation": "https://repo.maven.apache.org/maven2/...",
      "licenseConcluded": "Apache-2.0"
    }
  ]
}

SWID Tags (Software Identification Tags)

ISO standard (ISO/IEC 19770-2) originally designed for software asset management.

Strengths:

• International standard with government adoption
• Strong support in Windows ecosystem
• Designed for installed software inventory
• Integration with IT asset management tools

Best for: Enterprise IT asset management, Windows environments, government compliance

Which Format Should You Choose?

Who Requires SBOMs?

Understanding who mandates SBOMs helps you prioritize your efforts.

US Federal Government

Executive Order 14028 established SBOM requirements for software sold to federal agencies. Key points:

• Software vendors must provide SBOMs upon request
• Applies to new procurements and major updates
• NIST guidelines define minimum SBOM elements
• Specific agencies (DoD, DHS) may have additional requirements

If you sell to the US government or hope to, SBOM capability is now table stakes.

European Union

The Cyber Resilience Act introduces SBOM requirements for products with digital elements sold in the EU:

• Manufacturers must maintain SBOMs
• SBOMs must be available to market surveillance authorities
• Applies to software products and IoT devices
• Enforcement begins in 2027

Healthcare and Medical Devices

The FDA requires SBOMs for medical devices containing software:

• Required for premarket submissions
• Must include commercial, open-source, and off-the-shelf components
• Part of broader cybersecurity documentation requirements

Enterprise Customers

Beyond regulation, enterprise procurement increasingly includes SBOM requests:

• Security assessments ask for component inventories
• Vendor risk questionnaires include SBOM questions
• Some customers require SBOMs as contract terms

Even if you’re not directly regulated, your customers may be.

How to Generate SBOMs

Multiple tools can generate SBOMs from your codebase and dependencies. Here are the most widely-used options.

Syft (by Anchore)

An open-source CLI tool that generates SBOMs from container images, filesystems, and archives.

syft alpine:latest -o cyclonedx-json > sbom.json

syft dir:/path/to/project -o spdx-json > sbom.spdx.json

Supports: Container images (Docker, OCI), directories, archives, language-specific formats (Java, Node.js, Python, Go, Ruby, Rust)

Trivy (by Aqua Security)

A comprehensive security scanner that includes SBOM generation alongside vulnerability scanning.

trivy image --format cyclonedx myapp:latest > sbom.json

trivy fs --format spdx-json /path/to/project > sbom.spdx.json

Supports: Container images, filesystems, Git repositories, Kubernetes clusters

Language-Specific Tools

Build tools often have native or plugin-based SBOM generation:

Maven (Java):

mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom

npm (JavaScript):

npm sbom --sbom-format cyclonedx

pip (Python):

pip-audit --format cyclonedx-json > sbom.json

CI/CD Integration

SBOM generation should be part of your build pipeline. Here’s an example GitHub Actions workflow:

name: Generate SBOM

on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          artifact-name: sbom.cyclonedx.json
          format: cyclonedx-json

      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cyclonedx.json

SBOMs and Artifact Repositories

Artifact repositories play a central role in SBOM workflows because they store the actual components your SBOM inventories.

The Connection

When your build system resolves dependencies, it downloads them from artifact repositories:

1. Your pom.xml, package.json, or requirements.txt declares dependencies
2. Build tools fetch those dependencies from repositories (Maven Central, npm registry, PyPI, or your private repository)
3. The SBOM tool inventories what was actually used
4. The resulting artifact (JAR, container image, etc.) is stored in your artifact repository

The artifact repository is the source of truth for what components are available and what versions exist.

Why Private Repositories Matter for SBOM Workflows

Using a private artifact repository provides several SBOM-related benefits:

Controlled component sources: You know exactly where components came from. Public repositories can have components removed or modified; private repositories give you control.

Cached dependencies: If a component is removed from a public repository, you still have it cached. This preserves reproducibility for SBOM verification.

Additional metadata: Private repositories can store SBOM metadata alongside artifacts, creating a complete record.

Access control: Limit which components can enter your build system. Block known-vulnerable versions before they reach developers.

SBOM Storage Patterns

Organizations typically store SBOMs in one of several places:

Many teams store SBOMs alongside their build artifacts in their artifact repository, ensuring the SBOM and artifact remain linked.

Getting Started with SBOMs

Implementing SBOM practices doesn’t require a massive initiative. Here’s a practical path forward.

Step 1: Inventory What You Have

Before generating SBOMs, understand your current state:

• What package managers do you use? (Maven, npm, pip, etc.)
• Where do dependencies come from? (Public repos, private repos, vendored)
• How are builds currently tracked?
• What compliance requirements apply to you?

Step 2: Generate Your First SBOM

Start with a single project using a tool like Syft:

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

# Generate SBOM for your project
syft dir:. -o cyclonedx-json > sbom.json

# View the results
cat sbom.json | jq '.components | length'

Review the output. Are all your expected dependencies present? Are there surprises?

Step 3: Integrate with CI/CD

Once you understand what your SBOM contains, automate generation:

• Add SBOM generation to your build pipeline
• Store SBOMs alongside build artifacts
• Archive SBOMs for historical reference

Step 4: Add Vulnerability Scanning

Connect your SBOMs to vulnerability databases:

# Generate SBOM
syft dir:. -o cyclonedx-json > sbom.json

# Scan for vulnerabilities
grype sbom:sbom.json

Step 5: Establish Ongoing Processes

SBOM management is continuous:

• Regular regeneration: SBOMs should be generated with each release
• Vulnerability monitoring: Scan stored SBOMs when new vulnerabilities are disclosed
• Compliance documentation: Maintain SBOMs for audit purposes
• Dependency updates: Use SBOM data to prioritize updates

Common SBOM Challenges

As you implement SBOM practices, expect these challenges:

Incomplete Dependency Detection

Not all dependencies are visible to every tool:

• Native libraries may not appear in language-specific scans
• Build-time-only dependencies might be missed
• Vendored code (copied rather than imported) needs special handling

Solution: Use multiple tools and validate results. Container image scanning catches what filesystem scanning misses, and vice versa.

Transitive Dependency Explosion

A project with 50 direct dependencies might have 500+ transitive dependencies. Managing this volume requires:

• Automated tooling (manual tracking is impossible)
• Focus on critical components first
• Risk-based prioritization for vulnerability response

Format Interoperability

Different tools, customers, and regulators may require different formats.

Solution: Choose tools that support multiple output formats. CycloneDX and SPDX tools can usually generate both formats from the same scan.

Keeping SBOMs Current

An SBOM represents a point in time. Software changes constantly.

Solution: Generate SBOMs with every build, not as a one-time project. Treat SBOM generation as part of your standard CI/CD process.

SBOM Best Practices

Based on industry experience, here are practices that lead to successful SBOM programs:

1. Automate everything: Manual SBOM creation doesn’t scale. Build it into your pipeline.

2. Generate at build time: Capture the SBOM when you build, not after deployment.

3. Store with artifacts: Keep SBOMs alongside the software they describe in your artifact repository.

4. Use standard formats: Stick to CycloneDX or SPDX for maximum compatibility.

5. Include transitive dependencies: Your SBOM should show the full dependency tree.

6. Version your SBOMs: Each release should have a corresponding SBOM version.

7. Monitor continuously: New vulnerabilities affect existing SBOMs. Scan regularly.

8. Start simple: Get basic SBOM generation working before adding complexity.

Conclusion

A Software Bill of Materials is a complete inventory of your software’s components. What was once a security best practice is now a regulatory requirement for many organizations and a growing expectation from enterprise customers.

The good news: generating SBOMs is straightforward with modern tooling. Tools like Syft and Trivy can produce comprehensive SBOMs from your existing build artifacts. The key is integrating SBOM generation into your standard development workflow.

SBOMs provide value beyond compliance:

• Faster vulnerability response: Know immediately if you’re affected by newly-disclosed CVEs
• Better dependency hygiene: Visibility into what you depend on, including transitive dependencies
• License compliance: Track open-source license obligations across your portfolio
• Supply chain security: Understand and verify where your components come from

Your artifact repository is central to this workflow. It stores the components your SBOM inventories and provides the foundation for reproducible, auditable builds. Whether you use CloudRepo or another solution, ensuring your dependency sources are reliable and well-managed is the first step toward effective SBOM practices.

Related resources:

• Artifact Management: What It Is and Why It Matters - Understand how artifact repositories fit into your development workflow
• Security at CloudRepo - Learn about our approach to security and compliance
• Best Artifactory Alternatives - Compare artifact repository options

Ready to improve your artifact management and support SBOM workflows? Try CloudRepo free for 14 days - no credit card required.