Signalez un bug, suivez sa correction en public.

Signaler un bug

Le tracker d'issues est public, et c'est le même pour toutes les éditions : github.com/attestkeep/attestkeep-docs. Les signalements venant de la Community Edition ne passent pas au second plan : l'offre gratuite est à l'origine de la plupart des premiers signalements, et les traiter en privé serait un gâchis.

Le signalement corrigé le plus vite contient en général :

• la version de l'operator (kubectl -n attestkeep get deploy attestkeep -o jsonpath='{.spec.template.spec.containers[0].image}'),
• la distribution et la version de Kubernetes,
• ce que vous attendiez, ce qui s'est passé, et le log du controller à ce moment-là,
• si l'admission, le scan, la console ou le paquet de preuves est en cause.

Merci de ne pas joindre de paquet de preuves, d'export complet de scan ni de manifest de cluster à une issue publique. Ils contiennent vos noms d'image et la forme de votre cluster, et le tracker est public. Un extrait expurgé suffit ; s'il en faut plus, nous le demanderons en privé.

Signaler une vulnérabilité

Pas dans une issue publique. Utilisez le formulaire d'advisory privé de GitHub sur le même dépôt (Security → Report a vulnerability) ou écrivez à security@attestkeep.com. Si vous souhaitez chiffrer le message, dites-le dans un premier e-mail : vous recevrez une clé à utiliser pour votre réponse.

Donnez-nous de quoi le reproduire, et précisez :

• le composant et la version concernés,
• l'impact que vous lui prêtez et l'accès nécessaire pour l'atteindre,
• s'il est déjà public quelque part,
• comment vous souhaitez être crédité dans l'advisory, ou que vous préférez ne pas l'être.

Nous n'avons pas de programme de bug bounty rémunéré. Nous nous engageons en revanche à vous répondre franchement, à prendre une position honnête sur la correction et son calendrier et, une fois le problème corrigé, à publier sur le dépôt un advisory qui indique les versions concernées, en vous créditant sauf demande contraire. Nous n'engagerons pas de poursuites pour une recherche menée de bonne foi sur votre propre installation.

Après votre signalement

Chaque signalement reçoit un accusé de réception écrit par une personne, pas par un bot, et nous vous indiquons ensuite ce qu'il s'est avéré être : confirmé, non reproduit ou hors périmètre. S'il est confirmé, nous vous disons ce que nous comptons faire et à peu près quand ; si cette estimation change, vous l'apprenez de nous sans avoir à demander. Quand le correctif sort, un advisory est publié sur le dépôt avec les versions concernées, et vous y êtes crédité sauf si vous préférez ne pas l'être.

Un signalement reçoit un accusé de réception sous trois jours ouvrés. Au-delà, nous ne publions pas de tableau de délais par gravité : un chiffre gonflé ne veut rien dire, et un chiffre serré devient une promesse rompue lors d'une mauvaise semaine. Ce que nous ferons : répondre, continuer à répondre, et ne jamais laisser un problème confirmé sans position déclarée.

Cela vaut pour toutes les éditions, Community comprise : un signalement est trié selon ce qu'il est, pas selon ce que paie son auteur. Lorsqu'un contrat Enterprise fixe des conditions de support, c'est une affaire distincte entre nous et ce client, qui ne change rien au traitement décrit sur cette page.

Intégrité de release

Chaque image de release est construite pour linux/amd64 et linux/arm64 et signée avec cosign, pour que vous puissiez vérifier ce que vous allez exécuter avant de l'exécuter :

• les signatures se vérifient avec la clé publique publiée sur docs.attestkeep.com/cosign.pub,
• le scanner et le vérificateur de signatures sont figés dans l'image plutôt que téléchargés en cours de fonctionnement,
• la base de vulnérabilités est répliquée dans votre propre registry plutôt que récupérée chez nous.

L'operator lui-même vérifie les signatures et les attestations des images que votre cluster exécute : la même mécanique, tournée vers votre parc plutôt que vers le nôtre.

Point de contact

Le règlement (UE) 2024/2847 demande à un fabricant de désigner un point de contact unique pour les signalements de vulnérabilités et d'indiquer où se trouve sa politique de divulgation. Cette page constitue cette politique, et le contact est security@attestkeep.com.

Les mêmes informations figurent sur chaque paquet de preuves généré par le produit, à côté de l'identification de votre propre organisation : le document que lit un auditeur porte donc les deux.

Mis à jour : 22 août 2026