Endurecer flujos de trabajo de GitHub Actions: acciones fijadas por SHA, tokens de mínimo privilegio y entradas no confiables

Objetivo

Un flujo de trabajo cuyo comportamiento no pueda ser alterado por un tercero que publique una nueva versión de una acción, cuyo token no pueda hacer push de código ni de etiquetas salvo que un job lo necesite explícitamente, y cuyos scripts no puedan ser secuestrados por un título de pull request manipulado.

Requisitos previos

Acceso de escritura a los archivos de flujo de trabajo y a la configuración del repositorio; una lista de todas las referencias uses: en .github/workflows.

Pasos

1. Reemplazar cada uses: owner/action@v4 por el SHA de commit completo de 40 caracteres y conservar la etiqueta como comentario (# v4.2.1). La referencia de uso seguro citada indica que fijar a un SHA de commit completo es actualmente la única forma de usar una acción como una versión inmutable, y que el SHA debe verificarse como procedente del repositorio de la acción y no de un fork. Dejar que un bot de actualización de dependencias abra pull requests con los nuevos SHA.
2. Establecer permissions: contents: read en el nivel superior de cada flujo de trabajo. Según la sintaxis de flujo de trabajo citada, especificar cualquier permiso pone todos los no especificados en none; añadir packages: write o id-token: write en el job concreto que publica.
3. Tratar los datos del evento como no confiables: nunca escribir ${{ github.event.pull_request.title }} ni un nombre de rama dentro de un script run:. Pasarlo a través de una variable env: y referenciar "$TITLE" en el shell, o trasladar la lógica a una acción que reciba el valor como argumento, tal como recomienda la referencia de uso seguro.
4. Evitar hacer checkout del código de la pull request en flujos de trabajo pull_request_target o workflow_run; la referencia citada señala que estos disparadores se ejecutan con acceso de escritura al repositorio y con secretos incluso para forks. Si un paso privilegiado debe leer el contenido de un fork, dividirlo en un flujo de trabajo sin privilegios que suba un artefacto y otro privilegiado que lo consuma sin ejecutarlo.
5. Colocar los secretos de despliegue en entornos con revisores obligatorios, de modo que un job no pueda leerlos hasta que se apruebe.
6. Activar la política de organización o repositorio que exige fijar por SHA, para que una futura edición no pueda revertir el paso 1.

Resultado esperado

Cada archivo de flujo de trabajo nombra código exacto para cada dependencia, otorga al token solo lo que necesita un job, y no contiene ninguna línea de shell que concatene cadenas controladas por un atacante.

Límites y base de verificación

Fijar por SHA congela tanto las correcciones de errores como las puertas traseras; sin propuestas automatizadas de actualización, se degrada hacia acciones desactualizadas. Los flujos de trabajo reutilizables y las acciones compuestas traen sus propias líneas uses: que deben fijarse en su interior. La guía sigue la documentación de GitHub citada.