Checklist de integridad de releases de GitHub
Puntúa los 12 controles que hacen verificable una release: publicación de confianza con OIDC, releases firmadas, atestación y procedencia SLSA.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
Una release es el momento en que tu código se convierte en la dependencia de otra persona. Esta autoevaluación puntúa los controles que deciden si la release que la gente instala es de verdad el código que revisaste y firmaste, y no una compilada desde un origen elegido por un atacante o publicada con un token robado. Son doce controles en tres áreas: origen y procedencia de la release, publicación de confianza y firma, y un entorno de release protegido con una puerta humana sobre una llave de hardware. Cubre fijar el origen de la release a un repositorio que controlas, verificar que la etiqueta coincide con el artefacto (tag == artifact), la publicación de confianza con OIDC en PyPI y npm (sin tokens de larga duración), las releases firmadas y la atestación de artefactos, la procedencia SLSA, las compilaciones reproducibles y un entorno protegido con revisores obligatorios. Los controles marcados como «LiteLLM» rompen cada uno un eslabón del compromiso de release al estilo LiteLLM de octubre de 2026, en el que se publicó una release compilada desde el origen de un fork tras exfiltrar credenciales de publicación desde la CI. Marca cada control como implantado, parcial o ausente para obtener una puntuación ponderada de 0 a 100, un desglose por área, las carencias priorizadas y un informe exportable. Funciona al 100 % en el cliente: no se sube nada. Es una herramienta Pro.
- Recorre los 12 controles de las tres áreas: origen y procedencia, publicación de confianza y firma, y entorno de release protegido.
- Marca cada uno como implantado, parcial o ausente.
- Fíjate en los controles marcados como «LiteLLM»: cada uno habría roto un paso de ese compromiso.
- Revisa la puntuación de 0 a 100, el desglose por área y las carencias priorizadas, y exporta el informe.
Preguntas frecuentes
¿Qué es la publicación de confianza (OIDC) y por qué importa aquí?
La publicación de confianza permite que un registro de paquetes como PyPI o npm confíe en un token de identidad de corta duración emitido para tu ejecución de CI mediante OIDC, en lugar de un token de API de larga duración guardado como secreto. Los tokens de publicación de larga duración son justo el tipo de credencial que se exfiltra de la CI y se reutiliza para subir una versión maliciosa. Con la publicación de confianza por OIDC no hay ningún token permanente que robar: el registro confía en el workflow concreto del repositorio concreto, solo para esa ejecución.
¿Qué significa «verificar tag == artifact»?
Significa que el artefacto que publicas debe ser el que se compiló en la CI a partir de la etiqueta exacta revisada y firmada, no un archivo que alguien subió a mano o compiló desde otro origen. Se aplica compilando en la CI desde la etiqueta, publicando solo esa salida y comparando el digest del artefacto de la release con el digest de la compilación de la CI (y, mejor aún, con una atestación firmada de él). Es lo que impide que una «release compilada desde el origen de un fork» pase por la auténtica.
¿Qué es la atestación de artefactos o la procedencia SLSA?
Una atestación es una declaración firmada sobre un artefacto: quién lo compiló, desde qué commit de origen y con qué workflow. Las atestaciones de artefactos de GitHub y la procedencia de compilación SLSA permiten a quien lo consume verificar, antes de instalarlo, que un paquete lo compiló de verdad tu canalización a partir de tu código. Una release compilada desde el origen equivocado no supera la verificación en lugar de instalarse sin que nadie lo note.
¿Por qué un entorno protegido con una llave de hardware?
Un entorno de despliegue de GitHub con revisores obligatorios obliga a que una persona apruebe antes de que el trabajo de release pueda tocar los secretos de publicación, y limitar esos secretos a ese entorno los mantiene fuera de la CI ordinaria. Exigir que quien aprueba use una llave de seguridad de hardware resistente al phishing (FIDO2) significa que una contraseña o un código de un solo uso robados no pueden aprobar una release. Juntos ponen una puerta humana real y difícil de suplantar entre «compilación terminada» y «publicado para todo el mundo».
¿Cómo se relaciona con el incidente de LiteLLM?
Según se informó públicamente, el compromiso de LiteLLM de octubre de 2026 incluyó la publicación de una release compilada desde el origen de un fork tras exfiltrar secretos de la CI. Fijar el origen de la release, verificar tag == artifact, usar la publicación de confianza con OIDC en lugar de un token robable, atestar la compilación y condicionar la publicación a una persona con llave de hardware son los controles que, cada uno, habrían roto ese paso. Esta herramienta cita un incidente real y publicado como contexto y no está afiliada a LiteLLM ni a GitHub.
¿Es gratis?
No, es una herramienta Pro. Con una cuenta gratuita tienes 3 usos de prueba de herramientas Pro en total; después necesitas Pro.