2.2 Select and verify the remediated dependency

A security backport lets an application remain on its existing release line while adopting a fix. The exact Lightwell version includes a suffix such as .rhlw-00001. You select that version from the advisory for the matching package, then record it in the application’s default dependency property.

OSV is a JSON vulnerability-record format. Its affected entries identify packages and version ranges; a fixed event names a version containing the fix. This exercise uses LW-DEMO-0002, a workshop sample rather than a real CVE. The sample marks Commons Lang 3.14.0 affected and names a backport as fixed. Resolving the sample demonstrates version selection, not an independent security assessment.

By the end of this module, you will be able to:

The starter’s advisories/LW-DEMO-0002.json is imported from the same canonical fixture that provisioning uses for Nexus. WORKSHOP_REVISION records its source revision. You do not need to extract another copy from a ConfigMap.

Check that the record’s package name matches org.apache.commons:commons-lang3 in your POM. Find the fixed event under that package’s ranges and record its exact value. Do not select a version from an unrelated package.

You can also inspect the same file in Gitea: open workshop-templates/lightwell-dependencies, then advisories → LW-DEMO-0002.json. In the screenshot, the package name identifies Commons Lang and the fixed event names the exact version to select. Read your cloned file for the exercise; the screenshot is a navigation aid.

Use the advisory’s fixed version as the value of <commons.lang3.version>. The dependency’s <version> refers to that property. Changing the default property makes the selected version apply without an additional version override. The Remediated profile in settings selects a repository; it does not change this property.

Open ~/lightwell-dependencies/pom.xml in your terminal editor. Replace the default <commons.lang3.version> value with the exact fixed value you read. Keep the group and artifact unchanged.

The POM diff should show one changed line: the default version moves from 3.14.0 to 3.14.0.rhlw-00001. A newer upstream release is a different coordinate from this exercise’s simulated backport.

Stop and investigate a nonzero Maven status. Compare the saved logs from both modules. Success is the original version in the first tree and the exact advisory version in the second, with successful downloads from the corresponding Nexus channels.

If the baseline is missing, return to module 2.1 and capture the original version before repeating this comparison. Preserve existing evidence directories. On a repeated run with an existing cache, Maven may omit download lines; the fresh-cache commands above avoid that ambiguity.

You have three related observations: the advisory names the fix, Git shows your property change, and Maven shows the selected version and its source. There is no validation Job. The dependency tree does not prove a signature or independently establish that a vulnerability is fixed.

Keep your settings, edited POM, and evidence in Showroom. In Track 3.2, apply the selected version to the default property in your own application’s POM. Do not replace that application’s POM with this small exercise POM. Track 3 commits the change to your student-owned Gitea repository. In a later exercise, Renovate opens a pull request to update the dependency version and base-image digest recorded in lightwell-pins.properties. Track 7 uses the sample’s GAV-bound VEX evidence.

For customer delivery, see Verify supplier provenance for a real Java dependency. That separate control checks a real JAR against its supplier bundle and trusted key; the seeded fixture makes no such provenance claim.