El estado de los secretos: por qué se filtraron 28 millones de credenciales en GitHub en 2025 y qué hacer al respecto

«¿Cómo gestiona tu empresa las claves de API?»

Esa fue la pregunta que se planteó a la comunidad de desarrolladores en Hacker News. Una de las respuestas más votadas fue una sola palabra: «mal».

Los datos lo confirman: el informe State of Secrets Sprawl 2026 de GitGuardian reveló que tan solo en 2025 se agregaron 28.65 millones de secretos nuevos codificados directamente en repositorios públicos de GitHub, un aumento del 34 % respecto al año anterior. El informe de seguridad de GitHub contabilizó 39 millones de filtraciones de secretos en 2024. Un estudio académico publicado en IEEE S\&P 2025 analizó más de 80 millones de archivos y encontró que hasta el 30 % de los proyectos están en riesgo.

Este patrón se repite en todos los niveles de experiencia y tamaños de organización. Analizaremos las consecuencias legales y financieras que han tenido las filtraciones de credenciales de este tipo.

Esta guía integral explica por qué se filtran las credenciales, qué herramientas existen para detectar y prevenir las filtraciones, y cómo crear una defensa práctica por capas. Tanto si eres un desarrollador independiente que intenta limpiar sus archivos .env como si formas parte de un equipo de seguridad que implementa análisis en toda una organización, aquí encontrarás algo útil.

¿Qué se considera un «secreto»?

Un secreto es cualquier dato que permite acceder a un sistema o recurso. Los ejemplos más obvios son las claves de API, las contraseñas de bases de datos y las claves privadas SSH. Pero la definición se ha ampliado considerablemente:

• Credenciales de IAM en la nube (claves de acceso de AWS, JSON de cuentas de servicio de GCP, secretos de cliente de Azure)

• Tokens de OAuth y tokens de actualización

• URL de webhook (que suelen incluir autenticación integrada)

• Cadenas de conexión (bases de datos, colas de mensajes, cachés)

• Claves de cifrado y certificados de firma

• Claves de API de servicios de IA (OpenAI, Anthropic, Hugging Face, DeepSeek)

• Tokens de configuración de servidores MCP (una categoría que crece rápidamente; más adelante hablaremos de ella)

La guía de OWASP sobre gestión de secretos ofrece una taxonomía detallada. La clave es entender que cualquier dato que una máquina use para autenticarse es un secreto, y que las aplicaciones modernas implican la comunicación entre muchas máquinas.

Cómo se filtran los secretos

Entender cómo quedan expuestos los secretos es el primer paso para prevenirlo. A partir de conversaciones de la comunidad, investigaciones académicas y datos del sector, estas son las vías más comunes.

Commits accidentales

Este es el escenario más común: durante el desarrollo, un desarrollador agrega credenciales al código fuente («solo para probar») y confirma el archivo en el control de versiones. Aunque el secreto se elimine en un commit posterior, permanece indefinidamente en el historial de git. El modelo de datos de solo anexado de Git significa que git rm no elimina nada realmente. Los atacantes pueden —y suelen— analizar todo el historial de los repositorios públicos.

Un caso real de un hilo en r/aws: un equipo incorporó claves de acceso de IAM con permisos completos de S3 Delete directamente en JavaScript del frontend. En cuestión de días, un actor desconocido borró sus buckets de S3.

El problema de los archivos .env

Los archivos .env son una comodidad para el desarrollo que se ha confundido ampliamente con una barrera de seguridad. Nunca se diseñaron para eso. Sus riesgos están bien documentados:

• Los archivos .env se confirman por accidente cuando los desarrolladores usan git add . en lugar de agregar los archivos por nombre

• Se comparten por Slack, mediante capturas de pantalla o aplicaciones de notas, o se pegan en ChatGPT para pedir ayuda con la depuración

• Se incorporan a imágenes de Docker por usar sin cuidado las directivas COPY . .

El canal SnykSec de Snyk abordó este tema en profundidad:

Play Video: YouTube Video: pcbRwwaCPUg

