Repórtelo y vea cómo se corrige en público.

Avisar de un error

El tracker de issues es público y es el mismo para todas las ediciones: github.com/attestkeep/attestkeep-docs. Los avisos de Community Edition no son de segunda: la mayoría de los primeros avisos vienen de la edición gratuita, y tratarlos en privado sería desaprovecharlos.

El aviso que antes se corrige suele incluir:

• la versión del operator (kubectl -n attestkeep get deploy attestkeep -o jsonpath='{.spec.template.spec.containers[0].image}'),
• la distribución y versión de Kubernetes,
• lo que esperaba, lo que ocurrió y el log del controller de ese momento,
• si afecta a la admission, al escaneo, a la consola o al paquete de evidencia.

Por favor, no adjunte a una issue pública un paquete de evidencia, una exportación completa de escaneo ni un manifest del cluster. Contienen sus nombres de image y la forma de su cluster, y el tracker es público. Basta con un extracto anonimizado; si hace falta más, se lo pediremos en privado.

Avisar de una vulnerabilidad

No en una issue pública. Use el formulario de advisory privado de GitHub en el mismo repositorio (Security → Report a vulnerability) o escriba a security@attestkeep.com. Si quiere que el mensaje vaya cifrado, indíquelo en un primer correo y recibirá una clave con la que responder.

Incluya lo suficiente para que podamos reproducirlo e indíquenos:

• el componente y la versión afectados,
• el impacto que cree que tiene y el acceso necesario para alcanzarlo,
• si ya es público en algún sitio,
• cómo quiere que se le reconozca en el advisory, o si prefiere que no se le mencione.

No tenemos un programa de recompensas de pago. A lo que sí nos comprometemos es a una respuesta clara, una postura honesta sobre si se corregirá y cuándo, y, una vez corregido, un advisory en el repositorio con las versiones afectadas y con su nombre, salvo que pida lo contrario. No emprenderemos acciones legales por investigaciones hechas de buena fe contra su propia instalación.

Qué pasa después del aviso

El acuse de recibo de cada aviso lo envía una persona, no un bot, y le diremos cuál de tres cosas resultó ser: confirmado, no reproducido o fuera de alcance. Si se confirma, le diremos qué pensamos hacer y aproximadamente cuándo; si esa estimación cambia, se lo diremos nosotros sin que tenga que preguntar. Cuando sale la corrección, publicamos en el repositorio un advisory con las versiones afectadas y con su nombre, salvo que prefiera no aparecer.

Cada aviso recibe acuse en un plazo de tres días hábiles. Más allá de eso no publicamos una tabla de plazos por gravedad: un número holgado no significa nada, y uno ajustado acaba siendo un compromiso incumplido en una mala semana. Lo que sí haremos es responder, seguir respondiendo y no dejar nunca un problema confirmado sin una postura declarada.

Esto vale para todas las ediciones, Community incluida: un aviso se valora por lo que es, no por lo que paga quien lo envía. Cuando un acuerdo Enterprise fija condiciones de soporte, eso es un asunto aparte entre nosotros y ese cliente, y no cambia cómo se trata nada de lo descrito aquí.

Integridad de release

Cada image de release se construye para linux/amd64 y linux/arm64 y se firma con cosign, para que pueda verificar lo que va a ejecutar antes de ejecutarlo:

• las firmas se verifican con la clave pública publicada en docs.attestkeep.com/cosign.pub,
• el escáner y el verificador de firmas van fijados dentro de la image, no se descargan durante la ejecución,
• la base de datos de vulnerabilidades se replica en su propio registry en lugar de descargarse del nuestro.

El propio operator verifica firmas y attestations de las images que ejecuta su cluster: el mismo mecanismo, aplicado a su entorno en lugar de al nuestro.

Punto de contacto

El Reglamento (UE) 2024/2847 pide al fabricante que designe un punto de contacto único al que avisar de vulnerabilidades y que indique dónde está publicada su política de divulgación. Esta página es esa política, y el contacto es security@attestkeep.com.

Los mismos datos figuran en cada paquete de evidencia que genera el producto, junto a la identificación de su propia organización, de modo que el documento que lee un auditor lleva ambos.

Actualizado: 22 de agosto de 2026