El estado de la dispersión de secretos en 2026: hallazgos clave del informe de GitGuardian

En 2025, GitGuardian detectó 28,65 millones de nuevos secretos codificados en commits públicos de GitHub. Esto representa un aumento del 34% respecto al año anterior y el mayor incremento anual jamás registrado por la empresa. Esa cifra cubre únicamente repositorios públicos. El panorama completo, una vez incluidos los sistemas internos, herramientas de colaboración e infraestructura autoalojada, es considerablemente peor.

Tres temas atraviesan los datos:

1. El desarrollo asistido por IA ha pasado de ser experimental a ser la norma, acelerando la filtración de credenciales en cada capa del stack.
2. Los sistemas internos están mucho más expuestos de lo que la mayoría de las organizaciones suponen: los repositorios privados, canales de Slack e instancias autoalojadas de GitLab conllevan un riesgo significativo de credenciales.
3. La remediación sigue siendo el fallo crítico de la industria: el 64% de los secretos confirmados como válidos en 2022 seguían siendo explotables en enero de 2026, cuatro años después de su primera filtración.

Este artículo analiza cada hallazgo con los datos y el contexto que los equipos de TI y seguridad necesitan para impulsar el cambio internamente.

Conclusiones clave

• La IA es el principal impulsor de la exposición de credenciales. Ocho de los diez tipos de secretos filtrados con mayor crecimiento están vinculados a servicios de IA. La infraestructura LLM se filtra 5× más rápido que los proveedores de modelos principales.
• Los repositorios internos tienen 6× más probabilidad de contener un secreto codificado que los públicos. «Privado» no es un control de seguridad.
• Una cuarta parte de todos los incidentes internos se originan fuera del código fuente. Slack, Jira y Confluence representan el 28% de las filtraciones — con una tasa de severidad crítica mayor que los hallazgos basados en código.
• La remediación es el factor limitante de la industria. El 64% de los secretos confirmados como válidos en 2022 seguían siendo explotables en enero de 2026.
• La priorización solo por validación omite el 46% de los secretos críticos. Las credenciales genéricas — claves privadas, tokens personalizados, contraseñas — no pueden validarse automáticamente pero causan la mitad de todos los incidentes críticos.
• Las estaciones de trabajo de desarrolladores y los runners de CI/CD son una superficie de ataque subestimada. El ataque Shai-Hulud 2 encontró 294.842 ocurrencias de secretos en 6.943 máquinas comprometidas; el 59% eran runners de CI/CD.
• Los contratistas externos son un vector de secretos sin control. GitGuardian encontró 1.834 incidentes críticos en 13 firmas de consultoría, afectando potencialmente a 1.203 organizaciones cliente.
• Los archivos de configuración MCP son una nueva superficie de filtración en gran medida no monitoreada. En 2025, 24.008 secretos únicos fueron expuestos en configuraciones relacionadas con MCP en GitHub público — el 8,8% confirmados como válidos en el momento de la detección.

¿Qué tan grande es el problema de la dispersión de secretos en 2025?

La dispersión de secretos es la proliferación descontrolada de credenciales codificadas (claves API, contraseñas, tokens y certificados) a través de bases de código, archivos de configuración y herramientas de colaboración. Desde 2021, los secretos filtrados en GitHub público han crecido un 152%, mientras que la población de desarrolladores creció un 98%. La brecha se amplía cada año, y 2025 produjo el mayor incremento de volumen anual registrado.

Escala en números

La escala del problema es estructural. Más personas escriben más código, integran más servicios de terceros y generan más credenciales que pueden filtrarse.

Una métrica se mantuvo estable: los secretos por repositorio. La densidad permaneció aproximadamente igual, lo que sugiere que Push Protection de GitHub está cumpliendo su función de capturar credenciales comunes antes de que se hagan públicas. Pero el control de densidad no puede detener el crecimiento del volumen. Cuando el número total de commits se cuadruplica, incluso una tasa de filtración estable por repositorio produce un número récord de credenciales expuestas.

Cómo la IA está impulsando una nueva generación de secretos filtrados

