Generate a software bill of materials for every service, filter it for the packages that talk to Redis, Kafka, RabbitMQ and SQS, and record the broker server versions separately. Then when an advisory lands, you can answer which services use the affected component in minutes. The inventory is the control.
Why two inventories
An advisory can name a server, a client library, or both. The Redis CVE-2025-49844 advisory is about the server: it lists fixed releases for each Redis product line. Other advisories hit the client side, for example a deserialization issue in a library that reads messages. Because queue consumers parse data from a shared channel, client and server bugs both matter.
You need two lists:
| List | What it holds | Where it comes from |
|---|---|---|
| Client libraries | Packages in each application, with versions | Lockfiles and SBOMs per repository |
| Broker servers | Product, version, location, owner | Image tags, deployment manifests, cloud inventory |
Steps for the client list
- Collect lockfiles or generate an SBOM for each repository. Use the lockfile where there is one, because it records the resolved versions, including transitive ones.
- Search for packages that connect to brokers. Examples by ecosystem include redis and ioredis, pika and amqplib for RabbitMQ, kafkajs and confluent-kafka for Kafka, and the AWS SDK for SQS. Your own services will have others, so build the list from what you find.
- Look at wrappers too. Job frameworks such as Celery pull in a broker client as a dependency, and the framework has its own security guidance, as in Should Celery use pickle or JSON?.
- Record version, repository, owning team and where it runs.
- Re-run on every build, so the list does not rot.
Steps for the server list
- List every broker: the managed services, the containers and the machines. Include development and staging, since they often run older versions.
- Record the product, exact version and who can reach it. The version needs to match the format in advisories, such as the Redis release numbers.
- Note the configuration that matters: listener protocols, authentication, exposed ports.
- Assign an owner. An advisory with no owner waits.
Using it on advisory day
When a notice arrives, read it for the product, the affected range and the conditions. The Redis advisory is a good model: it names the issue, the fixed releases per product and the conditions for exploitation. Then query both lists. If the answer is "this service uses a library in the affected range," look at whether the vulnerable function is reachable in your code before you decide urgency, and remember that a client library bug usually matters only if your code calls the affected path.
Common gaps
- Indirect dependencies that carry a broker client without a direct entry in your manifest.
- Images with their own copy of a client or server, separate from the application lockfile.
- Local and CI stacks that start a broker with a floating tag.
- Services nobody owns that still consume from a queue.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a dependency inventory lists packages and versions, then imagine filtering it for your broker clients.
Safeguard produces SBOMs and runs dependency scanning, and its asset discovery helps find services and brokers that are missing from your records. The free scan is a quick way to see an inventory of one repository. For a related checklist, see Keep broker client libraries patched: a dependency inventory.
Quick check
Is a lockfile enough for the client inventory?
It covers resolved versions for that repository. Add images and runtime environments, since they can include other copies of libraries.
How often should I refresh the inventory?
On every build for clients, and on a schedule for servers, so changes are visible soon after they happen.
Sources
Last reviewed: 19 October 2026.
