detección de secretosQué hay que tener en cuenta al elegir una herramienta

Lo primero que hace la mayoría de la gente cuando prueba una detección de secretos es esto:

AWS_SECRET_KEY = "FAKEAWSSECRETKEY123456"
PASSWORD = "contraseña123"‍

Realizan el escaneo, no se detecta nada y la reacción inmediata es algo así como:

«Qué herramienta tan inútil. Mi perro podría haberlo atrapado».

Parece tan obvio. Sin duda, encontrar secretos es la parte más fácil de la seguridad, ¿no? Solo hay que buscar «password=», introducir unas cuantas expresiones regulares y listo. ¿Qué dificultad puede tener?

Y en cierto modo tienes razón. Encontrar cadenas que parecen secretos es fácil. Lo difícil es encontrar secretos reales sin quedar sepultado bajo falsos positivos.

Veamos por qué las pruebas son más difíciles de lo que parecen, por qué las peores soluciones suelen parecer las mejores y cómo se deben evaluar realmente estas herramientas.

Cómo detección de secretos

Existen dos enfoques principales para detectar secretos: la comparación de patrones basada en reglas y las estadísticas de entropía.

La detección basada en reglas se basa en expresiones regulares para detectar secretos con una estructura definida. Las claves de AWS son un ejemplo clásico. Siempre comienzan con el mismo prefijo y tienen una longitud fija, por lo que una expresión regular como esta las detectará:

AKIA[0-9A-Z]{16}

Da una sensación de poder cuando ves que marca una clave en el código. Hasta que te das cuenta de que también marca todos los marcadores de posición que se parecen a una.

AWS_ACCESS_KEY_ID="AKIA1234567890123456"

No está tan mal para una clave, pero si se introducen miles de reglas, rápidamente se vuelve muy ruidoso. Regex es útil, pero no puede separar las claves reales de las ficticias y se termina con un desorden frágil y ruidoso.

Filtrado con validación secreta

Una de las mejores formas de reducir los falsos positivos es validar los secretos tras su detección. Esto suele implicar realizar una llamada API segura. Por ejemplo, una clave AWS se puede comprobar con:

aws sts get-caller-identity --access-key <KEY> --secret-key <SECRET>

Si la llamada se realiza correctamente, dispondrá de una clave activa. Si falla, puede rebajar el nivel de alerta sin ningún problema. 

Esto es genial porque puedes lanzar una red muy amplia y luego reducirla. Pero aquí está el giro. Cuando pruebas una herramienta, no estás enviando claves AWS reales a GitHub. Estás usando claves falsas. Una herramienta que valida claves las descartará como no válidas, mostrándote cero resultados. Mientras tanto, la herramienta más perezosa que marca todo parece funcionar mejor.

Filtrado con estadísticas de entropía

‍

Supongo que aquí debemos explicar rápidamente qué significa entropía. Las cadenas de alta entropía se refieren a una cadena con una gran cantidad de aleatoriedad; más aleatoriedad = más entropía. 

‍

La mayoría de los secretos no pueden validarse, por lo que las herramientas recurren a otros métodos para reducir el ruido. Las estadísticas de entropía son uno de los más eficaces.

La idea es sencilla: los secretos reales parecen aleatorios. Los marcadores de posición no. Considera esta clave Stripe falsa:

StripeKey = «SK_123456789»

Coincide con la expresión regular, pero no es lo suficientemente aleatorio como para ser real. Una clave auténtica tiene una entropía mucho mayor, algo que los humanos no saben falsificar.

 El filtrado de palabras en inglés también ayuda. Las claves API reales casi nunca contienen palabras legibles. Si ves algo como:

PRUEBA823hufb934

puedes estar bastante seguro de que se trata de un marcador de posición o una credencial de prueba. Las buenas herramientas descartarán o ignorarán las cadenas que mezclan alta entropía con palabras obvias del diccionario como TEST, PASSWORD o DEMO. Esto suele causar problemas en las pruebas, ya que simular la entropía es realmente difícil para los humanos; seguimos patrones de forma natural cuando escribimos, aunque no seamos conscientes de ello. 

