La protección de secretos debe escalar con el software

Hoy, uno de cada tres pull requests en GitHub involucra a un agente de IA. Hace un año, esa cifra era menor de uno de cada 10. Si ese ritmo se mantiene, en los próximos dos años, la mayoría del código enviado a GitHub podría ser escrito por un agente. Es posible que gran parte nunca sea leído completamente por un humano.

Si los desarrolladores y los agentes se mueven más rápido, tenemos la responsabilidad de garantizar que la protección mantenga el ritmo acelerado de creación de código. Eso significa prevenir más filtraciones antes de que ocurran y hacer que la respuesta a las exposiciones que permanezcan dependa menos del esfuerzo humano manual.

Este es un punto crucial para los secretos filtrados. Los desarrolladores no se están volviendo más descuidados; están siendo superados por el ritmo. Las herramientas que permiten a los desarrolladores crear más software también deberían asumir más del trabajo de protegerlo.

En este ensayo, comparto los nueve trimestres de datos que respaldan esa afirmación. También presento el clasificador ajustado que construimos con Microsoft Applied Sciences para extender la push protection a secretos no estructurados. El modelo evalúa todo un conjunto de secretos candidatos en menos de dos milisegundos y podría más que duplicar el número de secretos que podemos prevenir.

Superados, no descuidados

Un nuevo secreto aparece en código visible públicamente aproximadamente una vez cada dos segundos, duplicándose anualmente durante los últimos tres años. El discurso público salta rápidamente a la idea de que la IA hizo a los desarrolladores descuidados.

Entre el Q2 2024 y el Q2 2026, los pushes examinados crecieron 2.84 veces mientras que los pushes que transportaban credenciales crecieron 2.59 veces. A lo largo de nueve trimestres completos de datos, no encontramos ninguna tendencia estadísticamente detectable respecto a la prevalencia por push. Al mismo tiempo, encontramos datos que sugieren que, más que nunca, los desarrolladores entienden el riesgo de las exposiciones accidentales y están menos dispuestos a aceptar ese riesgo. Durante el mismo período, la proporción de bloques en la ruta de push anulados por los desarrolladores cayó linealmente de 6.63% a 3.93%. Estas cifran desafían la afirmación común de que los agentes están haciendo que los desarrolladores se vuelvan más descuidados.

A una tasa fija, duplicar la actividad duplica las exposiciones esperadas. Si cada exposición requiere la misma respuesta humana, la carga de trabajo también se duplica. El tiempo medio para revocar manualmente un secreto ronda los 40 días; aproximadamente uno de cada cinco tomó más de 90 días. Estamos acelerando la creación de software mientras las credenciales expuestas pueden seguir siendo utilizables durante semanas o meses, porque la remediación humana no puede escalar al mismo ritmo que el desarrollo.

Decirles a los desarrolladores que tengan más cuidado no puede, por sí solo, resolver ese problema. A medida que crece la cantidad de código, debemos prevenir más exposiciones y reducir el esfuerzo humano que requieren las que permanecen, si queremos que el desarrollo de software siga siendo sostenible.

La prevención escala con la computación

He pasado los últimos pocos años trabajando en secret scanning en GitHub y el último año como líder de producto de esa área. Nuestro mayor impacto ha venido de conectar los puntos entre la detección y los sistemas que pueden actuar.

El catálogo de GitHub cubre a más de 150 socios técnicos a través de nuestro programa de asociación de secret scanning. A través de nuestro programa de socios, trabajamos con los emisores de secretos participantes para construir detectores y reportar exposiciones públicas para que puedan responder. En el Q2 2026, el escaneo público reportó con éxito un promedio de 26 coincidencias de credenciales por segundo, incluidas observaciones repetidas. Una vez notificados, un gran número de estos socios revoca inmediatamente el token: claves de API de OpenAI, credenciales de cuentas de Google Cloud, webhooks de Slack, tokens de usuario de Hugging Face, claves de SendGrid, etc. El propietario puede que aún necesite reemplazar el token, pero la revocación puede ocurrir sin esperar a que un desarrollador encuentre y procese una alerta de GitHub.

La push protection interviene antes. Detiene las credenciales reconocibles antes de que entren en el historial del repositorio, dando al desarrollador o al agente la oportunidad de corregir el cambio antes de que haya una exposición que investigar. Trabajamos con nuestros socios técnicos para aumentar las tasas de precisión de sus detectores tanto como sea posible, hasta que tengamos la confianza suficiente para proteger mediante push estos secretos para la comunidad de desarrolladores de forma predeterminada.

