SBOMs are not dependency lists.

But even after generating an SBOM, many teams run into a new problem:

They open the file… and don't know what they're looking at.

This article breaks down the structure of a real SBOM, using CycloneDX, so you can actually read and use it.

Why Most SBOMs Feel Useless at First

If you've ever opened a CycloneDX JSON file, you've probably seen something like:

{
  "components": [...],
  "dependencies": [...],
  "metadata": {...}
}

At a glance, it looks like:

  • a long list of packages
  • some nested references
  • a lot of fields you're not using

So teams fall back to what they understand:

"This is just a dependency list in JSON."

That's the mistake.

An SBOM is not meant to be read as a flat file.

It's meant to be understood as a model of your system.

1. Components: What Exists in Your Software

The components section is the foundation.

This is where you describe what is actually part of your system.

Not just libraries.

A proper SBOM can include:

  • Open source libraries (e.g. npm, pip, Maven)
  • Internal modules
  • Containers and images
  • Operating system packages
  • Services and APIs
  • Firmware (in embedded systems)

Example:

{
  "type": "library",
  "name": "lodash",
  "version": "4.17.21"
}

But in more advanced cases:

{
  "type": "container",
  "name": "backend-service",
  "version": "1.3.0"
}

Why this matters

If your SBOM only contains libraries, you're missing:

  • deployment context
  • runtime components
  • system-level dependencies

Which means incomplete visibility.

2. Dependencies vs Relationships (This Is Critical)

Most people stop at dependencies.

CycloneDX goes further.

Dependencies (basic)

  • A → B (A depends on B)

This is what most tools generate.

Relationships (richer context)

CycloneDX allows you to express more meaningful connections:

  • contains → container includes packages
  • uses → service calls API
  • depends on → traditional dependency
  • provides → component exposes capability

This is where SBOM becomes a graph, not a list.

Why this matters

During an incident, you don't just need to know:

"Is lodash present?"

You need to know:

  • Where is it used?
  • In which service?
  • In which container?
  • Is it exposed externally?

That requires relationships — not just dependencies.

3. Metadata: Context That Makes SBOMs Useful

Metadata is often ignored, but it's what makes SBOMs actionable.

Typical fields include:

  • Supplier / author
  • Timestamp
  • Versioning
  • Licensing
  • External references (e.g. repository URLs)

Example:

{
  "supplier": {
    "name": "Example Corp"
  },
  "timestamp": "2026-04-20T10:00:00Z"
}

Why this matters

Without metadata, you can't:

  • track ownership
  • validate source
  • perform license checks
  • assess trust

A list without context is hard to use.

4. BOM-Link: Connecting SBOMs Together

This is one of the most underused features.

Modern systems don't have one SBOM.

They have multiple:

  • application SBOM
  • container SBOM
  • infrastructure SBOM

BOM-Link allows you to connect them.

Example use case:

  • Application SBOM references container SBOM
  • Container SBOM references base image SBOM

Now you have a connected supply chain graph.

Why this matters

Without linking:

  • you analyze systems in isolation

With linking:

  • you understand full impact across layers

This becomes critical for:

  • large systems
  • microservices
  • cloud environments

5. Evidence and Confidence: Can You Trust the SBOM?

CycloneDX introduces evidence, which answers:

How do you know this component exists?

Possible sources:

  • Build-time analysis
  • Source code inspection
  • Binary analysis
  • Runtime observation

Why this matters

Not all SBOMs are equally reliable.

Two SBOMs might:

  • list the same component
  • but be derived in completely different ways

Which affects:

  • accuracy
  • completeness
  • trust

This is especially important in:

  • regulated environments
  • third-party SBOM validation
  • supply chain security

Putting It All Together

A real SBOM is not just:

  • a list of packages
  • a JSON file generated during build

It is:

A structured, contextual model of your software system.

It includes:

  • what exists (components)
  • how it connects (relationships)
  • what we know about it (metadata)
  • how we know it (evidence)
  • how it links to other systems (BOM-Link)

Once you start reading SBOMs this way, they become far more useful.

Common Pitfall

Many teams:

  • generate SBOMs
  • store them
  • never analyze beyond component lists

This leads to:

"We have SBOMs, but we still can't answer basic questions."

The problem is not generation.

It's interpretation.

What Comes Next

Now that you understand how an SBOM is structured, the next challenge is:

When and how should SBOMs be generated and updated?

In the next article, we'll cover:

"SBOM Lifecycle: Why 'Generate Once' Is Not Enough"

We'll explore:

  • design-time vs build-time vs runtime SBOMs
  • how SBOMs drift from reality
  • and how to integrate them into CI/CD pipelines