What OCImend does, precisely

What OCImend fixes, what it only reports, and what it does not do yet

An image fix is only trustworthy if its limits are clear. This page lists them, then answers the questions teams ask before adopting a tool like this.

Coverage

Does the fix get back into Git?

A fixed image on its own drifts away from the source that builds it. OCImend gives you three ways to close that gap, from least to most intrusive:

• Patch as code. A Dockerfile with only the final commands, pinned to the original image by digest, that reproduces the verified fix in your own CI and registry under your own name. You can stop using OCImend and keep the result.
• Fix the source. The change applied to the project's own Dockerfile, shown as a diff you can apply yourself.
• Open the pull request. Paste a GitHub token, review the exact diff, and OCImend opens the pull request as you (from a fork if you cannot push to the repository). Nothing is ever pushed to your default branch.

What happens to your token. It travels over HTTPS, is used for that one request, and is never stored, logged or shown again; it is kept out of error messages, and a rejected request does not repeat it back. A token that is not shaped like a GitHub token is refused before anything is sent, and a classic token with far more access than needed (organisation, deletion, hooks) is refused too. Use a fine-grained token limited to the one repository, with Contents and Pull requests read and write, expiring in a day. Requests are rate-limited per visitor and per repository, and the reviewed diff is the only change that is sent.

Every OCImend image also carries its source and base digests as labels and in its signed provenance, so what is running can always be traced back to what it was built from.

Does the fixed image still run?

Every build is started side by side with the original and its start-up behaviour compared. A build that adds vulnerabilities, removes none, or does not start like the original is withheld with the reason, never published. Upgrades that change a package's major version are listed for review in the signed remediation record and on the verify page, because those are the ones that can change behaviour. What OCImend does not run is your staging or canary: promote by digest through your own pipeline, and gate it with the policy check below.

What happens to signatures and SBOMs?

A fixed image is a new image with a new digest, so the original publisher's signature cannot carry over (it signs the original bytes). OCImend signs the new digest and attaches the evidence as signed attestations: a CycloneDX SBOM of the new contents, OpenVEX, SLSA provenance that names the source digest, per-scanner scan results from independent scanners, and a remediation record of exactly what changed. All are recorded in the public transparency log and verifiable with standard tools at /verify.

Registry support, plainly: images are served from a standard OCI registry (docker pull ocimend.io/…). Every signature and attestation is published twice: in the classic cosign tag layout that Kyverno and the Sigstore policy controller read, and in cosign's bundle format as OCI 1.1 referrers, which oras discover, cosign 3 and other referrers-aware tools find. The registry software does not serve the native /referrers/ endpoint (neither current release does); clients use the specification's tag fallback, so this works today without a registry change.

Policy gates and automation

• Policy as code. One file decides whether an image may ship: security grade, actively exploited or likely-exploited vulnerabilities, counts by severity, fixable-only or in-use-only counting, FIPS verdict, secrets, root, age, and accepted risks with an expiry. Unknown keys are an error, so a typo cannot silently weaken the gate. Check any scan against it with POST /api/scans/{id}/policy.
• CI. A packaged GitHub Action scans the image you just built, applies your policy, uploads SARIF, writes the report to the job summary and links to the fix.
• Cluster. Kyverno and Sigstore policy-controller policies admit only signed OCImend images.
• Watching. Watched images are re-checked every day: alerts for new exploited vulnerabilities, rebuilds when the distribution ships fixes.
• The GitOps loop, without a new operator. Fixed images are ordinary tags in a standard registry (1.27-fixed, 3.12-slim-fips), so Renovate, Dependabot, Flux image automation and Argo CD Image Updater track them like any other image: pin by digest and let the tool open the pull request for the next build. There is a ready Renovate preset for the tag pattern, and GET /api/fixed?image=nginx:1.27 returns the replacement for any image, pinned by digest, with its verification link. OCImend deliberately has no controller that changes your cluster on its own: promotion goes through your review, your pipeline and your signature policy.
• Zero-day. /cve/CVE-YYYY-NNNN shows which public images contain a vulnerability and which fixed images already remove it.

Where it fits

These are different approaches to the same problem, not rivals in every case:

• Patch tools you run yourself (for example Copacetic) patch operating-system packages in an image from a scanner report, in your own pipeline. OCImend adds a hosted service with a public registry, verification of the result, Go program rebuilds, FIPS enforcement, and signed evidence. If you want everything in your own infrastructure, a self-run tool fits better.
• Minimal images built from source on their own distribution (for example Chainguard) give you a different base to move to. OCImend fixes the image you already use on the distribution you already use, so there is no migration; if you are happy to change your base, those images are a strong option.
• Analysis and recommendation (for example Docker Scout) tell you what to update; OCImend also produces the updated image.

Missing something you need? Tell us from the app. See also the problems people report most and the trust center.