Gracias a los esfuerzos de nuestros socios, en el último mes, se bloqueó un secreto mediante la protección contra pushes al menos una vez por segundo. En cuanto a las credenciales vinculadas al emisor, GitHub bloquea más secretos de los que se escapan. Estoy orgulloso de lo ordinaria que hemos hecho que eso se sienta para los desarrolladores.

La remediación escala con las personas

Al incluir tipos adicionales de secretos, la protección contra pushes detiene cerca del 30% de los secretos recién detectados antes de que entren en el historial del repositorio. Encontramos el 70% restante después de que, lamentablemente, la credencial ya se ha perdido. Y:

1. La prevención escala con la computación, pero la remediación aún escala con las personas.
2. Rechazar un push cuesta computación; limpiar un secreto que ya se perdió en el historial visible cuesta el tiempo y la atención de un desarrollador.
3. A medida que crece la cantidad de código, debemos prevenir más exposiciones y reducir el esfuerzo humano requerido por las que permanecen, o de lo contrario el volumen de vulnerabilidades introducidas se volverá insostenible.

Decirles a los desarrolladores que sean más cuidadosos no puede resolver este desequilibrio. Reconocer más de estos secretos, antes en los flujos de desarrollo, es un trabajo que la plataforma debe asumir.

Resolviendo el problema de los cuatro cuerpos

Antes de que un secreto cruza el límite del push, el costo de detenerlo es pequeño, y la decisión es binaria: bloquear o permitir. Después de cruzarlo, la misma cadena puede autenticarse en un sistema real, y el costo es ilimitado.

En muchos casos, nuestra única pista de detección puede ser el código circundante y el contexto del entorno. Un token emitido por un proveedor puede tener un prefijo reconocible. Una contraseña interna de base de datos puede ser completamente no estructurada, sin ningún patrón identificador. Ya estábamos usando el contexto para encontrar estos secretos después del push; el problema era equilibrar ese juicio consciente del contexto con otros factores.

Nos referimos a esto como el «problema de los cuatro cuerpos» para la protección de secretos: precisión, latencia, rendimiento y costo son restricciones acopladas. La prevención debe valer el tiempo de un desarrollador. Un hallazgo adecuado para revisión posterior puede no justificar bloquear un push. Un falso positivo interrumpe a un desarrollador y hace que el siguiente bloqueo sea más difícil de confiar. Una comprobación que es demasiado lenta, costosa o difícil de escalar limita la frecuencia con la que puede ejecutarse.

Protección en el push en menos de 2 ms

Nuestro nuevo clasificador ModernBERT evalúa los secretos candidatos en contexto, sin generar código ni prosa. No solo es más preciso que los pipelines existentes basados en LLM, sino que es increíblemente rápido, evaluando lotes de candidatos en menos de dos milisegundos. También es extremadamente eficiente en costos, lo suficiente para ejecutarse a escala en la ruta crítica.

La inclusión de nuestro modelo en la protección de push nos permite más que duplicar el número de secretos que podemos prevenir. La funcionalidad está actualmente en vista previa privada. Más adelante este mes, la funcionalidad estará disponible para las organizaciones con GitHub Secret Protection en Enterprise Cloud y GitHub Teams. Consumirá créditos de IA.

También estamos llevando el modelo a superficies de desarrollador más allá del push.

• A partir de hoy, cualquier organización con detección de secretos con IA será actualizada automáticamente al nuevo modelo. Las alertas abiertas a partir de estos análisis posteriores al push siguen incluidas con la compra del escaneo de secretos de una organización sin costo adicional.
• El modelo también se incluirá con GitHub Enterprise Server 3.23 en vista previa pública, llevando alertas detectadas por IA a los clientes de Secret Protection incluso en entornos aislados (air-gapped).
• Estamos agregando el clasificador al /security-review comando para la Copilot CLI y la Copilot App, de modo que los usuarios de Copilot puedan abordar los secretos antes de un push sin necesidad del plan de GitHub Secret Protection de una organización. El uso de créditos de IA se atribuirá a GitHub Secret Protection en sus informes de uso de IA.

Mirando hacia adelante

El futuro que queremos es uno en el que los desarrolladores puedan confiar más trabajo a los agentes sin supervisar cada solicitud, y uno en el que el número de personas que una organización necesita para mantener seguras sus credenciales ya no escale con la cantidad de código que escribe. Le debemos a la comunidad de desarrolladores el mismo progreso en proteger el software que estamos entregando en producirlo.

Queremos que la gente construya más software. Nuestra capacidad de protegerlo debe crecer con nuestra capacidad de crearlo.

La publicación La protección de secretos debe escalar con el software apareció primero en The GitHub Blog.