Lo primero que hace la mayoría de la gente cuando prueba una herramienta de detección de secretos es esto:
AWS_SECRET_KEY = "FAKEAWSSECRETKEY123456"
PASSWORD = "password123"Ejecutan el escaneo, no se marca nada, y la reacción inmediata es algo parecido a:
«Qué herramienta más inútil. Mi perro lo habría detectado.»
Parece tan obvio. Seguro que encontrar secretos es la parte más fácil de la seguridad, ¿verdad? Solo hay que buscar password=, añadir unas cuantas expresiones regulares y listo. ¿Qué tan difícil puede ser?
Y en cierto modo, tienes razón. Encontrar cadenas que parecen secretos es fácil. Encontrar secretos reales sin verse sepultado por falsos positivos es la parte difícil.
Analicemos por qué las pruebas son más difíciles de lo que parecen, por qué las peores soluciones a menudo parecen las mejores y cómo deberías evaluar realmente estas herramientas.
Cómo funciona la detección de secretos
Existen dos enfoques principales para la detección de secretos: la coincidencia de patrones basada en reglas y las estadísticas de entropía.
La detección basada en reglas se apoya en expresiones regulares para identificar 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 regex como esta las detectará:
AKIA[0-9A-Z]{16}
Resulta potente cuando ves que marca una clave en el código. Hasta que te das cuenta de que también marca cada marcador de posición que se le parece.
AWS_ACCESS_KEY_ID="AKIA1234567890123456"
No es tan grave para una sola clave, pero si introduces miles de reglas, rápidamente se vuelve muy ruidoso. Las regex son útiles, pero no pueden separar las claves reales de las ficticias, y terminas con un desorden frágil y ruidoso.
Filtrado con validación de secretos
Una de las mejores maneras de reducir los falsos positivos es validando los secretos después de la detección. Esto suele implicar realizar una llamada segura a la API. Por ejemplo, una clave de AWS se puede probar con:
aws sts get-caller-identity --access-key <KEY> --secret-key <SECRET>
Si la llamada tiene éxito, tienes una clave activa. Si falla, puedes degradar la alerta de forma segura.
Esto es genial porque puedes lanzar una red muy amplia y luego acotarla. Pero aquí está el giro. Cuando pruebas una herramienta, no estás subiendo claves de AWS reales a GitHub. Estás usando claves falsas. Una herramienta que valida claves las descartará como inválidas, mostrándote cero resultados. Mientras tanto, la herramienta más perezosa que marca todo parece estar funcionando mejor.
Filtrado con estadísticas de entropía
Supongo que aquí necesitamos 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 se basan en otros métodos para reducir el ruido. Las estadísticas de entropía son uno de los más efectivos.
La idea es simple: los secretos reales parecen aleatorios. Los marcadores de posición no. Considera esta clave falsa de Stripe:
StripeKey = "SK_123456789"
Coincide con la regex, pero no es lo suficientemente aleatoria como para ser real. Una clave genuina tiene una entropía mucho mayor, algo que los humanos son pésimos falsificando.
El filtrado de palabras en inglés también ayuda. Las claves API reales casi nunca contienen palabras legibles. Si ves algo como:
TEST823hufb934
puedes estar bastante seguro de que es un marcador de posición o una credencial de prueba. Las buenas herramientas degradarán o ignorarán las cadenas que mezclan alta entropía con palabras obvias del diccionario como TEST, PASSWORD o DEMO. Esto a menudo causa problemas en las pruebas porque falsificar la entropía es realmente difícil para un humano; naturalmente seguimos patrones al escribir, incluso si no somos conscientes de ello.
Desafortunadamente, esto no siempre es tan sencillo, ya que las claves API son cadenas de alta entropía. UUIDs, hashes y nombres de archivo también son cadenas de alta entropía y no secretos. Por lo tanto, es importante introducir contexto alrededor del 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 encajan con el contenido en el que se encuentran, también serán ignoradas.
Por qué las peores herramientas parecen las mejores
Esta es la paradoja. Las peores soluciones, aquellas que alertan ante cada cadena de aspecto sospechoso, brillan en las pruebas rápidas. Capturan sin problemas tus claves y contraseñas de prueba. Las herramientas más inteligentes parecen defectuosas porque ignoran silenciosamente tus falsificaciones.
A menos que pruebes con datos realistas, terminarás elogiando la herramienta ruidosa y descartando la que realmente sería útil en producción.
Cómo probar la detección de secretos de la manera correcta
Si deseas una evaluación justa, necesitas mejores datos de prueba.
Una opción son los honey tokens. Servicios como CanaryTokens permiten generar credenciales inofensivas pero realistas. Una buena herramienta debería detectarlos al instante.
Otro enfoque es crear claves reales sin permisos, ejecutar las pruebas y revocarlas después. 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 profundo del historial de commits. Escanear proyectos reales revela cómo se comporta una herramienta en condiciones realistas y proporciona un benchmark de confianza.
Qué hace que una buena herramienta de detección de secretos
Una herramienta robusta de detección de secretos debería hacer todo lo siguiente:
- Validar secretos siempre que sea posible
Confirmar secretos reales con llamadas seguras a la API cuando los proveedores lo permitan. - Soportar patrones de secretos específicos
Detectar claves estructuradas como las de AWS, Stripe y Twilio utilizando expresiones regulares o reglas de patrones. - Gestionar secretos genéricos con entropía y contexto
Utilizar puntuación de aleatoriedad más análisis de código circundante para detectar secretos sin patrones fijos. - Filtrar credenciales falsas o de prueba
Reducir la prioridad de las claves que contengan palabras obvias del diccionario como TEST o PASSWORD. - Cubrir una amplia gama de tipos de secretos
Más allá de las claves API, incluir certificados, claves SSH, contraseñas de bases de datos y más. - Detener las filtraciones antes de que ocurran
Proporcionar hooks de pre-commit o integraciones IDE para evitar que los secretos entren en el control de versiones. - Escalar a través de repositorios y pipelines
Funcionar eficazmente en CI/CD, a través de historiales y a escala empresarial.
Conclusión
La detección de secretos parece sencilla, pero probarla es todo lo contrario. Las herramientas ruidosas que marcan cada secreto falso pueden parecer impresionantes, mientras que las herramientas más inteligentes que validan y filtran parecen hacer menos.
Si quieres probar correctamente, utiliza honey tokens, claves de acceso limitado o repositorios reales. Y al evaluar, busca las cualidades que importan en producción: validación, detección de patrones, análisis de entropía, filtrado por diccionario, amplia cobertura y, sobre todo, prevención antes del commit.
Porque la clave falsa de AWS que plantaste para las pruebas no es peligrosa. La real, escondida a plena vista, sí lo es.
