Firmar en CI sin filtrar la llave: el almacén como secreto, el entorno y los registros

Automatizar la firma es el momento en que la integración continua deja de ser una comodidad y pasa a ser un problema de seguridad con consecuencias irreversibles. Hasta ese punto, lo peor que puede ocurrir en el peor de los flujos es que alguien compile algo que no debía. A partir de ahí, la máquina que ejecuta tus flujos tiene acceso a la identidad criptográfica de tu aplicación, la misma que determina si una actualización puede reemplazar a la instalada en el teléfono de un usuario, y esa identidad no se puede revocar, ni rotar sin coordinación, ni recuperar si se pierde. La firma no autentica el binario ante un servidor que pueda cambiar de opinión: autentica la continuidad de la aplicación ante el sistema operativo, y esa relación se estableció el día de la primera publicación.

El modelo de amenaza: qué se protege y de quién

Antes de escribir una línea conviene enunciar de qué se está protegiendo la clave, porque las medidas razonables cambian por completo según la respuesta. Hay cuatro adversarios plausibles y solo uno de ellos suele estar en la cabeza de quien configura el flujo. El primero es el atacante externo que compromete el repositorio o una cuenta con permisos; es el que todo el mundo imagina. El segundo es el colaborador legítimo que, sin mala intención, ejecuta un flujo con un paso que imprime el entorno para depurar y deja la contraseña en un registro que queda archivado durante noventa días. El tercero es la dependencia de terceros: cualquier acción del mercado que se incorpore al flujo se ejecuta con acceso al mismo entorno, y una versión comprometida de una acción popular es un vector demostrado. El cuarto, el más incómodo, es el propio historial: una clave que estuvo alguna vez comprometida en el repositorio sigue ahí aunque el commit se haya revertido.

De ese análisis salen tres principios que ordenan todo lo demás. El primero es que la clave nunca debe existir en el sistema de archivos del repositorio, ni siquiera cifrada, porque el historial es indeleble y la contraseña de cifrado acaba viviendo en el mismo sitio. El segundo es que la clave solo debe estar disponible en los trabajos que realmente firman, y no en los que compilan variantes de depuración o ejecutan pruebas, porque cada trabajo que la ve amplía la superficie sin aportar nada. El tercero es que la fuga esperable no es un robo sofisticado sino una impresión accidental, y por tanto las defensas más rentables son las que hacen imposible imprimirla.

Existe además una asimetría de daño que conviene tener presente. Filtrar la clave de subida a la tienda es grave pero recuperable: se revoca, se registra una nueva y las publicaciones futuras usan la nueva. Filtrar la clave de firma de aplicación en el modelo antiguo, donde el binario que llega al dispositivo va firmado con ella, es catastrófico e irreversible, porque cualquiera puede producir actualizaciones que el sistema operativo aceptará como legítimas. Esa asimetría es, por sí sola, el argumento decisivo a favor de delegar la firma final en la tienda.

Transportar el almacén: por qué codificado y qué implica

El almacén de claves es un fichero binario y el almacén de secretos de la plataforma guarda cadenas de texto. La solución universal es codificarlo en base64 y guardar la cadena resultante como secreto, reconstruyendo el fichero durante la ejecución. Conviene entender que esa codificación no es cifrado: no aporta ninguna confidencialidad por sí misma, solo transporte. Lo que protege el almacén es la contraseña con la que se creó y el control de acceso del almacén de secretos, no el base64.

De ahí se deriva una regla práctica que mucha gente incumple: la cadena codificada y la contraseña del almacén deben ser secretos distintos, y quien tenga acceso a uno no debería tener acceso automático al otro cuando la organización permite esa separación. Guardar ambos en el mismo lugar es aceptable en equipos pequeños, pero conviene saber que se está aceptando.

La reconstrucción debe ocurrir en un directorio efímero fuera del árbol de trabajo, para que ninguna tarea que empaquete el directorio del repositorio lo arrastre por accidente, y debe eliminarse al terminar aunque el trabajo falle. La codificación sin saltos de línea evita un fallo clásico en el que la decodificación produce un fichero corrupto y el error que aparece varias fases después no menciona en ningún momento el almacén.

# En tu maquina, una sola vez: codificar sin saltos de linea
base64 -i upload-keystore.jks -o keystore.b64
# El contenido de keystore.b64 se pega como secreto del repositorio

- name: Reconstruir el almacen fuera del arbol de trabajo
  run: |
    echo "${{ secrets.KEYSTORE_BASE64 }}" | base64 --decode > "$RUNNER_TEMP/upload.jks"
    echo "KEYSTORE_PATH=$RUNNER_TEMP/upload.jks" >> "$GITHUB_ENV"

