Reading Time: 8 minutes

SBOMs aren’t optional anymore. Executive Order 14028, the EU Cyber Resilience Act, and your CISO’s latest email have made software bills of materials a non-negotiable part of your architecture.

The tooling has matured, but there are too many options. Picking the wrong stack costs months of rework. This post cuts through the noise and tells you what actually works.

TL;DR: What to Use

SBOM Generation:

  • Compliance-critical: Syft (industry standard, Red Hat supported)
  • All-in-one: Trivy (SBOM + vulnerability scanning)
  • Application dependencies: cdxgen (npm/Maven/pip focus)

Vulnerability Scanning:

  • Open source: Grype (pairs with Syft) or Trivy
  • Red Hat/OpenShift: Clair (Quay built-in) or RHACS
  • Enterprise: Snyk (best accuracy, high cost)

SBOM Storage:

  • On-prem Red Hat: RHTPA (Red Hat Trusted Profile Analyzer)
  • Open source: Dependency-Track (OWASP)
  • Knowledge graph: GUAC (Google)

RHEL VMs:

  • Red Hat Insights (agent-based, RPM-focused)

SBOM Generation

Syft: Industry Standard

Anchore’s Syft is the de facto standard. Fast, comprehensive, and Red Hat ships a supported version in RHEL 9.8+.

Use Syft when:

  • Regulatory compliance requires standalone SBOMs
  • Feeding RHTPA, Dependency-Track, or GUAC
  • You want separation between generation and scanning

