Security risks of severity 'High' in container

[jmaster1985]

There are two security risks of severity 'High' originated from the base image alpine:3.21.3 (please see the screenshot) - these has to be fixed:

[kthoms]

The latest alpine version is 3.22.0. Would this be fixed by upgrading the base image?

Is there are way to get automatic update PRs like from dependabot to keep up-to-date?

[jmaster1985]

I would take a look whether the version 3.22.0 would fix those issues. Also I'll check if we have an automatic option like Dependabot or something else there.

[jmaster1985]

Observation

The default image tag in the Helm chart currently points to a fixed version: 1.0.0-beta-4 and Artifacthub uses this version stated in values.yaml to scan the container.
Our Docker build process is also configured not to push this tag again if it already exists in the registry, ensuring immutability of versioned releases.

However, while our image remains the same, the base image we use (alpine:3.21.3) is not immutable. Alpine (like many other images) routinely updates the contents of patch-level tags to include the latest internal package upgrades and security patches, without changing the tag.

For example, I rebuilt a container today based on alpine:3.21.3 and found no security issues, while scanning the same image built two months ago (with the same tag) revealed existing CVEs (please find the scan results in the screenshots below). This shows how underlying security posture can change even for fixed-version builds.

Discussion Points

1. Immutability vs. Security

• Do we want to guarantee that fixed-version tags like 1.0.0-beta-4 are never rebuilt, even if the container image contain known vulnerabilities at build time?
• Or should we allow (or automate) regular rebuilding of versioned images to include updated base layers, making container images more secure, but technically mutable? (here of course the mutability is at the infrastructure level, not the software code itself)

2. Alternative Approach - Rebuild Only latest Regularly

• Since latest is inherently a floating tag, should we rebuild it daily to include updated base layers and patched dependencies?
• This lets us preserve immutability for versioned releases while still offering a regularly updated and secure latest image.

3. Helm and Kubernetes Behavior with latest

• If we configure the Helm chart to use image.tag: latest, Kubernetes will not automatically pull the new image if the tag hasn't changed, unless:
  • The imagePullPolicy is explicitly set to Always, which adds a download overhead everytime a new pod has to be created (not that ideal)

We need to decide whether we prioritize immutability or security for fixed-version images. One compromise could be rebuilding only the latest tag daily, with the Helm chart optionally pointing to it (if imagePullPolicy: Always is enforced).

Any thoughts and ideas would be helpful 🙏

Screenshots:

[jmaster1985]

Follow up to my previous comment, PR #21 adds Dependabot, fixes some missing configurations for Wildfly as well as a new workflow for pull-requests (since Dependabot would change the base image version, it might make sense to test the containers before merging its changes).

I would highly appreciate a review 🙏

[kthoms]

I think images should be immutable. Version 1.0.0-beta-4, for example, should be a fixed version. It may have security flaws over time, and this should be covered by new builds and new releases. We can expect more frequent, and also patch, releases later.
We can't support maintenance of older images with security patches on the free tier. If patches on already released docker versions are required we should only do this when we have the necessary sources to support that.
Also likely is that besides the base image other dependencies become outdated, e.g. Spring or Wildfly, which need their own patches. But in that case we would just release a new Operaton version with that.

[jmaster1985]

as discussed today, we'll keep the containers immutable and security issues would be addressed automatically as we release new versions. the two security issues in the current container would also be fixed automatically with the coming version 1.0.0-beta-5.

therefore I close this ticket - for awareness @kthoms