Por qué no conviene guardar secretos en archivos .env. Presenta alternativas prácticas con Doppler y 1Password CLI para inyectar secretos en tiempo de ejecución.

El video explica ataques a la cadena de suministro que apuntan específicamente a archivos .env (paquetes NPM comprometidos como tinyColor y ngx-bootstrap) y luego muestra cómo reemplazar los archivos .env estáticos con la inyección de secretos en tiempo de ejecución mediante Doppler y el comando op run de 1Password CLI.

La vía de la cadena de suministro

Los paquetes maliciosos que roban credenciales de entornos de desarrollo no son una posibilidad hipotética. Snyk ha seguido varios incidentes reales:

• El gusano Shai-Hulud para NPM se diseñó para buscar y exfiltrar tokens de NPM y GitHub a gran escala

• El compromiso de tinyColor/ngx-bootstrap incorporó malware para robar credenciales en paquetes con millones de descargas semanales

• En un caso especialmente notable, los atacantes convirtieron TruffleHog en un arma y lo usaron como carga maliciosa en un paquete NPM comprometido (@ctrl/tinycolor, 2.2 millones de descargas semanales). Usaron las propias capacidades de análisis de la herramienta de seguridad para encontrar y extraer secretos.

Las superficies fuera del código

La investigación de GitGuardian muestra que el 28 % de los incidentes con credenciales se origina completamente fuera de los repositorios de código. Los secretos se filtran a través de:

• Mensajes de Slack (el 2.4 % de los canales contiene al menos un secreto filtrado)

• Tickets de Jira (el 6.1 % expone credenciales, a menudo en registros de informes de errores)

• Páginas de Confluence (documentación con cadenas de conexión)

• Imágenes de Docker Hub (se encontraron credenciales integradas en más de 10,000 imágenes)

• Plataformas de formato de código (desarrolladores que pegan código en formateadores en línea)

• Prepublicaciones de arXiv (se encontraron miles de claves de API en la nube en archivos fuente LaTeX, según Dubniczky et al., 2025)

El factor del desarrollo asistido por IA

Esta es la vía de filtración que más rápido crece. El informe de GitGuardian de 2026 reveló que los commits asistidos por IA filtran secretos a una tasa del 3.2 %, aproximadamente el doble de la tasa de referencia. Varios factores contribuyen a esto:

• Las herramientas de programación con IA pueden generar código funcional que incluye credenciales codificadas directamente

• Las funciones de autocompletado de código pueden memorizar y volver a emitir credenciales de los datos de entrenamiento (Huang et al., 2023, 39 citas)

• Un incidente de 2024 reveló que Cursor (editor de código con IA) enviaba el contenido de los archivos .env a sus servidores para completar pestañas, incluso cuando los archivos estaban incluidos en .cursorignore

• Las herramientas neuronales de autocompletado de código no entienden por sí solas qué constituye un secreto.

Las credenciales de servicios de IA son la categoría de secretos filtrados que más rápido crece, con un aumento interanual del 81 % en 2025. Entre los tipos que más se filtran están los tokens de Hugging Face, las claves de Azure OpenAI y las credenciales de Weights & Biases. Solo en 2025 se detectaron 113,000 claves de API de DeepSeek.

El problema de las credenciales de MCP

Si trabajas con servidores de Model Context Protocol (MCP), debes tener en cuenta una nueva superficie de credenciales. GitGuardian encontró 24,008 secretos únicos en archivos de configuración relacionados con MCP en GitHub público, de los cuales 2,117 siguen siendo válidos.

La causa principal es reveladora: la documentación oficial de inicio rápido de MCP suele mostrar claves de API codificadas directamente en los ejemplos de configuración. Los desarrolladores copian estos patrones, reemplazan los marcadores de posición por sus claves reales y confirman el archivo de configuración. El ecosistema de MCP crece rápidamente y este patrón se propaga al mismo ritmo.

Snyk ha escrito ampliamente sobre cómo proteger los servidores MCP y los riesgos del panorama de desarrollo con IA agéntica. Las investigaciones sobre servidores MCP maliciosos y filtraciones de credenciales en los ecosistemas de Agent Skills aportan más contexto: las herramientas que usamos para crear aplicaciones de IA también se están convirtiendo en vías de exposición de credenciales.

