Lightwell Software Supply Chain Security Workshop

A trusted software supply chain (TSSC) is the set of controls that let you answer three questions for every production container. What went into the image? Who built it and signed it? Are known vulnerabilities remediated, without treating the public internet as a trusted input?

On OpenShift, Red Hat TSSC is those controls as products you will actually open in this workshop:

The same stack is what Red Hat Trusted Application Pipeline describes. You will not install that pipeline as a product. You will use the pieces above, on this cluster, under the names the modules use.

TSSC does not start when a pipeline runs. It starts with inputs you can name: a signed runtime base, application libraries from a trusted repository, and source that records both pins. Hummingbird is the base. Lightwell is the library layer.

Lightwell is the Red Hat and IBM initiative that maintains third-party application dependencies: libraries, frameworks, build tools, and the transitive dependencies those pull in. A scanner can name a CVE that your team cannot upgrade away from, because of certification, compatibility, or a release window. Lightwell supplies a security-only fix on the version you already run.

Lightwell is an annual subscription with two models. This workshop scores the Network path. Clearinghouse Premier is limited availability. You still need both names in a customer conversation, because a Premier remediation lands in the same proxy, the same source pin, and the same evidence store you configure here.

An embargo is a coordinated-disclosure window. The vulnerability and its patch stay inside 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, when VEX and OSV go to the broader ecosystem (Patch delivery lifecycle). This workshop scores the post-disclosure Network path. The controls are the same. What changes is when the public advisory exists. This cluster has no embargo exercise. The longer explanation is in Lightwell concepts.

Keep the layers separate when you talk to a customer. Lightwell covers application-layer dependencies. RHEL, OpenShift, and ACS cover the operating system and the platform. Hummingbird, part of Red Hat Hardened Images, is the runtime foundation the container starts from. Commercial SKUs, pricing, and associate-only sales guidance stay in Lightwell concepts.

Each gated module exists so you can see the control, not only so you can fill in a ConfigMap. Use the table as a glossary while you work: the objective, the page where you will meet it, and what changes if the customer is on Network or on Clearinghouse Premier.

Work the tracks in order. On each numbered page, Your change is the edit you make. Check is the command sequence that should succeed afterward. Do both before you continue. Later pages assume the earlier work landed: the mirrored digest, the Maven pin, the signature.

You prove the runtime base before anything else. First you verify the published image. Then you mirror it into the registry this cluster trusts, and you record the digest you will later put on a FROM line.

You stop resolving application libraries from the public internet. Maven reads Lightwell through Nexus. Then you replace a vulnerable default version with the exact remediated pin a Lightwell advisory names.

The pins have to live in source you own, or the next build can drift back to the public base and the public version. You take the Java repo on in-cluster Gitea, commit the mirrored Hummingbird digest and the Lightwell pins, and accept a Renovate pull request that updates those pins. A hand-edit of the same file fails the Check.

A trusted pin still fails if the build can reach around it. You remove public FROM lines, Maven Central, and curl from the files the build actually uses, prefetch the declared dependencies, and close egress from the build namespace. The BuildConfig then produces the image and an SBOM from what was already inside the trust boundary.

The image is an application artifact now, separate from the Lightwell library someone else already signed. You sign it keylessly with Trusted Artifact Signer, tighten Conforma until a known-bad image fails and yours passes, and repeat a key-based verify as you would on a disconnected network. This cluster stays on the network. The procedure is what you are practicing.

GitOps is allowed to deploy the signed digest, and admission refuses an unsigned one. Stage is the first remote. Production is a second Gitea remote. You commit the same signed digest there. The Check fails if the prod Application is still tracking stage.

A signed image still needs a record of what is inside it, and a statement of whether the Lightwell pin closed the CVE. You ingest the promoted digest into Trusted Profile Analyzer, then report the blast radius from the GAV-bound VEX. ACS has to be on for that image. Skipping the ACS check fails the module.

You walk one Java (Maven) supply chain on this OpenShift environment. The table is here so you do not lose time looking in the console for a product this cluster deliberately left out. When a customer asks about that product, the right-hand column is the sentence you use, and the page where this workshop already practiced the underlying control.

The nav does not lock. You can open 7.2 on the first morning and read ahead. The cluster still expects the earlier proof. Skip a Check and a later step fails for a concrete reason: the FROM digest is wrong, the image has no signature, or admission refuses the unsigned image.

Each gated module has an in-cluster Validate Job in the namespace lw-poc-validate. The Job grades the live object you changed and a report ConfigMap token that shows this module was completed. Do the Your change. Fill the token. Run the Job. If the Job already exists, delete it, create it again from ConfigMap validate-job-templates, and read the logs. There is no Solve. You can retry without a quota.

Here is that pattern on 1.1. Every later Check is the same three commands, with that module’s Job name.

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.

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.

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.

Expect CHECK PASSED: before you leave a module. CHECK FAILED: names the object to fix.

You read this guide in the RHDP Showroom, which is the lab nav plus an embedded terminal. oc, cosign, oc-mirror, and ec are already on PATH. Leave GitHub out of the lab: do not curl it for CLIs, and do not use it as the lab git remote. Gitea is in-cluster.

Discover URLs, digests, and passwords from the demo-userinfo-* ConfigMaps. Inventing a Route host will fail the command that consumes it. The Checks that grade you are the Validate Jobs in lw-poc-validate, and the example above is the one you copy. Never commit credentials: LW_USERNAME, LW_PASSWORD, student_password, or cosign.key.

Open the product docs when a customer asks where a claim is written. They do not replace a Check. The Check is what this cluster grades.

Open 1.1 Verify Hummingbird when you are ready to make the first change.

If you are delivering the workshop rather than taking it, the maps sit beside this page. Consultants: delivery map, Konflux mapping, disconnected transfer. Instructors: two-day grouping, which is an envelope for the room, not a timer. After the event: internal enablement checklist. Concepts you may want open in another tab: Lightwell concepts, acronym glossary.