Report it, and watch it get fixed in the open.

Reporting a bug

The issue tracker is public and it is the same one for every edition: github.com/portiger/kapan-k8s. Community Edition reports are not second class — the free tier is where most first reports come from, and handling them privately would waste that.

A report that gets fixed fastest usually carries:

• the operator version (kubectl -n portiger-kapan get deploy kapan -o jsonpath='{.spec.template.spec.containers[0].image}'),
• the Kubernetes distribution and version,
• what you expected, what happened, and the controller log around it,
• whether admission, scanning, the console or the evidence package is involved.

Please do not attach an evidence package, a full scan export or a cluster manifest to a public issue. They carry your image names and your cluster's shape, and the tracker is public. A redacted excerpt is enough; if more is needed, we will ask for it privately.

Reporting a vulnerability

Not in a public issue. Use GitHub's private advisory form on the same repository (Security → Report a vulnerability), or write to security@portiger.com. If you want the message encrypted, say so in a first mail and you will get a key to reply to.

Please include enough for us to reproduce it, and tell us:

• the affected component and version,
• the impact you believe it has, and the access needed to reach it,
• whether it is already public anywhere,
• how you would like to be credited in the advisory, or that you would rather not be.

We do not run a paid bounty. What we do commit to is a straight answer, an honest position on whether and when it will be fixed, and an advisory on the repository naming the versions affected once it is — with credit to you unless you ask otherwise. We will not take legal action over research conducted in good faith against your own installation.

What happens after you report

A report is acknowledged by a person, not a bot, and we will tell you which of three things it turned out to be: confirmed, not reproduced, or out of scope. If it is confirmed you get told what we intend to do and roughly when; if that estimate moves, you hear about it from us rather than by asking. When the fix ships, an advisory goes up on the repository naming the affected versions, with credit to you unless you would rather not have it.

We do not publish a table of deadlines. Two people with a product to run cannot honestly promise the same clock to every reporter in advance, and a published number would either be padded until it meant nothing or be a commitment we cannot keep in a bad week. What we will do is answer, keep answering, and never leave a confirmed issue without a stated position.

This applies to every edition including Community — a report is triaged on what it is, not on what the reporter pays. Where an Enterprise agreement sets out support terms, those are a separate matter between us and that customer and do not change how anything here is handled.

Release integrity

Every release image is built for linux/amd64 and linux/arm64 and signed with cosign, so you can verify what you are about to run before it runs:

• signatures are verifiable with the public key published on the repository,
• the scanner and the signature verifier are pinned into the image rather than pulled at runtime,
• the vulnerability database is mirrored into your own registry rather than fetched from ours.

The operator itself verifies signatures and attestations on the images your cluster runs — the same machinery, pointed at your estate rather than at ours.

Point of contact

Regulation (EU) 2024/2847 asks a manufacturer to name a single point of contact for vulnerability reports, and to say where its disclosure policy lives. This page is that policy, and the contact is security@portiger.com.

The same details are printed on every evidence package the product generates, next to your own organisation's identification — so the document an auditor reads carries both.

Last updated: 22 August 2026