A Rocky Linux container scan is accurate only when your scanner matches package versions against Rocky Linux's own errata feed (RLSA advisories) rather than borrowing Red Hat or CentOS data. Rocky is a downstream rebuild of RHEL, so its package versions and backported patches track RHEL closely but not identically — and a scanner using the wrong advisory source will report vulnerabilities that were already patched or miss ones that were not.
This distinction matters more on RHEL-family distributions than almost anywhere else, because of how enterprise Linux handles security fixes.
Why RHEL-family scanning is different: backporting
Red Hat and its rebuilds like Rocky do not usually jump to a new upstream version to fix a CVE. Instead they backport the security patch into the existing version and bump the release string. So a package might read openssl-3.0.7-27.el9 and still be fully patched against a recent CVE, even though upstream OpenSQL moved to a higher version number.
A naive scanner that compares your 3.0.7 against an upstream "fixed in 3.0.14" claim will scream about a vulnerability that Rocky already patched in the -27.el9 release build. This is the single biggest source of false positives in a Rocky Linux container scan, and it is why the advisory source is not an implementation detail.
Point your scanner at Rocky's advisory data
Modern scanners ship with Rocky support, but confirm it is actually being used. Trivy and Grype both consume distribution-specific vulnerability data:
# Trivy reads the OS release from /etc/os-release inside the image
trivy image rockylinux:9
# Verify it detected the right distro
trivy image --format json rockylinux:9 | \
grep -i '"Family"'
If the scan output shows the OS family as redhat when you expect rocky, your results are being matched against the wrong errata and you should treat them with suspicion. The fix is usually updating the scanner's vulnerability database or the scanner version itself.
For Grype:
grype rockylinux:9-minimal -o table
Both tools resolve the distribution from /etc/os-release, so a stripped or customized base image that lost that file will silently degrade detection. Keep os-release intact in derived images.
Scan the layers you actually control
A container scan reports on everything in the image, but your remediation power is uneven:
- OS packages (dnf/yum-installed): patch by rebuilding on an updated base image or running
dnf updatein the build. This is where Rocky-specific advisory matching applies. - Application dependencies (pip, npm, Maven, Go modules): patch by bumping the dependency, independent of the OS.
- The base image itself: often the fastest win is switching to a smaller Rocky variant like
rockylinux:9-minimalor a UBI-style minimal base, which removes packages you never used and shrinks the CVE count outright.
Separating these buckets in triage stops the common failure mode where the team stares at 200 findings and does nothing. Most of that count is usually one outdated base image.
Rebuild, do not hand-patch
The correct remediation for OS-level findings in a Rocky container is to rebuild on a fresh base, not to dnf update a running container. Containers are meant to be immutable; a patched running container disappears on the next deploy. Bake the update into the image:
FROM rockylinux:9
# Apply the latest security errata at build time
RUN dnf -y update --security && \
dnf clean all && \
rm -rf /var/cache/dnf
--security limits the update to packages with a security advisory, which keeps the change set small and reviewable rather than pulling in every available update.
Wire the scan into the pipeline as a gate
A scan that runs manually runs never. Put it in CI and fail the build on a severity threshold:
# Fail the pipeline on fixable HIGH or CRITICAL findings
trivy image --exit-code 1 --severity HIGH,CRITICAL \
--ignore-unfixed myorg/app-rocky:${GIT_SHA}
The --ignore-unfixed flag is worth calling out. It suppresses findings that have no available fix yet, so your gate only blocks on things the team can actually act on. Without it, an unpatchable low-level library CVE can wedge every deploy and train people to bypass the gate entirely. Continuous container scanning as part of a broader software supply chain view — the kind an SCA platform such as Safeguard provides — keeps these results deduplicated across images instead of re-reporting the same base-layer CVE in every service.
FAQ
Why does my Rocky Linux container scan show CVEs that are already patched?
Almost always an advisory-source mismatch. Rocky backports security fixes and bumps the release string rather than the upstream version, so a scanner using upstream "fixed in" data reports false positives. Make sure your scanner detects the OS family as Rocky and uses its RLSA errata.
Which scanner is best for Rocky Linux containers?
Trivy and Grype both support Rocky's distribution data and are free. The important thing is confirming the scanner correctly identifies the distro from /etc/os-release and uses Rocky errata, not generic Red Hat data.
Should I patch a running Rocky container or rebuild it?
Rebuild. Containers should be immutable, so bake dnf -y update --security into the Dockerfile and redeploy. Patching a live container is lost on the next deploy.
How do I stop unfixable CVEs from blocking my pipeline?
Use --ignore-unfixed so the gate only blocks on findings that have an available patch. This keeps developers from routinely bypassing a gate that flags issues they cannot resolve.