Los secretos en el código fuente (credenciales codificadas de forma fija, claves de API, cadenas de conexión a bases de datos, claves privadas y tokens de autenticación confirmados en repositorios de control de versiones) representan una de las vulnerabilidades de la cadena de suministro de software más frecuentes y de mayores consecuencias. Son frecuentes porque los flujos de trabajo de los desarrolladores bajo presión de tiempo suelen tomar atajos que incluyen las credenciales directamente en el código o en archivos de configuración. Tienen grandes consecuencias porque, una vez confirmadas en un repositorio, las credenciales pasan a ser accesibles para cualquiera con acceso al repositorio y, en repositorios públicos o semipúblicos, para cualquiera que pueda acceder al repositorio o clonarlo, incluso después de que las credenciales se eliminen de la base de código actual.
El problema del historial de git es el mecanismo de persistencia concreto que hace que 'eliminar las credenciales del código' sea una respuesta insuficiente. Los sistemas de control de versiones git conservan un historial completo de cada confirmación realizada en un repositorio. Una credencial confirmada y luego eliminada en una confirmación posterior sigue presente en el historial de git del repositorio, accesible para cualquiera que clone el repositorio y examine las confirmaciones anteriores. Es posible que la credencial se haya eliminado del extremo actual de la rama, pero permanece en el historial inmutable de confirmaciones. Una remediación adecuada requiere no solo eliminar la credencial del código actual, sino también reescribir el historial de git para borrar la confirmación (lo cual es destructivo y perjudicial) o rotar de inmediato la credencial expuesta.
La amenaza del análisis de repositorios públicos es el mecanismo de descubrimiento automatizado. Las herramientas automatizadas analizan continuamente los repositorios públicos de GitHub, GitLab y Bitbucket en busca de patrones de credenciales, revisando los historiales de confirmaciones, incluidas las históricas, en busca de formatos de claves de API, encabezados de claves privadas, cadenas de conexión y otros patrones de credenciales. Una credencial confirmada en un repositorio público en 2021 que se 'eliminó' mediante una confirmación posterior en 2021 sigue siendo detectable en 2024 por cualquiera que ejecute un análisis del repositorio. El tiempo transcurrido no reduce la validez de la credencial a menos que se haya rotado.
Por qué es importante
Los secretos en el código fuente importan para TPRM porque los repositorios de desarrollo de sus proveedores pueden contener credenciales que dan acceso a sistemas que tratan sus datos: credenciales de bases de datos de producción, claves de proveedores de nube, tokens de API de servicios que manejan sus datos. Una credencial comprometida en el repositorio de un proveedor es un vector de ataque a la cadena de suministro que no requiere explotar ninguna vulnerabilidad del software en ejecución del proveedor.
- Confirmación de la política aceptada sin verificación técnica
- El historial de git no está incluido en el alcance del análisis de secretos
- No se realiza un análisis de los repositorios públicos como parte de la evaluación de proveedores
- No se confirma la rotación de credenciales como respuesta a una exposición pasada
- El control de acceso a los repositorios no se evalúa junto con la gestión de secretos
Cómo se ve una buena práctica
Los programas maduros de gestión de secretos implementan ganchos de detección de secretos previos a la confirmación que impiden que los secretos lleguen al control de versiones, el análisis continuo de los historiales de los repositorios en busca de patrones de credenciales, la rotación inmediata como respuesta obligatoria ante cualquier exposición de credenciales descubierta y la revisión explícita del historial de git como parte de la evaluación de proveedores.
- Ganchos previos a la confirmación que impiden que los secretos lleguen al control de versiones
- Análisis continuo de los repositorios, incluido el historial de git
- Rotación inmediata de credenciales como respuesta obligatoria ante cualquier exposición
- Revisión del historial de git en busca de credenciales expuestas, no solo del código actual
- Análisis de los repositorios públicos como parte de la evaluación de la cadena de suministro de software del proveedor
Herramientas
Detección de secretos: GitLeaks, TruffleHog, GitHub Secret Scanning para el análisis de repositorios e historiales
Las herramientas de detección de secretos pueden analizar historiales completos de repositorios, no solo el código actual, en busca de patrones de credenciales. GitLeaks y TruffleHog admiten el análisis de confirmaciones históricas. Las alertas de análisis de secretos de GitHub están disponibles para los repositorios públicos. Para los profesionales de TPRM, ejecutar GitLeaks o TruffleHog sobre los repositorios públicos de un proveedor como parte de la evaluación de la cadena de suministro de software proporciona una comprobación concreta de exposición de credenciales que la confirmación mediante cuestionario no puede sustituir.
Ganchos previos a la confirmación: detect-secrets, git-secrets para la detección de credenciales antes de la confirmación
Los ganchos previos a la confirmación que analizan los cambios preparados en busca de patrones de credenciales antes de confirmarlos proporcionan el mecanismo de prevención que impide que las credenciales lleguen al control de versiones. Para los profesionales de TPRM, preguntar si los proveedores utilizan ganchos de detección de secretos previos a la confirmación junto con el análisis posterior a la confirmación ofrece una pregunta concreta sobre prevención frente a detección.
Desafíos de gobernanza
El desafío de gobernanza de los secretos en el código fuente es la complejidad de remediar el historial de git. Una vez que una credencial se ha confirmado en un repositorio con varios colaboradores, reescribir el historial de git para eliminarla resulta perjudicial: obliga a todos los colaboradores a rehacer sus cambios sobre el nuevo historial o a volver a clonar el repositorio. La solución pragmática es la rotación inmediata de la credencial, que inutiliza la credencial confirmada en el historial con independencia de que se haya limpiado o no el historial de git, combinada con ganchos previos a la confirmación para impedir futuras confirmaciones.
- Implementar la detección de secretos previa a la confirmación: prevención antes del control de versiones
- Analizar todo el historial del repositorio, no solo el código actual
- Exigir la rotación inmediata de credenciales ante cualquier exposición descubierta
- Analizar los repositorios públicos de los proveedores de software crítico
- Incluir el historial de git en el alcance de la evaluación de la gestión de secretos del proveedor
Si usted forma parte de un equipo pequeño
Ejecute GitLeaks sobre los repositorios públicos de GitHub de sus tres proveedores de software más críticos. El comando tarda minutos por repositorio y busca patrones de credenciales en todo el historial de git. Revise los hallazgos: cualquier patrón de credencial encontrado en el historial debe tratarse como una posible exposición y verificarse con el proveedor si la credencial se ha rotado. Ese análisis le dirá más sobre la higiene histórica de credenciales del proveedor que cualquier confirmación mediante cuestionario.
- Ejecutar GitLeaks sobre los repositorios públicos de los proveedores críticos
- Revisar los hallazgos y verificar la rotación de credenciales para cualquier exposición descubierta
- Preguntar al proveedor por la implementación de ganchos previos a la confirmación en los repositorios de desarrollo
- Exigir la divulgación de la rotación de credenciales como parte de la evaluación de proveedores
Qué exigir
Pregunte directamente:
"¿Utilizan ganchos de detección de secretos previos a la confirmación en todos sus repositorios de desarrollo y han analizado los historiales de sus repositorios, incluidas las confirmaciones históricas, en busca de credenciales expuestas? ¿Pueden confirmar que se han rotado todas las credenciales descubiertas en el historial de los repositorios?"
Evidencia que debe esperar
- Implementación de ganchos de detección de secretos previos a la confirmación
- Cobertura del análisis del historial de los repositorios
- Confirmación de la rotación de credenciales para cualquier exposición histórica
- Política de gestión de secretos y su aplicación
A un proveedor que confirme que no tiene credenciales codificadas de forma fija se le debe preguntar específicamente por el alcance respecto del historial de git y por la implementación de ganchos previos a la confirmación. La política prohíbe. Los ganchos previos a la confirmación previenen. El análisis del historial detecta. La rotación remedia. Los cuatro son necesarios para una cobertura completa de la gestión de secretos.
Cómo demostrarlo
- Registros del análisis de los repositorios públicos de los proveedores críticos
- Verificación de la implementación de ganchos previos a la confirmación
- Proceso de confirmación de la rotación de credenciales
- Cobertura del análisis del historial de los repositorios
Conclusión clave
Política: ninguna credencial codificada de forma fija. Código: credenciales eliminadas. Historial de git: clave de AWS, cadena de conexión a base de datos, clave privada de RSA; 31 meses, todavía accesibles para cualquiera que clone el repositorio. La política era real. La eliminación fue incompleta. Eliminar las credenciales del código actual las deja en el historial de git. El análisis del historial de git las encuentra. Los ganchos previos a la confirmación impiden la siguiente confirmación. La rotación inmediata inutiliza la credencial histórica, se haya limpiado o no el historial. Política más prevención más detección más rotación es una cobertura completa de la gestión de secretos. Política más eliminación del código actual es incompleta.