Desafortunadamente, esto tampoco es siempre tan sencillo, ya que las claves API son cadenas de alta entropía. Los UUID, los hash y los nombres de archivo también son cadenas de alta entropía y no secretos. Por lo tanto, es importante introducir también el contexto en torno al secreto. Las mejores soluciones combinan entropía, contexto y filtrado de palabras. Sin embargo, esto causa problemas en las pruebas, ya que si se añaden credenciales falsas que no se ajustan al contenido en el que se encuentran, también se ignorarán. 

¿Por qué las peores herramientas parecen las mejores?

Esta es la paradoja. Las peores soluciones, aquellas que simplemente gritan ante cualquier cadena sospechosa, brillan en las pruebas rápidas. Detectan alegremente tus claves y contraseñas falsas. Las herramientas más inteligentes parecen fallar porque ignoran silenciosamente tus falsificaciones.

A menos que realices pruebas con datos realistas, acabarás alabando la herramienta ruidosa y descartando la que realmente te ayudaría en la producción.

Cómo probar detección de secretos manera correcta

Si quieres una evaluación justa, necesitas mejores datos de prueba.

Una opción son los tokens de miel. Servicios como CanaryTokens te permiten generar credenciales inofensivas pero realistas. Una buena herramienta debería detectarlas al instante.

Otro enfoque consiste en crear claves reales sin permisos, ejecutar las pruebas y revocarlas posteriormente. Esto proporciona una entrada segura pero válida que activará la lógica de validación.

Sin embargo, el mejor método es ejecutar la herramienta en bases de código reales. Los secretos son comunes en los repositorios, especialmente en lo más profundo del historial de confirmaciones. El análisis de proyectos reales revela cómo se comporta una herramienta en condiciones realistas y le proporciona un punto de referencia en el que puede confiar.

¿Qué hace que una detección de secretos sea buena?

detección de secretos eficaz detección de secretos debe hacer todo lo siguiente:

1. Validar los secretos siempre que sea posible
   Confirmar los secretos reales con llamadas API seguras cuando los proveedores lo permitan.
   
   
2. Admite patrones secretos específicos
   Detecta claves estructuradas como AWS, Stripe y Twilio utilizando expresiones regulares o reglas de patrones.
   
   
3. Maneje secretos genéricos con entropía y contexto
   Utilice la puntuación de aleatoriedad y el análisis del código circundante para detectar secretos sin patrones fijos.
   
   
4. Filtrar credenciales falsas o de prueba
   Rebajar la clasificación de las claves que contengan palabras obvias del diccionario, como TEST o PASSWORD.
   
   
5. Cubre una amplia gama de tipos de secretos
   Más allá de las claves API, incluye certificados, claves SSH, contraseñas de bases de datos y mucho más.
   
   
6. Detenga las fugas antes de que se produzcan
   Proporcione ganchos previos al compromiso o integraciones IDE evitar que los secretos entren en el control de versiones.
   
   
7. Escala en repositorios y canalizaciones
   Trabaja de forma eficaz en CI/CD, en todos los historiales y a escala empresarial.
   
   

Conclusión

detección de secretos sencilla, pero probarla no lo es en absoluto. Las herramientas ruidosas que señalan cada secreto falso pueden parecer impresionantes, mientras que las herramientas más inteligentes que validan y filtran parecen hacer menos.

Si desea realizar pruebas adecuadas, utilice tokens de miel, claves de acceso limitado o repositorios reales. Y al evaluar, busque las cualidades que importan en la producción: validación, detección de patrones, análisis de entropía, filtrado de diccionarios, amplia cobertura y, sobre todo, prevención antes de la confirmación.

Porque la clave AWS falsa que has introducido para realizar pruebas no es peligrosa. La verdadera, que se oculta a plena vista, sí lo es.

‍