Play Video: YouTube Video: wIvoefvBpWE

El secreto para crear código de IA seguro. Cómo se integra Snyk en los flujos de trabajo de desarrollo con IA para detectar problemas de seguridad en el código generado.

SAST y análisis de secretos: relacionados, pero distintos

Una de las confusiones más frecuentes en las comunidades de desarrolladores es pensar que una herramienta SAST (pruebas de seguridad de aplicaciones estáticas) también cubre el análisis de secretos. Son disciplinas complementarias, pero distintas, y conviene entender la diferencia.

Las herramientas SAST, como Snyk Code, analizan el código fuente para detectar vulnerabilidades de seguridad, como fallas de inyección, deserialización insegura, evasiones de autenticación y otros problemas similares en el código. Por lo general, analizan el árbol de trabajo (el estado actual de los archivos).

Las herramientas especializadas en el análisis de secretos tienen un alcance distinto: analizan el historial completo de git, incluidos todos los commits, todas las ramas y todos los archivos eliminados que aún existen en el almacén de objetos. Esto importa porque:

1. Un secreto confirmado en un commit y eliminado en el siguiente sigue existiendo en el historial de git

2. Unir commits no elimina los datos «colgantes» a los que se puede acceder mediante el hash SHA-1

3. Los archivos eliminados siguen siendo analizables en archivos .pack

4. Un informe de un programa de recompensas por errores documentó $64,000 obtenidos únicamente al analizar archivos eliminados y blobs colgantes en repositorios públicos.

En la práctica, las organizaciones se benefician de ambas opciones: SAST para las vulnerabilidades de seguridad en el código y herramientas de análisis especializadas para detectar la exposición de credenciales. Cada una aborda superficies de riesgo distintas. Como dijo un profesional en r/devsecops: «Una herramienta de análisis de secretos también busca secretos en el historial de git, lo que puede llevar tiempo según el tamaño de tus repositorios».

Panorama de las herramientas de análisis de secretos

El ecosistema de código abierto para analizar secretos ha madurado considerablemente. Este es el panorama en 2026, con una evaluación honesta de las fortalezas y limitaciones de cada herramienta.

TruffleHog

TruffleHog (\~25,300 estrellas, Go, AGPL-3.0) fue creado por Dylan Ayrey en 2016 y ahora lo mantiene Truffle Security Co., que recaudó $25M en una ronda de financiamiento Serie B en noviembre de 2025.

Una función destacada es la verificación de credenciales en vivo. Además de buscar coincidencias con reglas de expresiones regulares, TruffleHog puede validar activamente las credenciales detectadas mediante las API de los proveedores para confirmar si siguen activas. Esto puede reducir considerablemente los falsos positivos. La herramienta incluye más de 800 detectores y una opción --only-verified que filtra los resultados para mostrar solo las credenciales confirmadas como activas.

TruffleHog analiza el historial de git, buckets de S3, organizaciones de GitHub/GitLab (incluidos issues, solicitudes de incorporación de cambios y comentarios), imágenes de Docker, Jira, Confluence, Slack y Syslog, y cubre una amplia variedad de superficies donde pueden aparecer credenciales.

Limitaciones: La licencia AGPL-3.0 es un impedimento documentado para su adopción empresarial; varios hilos de Hacker News y Reddit señalan que los equipos legales podrían rechazarla. TruffleHog también consume muchos recursos en análisis grandes y es más lento que las alternativas que solo usan expresiones regulares.

Gitleaks

Gitleaks (\~25,700 estrellas, Go, MIT) es una de las herramientas de código abierto para analizar secretos más utilizadas. Creada por Zach Rice, ofrece análisis rápidos y configurables mediante reglas personalizadas basadas en TOML.

Gitleaks destaca por su velocidad y capacidad de configuración. Es ideal para hooks pre-commit, donde la latencia de milisegundos es importante. La licencia MIT facilita su adopción empresarial.

