Configuración y secretos en el repositorio

En la configuración de una aplicación web hay cuatro preguntas que se hacen siempre. Qué pasa cuando hay un error: si la respuesta lleva trazas, rutas internas o mensajes del motor, quien lo provoque aprende cómo está hecho el sistema. Cómo se protege la sesión: si la cookie va solo por canal cifrado y no la lee el código del navegador. Quién puede llamar a la API desde otro origen. Y de dónde salen las claves: de variables de entorno o de un gestor de secretos, que es lo correcto, o escritas en un archivo del repositorio.

Lo que importa es la configuración que usa el entorno evaluado, no la de los equipos de los desarrolladores: un ajuste permisivo en el archivo de desarrollo es lo esperado, y el mismo ajuste en el de producción es un hallazgo.

Abre el laboratorio y lee la configuración de producción, que según su propio comentario también usa el entorno de pruebas. Busca el ajuste que decide qué ve el cliente cuando algo falla. El historial dice además cuándo se cambió y por qué: un ajuste de depuración que se activó para resolver un problema y nadie volvió a apagar es uno de los hallazgos más repetidos en cualquier revisión.

Cuando alguien quita una clave de un archivo y hace un commit, la clave desaparece de la versión actual, pero sigue en el commit anterior, y en todas las copias del repositorio que se hicieron desde entonces: las de cada desarrollador, la del servidor de integración, la que se entregó al evaluador. Por eso la corrección de una clave expuesta no es borrarla: es rotarla, de modo que el valor viejo deje de servir, y después, si se decide, limpiar el historial.

El escáner de secretos revisa también el historial y dice en qué commit aparece cada coincidencia. Ordena las coincidencias por lo que son: marcadores de plantilla, valores de desarrollo, datos de prueba o una clave que alguna vez fue la de producción.

Una clave en el historial es grave si todavía sirve. El evaluador no lo comprueba usándola: la carta lo prohíbe, y además usar una credencial ajena para ver si funciona es justo lo que no se hace en ningún encargo. Se comprueba con información del propio cliente: la fecha de la última rotación frente a la fecha en que la clave entró en el repositorio. Si la rotación es anterior, el valor del historial es el que está en uso.

Un escáner de secretos busca formas: asignaciones a variables con nombres como clave o secreto, cadenas con mucha variedad de caracteres, prefijos conocidos. Por eso marca también las plantillas con marcadores, los valores de desarrollo y los datos de las pruebas automáticas. Cada coincidencia se cierra con una razón, igual que una alerta del analizador. Y en el informe ninguna lleva el valor: se cita el archivo, el commit y la fecha, que es lo que el cliente necesita para encontrarla.