Module 0: CVEs, SBOMs, and the Patch Workflow — Foundations

Lightwell is a joint initiative between Red Hat and IBM focused on securing the open source software supply chain. It extends Red Hat’s proven model of enterprise open source maintenance by providing access to security remediations and mitigations far beyond our traditional product footprint.

In practice, that means remediated rebuilds of open source components. When a CVE lands against a widely used library, Red Hat rebuilds the affected version with the fix applied, signs it, and publishes it together with machine-readable metadata describing which CVEs that rebuild resolves. The rebuild keeps the upstream version number and the original API, with an .rhlw suffix marking it as remediated — so adopting it is a version bump rather than an upgrade.

That matters because the slow part of patching is rarely the patch. It is finding a fixed version you trust, or backporting one yourself, and then proving to everyone downstream that it is safe to take. Lightwell removes that step. This lab exists to show what you can build once it is gone: if a trustworthy fixed artifact simply arrives, remediation becomes plumbing — notice the new build, work out which applications use the component, raise the change, ship it. The rest of this lab automates that plumbing two different ways.

A CVE (Common Vulnerabilities and Exposures) is a public identifier for one specific flaw in one specific piece of software — for example CVE-2023-24998, a denial-of-service in Apache Commons FileUpload. The identifier is just a label; the useful part is the metadata attached to it.

Severity is scored with CVSS (Common Vulnerability Scoring System), which produces a number from 0.0 to 10.0 and a band:

The crucial thing to understand is that CVSS scores a flaw, not your risk. The score is computed once, globally, by someone who has never seen your environment. A critical CVE in a library you ship but never call is not a critical risk to you. A medium CVE in your internet-facing payment path may well be. Everything in this lab exists to close that gap — to move from "a CVE exists somewhere in our estate" to "this CVE affects these three applications, and here is the patch".

A Software Bill of Materials is a machine-readable inventory of everything inside a build: every direct dependency, every transitive dependency, their versions, and their licences. Think of it as the ingredients list for a container image. The two common formats are CycloneDX and SPDX; this lab uses CycloneDX.

SBOMs matter because modern applications are mostly other people’s code. A Java service with twenty declared dependencies routinely resolves to several hundred actual artifacts. When a CVE lands against one of those transitive dependencies, the question "are we affected?" is genuinely hard to answer without an inventory.

Without SBOMs, answering it means grepping build files across every repository, and you will miss things — transitive dependencies do not appear in your pom.xml. With SBOMs, it is a database query: which SBOMs contain commons-fileupload at a version below 1.5?

In this lab, SBOMs are stored and queried in Red Hat Trusted Profile Analyzer (RHTPA). In the quick win path you will generate SBOMs as part of the build; in the full automation path, RHTPA actively identifies which of your applications are affected by a given CVE.

An SBOM tells you a component is present. It does not tell you whether the vulnerable code is actually reachable. That is the role of VEX (Vulnerability Exploitability eXchange) — a supplier’s statement about whether a specific CVE genuinely affects a specific product.

Red Hat and other vendors publish VEX documents for their products. Customers can also generate VEX for their own applications and feed it into their scanners, so that known-safe components are not continuously flagged as vulnerable.

VEX is not directly demonstrated in this lab, but it is an important part of the broader supply chain story — it prevents SBOM data from drowning you in false positives.

A CVE is published. Here is what usually happens next:

Each step is individually reasonable. Together they routinely take weeks — and most of that time is not technical work, it is waiting, searching, and re-establishing context. Meanwhile the vulnerability is live in production.

Three things make it slow, and Lightwell attacks all three:

This lab demonstrates two approaches to automating CVE remediation with Lightwell. Both use the same underlying infrastructure — they differ in how much automation and intelligence is applied.