El desarrollo asistido por IA ha reconfigurado qué secretos se filtran, con qué rapidez se acumulan y dónde terminan. Ocho de los diez tipos de secretos filtrados con mayor crecimiento interanual están vinculados a servicios de IA. El auge de la infraestructura de IA es el principal impulsor de la exposición de credenciales en este momento.

El auge de la infraestructura de IA

En 2025, GitGuardian detectó 1.275.105 secretos pertenecientes a servicios de IA — un aumento del 81% respecto a 2024.

Detectores específicos con mayor crecimiento (relacionados con IA):

La tendencia más significativa es qué se está filtrando más allá de los propios proveedores de modelos. La infraestructura LLM (la capa de orquestación, recuperación y almacenamiento que rodea a los modelos principales) se filtra 5× más rápido que los proveedores de modelos. Solo Supabase ahora se ubica entre los 20 secretos más filtrados en general, con más de 248.600 ocurrencias.

El patrón es consistente: los desarrolladores que construyen aplicaciones impulsadas por IA conectan un modelo a una capa de recuperación, una herramienta de orquestación, una base de datos vectorial, un rastreador de experimentos y un servicio de monitoreo. Cada integración añade una nueva credencial. Cada credencial es una filtración potencial.

A medida que emergen nuevos proveedores de IA, hay un retraso inevitable antes de que la cobertura de detección se ponga al día. Push Protection de GitHub se enfoca en patrones conocidos. Los proveedores nuevos pasan desapercibidos. Para cuando se construye un detector, miles de claves pueden ya ser públicas.

Claude Code y los commits asistidos por IA filtran secretos al doble de la tasa base

Claude Code de Anthropic pasó de 22 commits coautorados en enero de 2025 a 2,16 millones en diciembre. Durante todo el año:

• Los commits asistidos por Claude Code = 0,4% de todo lo escaneado públicamente
• Los commits asistidos por Claude Code = 0,9% de todas las filtraciones
• Tasa de filtración: 3,2% vs. 1,5% de referencia en todos los commits públicos de GitHub

Tasa de filtración de Claude Code durante 2025:

Los commits de Claude Code también fueron consistentemente más grandes — aproximadamente 2× las líneas de código por commit desde abril en adelante. Los commits más grandes significan más superficie de exposición de credenciales en una sola revisión.

El matiz importante: el desarrollador mantiene el control de cada commit. Los asistentes de codificación con IA son herramientas. La tasa de filtración elevada refleja decisiones humanas — descuido, presión de tiempo o decisiones deliberadas de ignorar advertencias — no comportamiento autónomo de la IA.

La conclusión para los equipos de seguridad: trate los conjuntos de cambios generados por IA como unidades de revisión de mayor impacto, mantenga el escaneo automatizado en el flujo de trabajo del desarrollador y mantenga la remediación lo suficientemente rápida para que un secreto filtrado no permanezca válido el tiempo suficiente para ser explotado.

24.000 secretos en archivos de configuración MCP

¿Qué es MCP? Model Context Protocol es el estándar que surgió a principios de 2025 para conectar modelos de lenguaje grandes con herramientas y fuentes de datos externas. Cuando un desarrollador quiere que su agente de IA consulte una base de datos, busque en la web o interactúe con una plataforma SaaS, MCP maneja la conexión — y esas conexiones requieren credenciales.

Hallazgos clave:

• 24.008 secretos únicos expuestos en archivos de configuración relacionados con MCP en GitHub público en 2025
• 2.117 confirmados como válidos (8,8%) en el momento de la detección

Los 5 principales tipos de secretos válidos en configuraciones MCP:

Por qué las configuraciones MCP siguen filtrándose: Las guías oficiales de configuración de MCP normalizan la codificación directa. La documentación popular de inicio rápido muestra claves API pasadas como argumentos de línea de comandos dentro de archivos de configuración del servidor, o almacenadas en línea en archivos JSON que se envían al control de versiones. Cuando la documentación oficial trata la codificación directa como predeterminada, la dispersión sigue.

El caso Smithery.ai: El equipo de investigación de GitGuardian reveló una vulnerabilidad crítica en uno de los registros de servidores MCP más utilizados. Un solo error de path traversal en el proceso de construcción Docker de la plataforma expuso un token con privilegios excesivos que otorgaba ejecución de código arbitrario en los más de 3.000 servidores MCP alojados — y acceso a las claves API y secretos de miles de clientes en cientos de servicios.

