mayor aceptación
precisión de alertas ponderada por propietario
86%menor tiempo medio de ejecución de los escaneos
Escaneo posterior al push
98%menor costo de servicio
Modelo compacto frente a llamadas remotas a LLM
El escaneo de secretos funciona mejor cuando los desarrolladores confían en los resultados. Si se detecta muy poco, credenciales reales pueden permanecer en un repositorio. Si se alerta con demasiada frecuencia, los desarrolladores pueden perder tiempo investigando cadenas que no son secretos.
Los secretos genéricos hacen que ese equilibrio sea especialmente difícil. La misma cadena podría ser una credencial real o un marcador de posición de documentación, por lo que detectarla requiere comprender el código y el texto circundante.
Para abordar este desafío, entrenamos un clasificador de secretos específicamente para las necesidades del producto de GitHub: distinguir credenciales reales de imitaciones mientras se cumplen los requisitos de velocidad y eficiencia del escaneo a gran escala.
En nuestra publicación complementaria, La protección de secretos debe escalar con el software, explicamos por qué la protección de secretos debe mantenerse al ritmo del desarrollo acelerado por IA. Aquí, vamos a los bastidores del clasificador consciente del contexto que impulsa ese esfuerzo: cómo lo diseñamos, entrenamos y evaluamos para encontrar más secretos reales con menos ruido.
Lo que habilitamos
El escaneo de secretos de GitHub opera en dos momentos clave:
- Push protection ayuda a evitar que los secretos entren en un repositorio escaneando los cambios antes de que se acepte un push, dando a los desarrolladores la oportunidad de atender el hallazgo.
- Post-push scanning funciona después de que el código ha sido confirmado, escaneando continuamente el contenido del repositorio y creando alertas cuando se detectan posibles secretos para que los desarrolladores y los equipos de seguridad puedan investigarlos y remediarlos.
Desarrollamos un clasificador rápido que redujo el tiempo medio de ejecución de los escaneos posteriores al push en un 86% en comparación con el pipeline anterior basado en LLM. Esa eficiencia hizo que fuera práctico extender la detección de secretos genéricos a la protección de push, devolviendo resultados antes de que los desarrolladores hagan push de los cambios, y no solo después de que el código sea confirmado.
Por qué los secretos son difíciles de detectar
Las credenciales estructuradas suelen incluir un prefijo, longitud, alfabeto o checksum distintivos. Los secretos genéricos pueden no incluirlos. Su sintaxis se solapa con identificadores de compilación, checksums, hashes de activos, valores de ejemplo y otras cadenas no sensibles. El contexto es la señal decisiva.
| Credencial real probable | Imitación inofensiva probable |
|---|---|
| Una contraseña asignada junto a una URL de base de datos de producción | El mismo valor con forma de contraseña en un fixture de prueba |
| Una cadena de conexión en la configuración de despliegue | Una cadena de conexión de localhost en una guía de configuración |
| Un valor de alta entropía vinculado a una credencial de API | Una suma de comprobación de alta entropía, un ID de compilación o un hash de recurso |
Estos casos son negativos difíciles: cadenas que coinciden con un patrón de credencial pero que no son credenciales utilizables. Añadir más reglas puede suprimir algunos de ellos, pero cada excepción arriesga ocultar un secreto real. En su lugar, un clasificador aprendido puede utilizar señales como la ruta del archivo, el tipo de secreto, los nombres de variables y el código o texto cercano.
Por eso lanzamos un nuevo escáner que utiliza un proceso de dos etapas:
- Generación de candidatos: Los filtros de expresiones regulares escanean el contenido en busca de secretos potenciales con una alta tasa de recuperación. Esta etapa está optimizada para detectar de forma rápida y determinista grandes familias de patrones similares a credenciales.
- Clasificación consciente del contexto: Un clasificador ModernBERT ajustado evalúa cada candidato y su contexto circundante. Está entrenado para reconocer las señales que separan los secretos reales de los falsos positivos, incluidos los valores de marcador de posición, los ejemplos, los fragmentos de documentación, el contenido generado y los identificadores no sensibles. Como el modelo es pequeño y eficiente de ejecutar en nuestra infraestructura de inferencia, cuesta mucho menos servirlo y es más sencillo de escalar que un pipeline basado en LLM.
Impacto:
- Mejora del 11.5% en la aceptación de los usuarios, reduciendo los falsos positivos.
- Tiempo de ejecución de la detección de secretos posterior al push un 86% más rápido.
- Ahorro de costos de más del 98% en comparación con el pipeline basado en LLM.
Cómo funciona nuestro pipeline
A medida que se escanea el contenido, los patrones regex tienden una red amplia y marcan cualquier cosa que parezca una credencial, de modo que no se pasen por alto secretos reales al inicio. Luego, cada candidato pasa a un clasificador ModernBERT ajustado, que lee el valor junto con su ruta de archivo, los nombres de las variables y el código circundante. El clasificador estima la probabilidad de que sea un secreto real. Los hallazgos de alta confianza se convierten en alertas, y los imitaciones como marcadores de posición, fixtures de prueba y checksums se filtran antes de que lleguen a los desarrolladores.
PASO 1
Escanear
Contenido de repositorios, commits, pull requests y otras superficies escaneadas.
PASO 2
Generar candidatos
Los patrones regex identifican posibles tokens, claves y cadenas similares a credenciales.
PASO 3
Clasificar
ModernBERT ajustado evalúa el candidato + el contexto y asigna la probabilidad de que sea un secreto verdadero.
PASO 4
Alertar o suprimir
Los hallazgos de alta confianza avanzan; los probables falsos positivos se filtran.
La decisión de diseño importante es que el modelo no reemplaza el escaneo determinista. En cambio, lo complementa. Las expresiones regex siguen siendo la herramienta adecuada para encontrar rápidamente cadenas candidatas. El clasificador se utiliza donde el aprendizaje automático proporciona el mayor aprovechamiento: distinguir entre "parece un secreto" y "es probablemente un secreto real".
Un problema de negativos difíciles: secretos que casi parecen reales
La mayoría de los falsos positivos no son aleatorios. Son negativos difíciles: cadenas que coinciden con un patrón de credencial pero que no son credenciales utilizables. Algunos ejemplos son los marcadores de posición de la documentación, los ejemplos de juguete en las pruebas, los valores censurados, los identificadores no sensibles y los fixtures generados. Estos casos son fáciles de coincidir para una regex y difíciles de suprimir para un sistema puramente basado en reglas sin perder accidentalmente secretos reales.
ModernBERT ayuda porque puede leer el candidato junto con el código y texto cercanos, proporcionando una comprensión contextual comparable a la de un LLM sin la latencia y la sobrecarga computacional de generar resultados en lenguaje natural. Por ejemplo, un candidato rodeado de palabras como "example", "dummy", "fake" o "replace-me" puede ser de menor riesgo que un candidato asignado a una variable de entorno en un archivo de despliegue. El clasificador aprende estas diferencias contextuales a partir de ejemplos etiquetados en lugar de requerir que los ingenieros codifiquen cada excepción como otra regla.
Elegimos ModernBERT porque proporciona un ajuste sólido para esta carga de trabajo: es compacto, eficiente y muy adecuado para la clasificación sobre texto adyacente al código. Para el escaneo de secretos, el modelo necesita tomar una decisión calibrada sobre ventanas cortas de candidatos con alto rendimiento y baja latencia.
Eso hace que un clasificador de codificador ajustado sea una mejor forma de servicio que un LLM de propósito general para esta etapa del pipeline. El modelo puede entrenarse directamente sobre nuestro límite de decisión y evaluarse utilizando las mismas métricas de recall y precisión que importan para la calidad del escaneo de secretos.
Cómo entrenamos
El desafío era encontrar datos representativos para los casos en los que la sintaxis por sí sola es engañosa. La estrategia de entrenamiento y evaluación combina tres fuentes:
- Ejemplos derivados del producto de repositorios de GitHub, utilizando comentarios de la experiencia de detección de secretos y validación humana adicional.
- Candidatos regex de alto recall de datos de repositorios de GitHub, incluidos ejemplos anotados por humanos y etiquetas débiles utilizadas para ampliar la cobertura.
- Ejemplos sintéticos dirigidos a casos dispersos y difíciles, como secretos en documentación, fixtures de prueba, claves públicas, checksums, imitaciones estructuradas y pares de casi coincidencias.
Las filas sintéticas superan una validación determinista y una revisión de calidad basada en modelos antes de su inclusión. El entrenamiento enfatiza secretos reales, falsos positivos realistas y ejemplos negativos difíciles que frecuentemente confunden a los enfoques basados únicamente en expresiones regulares. Cada entrada del modelo incluye el valor candidato, la ruta del archivo, el tipo de secreto y una cantidad acotada de contexto circundante. Seleccionamos los umbrales mediante evaluación fuera de línea y luego validamos el comportamiento en tráfico similar al de producción antes de un despliegue más amplio.
Antes de dividir los datos, agrupamos las filas que comparten un repositorio, un valor candidato o un ejemplo, de modo que los cuasi duplicados no pudieran aparecer tanto en el entrenamiento como en la evaluación.
El entrenamiento se centró en los casos que más importan para la calidad de las alertas: secretos reales, falsos positivos realistas y negativos difíciles que las expresiones regulares suelen emparejar. La representación de entrada incluye la cadena candidata del secreto, la ruta del archivo, el tipo y una cantidad acotada de contexto circundante. La salida es una puntuación de clasificación que el escáner utiliza para decidir si la candidata debe continuar.
Optimizamos para el equilibrio del producto: preservar o mejorar la exhaustividad (recall) mientras se reducen los falsos positivos y el costo de servicio. En la práctica, esto significa que el umbral del clasificador se selecciona mediante evaluación sin conexión y luego se valida contra tráfico similar al de producción antes del despliegue.
El principio de entrenamiento más importante fue hacer que el modelo viera los ejemplos confusos. Incluimos candidatas que son sintácticamente similares a secretos reales pero semánticamente diferentes, de modo que el modelo aprende no solo cómo es un secreto, sino también cómo es un falso positivo en contexto.
El modelo entrenado se exporta a formato ONNX con cuantización de 8 bits, lo que permite una inferencia rápida.
Resultados de la evaluación
| Resultado en línea | Cambio frente al pipeline de LLM anterior | Qué mide |
|---|---|---|
| Aceptación ponderada por propietario del repositorio | 11.5% más alto | Aceptación del cliente de los hallazgos detectados |
| Tiempo medio de ejecución del escaneo posterior al push | 86% más bajo | Tiempo de ejecución del escaneo en producción |
| Costo de servicio | Más del 98% más bajo | Costo del clasificador compacto en comparación con las llamadas remotas al LLM |
Evaluamos el impacto del nuevo pipeline en producción en dos etapas: primero contra la línea base de producción en el mismo tráfico público y luego mediante un experimento A/B con clientes.
- Evaluación sin conexión: En el escaneo posterior al push, el nuevo pipeline logró 13% más de precisión y 19% más de exhaustividad (recall) que el pipeline de LLM anterior cuando se evaluó en el mismo tráfico público.
- Evaluación en línea: Luego validamos si estas mejoras de calidad se traducían en resultados para los clientes mediante un experimento A/B contra el pipeline de LLM anterior. La aceptación ponderada por propietario del repositorio aumentó un 11.5%. Ponderamos la aceptación por propietario del repositorio para reducir la influencia de los clientes que resuelven en bloque grandes volúmenes de alertas a la vez, lo que de otro modo podría distorsionar un promedio simple.
Llévate esto contigo
La mejor herramienta de seguridad es aquella en la que los desarrolladores confían lo suficiente como para usarla. Una mayor precisión significa menos alertas que distraen. Una mayor exhaustividad significa que se detectan más secretos reales. Un costo menor significa que podemos seguir mejorando la cobertura sin que el escaneo resulte prohibitivamente caro.
Para los desarrolladores y los equipos de seguridad, esto debería traducirse en menos falsos positivos y retroalimentación más rápida en los lugares donde es más probable que se introduzcan secretos: commits, pull requests y flujos de trabajo de desarrollo cotidianos.
Los sistemas híbridos son potentes. Las expresiones regulares nos dan velocidad, transparencia y una amplia cobertura de candidatas. ModernBERT nos da una comprensión del contexto aprendida y una reducción de falsos positivos. La combinación supera a cualquiera de los enfoques usados por separado para esta restricción del producto.
También aprendimos que el tamaño de un modelo no es lo mismo que su utilidad. Un clasificador ajustado más pequeño puede ser la respuesta correcta cuando la tarea es acotada, la frontera de decisión es medible y la eficiencia de servicio es crítica.
Este es un paso hacia hacer el escaneo de secretos más preciso, escalable y fácil de usar. De cara al futuro, nos enfocamos en dos áreas:
- Construir un ciclo de mejora continua. Usaremos bucles de retroalimentación de producción para identificar nuevos falsos negativos y falsos positivos, convirtiendo señales del mundo real en datos de entrenamiento y evaluación de mayor calidad.
- Explorar nuevas arquitecturas de modelos. Estamos investigando enfoques que puedan realizar la detección y extracción de secretos en un solo paso, reduciendo la complejidad del pipeline sin sacrificar precisión ni escala.
Agradecimientos
Enormes gracias a los equipos de ingeniería, ciencia y producto de GitHub y Microsoft que ayudaron a construir los datos de entrenamiento, la suite de evaluación, la infraestructura de servicio y el plan de despliegue para este nuevo escáner de secretos.
La entrada El modelo de GitHub para la detección de secretos: encontrar más secretos con menos ruido apareció primero en The GitHub Blog.