Lightwell Software Supply Chain Security Workshop

This Red Hat Demo Platform (RHDP) workshop walks one trusted software supply chain on a dedicated OpenShift claim. You verify a Hummingbird base, consume Lightwell dependencies, own the application source, build hermetically, sign and attest, promote a production container, then prove continuous compliance.

The lab application is Java (Maven). Where the same control applies to Python (pip) or Artifactory, the page says so in one sentence.

This page is a map, not an exercise. There is nothing to pass here. Hands-on work starts at 1.1 Verify Hummingbird: you discover the published Hummingbird pin and run cosign verify against it.

What is a trusted software supply chain

A trusted software supply chain (TSSC) is the set of controls that let you prove, for every production container, what went into the image, who built and signed it, and whether known vulnerabilities are remediated without pretending the public internet is a trusted input.

Red Hat TSSC is that proof on OpenShift: signed and attested artifacts (Red Hat Trusted Artifact Signer), a system of record for SBOMs and advisories (Red Hat Trusted Profile Analyzer), runtime and pipeline policy (Red Hat Advanced Cluster Security, Conforma / Enterprise Contract), GitOps promotion (OpenShift GitOps), and a golden path for developers (Red Hat Developer Hub). The same stack is described as the technology behind Red Hat Trusted Application Pipeline.

TSSC does not start at the pipeline. It starts with inputs you can name: a signed runtime base, application libraries that come from a trusted repository, and source that binds those pins. That is where Lightwell and Hardened Images sit.

TSSC controls wrapping Lightwell Network catalog consumption and Clearinghouse Premier member remediations

Lightwell Network and Lightwell Clearinghouse Premier

Lightwell is the Red Hat and IBM initiative that extends enterprise open source maintenance to third-party application dependencies (libraries, frameworks, build tools, transitive deps). Scanners find CVEs; teams often cannot upgrade because of certification, compatibility, or release windows. Lightwell supplies surgical security remediations on the versions you already run.

Lightwell is an annual subscription with two models. This workshop scores the Network consumption path. Clearinghouse Premier is limited availability and is not a second hands-on path. You still need to name both models in a customer conversation.

Model What it is How it shows up in this TSSC lab

Lightwell Network (available)

Consolidated access to Lightwell remediations for eligible open source vulnerabilities. Repositories are Validated (upstream-parity, signed, SBOM) and Remediated (security-only backports with a .rhlw-* version suffix). Consume through existing build and artifact-manager workflows.

Tracks 2, 3, and 7: enterprise Nexus proxy, exact .rhlw-* pin from an OSV fixed event, GAV-bound VEX/SBOM in TPA. Docs: Choose the right repository, Configure your Java build tool. Console: https://console.redhat.com/lightwell.

Lightwell Clearinghouse Premier (limited availability)

All Network benefits, plus vulnerability reporting and remediation for member-specific package versions, novel vulnerability verification and disclosure handling (secured patch embargoes), anonymized access to other member requests, and TAM services. Aimed at pre-selected critical infrastructure, with a broader release planned.

Not a separate cluster. A Premier remediation is still a pinned GAV (or +rhlw. wheel) that must land in the *same enterprise proxy, the same source pin, the same hermetic build, and the same TPA/ACS evidence. Tracks 2, 3, and 7 are the controls you would configure for that member version, including during an embargo (private proxy, pin from the GAV, delay public OSV/VEX).

An embargo is a coordinated-disclosure window: the vulnerability and its patch stay in a closed member set until a public date. Clearinghouse Premier can deliver that member pin during the window. Lightwell Network’s documented lifecycle ends at public Disclosure (VEX and OSV to the broader ecosystem; Patch delivery lifecycle). This workshop scores the post-disclosure Network path. The TSSC controls do not change; the timing of public OSV/VEX does. There is no embargo exercise on this claim. More: Lightwell concepts.

Lightwell Network catalog versus Clearinghouse Premier member-specific remediations

Do not treat Lightwell as a replacement for RHEL, OpenShift, or ACS. Those products cover OS and platform. Lightwell covers application-layer dependencies. Do not treat it as a replacement for Hummingbird / Red Hat Hardened Images either: Hardened Images are the runtime foundation; Lightwell is the library layer. Commercial SKUs, pricing, and associate-only sales guidance stay off this page (Lightwell concepts).

How this workshop maps to TSSC

Observe these TSSC objectives as you work. Each gated module exists so you can see the control, not only complete a ConfigMap.

Trust chain from Hummingbird digest and Lightwell GAV through signed app image to TPA VEX
TSSC objective Where you observe it Lightwell Network / Clearinghouse Premier

Trusted runtime input (signed minimal base)

1.1 published cosign verify; 1.2 dest digest after oc-mirror

Complementary. Hummingbird is not a Lightwell GAV. Premier does not replace Hardened Images.

Trusted library input (enterprise proxy, not the public index)

2.1 Maven settings.xml against Nexus Validated/Remediated

Network: this is how customers consume https://packages.redhat.com/lightwell/java/validated and https://packages.redhat.com/lightwell/java/remediated. Premier member versions (including embargoed GAVs) use the same remotes and must not fall through to Maven Central.

Exact-version remediation (not “upgrade to latest”)

2.2 OSV fixed → .rhlw-* default pin

This Check is post-disclosure Network OSV. Under a Premier embargo you may already have the .rhlw- GAV in the private proxy *before public OSV exists; still pin that exact version.

Source of truth binds those pins