Gestión de credenciales MCP — estándares mínimos:

• Nunca almacene secretos en archivos de configuración MCP. Utilice variables de entorno gestionadas por un gestor de secretos dedicado, no valores en línea en JSON o argumentos CLI.
• Los clientes, no los servidores, deben ser propietarios de los secretos. Los servidores MCP deben solicitar credenciales a los clientes en el momento de la consulta en lugar de incrustarlas en la configuración del lado del servidor.
• Excluya los directorios de configuración MCP del control de versiones mediante .gitignore.
• Conéctese a servidores MCP remotos únicamente a través de TLS.
• Escanee antes de hacer push. Las herramientas de escaneo pre-commit detectan secretos en archivos de configuración MCP antes de que lleguen al control de versiones.
• Requiera aprobación manual antes de cualquier acción MCP que toque sistemas de producción, bases de datos o pipelines de despliegue.

Los secretos en código, configuraciones y mensajes de chat son una brecha esperando suceder. Passwork proporciona a su equipo un lugar único y seguro para almacenar, compartir y rotar credenciales — para que nunca terminen codificadas en un repositorio o pegadas en un canal de Slack. Explore las capacidades de gestión de secretos de Passwork

Los sistemas internos son un punto ciego peligroso

El hallazgo más consecuente del informe 2026 es el que recibe menos cobertura mediática: el peligro es mayor donde las organizaciones se sienten más seguras. Los repositorios internos, las herramientas de colaboración y la infraestructura autoalojada se tratan como seguros por defecto — pero los datos dicen lo contrario.

Los repositorios internos filtran 6× más que los públicos

La razón es el antipatrón de «seguridad por oscuridad». Los equipos de desarrollo tienden a ser menos cautelosos dentro de un perímetro cerrado. Asumen que exponer un secreto en un repositorio privado es menos dañino porque no está sujeto a escrutinio público. El resultado es una acumulación silenciosa de credenciales codificadas programadas para ser eliminadas «más tarde» — y rara vez lo son.

Los repositorios internos también contienen las credenciales más valiosas:

• Tokens de CI/CD
• Claves de acceso a la nube
• Credenciales de bases de datos
• Tokens de herramientas internas

Estos son exactamente los activos que un atacante desea una vez que establece un punto de apoyo. Un solo secreto expuesto en un repositorio privado puede convertirse en un camino rápido hacia el movimiento lateral a través de toda la infraestructura.

Tasas de exposición por industria (repositorios públicos):

Estas cifras representan solo lo que es visible externamente. La exposición interna es 6× mayor en todos los sectores.

Las firmas de consultoría convierten la dispersión de secretos en riesgo de terceros

Los contratistas y firmas de consultoría operan simultáneamente en múltiples entornos de clientes. Poseen credenciales, tokens y conocimiento de configuración de cada cliente al que sirven — y frecuentemente trabajan en cuentas personales o repositorios fuera de la organización de GitHub de su cliente.

Análisis de GitGuardian de 13 firmas de consultoría:

La brecha de Red Hat (octubre de 2025): El grupo de ciberdelincuentes «Crimson Collective» exfiltró 570 GB de datos de 28.000 repositorios en la instancia interna de consultoría de GitLab de Red Hat, afectando aproximadamente a 800 organizaciones en todo el mundo. Los datos filtrados contenían:

• Claves API y credenciales de bases de datos
• Tokens de autenticación y configuraciones de VPN
• Detalles de infraestructura y arquitectura interna

Las organizaciones afectadas incluyeron a Bank of America, JPMorgan Chase, IBM, Cisco, la Armada de EE.UU. y la NSA. Los atacantes utilizaron las credenciales recolectadas para pivotar directamente hacia la infraestructura del cliente.

Cualquier organización que utilice contratistas o firmas de consultoría tiene un problema de secretos de terceros, haya sido descubierto o no.

Una de cada cuatro filtraciones internas se origina fuera del código fuente

Origen de los incidentes internos:

Las herramientas de colaboración (Slack, Jira, Confluence) representan el 28% de los incidentes, con una tasa de severidad crítica 13 puntos porcentuales más alta que las filtraciones basadas en código. Los secretos compartidos a través de estas herramientas tienden a ser credenciales de producción compartidas durante la respuesta a incidentes o la resolución urgente de problemas, cuando las personas se mueven rápido y no piensan en la higiene de seguridad.

El 4% de superposición entre hallazgos de SCM y ODS significa que estas son poblaciones de filtraciones en gran medida separadas. Escanear solo repositorios omite aproximadamente una cuarta parte de la exposición total de una organización.

80.000 secretos en GitLab autoalojado y registros Docker

GitGuardian identificó miles de instancias de GitLab autoalojadas y registros Docker dejados accesibles públicamente sin autenticación.

Resumen de hallazgos:

Tasas de validez por tipo de credencial (Docker vs. GitLab):

Cuanto más cerca está un activo de producción, mayor es la probabilidad de encontrar una credencial válida. La tasa de filtración de GitLab autoalojado y Docker es 3–4× mayor que la de GitHub público.

La investigación también descubrió más de 300.000 direcciones de correo electrónico (incluyendo 2.000 con dominios .gov) y referencias a hosts de bases de datos internas e infraestructura no pública.

El efecto «muñecas rusas»: las filtraciones expuestas públicamente contienen secretos válidos que otorgan acceso a infraestructura privada, que a su vez expone más secretos, multiplicando la brecha inicial en cada capa.

El 64% de los secretos filtrados en 2022 siguen siendo válidos en 2026

La detección sin remediación no es seguridad — es documentación. Los datos longitudinales del informe 2026 demuestran esto claramente.

Validez de secretos originalmente filtrados en 2022, reevaluados a lo largo del tiempo:

Esas credenciales han estado en código público, explotables por cualquiera que las encuentre, durante cuatro años. La persistencia es una señal operativa de que la remediación — no la detección — es el factor limitante de la industria.

Por qué la rotación rara vez ocurre:

Las credenciales no son cadenas aisladas. Están incrustadas en:

• Sistemas de construcción y pipelines de CI/CD
• Múltiples repositorios (duplicadas)
• Imágenes de contenedores (integradas en tiempo de construcción)
• Variables de CI y configuraciones de entorno
• Integraciones de proveedores y terceros

La decisión a corto plazo que muchos equipos toman no es la más segura — es la que evita romper algo: no hacer nada.

Distribución de violaciones de políticas NHI (datos de clientes de GitGuardian):

La velocidad de creación está superando la madurez de identidad. La IA facilita la creación de proyectos y la conexión de servicios, pero también facilita reproducir patrones inseguros a escala cuando el movimiento predeterminado es «simplemente añadir una clave».

Por qué falla la priorización solo por validación

Una suposición generalizada en la seguridad de secretos: si un secreto no puede ser validado — confirmado como actualmente activo — se debe despriorizarlo. El informe 2026 desafía esto directamente.

El 46% de los secretos críticos son invisibles para las herramientas de solo validación

La brecha existe porque la cobertura de validación siempre es incompleta:

• Las APIs cambian sin previo aviso
• Nuevos servicios se lanzan constantemente
• Cada proveedor requiere infraestructura dedicada para validar
• Las plataformas regionales y específicas de la industria proliferan

Ignorar los secretos no validables por defecto no es una estrategia conservadora. Es un punto ciego sistemático.

Los secretos genéricos causan la mitad de todos los incidentes críticos

Los «secretos genéricos» — claves privadas, tokens API personalizados, contraseñas y mecanismos de acceso detectados mediante verificaciones de entropía y contexto en lugar de patrones específicos del proveedor — se despriorizan rutinariamente porque no pueden validarse automáticamente.

Los datos dicen que esto es un error:

• 35% de los incidentes críticos se remontan a credenciales genéricas
• 51% de los incidentes de alta criticidad o críticos se remontan a credenciales genéricas

La investigación conjunta con Google (2025): GitGuardian y Google analizaron un millón de claves privadas filtradas contra los registros de Certificate Transparency. Hallazgos clave:

• El 4,5% de las claves filtradas se correspondían con certificados X.509 de confianza
• La mitad tenía un certificado válido en el momento de la filtración
• Más de 4.000 certificados HTTPS se ven comprometidos por año debido a una clave filtrada
• Las organizaciones afectadas incluyeron múltiples empresas Fortune 500 y una Autoridad de Certificación de confianza
• GitGuardian envió más de 4.000 correos de alerta a 600 organizaciones — tasa de respuesta: menos del 10%

Válido no siempre significa peligroso

El problema inverso es igualmente real. Aproximadamente el 10% de los secretos válidos son inherentemente de bajo impacto — tokens de sandbox, credenciales de entornos de prueba, cuentas de servicio con privilegios bajos con acceso solo a datos triviales.

Sin puntuación de riesgo contextual, los equipos rotan credenciales en orden de detección o validación, no en orden de amenaza.

Las cuatro capacidades que requiere una seguridad de secretos efectiva:

Los equipos que aún operan con enfoques de solo validación están sistemáticamente expuestos exactamente a las amenazas que más importan — mientras consumen tiempo de ingeniería en credenciales que representan poco peligro real.

La estación de trabajo del desarrollador como superficie de ataque pasada por alto

El ataque a la cadena de suministro Shai-Hulud 2 proporcionó a GitGuardian datos empíricos directos sobre cómo se ven realmente los secretos en las máquinas de los desarrolladores a escala. Al comprometer paquetes de npm y ejecutarse en el momento de la instalación, el malware recopiló sistemáticamente archivos de entorno y ejecutó escaneos estructurados de secretos locales en miles de máquinas reales.

Hallazgos de Shai-Hulud 2 en 6.943 máquinas comprometidas:

Cada secreto activo aparecía en aproximadamente ocho ubicaciones diferentes en la misma máquina — dotfiles, perfiles de shell, salidas de construcción, configuraciones de IDE y cachés de herramientas. Cada copia es un vector independiente para el robo.

Los tokens de GitHub dominaron el conjunto validado:

• 581 tokens de acceso personal
• 386 tokens OAuth
• 104 PAT de grano fino
• 101 tokens de GitLab

Cada uno permite acceso a repositorios, manipulación de flujos de trabajo o movimiento lateral a través de la cadena de suministro de software. Y debido a que el 59% de las máquinas comprometidas eran runners de CI/CD, esta exposición se extiende mucho más allá del desarrollador individual hacia la infraestructura de construcción compartida.

GitGuardian considera estas cifras conservadoras. El ataque solo se ejecutó donde se instaló el paquete malicioso. No alcanzó carpetas de memoria de agentes, cachés de IDE o la creciente superficie de artefactos generados por IA que ahora incluyen rutinariamente credenciales.

Passwork está disponible como solución autoalojada con control total sobre sus datos. Reemplaza archivos .env compartidos, credenciales pegadas en chat y tokens integrados en configuraciones de CI/CD — con una bóveda estructurada, acceso basado en roles y un registro de auditoría completo. Explore las opciones de despliegue de Passwork

El camino a seguir: De la detección reactiva a la gobernanza de NHI

La detección captura lo que ya existe. El objetivo es adelantarse a la exposición — visibilidad completa de cada credencial en el entorno: quién la posee, a qué accede y si debería seguir existiendo. Ese cambio, de perseguir filtraciones a gobernar identidades no humanas, es lo que significa la gobernanza de NHI en la práctica.

Paso 1. Centralizar secretos en plataformas de bóveda

Haga de la bóveda la fuente de verdad. Cuando los equipos pueden recuperar credenciales de manera confiable desde una única ubicación con control de acceso, dejan de inventar estrategias de almacenamiento fragmentadas — uno de los principales impulsores de la dispersión de secretos. La estructura de bóveda de Passwork está diseñada exactamente para esto: almacenamiento organizado, cifrado y con control de acceso para claves API, contraseñas de bases de datos, certificados, claves SSH y credenciales de cuentas de servicio.

Paso 2. Automatizar la rotación

