Los controles se construyeron ahí: escaneo pre-commit, revisiones de PR, políticas de CI/CD que bloquean pushes con tokens en texto plano
Enfoque de decisión
Los líderes de ingeniería necesitan evaluar si sus programas de detección de secretos cubren superficies fuera del repositorio: herramientas de colaboración, sistemas de ticketing y archivos de configuración de contenedores. El riesgo no está únicamente en el SCM.
Resumen en 90 segundos
Ahora, según el informe State of Secrets Sprawl 2026 de GitGuardian, aproximadamente el 28% de los incidentes de seguridad analizados se originan en herramientas de colaboración como Slack, Jira o Confluence, no en el código fuente. Los incidentes detectados fuera del repositorio tienen 13 puntos porcentuales más de probabilidad de ser clasificados como críticos que los encontrados en el SCM. El 64% de las credenciales comprometidas detectadas en 2022 seguían activas en 2026, según el mismo informe. GitGuardian reporta un patrón de acceso inicial a través de credenciales de Google Cloud Platform encontradas en tickets de soporte, ilustrando cómo las herramientas de ticketing pueden servir como punto de entrada para incidentes de seguridad.
¿Qué está pasando realmente?
Durante años, la ingeniería de seguridad orientada al código asumió que el repositorio era el lugar donde los secretos se filtraban. Los controles se construyeron ahí: escaneo pre-commit, revisiones de PR, políticas de CI/CD que bloquean pushes con tokens en texto plano. Esa capa tiene sentido y ha madurado.
El problema es que los secretos no respetan la arquitectura de controles. Un ingeniero resolviendo un incidente a las 2 AM copia un token de acceso en un ticket de Jira para que otro colega lo use. Una integración nueva se documenta en Confluence con las credenciales de staging incluidas. Un hilo de Slack con contexto de debugging queda archivado con una clave API funcional.
Según el informe de GitGuardian referenciado en la cobertura de Cinco Días, cerca del 28% de los incidentes analizados tienen su origen precisamente en estas superficies, no en el código. Y esa porción es desproporcionadamente peligrosa: los secretos encontrados fuera del SCM tienen 13 puntos más de probabilidad de clasificarse como críticos.
El informe de GitGuardian documenta un patrón donde credenciales expuestas en fuentes de baja vigilancia sirven como punto de entrada, desde ahí se localizan más secretos en el entorno y se escalan privilegios. No hay necesidad de explotar una vulnerabilidad de código. La puerta está abierta.
Lo que convierte esto en un problema estructural es la longevidad de las credenciales comprometidas. El mismo informe apunta que el 64% de las credenciales válidas identificadas en 2022 seguían activas en 2026. No se trata de ventanas de exposición de horas o días: son años durante los cuales un atacante con acceso a esas credenciales mantiene una sesión potencialmente funcional.
Un dato adicional que merece atención operacional: el informe reporta 28,65 millones de nuevas credenciales expuestas en commits públicos de GitHub durante 2025, un incremento del 34% respecto al año anterior. Ocho de los diez tipos de secretos con mayor crecimiento están vinculados a servicios de IA, lo que refleja la expansión acelerada de integraciones con APIs de LLMs en el stack de desarrollo.
¿Por qué importa para Líderes de Ingeniería de Software?
La superficie de ataque creció sin que los controles crecieran igual. La adopción de herramientas de colaboración y ticketing está completamente integrada en cómo trabajan los equipos de ingeniería modernos. Jira, Confluence y Slack son de facto parte del flujo de trabajo de incidentes, onboarding, documentación técnica y debugging colaborativo. Pero casi ningún programa de seguridad de la cadena de suministro los trata como superficies de riesgo de secretos.
Los controles de SCM son necesarios pero no suficientes. Si un equipo tiene pre-commit hooks, escaneo en CI y políticas de bloqueo en el repositorio, pero no hay visibilidad sobre qué circula en el ticketing y la colaboración, el programa tiene un punto ciego estructural. Esto es relevante para cualquier organización que use Jira o Confluence en SaaS multi-tenant, donde el alcance de una exposición puede ir más allá del tenant propio.
La rotación de credenciales no es práctica estándar, y los números lo demuestran. Un 64% de retención de credenciales comprometidas durante cuatro años indica que los procesos de rotación y revocación, cuando existen, no están cerrando el ciclo correctamente. Para equipos con muchas integraciones de IA, donde las API keys se crean con frecuencia y se asignan a proyectos experimentales que luego se abandonan, este riesgo se multiplica.
El patrón documentado es replicable. El vector de ataque de acceso a credenciales de plataforma cloud vía ticket de soporte es un riesgo que aplica a cualquier organización que use GCP, AWS o Azure y maneje incidentes con herramientas de ticketing. No requiere sofisticación técnica elevada por parte del atacante.
Perspectiva a futuro
La tendencia de expansión de credenciales vinculadas a servicios de IA sugiere que el problema se agravará a medida que los equipos integren más APIs de LLMs, herramientas de agentes y servicios de embeddings en sus stacks. Cada nueva integración crea credenciales adicionales que pueden terminar documentadas informalmente en canales de colaboración.
Es razonable anticipar que los programas de DSPM (Data Security Posture Management) y las herramientas especializadas en detección de secretos ampliarán sus capacidades hacia fuentes no-SCM. Si un equipo está evaluando tooling en esta categoría, la cobertura de fuentes como Jira, Confluence y Slack debería ser un criterio de evaluación explícito, no un opcional.
La presión regulatoria sobre gestión de accesos y gestión de secretos también va en aumento en sectores como fintech. Equipos en esas industrias tienen razones adicionales para cerrar este punto ciego antes de que lo haga una auditoría.
Movimientos de pares
No hay datos verificados disponibles sobre cómo organizaciones de referencia específicas están respondiendo a este patrón particular. Lo que sí es observable en la industria es la adopción creciente de plataformas de gestión de secretos como HashiCorp Vault, AWS Secrets Manager o equivalentes, aunque la cobertura de fuentes de colaboración sigue siendo un área menos madura que la gestión de secretos en pipelines de CI/CD.
Lo que aún es incierto
Los datos del informe State of Secrets Sprawl 2026 provienen de GitGuardian, una empresa con producto comercial en detección de secretos. Las cifras son plausibles y el patrón es coherente con lo que se observa en la industria, pero no han sido verificadas de forma independiente para este artículo. El alcance exacto de los incidentes y patrones de ataque mencionados tampoco han sido confirmados por fuentes primarias adicionales.
El dato de 28,65 millones de credenciales expuestas en GitHub durante 2025 refleja lo que GitGuardian pudo detectar en commits públicos, no el universo completo de exposiciones. La cifra real podría ser mayor o tener distribuciones distintas a las reportadas.
Una pregunta para tu equipo
¿Tienen visibilidad sobre qué credenciales, tokens o claves API circulan activamente en sus tickets de Jira, páginas de Confluence y canales de Slack, y existe un proceso definido para revocarlas cuando se detectan?
Fuentes
- Elpais — El mayor error de seguridad ya no está en el código: así explotan los ciberdelincuentes las credenciales (Link)