La desventaja son los falsos positivos. Gitleaks usa coincidencias de expresiones regulares sin verificación en vivo, por lo que marcará patrones que parecen secretos, pero no lo son. Los profesionales de r/devsecops recomiendan constantemente ejecutar primero Gitleaks en modo de referencia y ajustar los falsos positivos sin conexión antes de habilitarlo como una verificación que bloquea el proceso. La regla generic-api-key es una fuente de ruido especialmente común.

Cabe destacar que el propio Zach Rice (u/Phorcez) ha reconocido esta desventaja: «Gitleaks es ligero, rápido y muy configurable, pero no hace verificaciones. Para verificar, puedes usar algo como TruffleHog o, mejor aún, TruffleHog Enterprise».

Otros analizadores destacados

• Nosey Parker (2,300 estrellas, Rust, Apache 2.0). Creado por la empresa de pruebas de penetración Praetorian. Usa un algoritmo de entropía de cadenas que se considera superior a las expresiones regulares por sí solas para detectar secretos genéricos. Rápido y basado en Rust.

• Kingfisher (876 estrellas, Rust, Apache 2.0). La propuesta de MongoDB para 2025, que afirma ser entre 2 y 5 veces más rápido que Gitleaks. Agrega verificación en vivo y mapeo del radio de impacto (¿a qué tiene acceso realmente una clave filtrada?). Es un fork de Nosey Parker. Usa tree-sitter para analizar el contexto según el lenguaje. La función de radio de impacto es realmente novedosa.

• git-secrets (13,200 estrellas, Shell, Apache 2.0). Hook ligero basado en bash de AWS Labs. Se enfoca en credenciales de AWS y se considera que ya cumplió su propósito.

• ggshield (1,900 estrellas, Python, MIT). CLI de GitGuardian con más de 500 tipos de secretos, respaldado por una plataforma comercial. En marzo de 2026 agregó hooks para asistentes de programación con IA, con soporte para Cursor y Claude.

• Talisman (2,100 estrellas, Go, MIT). De ThoughtWorks. Se instala como hook global de git en todos los repositorios, ideal para aplicar políticas en toda la organización.

• ripsecrets (900 estrellas, Rust, MIT). Hook de precommit rápido y enfocado, con una baja tasa de falsos positivos gracias a sus reglas conservadoras.

Qué dicen los estudios comparativos académicos

Investigadores de la Universidad Estatal de Carolina del Norte publicaron el primer estudio comparativo riguroso de herramientas de detección de secretos con su conjunto de datos SecretBench (97,479 instancias etiquetadas de 818 repositorios). Los resultados son reveladores:

• Gitleaks: 88 % de exhaustividad (la más alta), 46 % de precisión

• GitHub Secret Scanner: 75 % de precisión (la más alta), menor exhaustividad

• TruffleHog: 52 % de exhaustividad, precisión intermedia

• Coincidencia entre herramientas: solo 76 % entre los verdaderos positivos de ggshield y TruffleHog. Solo 18 % entre ggshield y Gitleaks.

El equipo de investigación recomienda explícitamente combinar varias herramientas, ya que ninguna de las analizadas detectó todos los tipos de secretos. Estos datos respaldan el enfoque por capas.

El enfoque emergente basado en LLM

FuzzingLabs comparó la detección de secretos basada en LLM con herramientas tradicionales en bases de código reales. Estos fueron los resultados: GPT-5-mini alcanzó una exhaustividad del 84.4 %, frente al 37.5 % de Gitleaks. La investigación académica confirma esta tendencia: modelos de código abierto ajustados (LLaMA-3.1 8B, Mistral-7B) alcanzaron puntuaciones F1 de 0.985 en el conjunto de datos SecretBench.

Los LLM pueden detectar patrones que las herramientas basadas en expresiones regulares suelen pasar por alto, como secretos divididos (cuando una clave se concatena a partir de varias variables), tokens ofuscados, variables decodificadas y credenciales comentadas. Es probable que esta sea la próxima ola de herramientas de detección.

Una nota para quienes mantienen proyectos de código abierto

