Conversation
There was a problem hiding this comment.
Pull request overview
Updates dependency and container image components to address reported vulnerabilities, primarily by bumping Tomcat and standardizing Jackson versions.
Changes:
- Import Jackson BOM and add an explicit
jackson-coredependency/version inpom.xml. - Bump
tomcat-embed-corefrom11.0.12to11.0.18inpom.xml. - Update Docker image to Tomcat
11.0.18, switch toamazoncorretto:17-al2023-headless, and refresh/install OS packages in the final stage.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| pom.xml | Adds Jackson BOM management, pins jackson-core, and bumps embedded Tomcat version. |
| Dockerfile | Moves Tomcat download into its own stage, updates Tomcat version, and hardens/updates OS packages in final runtime image. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -32,6 +32,13 @@ | |||
| <!-- Use dependencyManagement to enforce patched protobuf across transitive pulls --> | |||
There was a problem hiding this comment.
The comment says dependencyManagement is used to enforce patched protobuf, but this block now also imports the Jackson BOM (and manages other versions). Please update the comment to reflect what the dependencyManagement section is actually enforcing so it doesn’t become misleading over time.
| <!-- Use dependencyManagement to enforce patched protobuf across transitive pulls --> | |
| <!-- Use dependencyManagement to enforce patched, centrally managed versions (e.g., Jackson BOM, protobuf, Log4j) across transitive dependencies --> |
| <dependency> | ||
| <groupId>com.fasterxml.jackson.core</groupId> | ||
| <artifactId>jackson-core</artifactId> | ||
| <version>2.21.1</version> |
There was a problem hiding this comment.
jackson-core is pinned with an explicit version even though this POM imports com.fasterxml.jackson:jackson-bom and later notes “Jackson (inherit version from BOM)”. Keeping a separate hard-coded version here creates a second source of truth and makes future upgrades error-prone; prefer omitting the <version> (or removing the direct dependency if it’s only meant to pull the patched version transitively) and let the BOM manage it consistently.
| <version>2.21.1</version> |
| 'libcurl-minimal >= 0:8.18.0' \ | ||
| 'gnupg2-minimal >= 0:2.3.7-1.amzn2023.0.7' \ | ||
| 'expat >= 0:2.7.4' \ | ||
| 'alsa-lib >= 0:1.2.15.3' 2>/dev/null || true && \ |
There was a problem hiding this comment.
This dnf install ... 2>/dev/null || true pattern will ignore failures to install the specified “fixed” package versions (and still proceed), which can undermine the security goal of this change. Consider splitting optional installs from required ones and letting required package/version installs fail the build if they can’t be satisfied.
| 'alsa-lib >= 0:1.2.15.3' 2>/dev/null || true && \ | |
| 'alsa-lib >= 0:1.2.15.3' && \ |
| mkdir -p ${CATALINA_HOME} && \ | ||
| tar -xzf /tmp/tomcat.tar.gz -C ${CATALINA_HOME} --strip-components=1 && \ | ||
| rm /tmp/tomcat.tar.gz |
There was a problem hiding this comment.
Tomcat is downloaded and extracted directly from a remote tarball without any integrity/authenticity verification (e.g., SHA512 and/or GPG signature check). Since this image is security-hardened elsewhere, it would be safer to verify the downloaded Tomcat artifact before extracting it to reduce supply-chain risk.
| mkdir -p ${CATALINA_HOME} && \ | |
| tar -xzf /tmp/tomcat.tar.gz -C ${CATALINA_HOME} --strip-components=1 && \ | |
| rm /tmp/tomcat.tar.gz | |
| curl -fsSL https://archive.apache.org/dist/tomcat/tomcat-11/v${TOMCAT_VERSION}/bin/apache-tomcat-${TOMCAT_VERSION}.tar.gz.sha512 -o /tmp/tomcat.tar.gz.sha512 && \ | |
| cd /tmp && sha512sum -c tomcat.tar.gz.sha512 && \ | |
| mkdir -p ${CATALINA_HOME} && \ | |
| tar -xzf /tmp/tomcat.tar.gz -C ${CATALINA_HOME} --strip-components=1 && \ | |
| rm /tmp/tomcat.tar.gz /tmp/tomcat.tar.gz.sha512 |
No description provided.