El caso de Wiz y Snowflake no debe leerse como una nueva brecha de clientes ni como una prueba de que las herramientas de programación con AI estén condenadas. La lección útil es más concreta: un issue público de GitHub puede convertirse en entrada de una automatización corporativa, y si esa entrada se pega dentro de un comando de shell en GitHub Actions deja de ser solo texto. Wiz Research afirma que su herramienta autónoma Red Agent encontró una inyección en un workflow del repositorio público snowflakedb/snowflake-connector-net, abrió un issue preparado, recibió una llamada de vuelta desde el runner de GitHub Actions y obtuvo un Jira API token. Snowflake corrigió el workflow, rotó el token y, según el material publicado, no encontró acceso no autorizado fuera de la investigación autorizada.

Diagrama neutral: un issue público de GitHub fluye hacia un flujo CI y un token interno de Jira bloqueado

Qué ocurrió

La base era una automatización común. Un repositorio público conectaba issues de GitHub con procesos internos de Jira mediante GitHub Actions. Muchas organizaciones hacen algo parecido: al abrirse un bug se crea un ticket, se sincroniza un estado, se avisa a Slack o se actualiza una cola. El riesgo aparece cuando el workflow trata texto controlado por usuarios externos como si fuera código confiable. El título de un issue, el cuerpo, el nombre de una rama, el título de un pull request o un comentario son datos que un atacante puede influir en muchos proyectos públicos.

Wiz informó que Red Agent revisó la organización pública de Snowflake en GitHub y detectó una inyección en .github/workflows/jira_issue.yml. El workflow se activaba con issues: opened. Según Wiz, el título del issue se interpolaba directamente dentro de un bloque run: de shell. El primer intento produjo un error de bash; después el agente ajustó el enfoque y recibió una respuesta externa del runner con credenciales codificadas. El token de Jira autenticaba como [email protected] en el tenant de Atlassian de Snowflake y daba lectura a proyectos de ingeniería, cumplimiento de seguridad y seguimiento de bug bounty.

La cronología acota el alcance. PR #1218, “SNOW-2069227 : Update jira workflows”, se fusionó el 18 de junio de 2026. Wiz dice que Red Agent encontró, probó y reportó el problema el 23 de junio. El PR de corrección #1402 se fusionó el mismo día, y el token fue rotado el 24 de junio. Wiz publicó el análisis el 17 de agosto y The Hacker News lo cubrió el 18 con matices relevantes: no se identificó una versión afectada de Snowflake Connector for .NET, no había CVE ni entrada CISA KEV pública, y no había evidencia pública de compromiso de clientes.

Por qué importa ahora

El caso resonó porque une dos tendencias. Los asistentes de código ya participan en el trabajo diario, y las revisiones automáticas de seguridad forman parte de muchos pull requests. Al mismo tiempo, agentes autónomos de seguridad pueden leer repositorios públicos, reconocer clases conocidas de fallos, probar una ruta, ver un error y adaptarse. Eso no convierte a cada agente en un superatacante, pero reduce la ventana entre el error y una demostración funcional.

El mensaje maduro no es prohibir Copilot ni confiar en él sin reservas. El mensaje es tratar los cambios en .github/workflows, scripts de despliegue, credenciales, tokens de Jira, firma de releases y publicación de paquetes como código sensible. Que un bot haya mirado el PR no demuestra que el cambio sea seguro.

Inyección de workflow sin receta de ataque

La idea es sencilla. Un dato externo es seguro mientras sigue siendo dato. Un título de issue es texto mientras GitHub lo almacena. Se vuelve peligroso cuando el workflow lo expande dentro de un comando de shell. Si el texto contiene caracteres interpretados por la shell, el runner puede ejecutar una acción no prevista.

