Melden Sie es, die Behebung ist öffentlich.
Bugs gehören in den öffentlichen Tracker. Schwachstellen laufen zuerst über einen vertraulichen Kanal und werden zu öffentlichen Advisories, sobald ein Release die Korrektur enthält. Beide Wege stehen unten; keiner hängt von Ihrer Edition ab.
Einen Bug melden
Der Issue-Tracker ist öffentlich und für alle Editionen derselbe: github.com/attestkeep/attestkeep-docs. Meldungen aus der Community Edition sind nicht zweitklassig – die meisten ersten Meldungen kommen aus der kostenlosen Edition, und sie im Verborgenen zu bearbeiten, wäre Verschwendung.
Am schnellsten behoben wird meist eine Meldung mit:
- der Operator-Version (
kubectl -n attestkeep get deploy attestkeep -o jsonpath='{.spec.template.spec.containers[0].image}'), - der Kubernetes-Distribution und -Version,
- dem, was Sie erwartet haben, was passiert ist, und dem zugehörigen Controller-Log,
- der Angabe, ob Admission, Scan, Konsole oder Nachweispaket betroffen sind.
Bitte hängen Sie an ein öffentliches Issue kein Nachweispaket, keinen vollständigen Scan-Export und kein Cluster-Manifest an. Sie enthalten Ihre Image-Namen und den Aufbau Ihres Clusters, und der Tracker ist öffentlich. Ein geschwärzter Auszug genügt; brauchen wir mehr, fragen wir vertraulich danach.
Eine Schwachstelle melden
Nicht in einem öffentlichen Issue. Nutzen Sie das private Advisory-Formular von GitHub im selben Repository (Security → Report a vulnerability) oder schreiben Sie an security@attestkeep.com. Wünschen Sie Verschlüsselung, sagen Sie das in einer ersten Mail; Sie erhalten dann einen Schlüssel für die Antwort.
Geben Sie genug zum Nachvollziehen an und nennen Sie uns:
- die betroffene Komponente und Version,
- die vermutete Auswirkung und den Zugang, den man dafür braucht,
- ob es bereits irgendwo öffentlich ist,
- wie Sie im Advisory genannt werden möchten oder ob Sie lieber ungenannt bleiben.
Ein bezahltes Bug-Bounty-Programm betreiben wir nicht. Zusagen können wir: eine klare Antwort, eine ehrliche Aussage dazu, ob und wann das Problem behoben wird, und nach der Behebung ein Advisory im Repository mit den betroffenen Versionen – mit Nennung Ihres Namens, sofern Sie nichts anderes wünschen. Gegen Sicherheitsforschung, die in gutem Glauben an Ihrer eigenen Installation stattfindet, gehen wir nicht rechtlich vor.
Was nach Ihrer Meldung passiert
Jede Meldung bestätigt ein Mensch, kein Bot, und wir teilen Ihnen mit, welches von drei Ergebnissen sie hatte: bestätigt, nicht reproduziert oder außerhalb des Umfangs. Ist sie bestätigt, erfahren Sie, was wir vorhaben und ungefähr bis wann; verschiebt sich diese Schätzung, hören Sie es von uns, ohne nachfragen zu müssen. Mit dem Release der Korrektur erscheint im Repository ein Advisory mit den betroffenen Versionen und Ihrer Nennung, sofern Sie diese nicht ablehnen.
Den Eingang einer Meldung bestätigen wir innerhalb von drei Werktagen. Darüber hinaus veröffentlichen wir keine Fristen nach Schweregrad: Eine großzügig bemessene Zahl sagt nichts aus, eine knappe wird zum Versprechen, das in einer schlechten Woche gebrochen wird. Was wir zusagen: Wir antworten, antworten weiter und lassen kein bestätigtes Problem ohne klare Position.
Das gilt für jede Edition, auch für Community – eine Meldung wird nach ihrem Inhalt eingestuft, nicht danach, was der Meldende zahlt. Legt ein Enterprise-Vertrag Support-Bedingungen fest, ist das eine eigene Angelegenheit zwischen uns und diesem Kunden und ändert nichts an dem hier beschriebenen Vorgehen.
Release-Integrität
Jedes Release-Image wird für linux/amd64 und linux/arm64 gebaut und mit cosign signiert, sodass Sie prüfen können, was Sie ausführen wollen, bevor es läuft:
- Signaturen lassen sich mit dem unter docs.attestkeep.com/cosign.pub veröffentlichten Public Key prüfen,
- Scanner und Signaturprüfer sind fest im Image enthalten und werden nicht erst im Betrieb nachgeladen,
- die Schwachstellendatenbank wird in Ihre eigene Registry gespiegelt, nicht von unserer geholt.
Der Operator selbst prüft Signaturen und Attestations der Images, die Ihr Cluster ausführt – dieselbe Technik, nur auf Ihre Umgebung gerichtet statt auf unsere.
Anlaufstelle
Die Verordnung (EU) 2024/2847 verlangt von Herstellern eine zentrale Anlaufstelle für Schwachstellenmeldungen und die Angabe, wo ihre Offenlegungsrichtlinie zu finden ist. Diese Seite ist diese Richtlinie, die Anlaufstelle ist security@attestkeep.com.
Dieselben Angaben stehen auf jedem Nachweispaket, das das Produkt erzeugt, neben der Identifikation Ihrer eigenen Organisation – das Dokument, das ein Auditor liest, enthält also beides.
Stand: 22. August 2026