Muchas de las herramientas de este artículo son proyectos de código abierto, y el ecosistema de herramientas para la gestión de credenciales sigue creciendo. Si mantienes un proyecto de código abierto en este ámbito (o en cualquier otro), el Programa para desarrolladores seguros de Snyk ofrece análisis de seguridad gratuito de nivel empresarial, que incluye SAST, SCA, análisis de contenedores e IaC, para los proyectos de código abierto que cumplan los requisitos. Es una forma de aplicar a las propias herramientas la misma seguridad por capas que hemos explicado.

Herramientas de gestión de secretos: ¿dónde deben almacenarse?

Detectar secretos filtrados resuelve una parte del problema. La otra consiste en garantizar que los secretos se almacenen y distribuyan de forma segura desde el principio.

HashiCorp Vault

Vault (35,300 estrellas) sigue siendo el estándar empresarial para la gestión de secretos. Su característica más destacada son los secretos dinámicos, que generan credenciales de corta duración a pedido en lugar de almacenar credenciales de larga duración. Vault también ofrece cifrado como servicio, PKI y firma de certificados SSH.

Dos aspectos importantes que considerar: la licencia de Vault cambió de MPL a BSL 1.1 en 2023, lo que impulsó el interés por el fork comunitario OpenBao. Además, IBM adquirió HashiCorp por aproximadamente 6,400 millones de dólares, por lo que Vault ahora forma parte de la plataforma de IBM.

Los profesionales señalan que Vault es potente, pero complejo. Una observación reveladora de r/devops: «alrededor de 2/3 de los clientes que lo implementaron [Vault] por su cuenta lo hicieron mal y, en realidad, gestionan los secretos con una seguridad equivalente o menor que si no usaran nada». Vault funciona mejor cuando se trata como un asunto de infraestructura con soporte operativo especializado.

Infisical

Infisical (25,600 estrellas, MIT) es la plataforma de gestión de secretos de código abierto que más rápido está creciendo. Integra la gestión y el análisis de secretos, así como PKI, en un solo producto con lanzamientos diarios. YC W23. Disponible en la nube o para autohospedaje.

Desde el cambio de licencia BSL de Vault, las conversaciones de la comunidad reflejan un interés creciente en alternativas con licencia MIT. Infisical ofrece funciones empresariales (RBAC, registros de auditoría, separación de entornos y operador de Kubernetes) y mantiene una licencia de código abierto. Se menciona con frecuencia junto a Vault y Doppler en las conversaciones de la comunidad de 2024-2025.

SOPS

SOPS (21,300 estrellas, MPL 2.0) adopta un enfoque distinto: cifra los secretos directamente en archivos YAML, JSON o ENV y permite confirmar los archivos cifrados en Git. Los nombres de las claves siguen siendo legibles (algo importante para las diferencias y el linting), mientras que los valores se cifran mediante AWS KMS, GCP KMS, Azure Key Vault o age.

SOPS aparece con frecuencia en conversaciones sobre flujos de trabajo de GitOps y es una recomendación habitual en los hilos sobre «¿cómo gestionan los secretos?». Combinado con direnv para el desarrollo local, es una opción práctica para los equipos que quieren guardar secretos de forma segura en el control de versiones.

Otras herramientas de gestión

• Doppler: SaaS comercial que se recomienda con frecuencia en conversaciones recientes de la comunidad. Gestión de secretos sin infraestructura, con separación de entornos.

• 1Password CLI (op run): Inyecta secretos durante la ejecución sin escribirlos en el disco. La autenticación biométrica (solicitud de Touch ID antes de inyectar un secreto) mejora significativamente la seguridad frente a los archivos estáticos.

• dotenvx (5,300 estrellas): Del creador del dotenv original. Los archivos .env.vault cifrados conectan los patrones sencillos de desarrollo con una gestión de secretos adecuada.

• External Secrets Operator (6,500 estrellas): El estándar de facto de Kubernetes para sincronizar secretos desde más de 30 servicios externos.

Cómo crear una defensa por capas: guía práctica

Ninguna herramienta ni práctica por sí sola evita todas las filtraciones de credenciales. El consenso de la industria, reflejado en Reddit, Hacker News, OWASP y la investigación académica, apunta a una defensa por capas:

