What people ask about
The problems people hit with container images, security and the software supply chain
We read what practitioners report in forums, issue trackers and write-ups, and built OCImend around the problems that come up most. Here is each one, in plain words, what OCImend does about it, and where it does not do something yet. Sources are linked so you can judge for yourself.
- Two scanners, two different answers
- "Critical, no fix available"
- Tags move; the image you tested is not the image you run
- A stolen publisher token overwrites trusted tags
- The free image you depended on is gone or frozen
- "Who builds this, and can I get out again?"
- Secrets in layers, root by default, latest everywhere
- ARM (arm64, Graviton, Apple silicon) images
- "Our nodes are immutable, so we are covered"
- Cluster add-ons that quietly go end of life
Two scanners, two different answers
What people run into. The same image gets different vulnerability counts from different scanners (different databases and matching rules), so nobody knows which number to believe or whether a fix really worked.
From: Comparative analysis of Grype and Trivy, Trivy vs Grype, 2026
What OCImend does. Every published image is scanned before and after by independent scanners (Trivy and Grype, plus govulncheck for rebuilt Go programs). OCImend records how many of the CVEs it removed each scanner confirms, by CVE id, and shows both numbers rather than picking one.
"Critical, no fix available"
What people run into. A scan shows hundreds of findings, many with no upgrade, and no one says what to do next. Teams filter them out and lose track.
From: Debian security team: triage, Container image vulnerability management 2026
What OCImend does. Findings are sorted into fix now, waiting on the distribution, not loaded by the app, and accepted. When no package fix exists, OCImend measures a better base or a newer release and offers it, and watches the image: when a fix ships it rebuilds and alerts you.
Tags move; the image you tested is not the image you run
What people run into. A tag such as 1.27 or latest can be re-pointed at any time, so the same Dockerfile builds different images on different days, and "what exactly was running?" has no answer. Update bots bump tags but often add no digest.
From: Container image digests vs tags, Silent rebuilds, tested with Dependabot and Renovate
What OCImend does. Every OCImend image has a digest, shown with a ready-to-use pull-by-digest command. Provenance records the source image's digest and the exact change, and the Dockerfile OCImend gives you pins the base by digest. Pin the digest, let Renovate or Dependabot propose the next one.
A stolen publisher token overwrites trusted tags
What people run into. In 2026 attackers used stolen credentials to push malicious images over existing tags of widely used security tools. Anyone pulling the tag got the attacker's image; nothing in the tag said so.
From: Trivy ecosystem compromise (Aqua advisory), Docker: the shape of supply-chain attacks in 2026
What OCImend does. OCImend images are signed by digest and carry provenance, an SBOM and a signed remediation record, all in the public transparency log, so a swapped image fails verification with standard tools and without trusting OCImend. The scanners and signing tools OCImend itself uses are pinned by checksum.
The free image you depended on is gone or frozen
What people run into. When a popular free image catalog was moved to a frozen "legacy" namespace in 2025, teams found tags missing, no more updates, and only latest left for free, with no safe way to keep pinning.
From: Bitnami deprecation: what happened, Renovate discussion: replacement rules
What OCImend does. OCImend scans any image from any registry, including frozen ones, and tells you how old and exposed it is. It rebuilds only releases that are still current (a frozen old tag is offered its current release first), and published fixed images are pulled from ocimend.io, pinned by digest. A frozen image that is end-of-life will say so: the real fix there is moving to a maintained release.
"Who builds this, and can I get out again?"
What people run into. Hardened-image vendors often ship their own Linux variant and tooling, which means new expertise, debugging without a shell, and lock-in. Teams hesitate to hand their base to someone they cannot inspect.
From: Why hardened images are suddenly everywhere (RedMonk), Hardened images: security without lock-in (Docker)
What OCImend does. OCImend fixes the image you already use, on the distribution you already use, and keeps its shell and tools unless you choose the hardened option. You get a Dockerfile with only the final changes, so you can reproduce the result without OCImend, and every claim is checkable with open tools. Who runs it: the company page.
Secrets in layers, root by default, latest everywhere
What people run into. The most repeated mistakes are still secrets baked into image layers (deleting the file later does not remove it from the earlier layer), containers that run as root, and unpinned latest tags.
From: Docker security: the mistakes everyone makes, Secrets in containers: what to never do
What OCImend does. Every scan looks through the layer history for secrets, flags images that run as root, and grades image hygiene. The hardened build can run non-root. Reports show which layer introduced each issue.
ARM (arm64, Graviton, Apple silicon) images
What people run into. Teams moving to ARM hit images that only ship amd64 ("no match for platform in manifest"), multi-arch builds that put the wrong binary in the arm64 entry, and no clarity on whether an arm64 image has the same CVEs.
From: Multi-arch image ships the amd64 binary (issue), Multi-arch container images
What OCImend does. OCImend lists the platforms an image offers and scans the one you choose (linux/arm64 included), so you can compare architectures. Not yet: fixed and FIPS rebuilds are verified on linux/amd64; FIPS images are amd64 only for now, and arm64 rebuilds are not offered until they can be verified the same way.
"Our nodes are immutable, so we are covered"
What people run into. Immutable node operating systems (Talos, Bottlerocket, Flatcar) shrink the host, but the images that run on them are unchanged: the same packages, the same CVEs, and a FIPS node does not make an app image FIPS.
From: Talos vs Bottlerocket vs Flatcar, FIPS 140-3 builds for Talos
What OCImend does. OCImend works on the workload image, which the node OS does not protect. Its FIPS images enforce FIPS mode in the image itself, so they do not need a FIPS host kernel. It does not scan or harden the node OS.
Cluster add-ons that quietly go end of life
What people run into. Add-ons such as ingress controllers, CoreDNS and CNI plugins are easy to miss in upgrades, and an image from a legacy registry or private mirror can hide that a project is retired (ingress-nginx stopped getting fixes in March 2026).
From: Kubernetes: ingress-nginx retirement, Add-ons missed in common installs
What OCImend does. Scan the add-on images you run, whatever registry or mirror they come from, to see their CVEs and end-of-life base. Release and support dates for the projects themselves are followed by Cloudlore, OCImend's sibling product.
What exactly OCImend does and does not cover: coverage. Missing a problem you have? Scan your image and tell us what you expected; we keep this page current from what people report.