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 exact versions. An exact version is the full name written in source. For the base, that name is the Hummingbird pull spec, digest included. For a library, that name is a version such as 3.14.0.rhlw-00001. 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.

Product reference checked on 2026-11-10: Lightwell offers Network and Clearinghouse subscriptions. Clearinghouse is generally available to eligible organizations for approved scope; this is not a promise of coverage for every package or vulnerability. Confirm eligibility, entitlements, and current service terms with Red Hat’s current offering information.

Predisclosure is a Network repository tier, not an exclusive Clearinghouse capability. Its versions add -nXXXX after the remediation suffix, for example 5.3.17.rhlw-00001-n0001. Follow the applicable access and redistribution terms; this is a reference topic, with no third repository exercise. See repository version suffixes.

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. For the evidence and repository concepts, see 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 module where you will meet it, and what changes if the customer is on Network or on Clearinghouse.

You walk one supply chain on this OpenShift environment. We use Java, Maven, an artifact manager such as Artifactory, and in-cluster Gitea. On this cluster the artifact manager is Nexus, and the application is a Java greeting service. 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 module where this workshop already practiced the underlying control.

Each Track 5 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 Exercise. 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, feel free to retry until you succeed.

Track 1 uses the Review in its guide: compare the mirrored image with the recorded starting state and inspect the playbook’s signature-verification evidence. The successful Ansible workflow publishes its report; you do not fill its token manually or run a separate validation Job. Track 2 uses Maven command output for its review. Track 3 uses repository inspection, comparisons with the earlier image and dependency evidence, and review of the merged Renovate pull request. Track 4 uses the existing Review sections to inspect Git source, live Pipeline and NetworkPolicy output, and saved build and SBOM evidence. Tracks 3 and 4 have no validation Job or report token to submit. Track 6 uses terminal checks of published Git configuration, Argo CD state, runtime policies, and signed-versus-unsigned evidence, with no validation Job or report token to submit. Track 7 compares the promoted digest with a retrieved TPA inventory, interprets the sample library advisory, and inspects ACS policy output for the same image. It uses terminal evidence and a local written report, with no validation Job or report token. Track 5 provides its own report keys and Job commands.

You read this guide in the RHDP Showroom, which is the lab nav plus an embedded terminal. ansible-playbook, 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 lab-* ConfigMaps. On a module that has a Validate Job, that Job in lw-poc-validate is the Check. 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 Build a verified base-image mirror with Ansible when you are ready to make the first change.

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

Showroom mounts persistent storage at /home/lab-user. Keep the application and stage/production GitOps clones in /home/lab-user/lightwell-workspace; the exercises use absolute paths so temporary registry login settings cannot redirect your work. Keep the existing evidence directories (lightwell-build-evidence, lightwell-signing-evidence, and any Track 7 evidence) and lab-trust under that same home. /tmp is only for files you can recreate from Git or cluster state. The home volume survives a Showroom pod replacement, but it is not a backup after your claim or its PVC is deleted.

When you return, open a new terminal, confirm oc whoami, and rerun the current module’s discovery commands to restore shell variables. Showroom initializes Git authentication on startup; if a push cannot authenticate, use the Git setup instructions in module 3.2. Repeat the registry login before signing or copying images, because its temporary credentials may be gone. Inspect git status in each existing clone before continuing. Do not reclone over it, reset it, or regenerate a signing key that is already present. Compare saved image digests with the live image before reusing verification evidence.

If you started with an older guide and the old /tmp clone still exists, move that directory into /home/lab-user/lightwell-workspace only when the destination does not exist; moving the whole clone preserves uncommitted files and .git. Also move any track6-*-verification.json and unsigned-test event evidence into /home/lab-user/lightwell-signing-evidence before a restart. If both old and new directories exist, inspect them and reconcile your edits before proceeding. After /tmp has been lost, clone from the student-owned remote to recover pushed commits and repeat the evidence-producing steps. Uncommitted files lost with /tmp cannot be recovered from Git.