Module 1: The Environment

Duration: 10 minutes

Lab access and credentials (click to expand)

Everything below is already running. The tabs on the right of this Showroom window open each component in place, which is easier to follow than switching browser windows — the links are there if you prefer your own tab.

Component Credentials

OpenShift Console — Pipelines, Topology

{user} / {password} (SSO)

GitLab

{user} / {password}

Artifact Manager (Nexus)

admin / {password}

Renovate

{user} / {password} (SSO)

ArgoCD

{user} / {password} — via Log in via OpenShift

Trusted Profile Analyzer

{user} / {password} (SSO)

Ansible Orchestrator

{user} / {password}

Snow

(no login required)

Your GUID is %GUID%, and it appears in most of the names you will meet: the GitLab group acme-%GUID%, the running applications in {user}-app, and the build pipelines in build-%GUID%.

This module orients you to the pre-deployed environment. Everything described here is already running. You do not need to open anything yet — you will visit each component as needed throughout the lab.

Your Company: Acme Inc.

You are a platform engineer at Acme Inc., a financial services company. Your team manages three Java applications:

Application Risk Description

wire-transfer-svc

High

Customer-facing wire transfer processing service. Subject to PCI-DSS and SOX compliance. Downtime or security incidents have direct business impact.

benefits-mgmt-app

Low

Internal employee benefits enrollment application. Used by HR during enrollment periods. Not customer-facing; brief downtime is tolerable.

report-generator-app

Low

Internal scheduled report generation service. Runs batch jobs for compliance and analytics. No real-time availability requirements.

All three applications are stored in your GitLab instance under the acme-%GUID% group. Each has intentionally outdated dependencies with known CVEs — that is the point.

The Platform Components

Every component you will use, with its credentials, is listed in the Lab access and credentials block at the top of this page. Expand it whenever you need a URL or a password — it is repeated at the start of every module so you never have to come back here for it.

You will visit these as needed throughout the lab.

Red Hat OpenShift

The application platform underneath everything in this lab. Every component listed below — GitLab, Nexus, TPA, ArgoCD, Ansible Orchestrator, Snow, and the AI agents — runs on OpenShift. The platform provides the develop, secure, deploy, and monitor capabilities they all rely on: container builds and image registries, role-based access control and security context constraints, operator-managed infrastructure, service networking, and the web console you will use to observe pipelines, deployments, and pod health. Whether you are running a quick dependency bump or a full AI-assisted remediation, OpenShift is the platform that makes the pipeline possible.

Ansible Orchestrator

Drives the full automation workflow. Receives events from the artifact manager, dispatches queries to TPA, hands off to AI agents, and tracks the entire flow through Snow.

  • Quick Win: Not used.

  • Full Automation: Orchestrates the entire remediation pipeline end to end.

Trusted Profile Analyzer (TPA)

Stores and queries SBOMs generated by your builds. Each participant has their own dedicated TPA instance, so you only see data for your own applications.

  • Quick Win: You compare SBOMs after the build to confirm the fix landed.

  • Full Automation: The orchestrator actively queries TPA to find which applications are affected by a CVE.

Trusted Artifact Signer (TAS) and Tekton Pipelines

Tekton compiles the application, generates an SBOM, and pushes the container image to the OCI registry. Pipelines trigger automatically when a merge request is merged in GitLab. Trusted Artifact Signer provides keyless signing via Sigstore (Fulcio + Rekor), so every image built by Tekton is cryptographically signed without managing long-lived keys.

  • Both paths: Tekton builds and TAS signs the patched application after you (or the AI) approve a merge request.

ArgoCD

Detects new container images and deploys them to the target environment.

In this lab, ArgoCD deploys straight to production. Real-world customers typically configure multiple stages — test, staging, production — each with its own sync policy and approval gate.

  • Both paths: ArgoCD deploys the newly built image to production after the pipeline completes.

GitLab

Source code for your three Acme applications. Each app has a pom.xml with vulnerable dependencies and a renovate.json that configures the Lightwell preset.

  • Quick Win: Renovate creates merge requests here. Merging triggers the CI pipeline.

  • Full Automation: AI agents create merge requests here. Low-risk ones are auto-approved; high-risk ones wait for you.

Renovate

A dependency update tool that creates merge requests when it finds newer versions. Installed at the cluster level; you trigger scans by creating RenovateJob custom resources.

  • Quick Win: You create a RenovateJob and watch it generate merge requests.

  • Full Automation: Not used — the AI agents handle remediation instead.

Snow

Snow is the IT Service Management (ITSM) ticketing system used in this lab to track remediation from detection through deployment. In production, any ITSM platform works here — ServiceNow, Jira Service Management, BMC Helix, or Freshservice, for example.

  • Quick Win: Not used.

  • Full Automation: The Ansible Orchestrator opens a ticket at the start and updates it at every stage — TPA analysis, AI assessment, MR creation, build, deploy, and closure.

Lightwell Repository (Simulated)

Lightwell publishes remediated, signed builds of open source components — the .rhlw-NNNNN versions you read about in Module 0. In a production environment, these would be fetched from packages.redhat.com with an active Lightwell subscription.

For this lab, a simulated Lightwell repository is hosted in your dedicated artifact manager (Sonatype Nexus). It contains the same artifact structure as the real Lightwell repository — Maven metadata, POMs, and JARs with .rhlw version suffixes — so the automation behaves identically. The artifact manager also serves as a Maven build cache and an OCI container registry for your built images. In production, any Maven-compatible artifact manager works — JFrog Artifactory, Sonatype Nexus, or even a simple Maven proxy.

  • Quick Win: Renovate watches this repository for new .rhlw versions and creates merge requests.

  • Full Automation: The artifact manager fires an event when a new artifact arrives, triggering the Ansible Orchestrator workflow.

Ready?

Continue to Module 2: Quick Win — Automated Dependency Updates.