Pin each broker image to a specific version, scan it in the pipeline before it deploys and again on a schedule, keep secrets such as the RabbitMQ Erlang cookie out of image layers, and rebuild or upgrade when an advisory names your version. Treat broker images like application code.
Why broker images get skipped
Teams scan the images they build and trust the ones they pull. A Redis, Kafka or RabbitMQ image arrives from a public registry, works, and then runs for years on a floating tag. Meanwhile advisories keep appearing. Redis's CVE-2025-49844 notice lists fixed releases for each product line, and a container started from an older image remains in the affected range until someone rebuilds it. An image has two sets of risk: the broker itself, and the operating system packages and libraries bundled with it.
A routine
- Inventory. List every broker image in use across clusters, Compose files, CI service definitions and Helm charts. Include tags.
- Pin. Replace floating tags with specific versions. For stronger pinning use the image digest. A tag can move, a digest cannot.
- Scan before deploy. Run an image scan in the pipeline. It should report operating system packages and application libraries inside the image, and fail the build on findings you have decided are unacceptable.
- Scan on a schedule. A passing image today can have a known issue next week, with no change to the image. Re-scan what is running, not only what you are building.
- Check the broker version against advisories. Match the exact version to the fixed releases in vendor notices.
- Rebuild or upgrade. Pull the fixed version, test in staging with real client behaviour and roll out.
- Record what you did and when. That record is evidence for audits and answers to customers.
What a scan will not tell you
A scan reports known vulnerabilities in packages. It does not check your broker configuration. An up to date Redis image with no password and a public port is still exposed. The Kafka listener protocols, the RabbitMQ guest account and the Redis bind address all live in configuration, not in the image. Pair scanning with configuration review, as in How do you stop a risky broker config change in a pull request?.
Keep secrets out of layers
The RabbitMQ clustering documentation says the community Docker image uses the RABBITMQ_ERLANG_COOKIE environment variable to fill the cookie file. If you bake that value into a Dockerfile or a derived image, anyone who can pull the image can read it. Inject secrets at runtime from your secret store, and check derived images for secrets before they are pushed. See What is the RabbitMQ Erlang cookie.
Decide your policy in advance
Write down the thresholds before an advisory forces a decision. For example: a fix is available and the broker is reachable from untrusted networks, patch within a short, fixed window; internal only with credentials and TLS, patch on the normal cycle. Your own numbers will differ. What matters is that the rule exists and the exceptions have owners and expiry dates.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings split between operating system packages and application libraries, and think about which broker images you would run through it first.
Safeguard scans dependencies and builds SBOMs, and its asset discovery helps find images and services that were missing from your list. The free scan is a quick way to try it.
Quick check
Is the latest tag a safe way to stay current?
It moves without notice, so you can get an untested version or a breaking change. Pin versions or digests and update on purpose.
Does a clean image scan mean the broker is secure?
No. It covers known package vulnerabilities. Configuration, network exposure and credentials need separate checks.
Sources
Last reviewed: 19 October 2026.
