Soporte de seguridad para SDKs y herramientas

Esta página trata sobre el software que descarga y ejecuta por su cuenta: los SDKs, la CLI, el proveedor de Terraform/OpenTofu y el servidor MCP. Explica durante cuánto tiempo reciben correcciones de seguridad, cómo informar de una vulnerabilidad, dónde se publican los avisos de seguridad y qué se incluye con cada versión para que pueda verificar lo que instala. KeenAuth diseña estos procesos para cumplir los requisitos del Reglamento de Ciberresiliencia de la UE (CRA) para productos con elementos digitales.

Aún no se ha publicado ningún paquete en un registro público. Todo lo de esta página que está vinculado a una versión (SBOM, firmas, procedencia) empieza con la primera versión de cada paquete.

Periodo de soporte

La línea de productos en su conjunto recibe soporte de seguridad durante al menos 5 años, contados desde su disponibilidad general.
Las correcciones de seguridad se publican en la última versión mayor de cada paquete, y la actualización a ella es gratuita.
La versión mayor anterior recibe correcciones de seguridad durante 12 meses después de que la siguiente versión mayor esté disponible de forma general.
Cada actualización de seguridad publicada permanece disponible durante al menos 10 años, o durante el resto del periodo de soporte si este es más largo.

La política completa, incluidos los avisos de fin de vida útil y el soporte de entornos de ejecución, está en la página de política de versionado y obsolescencia.

Informar de una vulnerabilidad

Envíe un correo a security@keenauth.com. Este canal está siempre abierto y no depende de una campaña de programa de recompensas por errores.

Cifre los datos sensibles con nuestra clave OpenPGP, publicada en https://trust.keenauth.com/pgp-key.txt. Su huella digital es 0336 4D65 3B6C AA93 98A6 BE84 5C82 4CF9 48AB 83D6.
Nuestros datos de contacto también se publican en https://trust.keenauth.com/.well-known/security.txt (RFC 9116).
Incluya el nombre y la versión del paquete, una descripción y el impacto, la reproducción paso a paso y, si desea que se le mencione, su nombre o alias.
No informe de vulnerabilidades mediante tickets de soporte ni incidencias públicas.

Una configuración predeterminada insegura en un SDK está dentro del alcance. Los tiempos de respuesta, las normas de pruebas, el puerto seguro y la divulgación coordinada se detallan en nuestra política de divulgación de vulnerabilidades.

Avisos de seguridad

Cuando corregimos una vulnerabilidad, publicamos un aviso de seguridad en https://trust.keenauth.com/advisories. Cada aviso tiene un identificador con el formato ASA-YYYY-NNNN e indica:

una descripción, el impacto y la acción que debe realizar;
en el caso de un SDK o una herramienta, el nombre del paquete, el rango de versiones afectadas y la versión corregida;
un vector CVSS v4.0 y la fecha de la corrección;
los créditos para las personas que informaron del problema.

Las vulnerabilidades en los SDKs, la CLI, el servidor MCP y el proveedor también reciben identificadores CVE a través de los avisos de seguridad de GitHub.

Para recibir notificaciones, siga el feed Atom https://trust.keenauth.com/advisories.atom en cualquier lector de feeds.

Si una vulnerabilidad en uno de estos productos se explota activamente, o un incidente grave afecta a su seguridad, lo notificamos a las autoridades según exige el CRA e informamos a los usuarios mediante un aviso.

SBOM y VEX

Disponibles con la primera versión de cada paquete:

SBOM. Cada versión incluye una lista de materiales de software en formato CycloneDX JSON, que enumera los componentes que contiene el paquete.
VEX. Cuando una vulnerabilidad conocida en un componente listado no afecta al paquete, lo indicamos en un documento OpenVEX. Un documento VEX solo se genera cuando existe dicha declaración; una versión sin ella no tiene archivo VEX.

Verificar una versión

Disponible con la primera versión. Los paquetes de JavaScript/TypeScript en npm y el paquete de Python en PyPI se compilan y publican desde los repositorios públicos de los SDKs mediante un flujo de publicación que usa publicación de confianza, sin tokens de registro de larga duración.

npm: los paquetes se publican con procedencia. Compruebe las firmas del registro y las atestaciones de procedencia de los paquetes de su proyecto con:
```
npm audit signatures
```
PyPI: las versiones se publican con atestaciones, que se muestran en la página del proyecto.
Paquetes Sigstore: cada archivo de paquete y su SBOM se firman con firma sin claves de Sigstore, y los archivos de paquete incluyen una atestación de procedencia SLSA. Estos archivos se adjuntan a la ejecución del flujo de publicación en el repositorio público de los SDKs y se conservan allí durante 90 días. Verifique un archivo descargado con:
```
cosign verify-blob <file> --bundle <file>.sigstore.json \
  --certificate-identity "https://github.com/<owner>/<repo>/.github/workflows/release.yml@refs/tags/<tag>" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
```
El comando debe indicar que la firma se ha verificado. Use el repositorio y la etiqueta de la versión que descargó.

El servidor MCP es un paquete de npm y sigue los pasos de npm descritos arriba. Los pasos de firma y verificación para el SDK de Go, la CLI y el proveedor se publicarán aquí con su primera versión.