Capa 1: Hooks de precommit (detectar antes de confirmar cambios)

Instala una herramienta de análisis de secretos (como Gitleaks, ggshield o TruffleHog) como hook de precommit. Así obtendrás la respuesta más rápida y detectarás la mayoría de las confirmaciones accidentales.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.1
    hooks:
      - id: gitleaks

Importante: Los hooks de precommit del lado del cliente se pueden omitir (--no-verify). Para aplicar controles más sólidos, implementa hooks pre-recepción del lado del servidor que bloqueen, a nivel del repositorio, los envíos que contengan secretos.

Cuando implementes el análisis por primera vez, usa el modo de referencia: analiza todo el historial del repositorio, reconoce los hallazgos existentes y, a partir de ahí, alerta solo sobre secretos nuevos. Así evitarás que la fatiga por falsos positivos perjudique la adopción.

Capa 2: Análisis de CI/CD (detectar lo que no detectó el precommit)

Agrega un paso de análisis a tu pipeline de CI. Las herramientas que permiten verificar credenciales (como la opción --only-verified de TruffleHog) pueden reducir el ruido al confirmar si las credenciales detectadas siguen activas:

# Example using TruffleHog
trufflehog git file://. --only-verified --fail

Esta capa detecta secretos que eludieron los hooks de precommit (hooks desactivados, confirmaciones combinadas, envíos forzados y contribuciones desde forks).

Capa 3: Bóveda centralizada de secretos (eliminar el origen de las filtraciones)

Deja de guardar secretos en archivos .env, variables de entorno y archivos de configuración. Usa un administrador de secretos dedicado para inyectarlos durante la ejecución:

• Entornos AWS: AWS Secrets Manager o SSM Parameter Store con roles de IAM

• Multinube: Vault, Infisical o Doppler

• Kubernetes: External Secrets Operator para sincronizar secretos desde la bóveda que elijas

• Equipos pequeños: SOPS + age para configuración cifrada, o dotenvx para cifrar .env

El administrador de secretos debe ser la única fuente de verdad, no una copia adicional junto a secretos que siguen en archivos .env, variables de CI y wikis del equipo.

Capa 4: OIDC para CI/CD (eliminar por completo las credenciales estáticas)

Un cambio de arquitectura que vale la pena evaluar: reemplazar las credenciales estáticas de CI/CD por identidad federada basada en OIDC.

# GitHub Actions example - no stored AWS credentials
permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-arn: arn:aws:iam::123456789:role/deploy
      aws-region: us-east-1

Este patrón usa el proveedor OIDC de GitHub para solicitar credenciales de AWS de corta duración mediante AssumeRoleWithWebIdentity. No se almacenan claves de acceso de IAM en ningún sitio. El consenso de la comunidad en Hacker News y r/devops es claro: las credenciales estáticas en GitHub Secrets ya son una práctica anticuada.

Play Video: YouTube Video: 5xngh29yx9A

Capa 5: Análisis periódico del historial completo (detectar filtraciones antiguas)

Programa análisis periódicos de todo el historial de repositorios de tu organización. Así detectarás:

• Secretos confirmados antes de implementar el análisis

• Secretos en confirmaciones eliminadas y objetos git sin referencias

• Repositorios antiguos que pasaron de privados a públicos

Varias herramientas permiten analizar toda la organización. Por ejemplo, TruffleHog puede analizar una organización completa de GitHub:

trufflehog github --org=your-org --only-verified

Capa 6: Diseño del formato de los tokens (hacer que los secretos se identifiquen por sí mismos)

Si estás creando API, diseña tus tokens para que puedan identificarse. El rediseño del formato de tokens de GitHub en 2021 (con prefijos conocidos como ghp_ y sumas de verificación integradas) mejoró considerablemente la precisión del análisis. El prefijo sk_live_ de Stripe es el ejemplo clásico.

Los tokens que se identifican por sí mismos multiplican la eficacia de todas las herramientas de análisis del ecosistema. Un gerente de producto de GitHub instó explícitamente a todos los proveedores de servicios a adoptar este patrón.

Cuando se filtran secretos: respuesta a incidentes