Known issue: Invalid PURLs for Java archives without Maven metadata (anchore/syft#4598). Fix: ensure META-INF/maven/ directories in JARs.

Example:

 1# Generate CycloneDX SBOM
 2syft registry.redhat.io/ubi9/ubi:latest -o cyclonedx-json > sbom.json
 3
 4# Sign it
 5cosign sign-blob --key cosign.key sbom.json > sbom.json.sig
 6
 7# Upload
 8curl -X POST https://rhtpa.company.com/api/v1/sbom \
 9  -H "Content-Type: application/json" \
10  --data-binary @sbom.json

Trivy: Swiss Army Knife

Aqua’s Trivy does everything: SBOM generation, vulnerability scanning, misconfiguration detection, secret scanning.

Use Trivy when:

  • You want one tool for multiple tasks
  • Kubernetes/cloud-native environments
  • Don’t need to separate SBOM from scanning

Trade-off: SBOM generation is good but not as comprehensive as Syft for edge cases. Fine for 95% of use cases; use Syft for audited SBOMs.

1# Scan + generate SBOM
2trivy image registry.redhat.io/rhtpa/rhtpa-server:2.2.4
3
4# Export SBOM
5trivy image --format cyclonedx registry.redhat.io/rhtpa/rhtpa-server:2.2.4 > sbom.json

cdxgen: Developer’s Friend

OWASP cdxgen excels at application dependencies. Understands build files better than filesystem scanners.

Use cdxgen when:

  • Scanning application source code
  • Need license compliance (SPDX)
  • Want call graphs for reachability analysis
1# Scan Node.js with call graph
2cdxgen -t js -o sbom.json --include-formulation --evidence .

Vulnerability Scanning

Grype: Syft’s Partner

Anchore’s Grype scans SBOMs for vulnerabilities. Matches against NVD, Red Hat Security Data, OSV, GitHub Security Advisories.

Why separate tools?

  • Generate SBOM once, scan repeatedly (new CVEs daily)
  • Store for compliance, scan on-demand
  • Different teams (DevOps generates, SecOps scans)
1# Generate with Syft
2syft image:tag -o cyclonedx-json > sbom.json
3
4# Scan months later
5grype sbom:./sbom.json

Clair: Red Hat’s Scanner

Clair is Red Hat’s container vulnerability scanner, built into Quay.

Use Clair when:

  • Using Red Hat Quay as registry
  • Scanning Red Hat images (UBI, RHEL, OpenShift)
  • Want automatic scanning on push

Limitation: Container-only. Won’t scan VMs, filesystems, or app dependencies.

RHACS: OpenShift Admission Control

Red Hat Advanced Cluster Security is admission control + runtime security for OpenShift.

Use RHACS when:

  • Running OpenShift Container Platform
  • Need policy enforcement at deploy time
  • Want runtime threat detection

Example policy:

1apiVersion: platform.stackrox.io/v1alpha1
2kind: AdmissionControllerConfig
3spec:
4  enforce: true
5  policies:
6    - name: "Block Critical CVEs"
7      severity: CRITICAL_SEVERITY
8      enforcement: HARD

SBOM Storage & Search

When the next Log4Shell drops, you need to answer “which systems are affected?” in minutes.

RHTPA: Red Hat’s Platform

Red Hat Trusted Profile Analyzer is an on-prem SBOM platform. Natively supports CSAF (Red Hat’s advisory format) and VEX.

Use RHTPA when:

  • Heavy Red Hat investment (RHEL, OpenShift, Ansible)
  • On-prem deployment needed (air-gapped, compliance)
  • Want native CSAF/VEX support

Known issue: Rejects SBOMs with invalid PURLs (HTTP 400). Don’t hack around it—fix the root cause (add Maven metadata to JARs).

1# Upload SBOM
2curl -X POST https://rhtpa.company.com/api/v1/sbom \
3  -H "Content-Type: application/json" \
4  --data-binary @sbom.json
5
6# Query affected systems
7curl "https://rhtpa.company.com/api/v1/vulnerabilities/CVE-2024-1234/affected-systems"

Dependency-Track: Open Source

OWASP Dependency-Track is the most mature open source SBOM platform. Excellent UI, policy engine, 10+ vulnerability databases.

Use Dependency-Track when:

  • Want free, open source
  • Need SQL-based search (easier than GraphQL)
  • Managing thousands of SBOMs (containers + apps)

GUAC: Knowledge Graph

Google’s GUAC (Graph for Understanding Artifact Composition) is a supply chain knowledge graph. GraphQL queries over SBOMs, SLSA attestations, and vulnerabilities.

Use GUAC when:

  • Need complex supply chain queries
  • Correlating SBOMs with build provenance
  • Team comfortable with GraphQL

Trade-off: Bleeding-edge. Powerful but steeper learning curve.

Red Hat’s Integrated Stack (TSSC)

Red Hat’s Trusted Software Supply Chain integrates everything:

1Code → OpenShift Pipelines (Tekton)
2     → Syft generates SBOM
3     → Tekton Chains generates SLSA provenance
4     → Cosign signs everything
5     → Red Hat Quay (push + Clair scan)
6     → RHTPA (consume SBOM, match vulnerabilities, generate VEX)
7     → RHACS (admission control, enforce policy)
8     → OpenShift (deploy with runtime monitoring)

Why this matters:

  • Unified support (single vendor)
  • CSAF/VEX native (Red Hat publishes all advisories as CSAF 2.0)
  • FIPS compliance (all components FIPS 140-3)
  • Air-gapped support

Trade-off: Vendor lock-in.

Containers vs VMs

Containers:

  • Generation: Syft, Trivy
  • Scanning: Grype, Trivy, Clair, RHACS
  • Why: Layer-based, package managers (apk, rpm, deb)

VMs (RHEL):

  • Generation: Syft (filesystem scan), Red Hat Insights
  • Scanning: Red Hat Insights, OpenSCAP, dnf security
  • Why: RPM-focused, agent-based

Don’t use Red Hat Insights for containers. It only tracks RPMs, won’t see npm/pip/Maven. Use RHTPA or Dependency-Track.

Beyond Basic SBOM Generation

Generating and scanning SBOMs is foundational, but you’ll eventually need:

SBOM Attestation & Signing - Prove SBOMs came from your build pipeline, not an attacker. Tools: Cosign, in-toto, SLSA provenance. (Covered in Part 3: Signing & Attestation)

VEX (Vulnerability Exploitability eXchange) - Document which CVEs actually affect you vs. false positives. Red Hat publishes all advisories as CSAF with VEX status. (Covered in Part 2: Vulnerability Scanning)

SBOM Quality Validation - Validate NTIA minimum elements (author, timestamp, dependencies, component names/versions, hashes) before ingesting. Tool: ntia-conformance-checker. Tip: RHTPA rejects invalid PURLs—validate locally first.

SBOM Diffing - Detect supply chain drift (unexpected dependencies, downgrades). Tool: Bomber. Use case: audit dependency changes before production.

Long-Term Storage - Regulators may require 7-year retention. S3 Object Lock (WORM) + PostgreSQL metadata index, or let RHTPA/Dependency-Track handle it.

Build-Time vs Runtime

Build-time (most tools here):

  • Analyze static artifacts (images, code, SBOMs)
  • Catch known CVEs before deployment

Runtime:

  • Falco (eBPF threat detection)
  • Sysdig Secure (commercial)
  • Tetragon (Cilium eBPF)
  • RHACS (OpenShift runtime)

You need both. Build-time catches known CVEs. Runtime catches zero-days and attacks-in-progress.

Decision Frameworks

Scenario 1: Red Hat-Heavy On-Prem

Stack:

  • SBOM: Syft (Red Hat supported)
  • Scanning: Clair (containers), Insights (VMs), RHACS (OpenShift)
  • Platform: RHTPA (on-prem, CSAF native)
  • CI/CD: OpenShift Pipelines or Konflux
  • Policy: RHACS admission control

Why: Maximum integration, single vendor support, FIPS compliance

Scenario 2: Kubernetes Multi-Cloud

Stack:

  • SBOM: Trivy + cdxgen (app dependencies)
  • Scanning: Trivy or Grype
  • Platform: Dependency-Track or GUAC
  • CI/CD: GitLab CI, GitHub Actions, Tekton
  • Policy: OPA/Gatekeeper or Kyverno

Why: Vendor-neutral, cloud-native, cost-effective

Scenario 3: Enterprise Compliance

Stack:

  • SBOM: Syft (compliance-grade)
  • Scanning: Snyk (highest accuracy) or Grype
  • Platform: Dependency-Track or RHTPA
  • Attestation: Cosign + in-toto (SLSA provenance)
  • Storage: S3 Object Lock (WORM), 7-year retention
  • Policy: OPA with compliance policies

Why: Audit trail, immutable storage, provable compliance

Practical Recommendations

Starting from scratch:

Week 1: Deploy Syft, generate SBOMs for 10 critical services, store in S3

Week 2: Add Grype, scan SBOMs, send results to Slack

Week 3: Deploy Dependency-Track or RHTPA, upload SBOMs

Week 4: Integrate into CI/CD (auto-generate on every build)

Month 2: Add policy enforcement (block CVSS > 7.0)

Month 3: Advanced features (attestation, VEX, reachability)

Already generating SBOMs but can’t search them?

Deploy Dependency-Track this week. SBOMs in S3 that nobody can search is compliance theater. When the next Log4Shell drops, you need to answer “which systems?” in under an hour.

On OpenShift but not using RHACS?

RHACS admission control prevents vulnerable images from reaching production. Worth the licensing cost.

The Bottom Line

SBOM tooling has matured—there’s no excuse not to have this in production. Regulatory pressure is accelerating.

Pick based on your ecosystem:

  • Red Hat-heavy: Syft + RHTPA + RHACS
  • Cloud-native: Trivy + Dependency-Track + OPA
  • Enterprise compliance: Syft + Snyk + GUAC + S3 WORM

Start small (Syft + Grype), prove value (find vulnerabilities before production), then expand (platform, policy, attestation).

The goal isn’t perfect security—it’s demonstrable due diligence. When your CISO asks “which systems are vulnerable to CVE-2026-XXXX?”, answer in minutes with data, not guesses.

Build it now, before the regulator asks.

Resources

Related Case Studies:

  • Case 04479158: RHTPA invalid PURL issue (Syft Maven bug)
  • Case 04473326: Hummingbird container mirroring
  • Case 04466330: CSAF metadata cross-product mismatch

Reference:

Tools:

Next in series: Part 2 - Vulnerability Scanning That Doesn’t Lie (runtime vs build-time, VEX, EPSS, false positive management)

Previous: Series Introduction

Author: James Kirkland
Last Updated: 2026-06-26
Feedback: https://github.com/jkirklan/tuscon/issues