3.1 learner-owned Gitea; 3.2 dest FROM + default pin; 3.3 bot PR

Renovate (MintMaker in a client engagement) is how new Network or Premier pins arrive without a hand-edit. During embargo, merge the pin; do not paste the advisory into a public PR description.

Hermetic production of the image (source, prefetch, network)

4.1–4.4

Lightwell GAVs must resolve from the internal proxy after egress is denied. Premier does not add a public fallback.

Integrity of the app artifact (sign, policy, disconnected verify)

5.1–5.3

You sign the application image. Lightwell already signed the library. Distinct layers.

Only the signed digest may run, and prod is a separate promote

6.1–6.2

Admission does not care which Lightwell model produced the GAV. It cares that the image is signed.

Continuous compliance (SoR + blast radius)

7.1–7.2

Network: GAV-bound VEX/OSV for the pin (public, post-disclosure). Premier: member advisories ingest into the same TPA; during embargo that metadata stays off public scanner feeds.

Seven tracks

Seven-track TSSC flow — Hummingbird through continuous compliance

Work the tracks in order. On each numbered page, Your change is the edit you make; Check is the commands that should succeed afterward. Do both before you continue. Later pages assume the earlier work landed.

Track 1 — Hummingbird
Track 2 — Lightwell dependencies
Track 3 — Source
Track 4 — Hermetic build
Track 5 — Signed and attested image
Track 6 — Production container
Track 7 — Continuous compliance

What this workshop does not include

You walk one Java (Maven) supply chain on this OpenShift environment. The items below are out of scope on purpose. Do not look for them in the console or the nav.

Not in this workshop What you do instead

Hosted Konflux

Builds run as OpenShift Pipelines (the Task and BuildConfig names on the cluster). Names you may hear in a customer conversation are in Konflux mapping. Do not install Konflux.

A physical air-gap or data diode

This environment stays on the network. 5.3 is the key-based sign and verify procedure. Disconnected transfer is a simulated file drop, not USB or a diode.

Building Project Hummingbird images

You verify and consume published Red Hat Hardened Images. You do not rebuild the Fedora factory that produces them.

FIPS certification in the lab

FIPS is a product claim on the image you consume. This workshop does not rebuild an image to produce FIPS evidence.

JFrog Artifactory, or a Python (FastAPI) application

The lab application is Java. Nexus is the enterprise proxy you configure. Short callouts cover pip and Artifactory patterns; you do not install Artifactory or scaffold a second app.

A live Clearinghouse Premier membership, member-specific GAV, or embargo window

You practice the post-disclosure Network pin and the TSSC controls Premier would reuse (private proxy, exact pin, SoR). You do not request a member-only package or sit inside a real embargo on this claim. Concept: Lightwell concepts.

A customer proof-of-value or certification exam

This is a guided workshop. You practice the flow here. Internal enablement is scored after the event. It is not a live PoV on this environment.

A production virtual machine

You promote a signed container digest through GitOps (6.1, 6.2). The same digest can later run on bootc or Satellite; there is no VM to boot here.

Honor system

The nav does not lock. You can open 7.2 on day one. Nothing in this workshop pastes the answer for you. If you skip a Check, later steps fail for real (wrong FROM, no signature, unsigned image denied).

Each gated module has an in-cluster Validate Job in lw-poc-validate. Do the Your change. Fill that module’s report ConfigMap token. Run the Job (delete it if it already exists, create it from ConfigMap validate-job-templates, read the logs). Then continue. There is no Solve. Unlimited retries.

Here is 1.1 as an example:

Fill the report

The Job also grades ConfigMap report-01-hummingbird-verify key consume_published. Set it to consume-published. Empty or REPLACE_ME fails even if cluster state is correct. Do not copy validate-docs.

oc -n lw-poc-validate edit configmap report-01-hummingbird-verify

The scored Check is Job validate-01-hummingbird-verify in lw-poc-validate. Direct nav URLs still work (honor system). Unlimited retries. There is no Solve.

Run the Validate Job
oc -n lw-poc-validate delete job validate-01-hummingbird-verify --ignore-not-found
TPL='job-01.yaml'
oc -n lw-poc-validate get configmap validate-job-templates \
  -o go-template="{{ index .data \"${TPL}\" }}" | oc create -f -
oc -n lw-poc-validate logs -f job/validate-01-hummingbird-verify

Expect CHECK PASSED: before you continue. CHECK FAILED: names the object to fix. Delete the Job and create it again as often as you need.

The same three commands appear on every gated Check, with that module’s Job name.

Before you start

  • This guide runs in the RHDP Showroom (lab nav plus embedded terminal).

  • oc, cosign, oc-mirror, and ec are already on PATH. Do not curl github.com for CLIs.

  • Discover URLs, digests, and passwords from demo-userinfo-* ConfigMaps. Do not invent Route hosts. Do not use GitHub as lab git. Gitea is in-cluster.

  • Gated Checks are Validate Jobs in lw-poc-validate. The intro shows how to run one.

  • Never commit credentials (LW_USERNAME / LW_PASSWORD, student_password, cosign.key).

Official documentation

Use product docs when a customer asks “where is that written?”, not as a substitute for the Checks.

Start here

Open 1.1 Verify Hummingbird when you are ready to work.

Consultant maps: delivery map, Konflux mapping, disconnected transfer. Instructors: two-day grouping (envelope, not a timer). After the event: internal enablement checklist. Concepts: Lightwell concepts, acronym glossary.