Su automatización recibe un secreto, lo conserva y luego lo envía a GitHub para leer un repositorio. Funcionaba ayer, pero ahora un valor más largo se trunca al pasarlo. Los permisos pueden ser correctos y la consulta puede fallar de todos modos. El final del despliegue de los nuevos tokens de instalación de GitHub Apps, anunciada el 2 de octubre de 2026, invita a seguir este secreto durante todo su recorrido.
Identificar el secreto concernido antes de buscar por todas partes
Una GitHub App es una aplicación a la que se le conceden permisos sobre un conjunto de repositorios. Su instalación tiene un contexto de acceso propio. El token de instalación se utiliza para llamadas realizadas en este contexto; se diferencia del secreto de un usuario y de la clave privada de la aplicación.
La documentación de GitHub separa la autenticación de la aplicación y la generación de un token para su instalación. Antes de su auditoría, por lo tanto, encuentre el componente que obtiene efectivamente este último. Una configuración que lleva simplemente el nombre « GitHub token » no basta para identificar su familia. Documentación de los tokens de instalación.
El 2 de octubre, GitHub anunció el fin del despliegue iniciado el 27 de abril: los nuevos tokens de instalación usan por defecto un formato sin estado. Conservan el prefijo ghs_ y tienen alrededor de 520 caracteres, frente a 40 anteriormente. Los permisos, el alcance de los repositorios, la expiración de una hora y el endpoint permanecen sin cambios. El encabezado temporal X-GitHub-Stateless-S2S-Token quedará obsoleto el 30 de noviembre de 2026. Anuncio de finalización del despliegue.
Stateless describe aquí el nuevo formato del proveedor. No necesita entender su interior para transmitir el secreto correctamente. El valor debe permanecer opaco: su aplicación lo transporta, pero no construye sus reglas de acceso decodificando lo que cree reconocer en él. El orden de magnitud publicado no es una nueva longitud exacta que imponer en un formulario.
Dibujar la ruta real, del proveedor a la solicitud
Nuestro ejemplo ficticio es una herramienta interna que consulta el estado de los repositorios. Un servicio obtiene el token, un almacenamiento lo conserva brevemente, un proceso de trabajo lo carga y un cliente HTTP lo envía. Una interfaz de administración y una recopilación de errores también pueden manipularlo. Cada uno de estos pasos puede conservar una hipótesis antigua.
Comience con los nombres de variables, las propiedades y los parámetros que transportan el valor. Luego busque las restricciones sobre su longitud y las transformaciones aplicadas: corte de cadena, eliminación de caracteres, codificación o copia hacia un campo diferente. Una restricción puede provenir del código, de un esquema de base o de un componente externo.
Una columna demasiado corta puede provocar un error explícito, pero algunos caminos pueden truncar silenciosamente. Un campo de interfaz puede rechazar la entrada incluso antes de la llamada de red. Una máscara de registro puede reconocer solo el secreto antiguo y dejar que parte del nuevo aparezca. Por lo tanto, no reduzca la auditoría a la línea que construye el encabezado de autenticación.
| Componente a examinar | Pregunta útil | Prueba esperada |
|---|---|---|
| Servicio de obtención | ¿La respuesta está copiada en su totalidad? | Igualdad sobre un valor ficticio |
| Almacenamiento | ¿La capacidad y los controles son adecuados? | Lectura después de la escritura sin pérdida |
| Carga | ¿Se modifica el valor en tránsito? | Comparación antes y después del paso |
| Cliente de red | ¿El encabezado contiene el valor correcto? | Captura en un transporte simulado |
| Registros y errores | ¿Aparece una parte del secreto? | Búsqueda negativa en las salidas |
Esta cuadrícula es una propuesta de Partitech. Agregue un responsable por línea, ya que una prueba concluyente sobre el código de la aplicación no valida necesariamente el proxy o la herramienta de almacenamiento gestionada por otro equipo.
Probar una propiedad, en lugar de un ejemplo de formato
La propiedad buscada es simple: el valor que entra debe ser idéntico al que alcanza el transporte previsto. Una cadena de prueba no necesita parecer un verdadero secreto. Elija un prefijo explícito, por ejemplo FAUX_SECRET_TEST_, y tamaños variados, incluyendo uno que supera el orden de magnitud anunciado. Estos valores nunca deben permitir una autenticación.
Puede incluir una cadena corta, una más larga y un valor que contenga los caracteres que su componente acepta según su contrato. Los tamaños son parámetros de prueba locales, no una estimación de los futuros tokens de GitHub. Mantenga límites razonables contra las entradas abusivas; evite únicamente una restricción proveniente de un formato antiguo sin justificación técnica.
Pseudocódigo del control propuesto, no ejecutado aquí:
pour chaque valeur factice du jeu de test
écrire dans le stockage de test
relire par le chemin de chargement réel
envoyer au client HTTP simulé
vérifier l'égalité avec la valeur de départ
provoquer une erreur de transport simulée
vérifier l'absence de la valeur dans toutes les sorties
Agregue un caso que exceda intencionalmente la capacidad definida de su componente. El error debe ser claro y no debe truncar y luego continuar, ni mostrar el contenido recibido. Esta prueba verifica la calidad de la negativa; no le pide que acepte cadenas de tamaño infinito.
Para el enmascaramiento, busque el secreto completo pero también los segmentos reconocibles que puedan ser expuestos. Una regla que oculta el inicio y muestra el final sigue siendo una filtración. Inspeccione la respuesta de error, la consola, los registros estructurados y los posibles archivos adjuntos de diagnóstico. Haga esto con valores ficticios, para que la investigación no se convierta en una exposición en sí misma.
Corregir la frontera defectuosa sin ampliar los derechos
Si el almacenamiento trunca, corrija su capacidad según las convenciones de su aplicación. Si una expresión regular exige exactamente la longitud antigua, reemplace esta suposición por un control coherente con el uso real. Si una herramienta de diagnóstico reconoce solamente un patrón antiguo, prefiera retirar la propiedad secreta de la recopilación en lugar de intentar adivinar todas sus formas futuras.
Un error de formato no justifica agregar permisos a la aplicación. En nuestra herramienta ficticia, la lectura de repositorios sigue siendo una lectura de repositorios, incluso después de corregir el almacenamiento. Verifique por separado los permisos realmente necesarios; no confunda un rechazo local con un rechazo de autorización remoto.
Cuando sea necesario un cambio de esquema, prepárelo con el mecanismo de migración existente. Verifique el orden de despliegue entre la base y el código, las instancias antiguas todavía activas y la manera en que leen los nuevos datos. Una escritura correctamente ampliada siempre puede ser mal leída por una instancia que conserva la validación antigua.
Evite guardar más secretos para facilitar la comparación. Su prueba puede registrar « igualdad verificada » y el nombre del escenario de prueba, sin conservar el valor. Un almacenamiento temporal debe mantener su expiración y sus controles de acceso. El trabajo se centra en el transporte fiel, no en la multiplicación de copias.
Preparar el 30 de noviembre y la supervisión
El anuncio del 15 de mayo presentaba un encabezado temporal que permitía elegir el comportamiento de generación durante la transición. Permanece como un contexto histórico, distinto del final del despliegue anunciado en octubre. Anuncio del encabezado de transición.
Elabore la lista de los componentes que aún utilizan este encabezado. Asigne la eliminación a una versión de entrega, con un responsable y una prueba de compatibilidad. La fecha límite del 30 de noviembre anunciada por GitHub debe figurar en su seguimiento: una opción de transición no es un mecanismo permanente de retroceso.
Después de las pruebas locales, una verificación autorizada en un entorno de prueba de GitHub puede verificar la obtención y el uso del token, con los derechos mínimos necesarios. Debe mantener los secretos fuera de las capturas. Distinga en su informe lo que el transporte simulado ha demostrado de lo que esta llamada real ha confirmado.
Para la supervisión, siga los errores por componente y por etapa: obtención, almacenamiento, carga, consulta. Compare las tendencias antes y después de la entrega, sin asociar un incidente a un formato únicamente porque aparece en la misma fecha. Una respuesta de rechazo puede tener varias causas; su inventario permite probar la hipótesis correcta.
Elegir una reversión que siga siendo compatible
Un regreso a una versión anterior que trunque los nuevos tokens reintroduciría el problema. Por lo tanto, prepare una versión de respaldo que conserve la corrección de compatibilidad, o un plan de retirada del cambio funcional que no restaure la antigua restricción. Documente este punto antes de lanzar la entrega.
La tarea puede considerarse calificada cuando los pasajes reales tienen un responsable, los ensayos simulados preservan íntegramente el valor, los errores permanecen sin secreto y la retirada del encabezado temporal está planificada. No se reivindica ninguna prueba ejecutada sobre una integración de Partitech en este artículo.
Para su próxima revisión técnica, elija un solo recorrido de token de instalación y aplique la cuadrícula de extremo a extremo. Obtendrá un perímetro de corrección concreto, en lugar de una reescritura general de la autenticación. La robustez útil depende de la fidelidad del transporte y de la discreción de los diagnósticos, independientemente de la forma actual del secreto.
Fuentes y fecha de verificación
Fuentes abiertas el 6 de octubre de 2026: fin del despliegue, encabezado temporal de mayo y documentación de GitHub Apps. Las pruebas descritas constituyen un protocolo propuesto, sin secreto funcional ni resultado fabricado.