Resumen

  • Una atestación de GitHub criptográficamente válida vincula el resumen del artefacto con una procedencia de compilación registrada; no certifica que el artefacto sea seguro.
  • El consumidor conserva el control decisivo y debe denegar el despliegue si el repositorio, la identidad inmutable del workflow, el commit o la versión, el entorno o el límite de confianza del runner no cumplen la política.
  • Las atestaciones de repositorios privados ofrecen una observabilidad distinta porque la instancia Sigstore de GitHub no emplea el registro público de transparencia de los repositorios públicos.

Una firma correcta no obliga a admitir el artefacto

La prueba más útil aparece cuando todo lo criptográfico parece estar en orden. Una puerta de despliegue recibe una imagen, verifica la firma, confirma que el resumen coincide y lee una declaración de procedencia íntegra. Pese a ello, la rechaza. La compilación puede proceder de otro repositorio, haber utilizado un workflow reutilizable identificado por una etiqueta móvil, corresponder a un commit no autorizado, declarar un entorno equivocado o haberse ejecutado en un runner fuera del perímetro aceptado.

Ese rechazo no invalida la atestación. Demuestra que la verificación se ha integrado en una decisión de admisión.

GitHub define las atestaciones de artefactos como afirmaciones firmadas que establecen la procedencia de una compilación. Pueden identificar el workflow vinculado al artefacto, el repositorio, la organización, el entorno, el SHA del commit y el evento que puso en marcha la ejecución. La identidad OpenID Connect utilizada para establecer la procedencia puede aportar otros datos.

La atestación se genera después de compilar, con permisos para el token de identidad y para escribir la declaración. En un binario, el sujeto puede ser el archivo producido. En un contenedor, el nombre completo y el resumen enlazan la evidencia con un contenido concreto, no solo con una etiqueta mutable. Así puede comprobarse que el objeto presentado corresponde al objeto que recorrió la ruta declarada.

Pero la ruta no equivale a un dictamen sobre el resultado. La atestación no demuestra que el código fuente carezca de fallos, que todas las dependencias sean fiables ni que las instrucciones de construcción fueran adecuadas. Tampoco prueba que la máquina ejecutora estuviera libre de compromiso. Convierte la procedencia en evidencia verificable; no absorbe todos los demás riesgos de la cadena de suministro.

GitHub advierte expresamente que generar una atestación, sin verificarla, no aporta un beneficio de seguridad. También señala que la existencia de la declaración no garantiza que el artefacto sea seguro. Es el consumidor quien debe establecer criterios, evaluar el contenido y adoptar una decisión de riesgo. Limitarse a comprobar que la firma es auténtica deja sin resolver la parte más importante: si la ruta firmada era una ruta aceptable.

El contenido de la política importa más que el sello

El repositorio y la organización esperados forman un primer filtro, pero rara vez bastan. Dentro de una misma organización puede haber un workflow de publicación centralizado y revisado, junto a otras automatizaciones con controles distintos. Que ambos puedan generar declaraciones válidas no los vuelve equivalentes.

Por eso debe comprobarse una identidad inmutable del workflow. GitHub considera que el SHA completo de un commit es la referencia más segura para un workflow reutilizable externo. Las ramas avanzan y las etiquetas pueden trasladarse. Una atestación puede registrar correctamente un nombre y una referencia cuyo contenido ya no coincide con la versión revisada. Aceptar solo el nombre deja abierta una parte de la definición del proceso.

El commit, la condición de lanzamiento, el evento y el entorno acotan aún más la admisión. Una política de producción puede exigir que el binario proceda de un commit aprobado para la versión, no de cualquier commit del repositorio correcto. También puede reservar la admisión a un entorno de publicación gobernado. Son decisiones del consumidor; la firma no las deduce ni las impone.

El runner añade un límite diferente. GitHub alerta de que los runners autohospedados no tienen garantizado un entorno efímero y limpio, y que código no fiable puede comprometerlos de forma persistente. Una declaración válida no prueba que un runner concreto estuviera intacto. La política debe decidir por separado qué clases de ejecución, grupos de runners o entornos se consideran aceptables.

De la evidencia a la aplicación efectiva

GitHub documenta un modelo de aplicación para Kubernetes mediante Sigstore Policy Controller, una raíz de confianza de GitHub y una política de imágenes del clúster. La política se activa por espacio de nombres y permite verificar declaraciones antes de admitir imágenes.

El detalle operativo revela la frontera real. Instalar el controlador sin configurar políticas no aplica nada. Incluso después de instalar una política, debe habilitarse en los espacios de nombres pertinentes. Los patrones de imágenes y sus exenciones determinan además qué queda cubierto. Por tanto, generar atestaciones y aplicarlas en el punto de despliegue son capacidades distintas.

También hay que interpretar con cuidado la diferencia entre repositorios públicos y privados. Las declaraciones públicas utilizan la instancia pública de Sigstore y se escriben en un registro de transparencia legible públicamente. Las privadas usan la instancia Sigstore de GitHub, basada en el mismo código, pero sin ese registro público y federada solo con GitHub Actions. Es una diferencia de observabilidad y escrutinio independiente, no evidencia suficiente de debilidad.

Las fuentes disponibles no publican tasas generales de adopción, rechazo o falsa aceptación. Tampoco permiten afirmar que todos los consumidores aplican políticas o que un runner específico no fue comprometido. Presentar esas incógnitas como hechos excedería la evidencia.

La conclusión operativa es tratar la verificación como control de admisión. Antes del despliegue deben exigirse el repositorio esperado, una identidad inmutable del workflow, el commit o la condición de versión aprobados, el entorno previsto y un límite de confianza aceptable para el runner. Si cualquiera difiere, hay que rechazar el artefacto y conservar un recibo que identifique la condición incumplida.

Fuentes