[vharseko]

Fixes the code scanning (Trivy) findings that are still present in an image built from master.

Changes

Library	Was	Now	Comes from	Alerts
bcprov / bcpkix / bcutil-jdk15to18	1.71	1.86 (pinned)	com.ibm.mq.allclient 9.3.1.0	#96 #97 #111 #112
kafka-clients	3.9.1	3.9.2	kafka_2.13 3.9.1 → 3.9.2	#94
jose4j	0.9.4	0.9.6	kafka_2.13	#95
lz4-java	org.lz4 1.8.0	at.yawk.lz4 1.11.4 (pinned)	kafka-clients	#98 #126 #127
httpcore5 / httpcore5-h2	5.3.6	5.4.4 (pinned, with httpclient5 5.6.5)	antisamy ← esapi ← openam-federation-library	#92 #93
/usr/bin/pebble (Go stdlib 1.27.1)	present	removed from the image	tomcat:11-jre25 base (Ubuntu 26.04)	#113–#116

Notes:

• Kafka stays on 3.9.x: EmbeddedKafka runs the ZooKeeper-mode kafka.server.KafkaServer, which Kafka 4.0 removed. kafka-clients 3.9.2, the last 3.9.x, brings at.yawk.lz4 1.10.1, which is still inside CVE-2026-106451 (GHSA-mcr4-qmvw-px4g, fixed in 1.11.4), so lz4-java is pinned to 1.11.4.
• Bouncy Castle: besides the CVEs, 1.86 is signed with the same certificate as opendj-core's bc-fips 2.1.3, while 1.71 is not. With the FIPS jars first on the classpath, loading org.bouncycastle.crypto classes of 1.71 failed with "signer information does not match". MQ_IBMBouncyCastleTest pins this: red on 1.71, green on 1.86, while the openig-core test classpath lists the FIPS jars first.
• HttpClient 5 ships in the war through antisamy, but its version was decided by the test-scoped wiremock (nearer in the dependency tree), so it is now pinned explicitly.
• pebble: the Ubuntu 26.04 base image is built with rockcraft and carries /usr/bin/pebble outside dpkg, so apt-get upgrade never patches it. The image runs catalina.sh, not pebble. The rm deletes it from the container filesystem; the base layer still carries the file, but whiteout-aware scanners such as Trivy do not report it.

Verification

