Política de seguridad

La seguridad es una prioridad. Si descubres una vulnerabilidad en KubeBolt o en cualquiera de nuestros servicios, queremos saberlo. Esta página describe cómo reportarla de forma responsable, qué puedes esperar de nosotros y qué hacemos por nuestro lado.

1. Cómo reportar

Envía los detalles a hello@kubebolt.io con el asunto [security]. Incluye:

• Una descripción del problema y su impacto potencial.
• Pasos para reproducirlo (URLs, payloads, condiciones).
• Versión afectada, si aplica al producto open source o al agente.
• Tu nombre o alias, opcional, si quieres atribución pública tras la corrección.

Te pediremos que no divulgues públicamente el problema hasta que hayamos tenido tiempo razonable para corregirlo.

2. Plazos de respuesta

Nuestro compromiso:

• Acuse de recibo: dentro de 72 horas.
• Clasificación inicial y validación: dentro de 7 días.
• Plazo para parchear: proporcional a la severidad. Crítico ≤ 14 días, alto ≤ 30 días, medio ≤ 90 días.
• Divulgación coordinada: acordamos contigo una fecha de publicación tras el parche, hasta 90 días desde el reporte.

3. Alcance

Está dentro del alcance:

• kubebolt.io (este sitio) y todos sus subdominios.
• app.kubebolt.io, la aplicación de KubeBolt Cloud.
• agent.kubebolt.io, el punto de entrada por el que el agente se conecta desde tu clúster.
• Las APIs públicas del sitio: el alta en la lista de novedades, el formulario de feedback y su subida de adjuntos, y el asistente Kobi.
• El repositorio open source github.com/clm-cloud-solutions/kubebolt y los artefactos oficiales (Helm, Docker, GHCR, Homebrew, krew).

Sobre los clústeres de clientes: están fuera del alcance de las pruebas. No los ataques, ni siquiera para demostrar un hallazgo. Si crees haber encontrado una vía para alcanzar el clúster de otra organización, párate ahí y descríbenosla: la reproducimos nosotros en un entorno propio.

4. Fuera de alcance

No consideramos vulnerabilidades:

• Ataques de denegación de servicio o que requieran un volumen anormal de tráfico.
• Problemas de configuración del cliente fuera de nuestro control (DNS, proveedor de internet, navegador).
• Configuraciones SPF o DMARC laxas en dominios desde los que no enviamos correo.
• Cabeceras que revelan la versión en respuestas HTTP.
• Reportes obtenidos exclusivamente por escaneos automáticos, sin demostrar impacto.
• Vulnerabilidades en dependencias de terceros que ya tienen CVE público y corrección pendiente en el proyecto original.
• Ingeniería social, phishing al equipo o intrusión física.

5. Reglas para investigar

Cuando investigues vulnerabilidades, por favor:

• No accedas a datos de otros usuarios. Si encuentras una forma, demuéstralo con tus propios datos de prueba y avísanos de inmediato.
• No degrades ni interrumpas el servicio. Sin pruebas de carga, sin borrados masivos, sin saturar los límites de peticiones.
• No extraigas ni divulgues datos privados a los que hayas accedido accidentalmente; bórralos y notifícanos.
• Cumple la legislación aplicable.

Si actúas de buena fe siguiendo estas reglas, no emprenderemos acciones legales contra ti por el reporte ni colaboraremos con autoridades para perseguirte (safe harbor).

6. Qué versiones parcheamos

Conviene decirlo con claridad, porque cambia lo que puedes esperar según cómo ejecutes KubeBolt:

• KubeBolt Cloud: lo parcheamos nosotros. No tienes que hacer nada, y no hay versiones antiguas expuestas.
• Open source y self-hosted: las correcciones de seguridad salen en la última versión publicada de la línea vigente. Hoy no hacemos backports a líneas anteriores: si corres una versión antigua, la vía de corrección es actualizar. Lo decimos porque una política de divulgación que no aclara qué se parchea está incompleta.
• El agente sigue su propia línea de versiones y la misma regla.

7. Qué hacemos por nuestro lado

La divulgación responsable es la mitad del trato. Esta es la nuestra, y todo se puede verificar en el repositorio público:

• Imágenes y charts firmados con cosign en cada publicación, para que puedas verificar la procedencia de lo que despliegas.
• SBOM en formato CycloneDX por imagen, adjunto a cada versión publicada.
• Escaneo de imágenes con Trivy en cada pull request, antes de que nada se etiquete.
• Análisis estático con CodeQL sobre el código del producto.

8. Si la brecha es nuestra

Si somos nosotros quienes sufrimos un incidente de seguridad que afecte a tus datos, te lo comunicaremos sin dilación indebida y, en todo caso, dentro de las 72 horas siguientes a que tengamos constancia, con lo que sepamos en ese momento: qué ha pasado, qué datos están implicados, qué estamos haciendo y qué te recomendamos hacer a ti. Si al principio no lo sabemos todo, te lo diremos por fases en lugar de esperar a tener el cuadro completo. Como encargados del tratamiento, notificamos al responsable en el plazo que exige el RGPD.

9. Reconocimiento

Tras corregir el problema, podemos reconocerte públicamente en las notas de la versión, si tú quieres. De momento no ofrecemos un programa de recompensas económicas; lo evaluaremos cuando crezca la base de usuarios.

10. Cifrado del reporte

Si prefieres cifrar tu reporte con PGP, escríbenos primero solicitando nuestra clave pública actual. Estamos trabajando en publicar una clave estable en una próxima iteración. Esta sección trata solo del correo con el que nos escribes: el cifrado dentro del producto, en tránsito y en reposo, está en la página de Confianza.

11. Contacto

hello@kubebolt.io · asunto [security]

Si lo que buscas no es reportar un fallo: la postura técnica del producto (qué sale de tu clúster, qué nunca sale, aislamiento y auditoría) está en Confianza; el tratamiento de datos personales, en la Política de privacidad; y los avisos publicados, en los advisories de GitHub.