Si un secreto debe existir, no debería vivir para siempre. El reemplazo regular de credenciales acorta la ventana en que un atacante puede explotar un secreto filtrado y obliga a los equipos a tratar las credenciales como objetos con un ciclo de vida, no como tareas de configuración de una sola vez. La rotación es mucho más simple una vez que existe una estrategia de bóveda — la bóveda se convierte en la única ubicación a actualizar, en lugar de buscar cada lugar donde se copió una credencial.

Paso 3. Corregir los flujos de trabajo de los desarrolladores

Los desarrolladores codifican secretos directamente porque es la forma más rápida de hacer que el código funcione. Elimine la necesidad de archivos .env compartidos y tokens copiados haciendo que la recuperación de credenciales basada en bóveda sea igualmente rápida. El camino seguro tiene que ser más fácil que el inseguro.

Paso 4. Adelantar el escaneo

El escaneo pre-commit y la detección a nivel de estación de trabajo detienen los incidentes antes de que lleguen a cualquier lugar permanente. Las herramientas de escaneo modernas proporcionan señales accionables con bajas tasas de falsos positivos — una mejora significativa respecto a las herramientas ruidosas que erosionaron la confianza de los desarrolladores en el pasado.

Paso 5. Avanzar hacia la autenticación basada en identidad

La salida a largo plazo de los secretos estáticos de larga duración es el acceso de corta duración basado en identidad. Marcos como SPIFFE, implementados por SPIRE de código abierto, reemplazan la autenticación de cadenas compartidas con identidad de carga de trabajo fuertemente atestiguada. Cada carga de trabajo recibe credenciales de corta duración just-in-time en lugar de una clave estática que puede ser copiada, filtrada y explotada durante años.

Tres principios para 2026

Tres preguntas de gobernanza que toda organización debe responder

1. ¿Qué identidades no humanas existen en nuestro entorno?
2. ¿Quién las posee?
3. ¿A qué pueden acceder?

Si alguna de esas preguntas no puede responderse con confianza, la adopción de IA está superando la postura de seguridad.

Conclusiones clave para equipos de TI y seguridad

El informe 2026 de GitGuardian es un relato detallado de un problema en aceleración. Esto es lo que los datos exigen en la práctica:

Las organizaciones que tratan la gestión de credenciales como una disciplina de ciclo de vida — con bóvedas centralizadas, rotación automatizada y control de acceso aplicado — estarán mejor posicionadas para la era de la IA agéntica. Aquellas que la tratan como una tarea de limpieza seguirán descubriendo que sus secretos sobreviven a sus suposiciones de seguridad.

Los datos son claros: los secretos en código, configuraciones y mensajes de chat son una brecha esperando suceder. Passwork proporciona a su equipo un lugar único y seguro para almacenar, compartir y rotar credenciales — con acceso basado en roles, un registro de auditoría completo y despliegue autoalojado que mantiene todo dentro de su propia infraestructura. Pruebe Passwork en su infraestructura

Preguntas frecuentes

¿Qué es la dispersión de secretos?

La dispersión de secretos es la proliferación descontrolada de credenciales codificadas — claves API, contraseñas, tokens, certificados y cadenas de conexión — a través de bases de código, archivos de configuración, pipelines de CI/CD y herramientas de colaboración. Ocurre cuando las credenciales se crean más rápido de lo que se rastrean, rotan o revocan, dejando a las organizaciones con un inventario creciente de vías de acceso explotables que no pueden contabilizar completamente.

¿Cuántos secretos se filtraron en GitHub en 2025?

GitGuardian detectó 28,65 millones de nuevos secretos codificados en commits públicos de GitHub en 2025 — un aumento del 34% respecto a 2024 y el mayor incremento anual jamás registrado. Esa cifra cubre únicamente repositorios públicos. Los repositorios internos, herramientas de colaboración e infraestructura autoalojada añaden sustancialmente a la exposición total.

¿Qué porcentaje de secretos filtrados nunca se revocan?

El 64% de los secretos confirmados como válidos en 2022 seguían siendo válidos y explotables en enero de 2026, lo que significa que habían estado en código público durante cuatro años sin ser rotados ni revocados. La tasa de validez era aproximadamente del 70% cuando el mismo conjunto de datos fue reevaluado en enero de 2025, mostrando solo un descenso gradual a pesar de cuatro años de exposición.