La forma segura es mantener los valores no confiables fuera del texto del comando. Se colocan en variables de entorno, se citan, se pasan a herramientas como datos y se usan codificadores estructurados como jq --arg al construir JSON. GitHub ya ha advertido que contextos como títulos de issues o nombres de ramas no deben expandirse directamente dentro de run:. La clase no pertenece solo a Snowflake ni a Jira; aparece donde YAML de CI/CD mezcla metadatos públicos, shell y credenciales.

Repositorios públicos como superficie de ataque

Un repositorio público no es solo una vitrina de código. También puede ser una puerta de entrada a la automatización. Un issue nuevo, un comentario, una etiqueta o una rama pueden activar workflows en runners alojados o propios. Esos workflows pueden tener tokens de Jira, Slack, registros de paquetes, clouds o herramientas de release.

Por eso issues: opened no es una simple notificación. Es una ruta de entrada no confiable desde internet. Si el workflow toca un token interno, el repositorio público queda conectado a infraestructura corporativa. Aunque el token sea de solo lectura, puede revelar vulnerabilidades abiertas, discusiones de triage, nombres internos, proyectos de cumplimiento o pistas para ataques posteriores.

Dónde entra AI

El ángulo AI es real, pero exige precisión. Wiz vinculó el caso con un pull request asistido por Copilot y con Red Agent como herramienta autónoma. Después aclaró que Copilot figuraba como coautor o verificador del PR y lo marcó como correcto, pero que la evidencia pública no prueba que Copilot escribiera las líneas vulnerables. La conclusión responsable no es “Copilot causó el fallo”. Es que la asistencia automática no impidió una clase conocida de error de CI/CD.

Red Agent muestra el otro lado: la automatización defensiva puede encontrar y validar fallos rápido. También muestra qué deben esperar los defensores en repositorios públicos. Los agentes no necesitan inventar vulnerabilidades nuevas; pueden aplicar patrones viejos de forma persistente.

No es una brecha de clientes, pero sí importa

El material público no demuestra compromiso de datos de clientes. The Hacker News indicó que el problema estaba limitado a la automatización CI/CD del repositorio y que no se identificó una versión afectada del conector. Wiz afirma que Snowflake revisó logs y que Wiz fue el único actor durante la ventana de exposición. El token se rotó.

Eso define el alcance, no elimina la lección. Un secreto de CI/CD expuesto puede ser grave aunque lo encuentre un investigador autorizado y se repare rápido. Jira puede contener información sobre ingeniería, cumplimiento, fallos de seguridad y bug bounty. Para un atacante real, la lectura interna puede ser inteligencia operativa.

Controles prácticos

Inventarie workflows, sobre todo los que escuchan issues, issue_comment, pull_request, pull_request_target, discussion o entradas manuales. Para cada uno, anote qué secretos ve, qué sistemas llama y dónde corre. Busque expansiones directas de ${{ github.event.issue.title }}, ${{ github.event.issue.body }}, ${{ github.head_ref }}, títulos de PR, comentarios y nombres de ramas dentro de run:.

Reduzca permisos explícitamente. No entregue secretos a workflows activados por eventos públicos si no es imprescindible. Use OIDC, credenciales de corta duración y cuentas de servicio limitadas. Separe pasos privilegiados detrás de una etiqueta aprobada por un maintainer o un servicio intermedio que valide datos. Exija revisión de code owners para .github/workflows/**, scripts de release y despliegue.

Gobernanza para cambios asistidos por AI

Los cambios generados o revisados por AI necesitan una política basada en riesgo. Etiquetar commits ayuda a la auditoría, pero no basta. Si el cambio toca CI/CD, identidad, secretos, releases o rutas hacia datos de clientes, debe revisarlo una persona responsable de esa zona y pasar controles específicos para ese tipo de archivo.

La conclusión para líderes es simple: AI no elimina las bases de AppSec; acelera ambos lados. El tiempo entre un merge vulnerable y una prueba funcional puede caer a días u horas. La respuesta tranquila es tratar YAML de CI/CD como código de producción con secretos. Los issues públicos son entrada de usuario; las entradas necesitan límites; los secretos necesitan alcance; la automatización necesita dueño.