Before running a vendor's container image, ask for its SBOM, patch and rebuild cadence, signing and provenance, the privileges it needs, how it handles vulnerabilities, and how long each version is supported. Then scan it yourself. A vendor's answer is a claim; your scan is evidence.
Questions that matter
| Area | Ask |
|---|---|
| Inventory | Do you publish an SBOM per image version, and in which format? |
| Patching | How often do you rebuild on a fixed base? What is your target time to ship a fix for critical issues? |
| Provenance | How is the image built, and can you provide signed build provenance? |
| Signing | Is each image signed, and how do we verify it? |
| Privileges | Does it need root, extra capabilities, host mounts or privileged mode? Why? |
| Network | Which outbound connections does it make, and to where? |
| Data | What data does it read or write, and where is it stored? |
| Vulnerabilities | How do you disclose issues and publish exploitability statements? |
| Support | How long is each version supported? What is the end-of-support policy? |
What a good answer looks like
Specific and checkable. "We rebuild weekly and publish a new digest" can be verified from the registry. "We take security seriously" cannot. An SBOM you can open beats a promise of one. If the vendor offers VEX statements, ask how they are kept current.
For signing, remember what a signature proves. It shows who published the image and that it has not changed since. It does not show the image is free of flaws. See what a container image signature proves.
Verify before you trust
- Pull by digest and record it.
- Generate your own inventory and compare it with the vendor's SBOM.
- Scan and read the findings, not just the count.
- Run it in a test namespace with restrictive settings and see what breaks. Anything that needs privileged mode deserves a conversation.
- Check its manifest for a non-root user.
Red flags
Be cautious when the vendor cannot say how often images are rebuilt, ships only a latest tag, requires privileged mode without a clear reason, bundles tools like compilers and shells in a runtime image, or cannot explain how it learns of new vulnerabilities in its own dependencies. None of these proves the image is unsafe, but each one means more work for you and a harder conversation at renewal.
Put the answers somewhere
Keep the responses with the vendor's record. When a critical CVE appears, you want to know which vendor images contain the package and who to call. Our post on evaluating container SBOM and scanning pairs well with this list.
Quick check
Is an official or verified publisher badge enough?
It tells you who published the image. It does not replace your own scan and privilege review.
What if the vendor will not share an SBOM?
You can still generate one by analyzing the image. Note the refusal as a risk factor in your vendor review.
Safeguard generates and scans SBOMs and tracks dependencies, so you can compare a vendor's claims with your own inventory; the free scan is a starting point.
Last reviewed: 19 October 2026.
