Auditor de seguridad de GitHub Actions
Pega un YAML de workflow y detecta acciones sin fijar, «pwn requests» de pull_request_target, permisos write-all, secretos filtrados y curl|bash, en tu navegador.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
Pega un workflow de GitHub Actions y ve los patrones de riesgo sobre los que el propio GitHub advierte: pull_request_target que hace checkout de código no fiable de un fork, acciones fijadas a un @main o @v4 mutable en lugar de a un SHA de commit completo, permissions: write-all o ningún bloque de permisos, secretos impresos en los logs, curl | bash, runners autoalojados e inyección de scripts con ${{ github.event.* }}. Cada hallazgo tiene una severidad, la línea causante, por qué importa y una corrección concreta, además de un informe que se puede copiar o descargar. La biblioteca de comprobaciones sigue la documentación Security Hardening for GitHub Actions de GitHub y la guía de GitHub Security Lab sobre las «pwn requests». La CI es un lugar privilegiado: guarda los tokens que publican código, crean versiones y llegan a producción. La herramienta nace del compromiso de cadena de suministro de identidad de GitHub de LiteLLM en octubre de 2026, en el que, según se informó públicamente, un punto de apoyo en la CI se usó para exfiltrar secretos; los tokens de mínimo privilegio y las fuentes de workflow fijadas y de confianza son los controles que contienen ese radio de impacto. Todo se ejecuta en tu navegador: el workflow nunca se sube ni se ejecuta. PlayCISO no está afiliado a LiteLLM ni a GitHub. Es una herramienta Pro.
- Pega el YAML de tu workflow de GitHub Actions.
- Revisa los hallazgos ordenados por severidad, cada uno con la línea causante y por qué importa.
- Aplica la corrección concreta de cada hallazgo: fija las acciones a un SHA completo, reduce los permisos de GITHUB_TOKEN y no ejecutes código de PR no fiable bajo un disparador privilegiado.
- Copia o descarga el informe para la revisión.
Preguntas frecuentes
¿Sube o ejecuta mi workflow?
No. El análisis es 100 % en el cliente, con coincidencia de cadenas y expresiones regulares en tu navegador. El YAML nunca sale de tu dispositivo, no se hace ninguna petición de red y el workflow nunca se ejecuta. Puedes desconectarte de la red y sigue funcionando.
¿Por qué marca actions/checkout@v4 como un problema?
Las etiquetas como v4 y las ramas como main son mutables: el mantenedor de la acción, o un atacante que comprometa su cuenta, puede volver a apuntar la etiqueta a código nuevo que después se ejecuta en tu pipeline con tus secretos. La guía de endurecimiento de GitHub recomienda fijar las acciones de terceros a un SHA de commit completo (de 40 caracteres), que es inmutable. La herramienta trata una etiqueta como riesgo medio y una rama como @main como riesgo alto.
¿Qué es la «pwn request» de pull_request_target?
pull_request_target (y workflow_run) se ejecutan en el contexto del repositorio base con acceso a sus secretos, a diferencia de pull_request, que en las PR de forks se ejecuta sin ellos. Si un workflow así hace checkout de la cabeza de la pull request (el código del fork) y después compila o ejecuta scripts de él, cualquier colaborador puede abrir una PR cuyo código se ejecute con tus secretos. GitHub Security Lab lo llama «pwn request». Usa pull_request para el código no fiable y nunca ejecutes código de la cabeza de una PR en un disparador privilegiado.
¿Qué relación tiene con el incidente de LiteLLM?
En el compromiso de LiteLLM de octubre de 2026, según se informó públicamente, una clave filtrada llevó a un token de la CLI de GitHub de un propietario de la organización, que se usó para exfiltrar secretos de la CI, publicar una versión compilada a partir de un fork y después borrar los registros de ejecución y hacer un force-push para ocultar el rastro. Los workflows endurecidos reducen ese radio de impacto: los permisos de mínimo privilegio de GITHUB_TOKEN limitan lo que puede tocar un job secuestrado, los SHA de acciones fijados impiden que entre una versión maliciosa y no ejecutar código no fiable con secretos cierra el punto de apoyo inicial. La herramienta cita un incidente real y publicado como contexto; no está afiliada a LiteLLM ni a GitHub.
¿Un resultado limpio garantiza que mi workflow es seguro?
No. Esto compara con una biblioteca fija de errores bien conocidos. Un workflow puede pasar todas las comprobaciones y aun así ser inseguro por una lógica que la herramienta no modela. Tómalo como una primera pasada rápida, no como sustituto de una revisión ni del propio escaneo de código de 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.