¿Por qué los repositorios internos son más peligrosos que los públicos?

Los repositorios internos tienen 6× más probabilidad de contener un secreto codificado que los públicos — 32,2% vs. 5,6% en 2025. Los equipos tienden a ser menos cautelosos dentro de un perímetro cerrado, asumiendo que un repositorio privado es inherentemente seguro. Los repos internos también contienen las credenciales más valiosas: tokens de CI/CD, claves de acceso a la nube y credenciales de bases de datos — exactamente lo que los atacantes buscan una vez que establecen un punto de apoyo.

¿Cómo aumenta la codificación asistida por IA el riesgo de filtraciones de secretos?

Los asistentes de codificación con IA generan commits más grandes con más código por cambio, aumentando la superficie de exposición de credenciales. Los commits coautorados por Claude Code filtraron secretos al 3,2% — más del doble del 1,5% de referencia en todos los commits públicos de GitHub. Los secretos de infraestructura LLM se filtran 5× más rápido que los secretos de proveedores de modelos principales. Cada nueva integración de servicio de IA añade credenciales que pueden codificarse, copiarse y filtrarse.

¿Qué son los archivos de configuración MCP y por qué filtran secretos?

Model Context Protocol (MCP) es el estándar para conectar modelos de lenguaje grandes con herramientas y fuentes de datos externas. Los archivos de configuración MCP definen cómo un agente de IA se conecta a bases de datos, APIs y servicios — y esas conexiones requieren credenciales. En 2025, GitGuardian encontró 24.008 secretos únicos en archivos de configuración MCP en GitHub público, con 2.117 confirmados como válidos. Las guías oficiales de configuración de MCP a menudo normalizan la codificación de credenciales directamente en archivos de configuración, lo que propaga el problema.

¿Qué es la priorización solo por validación y por qué falla?

La priorización solo por validación es la práctica de desprirorizar secretos que no pueden confirmarse como actualmente activos. Falla porque el 46% de los secretos críticos no pueden validarse — pertenecen a servicios sin verificadores de validación, o a tipos de credenciales genéricas como claves privadas y tokens personalizados. Los equipos que usan este enfoque omiten casi la mitad de sus filtraciones más peligrosas mientras gastan esfuerzo de remediación en credenciales válidas de bajo riesgo. La priorización efectiva requiere puntuación de riesgo contextual, no solo una verificación de validez.

¿Qué es la gobernanza de NHI y por qué importa?

La gobernanza de identidades no humanas (NHI) es la práctica de gestionar el ciclo de vida completo de las identidades de máquinas — cuentas de servicio, claves API, tokens de agentes y otras credenciales no humanas — con el mismo rigor aplicado a las cuentas de usuarios humanos. Responde a tres preguntas: qué NHI existen en el entorno, quién las posee y a qué pueden acceder. A medida que el desarrollo asistido por IA acelera la creación de credenciales, la gobernanza de NHI es la disciplina que evita que la velocidad de creación supere permanentemente la postura de seguridad.

Robo de tokens OAuth y ataques de credenciales: Revisión de abril de 2026

APT28 secuestró 18.000 routers para robar tokens OAuth. Storm-2372 evadió MFA sin tocar una contraseña. 28,6 millones de secretos se filtraron en GitHub. Los mayores incidentes de abril de 2026 — y qué tienen en común.

Passwork BlogAlex Muntyan

Dentro de ataques reales a la cadena de suministro: Bitwarden CLI, Axios y Vercel

¿Por qué violar su red cuando los atacantes pueden comprometer una dependencia de confianza con millones de descargas e infiltrarse silenciosamente en miles de organizaciones a la vez? Tres campañas de 2026 demuestran que los ataques a la cadena de suministro ya no son incidentes aislados.

Passwork BlogAlex Muntyan

Caos de contraseñas: Por qué es un problema empresarial y cómo solucionarlo

Una contraseña olvidada cuesta $70. Una brecha cuesta $4,44 millones. Ambas comienzan de la misma manera — credenciales compartidas por Slack, almacenadas en hojas de cálculo, nunca rotadas. Esto es lo que realmente cuesta el caos de contraseñas y cómo eliminarlo.

Passwork BlogAlex Muntyan