Incluso con todas las capas implementadas, ocurren filtraciones. Protocolo de respuesta:

1. Rota la credencial de inmediato. No lo debatas ni investigues primero. Revoca la credencial y genera una nueva. Los bots de detección automatizada analizan la API de GitHub a los pocos minutos de un push público.

2. Revisa los registros de auditoría. Revisa CloudTrail, GCP Audit Logs o el equivalente para detectar cualquier uso no autorizado de la credencial expuesta.

3. Evalúa el radio de impacto. ¿A qué acceso daba la credencial? ¿Qué datos podrían haberse consultado?

4. Limpiar el historial es secundario. Usa git filter-repo o BFG Repo-Cleaner para eliminar el secreto del historial de git si el cumplimiento normativo lo exige. Rotar la credencial aborda el riesgo de seguridad, mientras que limpiar el historial responde a requisitos de cumplimiento e higiene. Una vez que un secreto se hace público, aunque sea por poco tiempo, debe considerarse comprometido, independientemente de que se limpie el historial.

El consenso entre profesionales en r/devsecops: rota el secreto (así el historial deja de ser un riesgo) y no limpies el historial salvo que el cumplimiento normativo lo exija. Algunas organizaciones incluso dejan las credenciales rotadas en el historial como señuelo para detectar intrusiones.

La realidad legal: las filtraciones de credenciales tienen consecuencias

El panorama legal en torno a la seguridad de las credenciales ha evolucionado considerablemente. Estos casos muestran por qué su gestión es una prioridad empresarial:

United States v. Sullivan (9th Cir. 2025). El director de seguridad de Uber fue condenado penalmente por obstrucción de la justicia y encubrimiento de un delito grave al ocultar una brecha causada por credenciales de AWS codificadas directamente en repositorios de GitHub. Los atacantes encontraron las credenciales y accedieron a almacenamiento S3 que contenía datos de 57 millones de usuarios. El equipo de Sullivan les pagó 100,000 dólares a través del programa de recompensas por errores sin revelar la brecha. El Noveno Circuito confirmó la condena, sentando precedente de que los ejecutivos enfrentan responsabilidad penal personal por ocultar brechas causadas por credenciales.

Capital One (2022). Un exingeniero de AWS explotó una vulnerabilidad SSRF para robar credenciales de metadatos de IAM en la nube, lo que le permitió acceder a los datos de aproximadamente 100 millones de clientes. La demanda colectiva civil terminó en un acuerdo de 190 millones de dólares.

Medidas de cumplimiento de la FTC. Tras FTC v. Wyndham (3d Cir. 2015) (73 citas), los acuerdos de consentimiento de la FTC ahora suelen exigir programas obligatorios de rotación de credenciales, análisis de secretos en repositorios de código y la prohibición de incluir credenciales directamente en el código fuente. La FTC ha llegado a acuerdos en acciones de cumplimiento con Uber, Meta y otras empresas por fallas en la seguridad de las credenciales.

SEC v. SolarWinds (S.D.N.Y., 2023). La SEC presentó cargos en los que alegaba que SolarWinds había tergiversado ante los inversionistas sus prácticas reales de gestión de secretos. Las principales acusaciones superaron una desestimación parcial, lo que extendió la responsabilidad por filtraciones al ámbito de la legislación sobre valores.

La filtración de datos de Equifax, originada por fallas en las credenciales y los controles de acceso, derivó en un acuerdo de USD 700 millones con la FTC, el mayor acuerdo por seguridad de datos en la historia de la FTC.

6 principios clave

Estas observaciones se basan en OWASP, investigaciones académicas y debates entre profesionales:

1. Los repositorios privados contienen más secretos que los públicos. GitGuardian descubrió que los repositorios privados tienen 6 veces más probabilidades de contener secretos codificados que los públicos. Los repositorios privados se clonan, se bifurcan, los contratistas acceden a ellos y, en ocasiones, se hacen públicos.

2. Los secretos incluidos en un commit permanecen en el historial de Git, aunque se eliminen en el siguiente commit o el repositorio sea privado. El modelo de datos de Git, en el que solo se agregan datos, implica que toda credencial incluida en un commit debe considerarse expuesta.