- name: Construir y firmar
  env:
    KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }}
    KEY_ALIAS: ${{ secrets.KEY_ALIAS }}
    KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }}
  run: ./gradlew bundleRelease

- name: Borrar el almacen pase lo que pase
  if: always()
  run: rm -f "$RUNNER_TEMP/upload.jks"

El entorno y la configuración de firma en Gradle

La configuración de firma debe leer del entorno y degradar limpiamente cuando ese entorno no está, para que un desarrollador pueda compilar la variante de publicación en local sin poseer la clave. El patrón correcto es condicionar la existencia misma de la configuración a la presencia de las variables, en lugar de definirla siempre y fallar con un error críptico. Así el flujo de integración que no firma sigue funcionando y el que firma obtiene lo que necesita.

Hay un detalle de higiene que conviene añadir: si el proyecto todavía usa un fichero de propiedades local para las credenciales de firma, ese fichero debe estar excluido del control de versiones y la lógica debe preferir siempre el entorno cuando ambos existan. La combinación inversa, en la que el fichero gana, produce el escenario en el que la máquina firma con una clave equivocada porque alguien dejó un fichero olvidado en la imagen.

// build.gradle.kts del modulo de aplicacion
android {
    signingConfigs {
        create("release") {
            val ruta = System.getenv("KEYSTORE_PATH")
            if (ruta != null) {
                storeFile = file(ruta)
                storePassword = System.getenv("KEYSTORE_PASSWORD")
                keyAlias = System.getenv("KEY_ALIAS")
                keyPassword = System.getenv("KEY_PASSWORD")
            }
        }
    }
    buildTypes {
        getByName("release") {
            isMinifyEnabled = true
            if (System.getenv("KEYSTORE_PATH") != null) {
                signingConfig = signingConfigs.getByName("release")
            }
        }
    }
}

Después de firmar merece la pena verificar, y no dar por hecho. La herramienta de firma del SDK informa de con qué esquemas quedó firmado el artefacto y de qué certificado lo respalda, y comparar la huella del certificado con la esperada convierte un fallo silencioso de configuración en un error explícito. Es el equivalente de leer el recibo.

# Verificar el esquema y el certificado del artefacto firmado
apksigner verify --print-certs --verbose app-release.apk

# Para un paquete de aplicacion, comprobar la huella del almacen usado
keytool -list -v -keystore "$KEYSTORE_PATH" -alias "$KEY_ALIAS"

flowchart TD
A[Secreto en base64 en el almacen de la plataforma] --> B[Paso de reconstruccion]
B --> C[Fichero temporal fuera del arbol de trabajo]
D[Contrasenas como variables de entorno] --> E[Proceso de gradle]
C --> E
E --> F[Artefacto firmado]
F --> G[Verificacion del certificado]
G --> H[Subida al canal de prueba]
E --> I[Paso de limpieza siempre]
I --> J[Fichero temporal eliminado]
style J fill:#a6e3a1,color:#11111b
style A fill:#f9e2af,color:#11111b

Las fugas que nadie anticipa

Las tres vías de fuga clásicas no tienen nada que ver con el paso de firma. La primera son los artefactos que el flujo publica: un directorio de resultados que incluye por accidente el fichero reconstruido, un informe de compilación que copia el entorno o un volcado de fallo que adjunta el directorio temporal completo. Conviene enumerar explícitamente qué rutas se suben en lugar de subir directorios enteros, y auditar una vez el contenido real de un artefacto descargado.

La segunda son los flujos disparados por ramas ajenas. Un pull request desde una bifurcación no debe tener acceso a los secretos, y por defecto no lo tiene, pero existe un disparador alternativo diseñado para ejecutar en el contexto del repositorio principal que sí los expone y que se combina con demasiada frecuencia con un paso que descarga y ejecuta el código propuesto. Esa combinación concreta es una entrega directa de la clave a cualquiera que abra un pull request. La regla es sencilla: si un flujo puede ejecutar código de una bifurcación, no debe ver secretos de firma bajo ninguna circunstancia.

La tercera es el registro producido por herramientas de terceros que no saben que están manejando un secreto. Un plugin que imprime su configuración al arrancar, una acción que reporta las variables que ha recibido, una herramienta de subida que incluye la petición completa en su mensaje de error. La plataforma enmascara los valores exactos de los secretos que conoce, pero no enmascara transformaciones de esos valores, de modo que un secreto que aparece decodificado, troceado o vuelto a codificar de otra forma atraviesa el filtro sin problema. Cuando un paso derive un valor sensible nuevo, hay que registrarlo explícitamente como enmascarado.