• mvn verify -pl openig-core,openig-saml,openig-war -am: BUILD SUCCESS, no failures (1039 tests in openig-core).
• EmbeddedKafkaTest and MQ_KafkaTest (JUnit 4, which the default run does not pick up, so run with -Dtest): pass, the embedded ZooKeeper-mode KafkaServer starts on 3.9.2.
• MQ_IBMBouncyCastleTest under surefire: passes on 1.86; fails on 1.71 with SecurityException: class "org.bouncycastle.crypto.InvalidCipherTextException"'s signer information does not match ....
• LZ4 under Kafka 3.9.2 with lz4-java 1.11.4 (no test sets compression.type=lz4, so checked by hand): MemoryRecords with Compression.lz4() round-trip for magic v1 and v2 through LZ4Factory:JNI.
• The built war contains bcprov/bcpkix/bcutil-jdk15to18 1.86, httpclient5 5.6.5, httpcore5/-h2 5.4.4, kafka-clients 3.9.2, jose4j 0.9.6, lz4-java 1.11.4 (at.yawk.lz4), and no org.lz4.
• An image built from the first round's war the same way as build.yml has no /usr/bin/pebble and reaches healthy; this round changes only a comment in the Dockerfile, and build-docker on this PR builds the image from the new war and waits for healthy.
• Trivy: the build.yml scan cannot turn the check red (continue-on-error, ignore-unfixed), so the result is read from the PR ref:

  gh api "repos/OpenIdentityPlatform/OpenIG/code-scanning/alerts?ref=refs/pull/190/merge&tool_name=Trivy&state=open" \
    --jq '.[] | .rule.id + " " + .most_recent_instance.location.path'

  On the first round (d5c89744) it returned one alert, CVE-2026-106451 .../WEB-INF/lib/lz4-java-1.10.1.jar (CVE-2024-38999 requirejs v2.3.6 was discovered to contain a prototype pollution  #128), which the lz4 pin of baba1516 addresses; the result for baba1516 is pending its build-docker run. A CVE still listed proves it is not fixed; a missing one alone does not prove it is.
  ignore-unfixed keeps org.lz4 1.8.0 (Update README.md: add backers and sponsors #126, ISSUE_TEMPLATE: add "Vote to raise the priority" #127: no fixed version in that namespace) out of the build.yml scan altogether, so their closure on this PR is shown by the advisory ranges, not by the scan: CVE-2025-66566 is fixed in at.yawk.lz4 1.10.1 and CVE-2026-106451 in 1.11.4.

After merge

Code scanning merges alerts across the trivy-build-default and trivy-image-latest categories, so the alerts above (except the pebble ones, which only exist in the master build) stay open until the next release republishes openidentityplatform/openig:latest.

[maximthomas]

praise: Most of the alerts really do close, and the BC pin also fixes a signer clash with the bc-fips jars the war already ships.

• pom.xml:1090-1105: bcprov/bcpkix/bcutil-jdk15to18 1.86 are signed with the same Bouncy Castle certificate as opendj-core's bc-fips 2.1.3. At 1.71 they were not. With the FIPS jars first, which is also alphabetical order, resolving com.ibm.mq.allclient's 101 BC member refs failed 3 times (PaddedBufferedBlockCipher.*, "signer information does not match"). At this head all 101 resolve, whatever the jar order.
• pom.xml:1106-1122: mvn dependency:tree -pl openig-war at this head resolves httpclient5 5.6.5 and httpcore5/httpcore5-h2 5.4.4 in compile scope. The advisory ranges of #92-#98, #111, #112 and #126 all exclude the versions this head resolves. IT_SwaggerRoute (wiremock) passes in CI with the new HttpClient.
• openig-docker/Dockerfile:47: on all four platforms release.yml builds, /usr/bin/pebble is a regular file outside dpkg at that same path. It is the only Go binary in the amd64 base, and nothing runs it (Entrypoint null, CMD catalina.sh run, the HEALTHCHECK curls /openig/).

---

issue (blocking): lz4-java 1.10.1, which kafka-clients 3.9.2 brings in, is still inside CVE-2026-106451 (alert #127), and the commit says it addresses that alert.

openig-core/pom.xml:156, pom.xml:1105

GHSA-mcr4-qmvw-px4g covers at.yawk.lz4:lz4-java <= 1.11.3, first patched in 1.11.4. At this head, mvn dependency:tree -pl openig-war -am resolves at.yawk.lz4:lz4-java:1.10.1 (runtime, via kafka-clients 3.9.2) as the war's only lz4, and no pom manages its version. So #127's lz4-java-1.8.0.jar location goes away, but the same CVE ships as lz4-java-1.10.1.jar. kafka-clients 3.9.2 is the last 3.9.x, so staying on Kafka 3.9 means pinning lz4. What was checked:

• kafka-clients 3.9.2 makes 13 net.jpountz method refs (Lz4BlockInputStream, Lz4BlockOutputStream; kafka_2.13 makes none), and all 13 resolve against 1.11.4 and 1.12.1.
• The GitHub advisory database lists nothing against 1.11.4. Against 1.10.1 it lists six advisories, one of them high.

Not checked: LZ4 at runtime under Kafka. No test sets compression.type=lz4.

		<!-- lz4 of kafka-clients 3.9.2 (openig-core): 1.10.1 is inside CVE-2026-106451, fixed in 1.11.4 -->
		<dependency>
			<groupId>at.yawk.lz4</groupId>
			<artifactId>lz4-java</artifactId>
			<version>1.11.4</version>
		</dependency>

Or: keep 1.10.1, and drop #127 from the commit message and from the lz4 row of the description's table.

---

suggestion (non-blocking): No test checks that com.ibm.mq.allclient's Bouncy Castle calls link against the BC version this PR forces on it.

openig-core/src/test/java/org/openidentityplatform/openig/mq/MQ_IBMTest.java:45

The root pin overrides the 1.71 that allclient 9.3.1.0 declares. MQ_IBMTest needs a hand-started queue manager, configures no TLS/AMS, never reads the handle() futures and asserts nothing. A BC version that allclient cannot link against would stay green, and so would one signed differently from opendj-core's bc-fips. Measured outside surefire: with the FIPS jars first, resolving PaddedBufferedBlockCipher.doFinal fails at the base (1.71) with "signer information does not match" and passes at this head.

package org.openidentityplatform.openig.mq;

import org.testng.annotations.Test;

public class MQ_IBMBouncyCastleTest {

    @Test
    public void mqAmsCipherClassesLinkNextToBcFips() throws Exception {
        // PaddedBufferedBlockCipher is only in bcprov-jdk15to18; its InvalidCipherTextException is also in bc-fips
        Class.forName("org.bouncycastle.crypto.paddings.PaddedBufferedBlockCipher")
                .getMethod("doFinal", byte[].class, int.class);
    }
}

Pin: the case turns red on the base's 1.71 when openig-core's test classpath has the FIPS jars first. The tree lists opendj-core before com.ibm.mq.allclient. The case has not been run under surefire.

---

suggestion (non-blocking): The "build.yml scan on this PR" that the Verification section relies on cannot show these alerts closing.

.github/workflows/build.yml:143, :153, :163

The Trivy step runs in build-docker with continue-on-error: true and ignore-unfixed: true. Nothing it finds can turn it red, not even a CVE that still ships, such as lz4 1.10.1 above. It uploads under trivy-build-default, but #92, #93, #126 and #127 are trivy-image-latest alerts from docker-scan.yml. Quote the PR-ref results rather than the green check:

gh api "repos/OpenIdentityPlatform/OpenIG/code-scanning/alerts?ref=refs/pull/190/merge&tool_name=Trivy&state=open" \
  --jq '.[] | .rule.id + " " + .most_recent_instance.location.path'

Pin: once build-docker has run, the CVE ids of #92-#98, #111-#116, #126 and #127 should be missing from that list. A CVE still listed proves it is not fixed. A missing CVE alone does not prove it is.

---

nitpick (non-blocking): The Dockerfile comment says pebble "is removed", but the pushed image's base layer still carries it.

openig-docker/Dockerfile:32-33, :47

The rm -f in this RUN adds a whiteout over the tomcat:11-jre25 layer that holds the 10.5 MB binary. The container filesystem no longer shows it, and neither do whiteout-aware scanners such as Trivy, the source of #113-#116. A tool that reads the image layer by layer still finds it.

# /usr/bin/pebble ships with the Ubuntu base image outside dpkg, so apt-get upgrade never patches
# its Go runtime; the image runs catalina.sh, not pebble, so it is deleted from the container
# filesystem (the base layer still carries it; Trivy applies whiteouts)

[vharseko]

Addressed in baba151.

lz4 (blocking): pinned at.yawk.lz4:lz4-java 1.11.4 in the root dependencyManagement, with your comment. The war now carries lz4-java-1.11.4.jar and no other lz4. The PR-ref scan confirmed the problem on d5c89744: its only open Trivy alert was #128, CVE-2026-106451 on lz4-java-1.10.1.jar. On the runtime gap you noted: MemoryRecords with Compression.lz4() (kafka-clients 3.9.2) round-trips for magic v1 and v2 on 1.11.4 through LZ4Factory:JNI, checked by hand, not as a test.

BC linkage test: added as MQ_IBMBouncyCastleTest. Under surefire it passes on 1.86 and fails on 1.71 with SecurityException: class "org.bouncycastle.crypto.InvalidCipherTextException"'s signer information does not match .... Its Javadoc notes that it depends on the FIPS jars coming first. The pom comment on the BC pin now also gives the signer reason, not only the CVEs.

Verification via the PR ref: the description now quotes the query result instead of the green check. For baba1516 the result is pending: build-docker has not run yet. One correction on the list: #92 and #93 are not trivy-image-latest-only. They have trivy-build-default instances on master and on the merge refs of #176, #178, #181 and #189, and none on refs/pull/190/merge, so the PR scan does show them gone. #126 and #127 are the ones it cannot show: org.lz4 has no fixed version, so ignore-unfixed drops them from the build scan.

Dockerfile comment: took your wording.

[maximthomas]

praise: Round 2 closes the lz4 gap, and the new Bouncy Castle test fails under the real build, as the description says.

• pom.xml:1108-1113 pins at.yawk.lz4:lz4-java to 1.11.4, the first patched version of GHSA-mcr4-qmvw-px4g. All 13 net.jpountz refs in kafka-clients 3.9.2 resolve in it.
• MQ_IBMBouncyCastleTest is red under surefire with the root-pom BC pins reverted (tests=1 failures=1, SecurityException: ... signer information does not match) and green at the head. In the forked classpath bc-fips-2.1.3 comes ahead of bcprov-jdk15to18.
• The Dockerfile comment now matches the image: ubuntu:26.04 itself carries /usr/bin/pebble, and the rm deletes it from the container filesystem, not from the base layer.