Module 5: Inner Loop, Outer Loop & Next Steps

What you proved on one laptop

This workshop walked a single developer through a single application:

  • Module 2: the bug is real on an API that parses untrusted YAML

  • Module 3: open-source upgrade paths were slow, then still painful

  • Module 4: swap to 1.33.0.rhlw-00001, rebuild, re-test — no Java source changes

From that seat, Lightwell looks almost too easy: edit pom.xml, run tests, move on.

What enterprises actually face

Real organizations rarely fix one app in isolation.

Imagine the same SnakeYAML finding across dozens or hundreds of Java services — many with snakeyaml only as a transitive dependency, some with custom parsers like ours, all flagged by the same security report. Even when the fix is a dependency swap, someone still has to:

  • Find every affected repository and branch

  • Open pull requests (or batch automation) per service

  • Run each pipeline — unit tests, integration tests, security scans

  • Get reviews, change approvals, and release windows

  • Deploy through staging and production, often per team or per cluster

  • Prove to auditors what was deployed, when, and from which signed artifact

That work routinely takes weeks to months — not the minutes you spent in Module 4. The inner loop is necessary but not sufficient. A fixed jar in a repository does not close a CVE across a fleet by itself.

Where the outer loop fits

Project Lightwell supplies the remediated library — a drop-in build on the version you already pin, with signed artifacts and a software bill of materials (SBOM) describing what is inside.

Red Hat Advanced Developer Suite — software supply chain (RHADS) is the automated software factory that turns those libraries into governed releases at scale: rebuild many applications through the same pipeline, attach SBOMs and signed attestations (proof of how each build was produced), scan results, and policy checks before anything reaches production.

Together:

  • Lightwell answers: "Is there a safe snakeyaml build compatible with my code?"

  • RHADS answers: "How do we rebuild, verify, sign, and roll out that fix across every team — safely and auditably?"

Without the factory, every squad repeats the Module 4 steps by hand. With it, platform engineering can remediate in bulk — same CVE, many repos, one controlled path from fix to production.

RHADS was previously marketed as Red Hat Trusted Application Pipeline; you may still see TSSC (Trusted Software Supply Chain) in workshop names and older docs.

If Lightwell had existed back then

Path Typical time to fix Application code changes

Wait for open-source 2.0 and absorb the breakage

Weeks to months (per app)

Many

Refactor to SafeConstructor

Days to weeks (per app)

Moderate (breaks custom Constructor apps)

Lightwell .rhlw hot-swap (inner loop only)

Minutes (one developer, one app)

Zero

Lightwell + RHADS at enterprise scale

Days to weeks (many apps, automated)

Zero for compatible apps; orchestration handles the rest

The last row is the full story: Lightwell removes the parser rewrite trap; RHADS removes the manual repetition trap.

What to do next

You completed: developer inner loop — validate locally, swap the dependency, prove the attack no longer works.

The real next step for your organization is not another self-paced lab on your own. Talk to your Red Hat account team about a workshop tailored to your environment: Project Lightwell for remediated dependencies, plus trusted software supply chain / RHADS for rebuilding, signing, and rolling out fixes across your application portfolio — with your CI/CD systems, artifact repositories, and compliance requirements in the room.

Want a preview first? The Lightwell TSSC Workshop on RHDP is a public example of outer-loop concepts (SBOMs, attestations, pipeline guardrails). It is useful background; it is not a substitute for a customer-specific engagement.

Further reading: RHADS documentation