Reading Time: 3 minutes

You know that feeling when your CISO forwards you an email with “FYI” in the subject line? Nine times out of ten, it’s about supply chain security. Log4Shell, SolarWinds, the XZ backdoor—every incident becomes another line item on your compliance checklist.

The regulatory landscape has shifted. Executive Order 14028, the EU Cyber Resilience Act, NIST’s SSDF framework—they’re all saying the same thing: you need to prove you know what’s in your software, where it came from, and whether it’s vulnerable.

This isn’t security theater. When the next critical CVE drops, you need to answer “which systems are affected?” in minutes, not days. When an auditor asks “how do you verify third-party dependencies?”, you need receipts.

I’ve spent the past few months building supply chain security into a multi-cloud environment running Red Hat OpenShift, dealing with RHEL VMs, containers, and everything in between. This series documents what actually works—not theoretical best practices, but battle-tested tooling and architecture.

Supply chain security is one of those areas where the gap between “what we should do” and “what we actually do” is enormous. The goal of this series is to close that gap—to give you actionable guidance that works in the real world.

What This Series Covers

Part 1: SBOM Tools for Software Architects

Focus: How to generate, store, and search software bills of materials

We’ll compare the major SBOM generation tools (Syft, Trivy, cdxgen), vulnerability scanners (Grype, Clair, RHACS), and SBOM platforms (RHTPA, Dependency-Track, GUAC). You’ll learn when to use each tool, how Red Hat’s ecosystem fits together, and how to build SBOM search that actually works when you need it.

Key decisions:

  • Syft vs Trivy vs cdxgen for SBOM generation
  • Where to store SBOMs (RHTPA, Dependency-Track, or S3)
  • How to search SBOMs when CVEs hit
  • Red Hat Insights for RHEL VMs vs container-focused platforms

Part 2: Vulnerability Scanning That Doesn’t Lie

Focus: Build-time vs runtime scanning, false positive management, and exploitability analysis

Not all CVEs are created equal. A CVSS 9.8 vulnerability in a library you don’t actually call is noise. A CVSS 7.0 with public exploits targeting your exact version is a crisis. We’ll cover reachability analysis, VEX (Vulnerability Exploitability eXchange), EPSS scores, and how to build a scanning pipeline that prioritizes signal over noise.

Topics:

  • Build-time scanners (Grype, Trivy, Clair) vs runtime (Falco, RHACS)
  • Container vs VM scanning strategies
  • VEX and CSAF for exploitability context
  • Red Hat’s TSSC (Trusted Software Supply Chain) workflow

Part 3: Signing, Attestation, and Provenance

Focus: Proving your build process is trustworthy

How do you prove a container image came from your CI/CD pipeline and not an attacker’s laptop? SLSA provenance, in-toto attestations, and Sigstore. We’ll cover Cosign for signing, Tekton Chains for automated attestation, and how Red Hat’s Konflux integrates it all.

Topics:

  • Cosign and keyless signing (Sigstore)
  • SLSA provenance levels (what’s realistic to achieve)
  • Tekton Chains for OpenShift Pipelines
  • Red Hat’s Konflux vs DIY supply chain security

Part 4: Policy Enforcement and Admission Control

Focus: Blocking bad artifacts before they reach production

You’ve generated SBOMs, scanned for vulnerabilities, and signed your artifacts. Now what? Policy enforcement is where it all comes together. We’ll cover OPA/Gatekeeper, Kyverno, and Red Hat Advanced Cluster Security (RHACS) for Kubernetes admission control.

Topics:

  • OPA vs Kyverno for policy-as-code
  • RHACS admission control on OpenShift
  • Policy examples: “block CVSS > 7.0”, “require signatures”, “ban outdated base images”
  • Handling policy exceptions without creating backdoors

Part 5: Incident Response When Supply Chain Attacks Hit

Focus: What to do when the next Log4Shell drops

When a critical vulnerability hits (and it will), you need a runbook. We’ll cover the detection-to-remediation pipeline: how to search SBOMs for affected systems, prioritize patching, verify fixes, and communicate with stakeholders. Plus the stuff nobody talks about—like what to do when the vulnerable library is embedded in a third-party vendor product you can’t just patch.

Topics:

  • CVE response runbooks (detection, triage, remediation)
  • Using SBOM platforms for blast radius analysis
  • Coordinated disclosure and VEX documents
  • Handling vendor dependencies (when you can’t patch yourself)

A Note on Tooling Choices

This series emphasizes Red Hat tooling where applicable (RHEL, OpenShift, RHTPA, RHACS, Clair) because that’s the environment I operate in. But I’m not a Red Hat evangelist—I’ll call out when open source alternatives are better, when vendor lock-in is a real concern, and when the “Red Hat way” doesn’t make sense.

For every Red Hat tool, I’ll provide:

  • Open source alternatives (Dependency-Track vs RHTPA, OPA vs RHACS)
  • When to use the Red Hat option (on-prem, FIPS compliance, unified support)
  • When to use the alternative (multi-cloud, vendor neutrality, cost)

If you’re not on Red Hat’s stack, you can still apply 90% of the patterns—just swap in your vendor’s equivalent tools.

What This Series Isn’t

Not covered:

  • Binary analysis and reverse engineering (Ghidra, Binwalk, radare2)
  • Source code security scanning (SAST tools like SonarQube, Checkmarx)
  • Secret scanning (gitleaks, TruffleHog)
  • Dependency update automation (Renovate, Dependabot)
  • License compliance deep-dives (ScanCode, FOSSology, ORT)

Those are important, but they’re adjacent to supply chain security, not core to it. This series focuses on knowing what’s in your software and whether it’s vulnerable—the SBOM and vulnerability management stack.

If there’s demand, I’ll cover those topics in a follow-up series.

How to Follow Along

Reading order:

  1. Part 0 (this post): Series overview
  2. Part 1: SBOM Tools for Architects (available now)
  3. Part 2-5: Publishing over the next 4 weeks

Hands-on labs: Each post includes working examples you can run locally:

  • SBOM generation with Syft/Trivy
  • Vulnerability scanning with Grype
  • SBOM platform setup (Dependency-Track or RHTPA)
  • Policy enforcement with OPA or RHACS

No SaaS required. Everything runs on your laptop or in a local Kubernetes cluster.

Up next: SBOM Tools for Software Architects →

Questions or feedback? Open an issue at https://github.com/jkirklan/tuscon/issues