3. La cobertura de las herramientas varía. Los estudios comparativos académicos muestran solo entre un 18 % y un 76 % de coincidencia entre los conjuntos de verdaderos positivos de las herramientas. Ejecutar varias herramientas en distintas capas mejora la cobertura.

4. Rotar las credenciales reduce el riesgo; limpiar el historial ayuda a cumplir con las normas. Revocar la credencial hace que el historial de Git deje de ser peligroso. Limpiar el historial sin rotar la credencial no lo hace.

5. La detección por sí sola tiene un valor limitado si no se toman medidas. El 64 % de los secretos filtrados en 2022 seguía activo en 2026. Las organizaciones que detectan las filtraciones, pero no las corrigen, mantienen el mismo riesgo subyacente.

6. Las estaciones de trabajo de los desarrolladores son una superficie de ataque cada vez mayor. Los ataques a la cadena de suministro, las herramientas de codificación con IA que acceden a archivos y las inyecciones de prompts dirigidas a servidores MCP crean vías para extraer credenciales de los equipos locales. La investigación de Snyk sobre agentes de codificación con IA armados analiza esta superficie de ataque emergente.

Por dónde empezar

La defensa por capas descrita anteriormente puede parecer difícil de implementar de una sola vez. La buena noticia es que cada capa aporta valor por sí misma y puedes adoptarlas gradualmente.

• Empieza por obtener visibilidad: Antes de corregir las filtraciones de credenciales, necesitas saber dónde están. Agrega un hook de análisis previo a la confirmación (herramientas como Gitleaks, ggshield y TruffleHog lo admiten) para detectar nuevas filtraciones y, luego, ejecuta un análisis en toda la organización con verificación de credenciales para conocer tu nivel actual de exposición. Si ya usas Snyk Code para SAST, combinarlo con un análisis especializado de secretos ayuda a cubrir tanto las vulnerabilidades en el código como la exposición de credenciales.

• Audita tus .env archivos y secretos de CI/CD: Comprueba si hay credenciales reales en el control de versiones, incluso en repositorios privados. Rota las que se hayan confirmado. Revisa tus pipelines de CI/CD en busca de credenciales estáticas que puedan reemplazarse por una identidad federada basada en OIDC.

• Evalúa tu enfoque para gestionar secretos. Si tu equipo todavía comparte credenciales mediante archivos .env o configura manualmente las variables de entorno, explora opciones centralizadas como Infisical, Vault o Doppler, que inyectan secretos durante la ejecución.

• Protege tus flujos de trabajo de desarrollo con IA: Si tu equipo usa asistentes de codificación con IA o servidores MCP, revisa esas configuraciones para detectar credenciales codificadas. La integración de Snyk con servidores MCP puede analizar código generado por IA en tiempo real, y Snyk Open Source ayuda a detectar dependencias comprometidas antes de que lleguen a tu base de código (la misma vía de la cadena de suministro que distribuye malware que roba credenciales).

• Fomenta la concientización en la organización: Tanto las herramientas como las prácticas del equipo contribuyen a una gestión eficaz de las credenciales. La plataforma de seguridad para desarrolladores de Snyk integra SAST, SCA, seguridad de contenedores y análisis de IaC en los flujos de trabajo de desarrollo, para ofrecer a los equipos una visión unificada de su postura de seguridad. Cuando los desarrolladores pueden ver los problemas de seguridad en las herramientas que ya usan, la adopción se da de forma natural.

La respuesta más votada en HN fue sincera. Muchas organizaciones gestionan mal sus credenciales. Pero las herramientas, las prácticas y el conocimiento de la comunidad para hacerlo mejor nunca habían sido tan accesibles.

¿Están preparadas tus aplicaciones de Python para el aumento de filtraciones de secretos impulsadas por IA y los riesgos de exposición de credenciales que se destacan arriba? Descarga el whitepaper La crisis de seguridad de la IA en tu entorno de Python para descubrir cómo los equipos líderes protegen los flujos de trabajo de desarrollo con IA.