Cometer errores al subir información sensible a un repositorio es más común de lo que parece. Aunque el archivo .gitignore es la primera línea de defensa, una llave de API o una cadena de conexión pueden terminar expuestas en el historial de commits por un simple descuido. Conocer las herramientas que GitHub ofrece para detectar estas filtraciones, y sobre todo entender sus limitaciones, marca la diferencia entre un proyecto seguro y uno vulnerable.
¿Qué tipo de información sensible puede filtrarse en un repositorio?
Dentro del código fuente o los archivos de configuración de un proyecto pueden aparecer datos que nunca deberían ser públicos:
- Llaves de acceso a una API (como una Stripe API Key).
- Cadenas de conexión a bases de datos.
- Credenciales de servicios de terceros.
El problema no termina con borrar la línea comprometida. Cada commit queda registrado en el historial de Git, por lo que cualquier persona con acceso al repositorio podría recuperar ese dato incluso después de eliminarlo del código actual [01:05].
¿Cómo activar Code Scanning y Secret Scanning en GitHub?
Para habilitar estas herramientas es necesario que el repositorio sea público (en repositorios privados estas opciones pueden no estar disponibles en planes gratuitos) [02:00].
El proceso para configurarlas es el siguiente:
- Ir a Settings del repositorio.
- Buscar la sección Code Security and Analysis [02:15].
- Dentro de Code Scanning, seleccionar la herramienta CodeQL Analysis y dejar la configuración por defecto. GitHub detecta automáticamente el lenguaje principal del proyecto.
- En el panel de seguridad aparecen tres categorías de alertas: Dependabot, Code Scanning y Secret Scanning [02:50].
Cuando Secret Scanning detecta un secreto activo, genera una alerta indicando el tipo de credencial expuesta y ofrece recomendaciones claras para mitigar el daño.
¿Qué hacer cuando se filtra un secreto?
GitHub propone cuatro pasos esenciales ante cualquier filtración [03:15]:
- Rotar la credencial: acudir al servicio de terceros y solicitar nuevas llaves de acceso. Las anteriores deben quedar invalidadas de inmediato.
- Modificar el código: eliminar el secreto del archivo fuente.
- Prevenir futuras filtraciones: utilizar archivos de variables de entorno (
.env, appsettings.json) y agregarlos al .gitignore.
- Revisar el historial: verificar que no existan otros commits con información comprometida.
Simplemente borrar la línea no es suficiente. La rotación de credenciales es el paso más crítico porque el secreto ya quedó expuesto en el historial de cambios.
¿Es infalible Secret Scanning de GitHub?
La respuesta directa es no. Durante la demostración se comprobó que patrones reconocidos, como una Stripe API Key, son detectados rápidamente. Sin embargo, al agregar una cadena de conexión a SQL con un nombre genérico como testing_connection, el escaneo no generó ninguna alerta nueva incluso después de varios minutos [04:45].
Esto demuestra que GitHub identifica patrones conocidos pero no puede detectar todas las variantes de información sensible. Si el nombre de la variable o el formato de la cadena no coincide con los patrones predefinidos, la filtración pasa desapercibida [05:30].
¿Cuál es la mejor estrategia para proteger secretos en tus proyectos?
La prevención siempre será más efectiva que la corrección. Las variables de entorno almacenadas en archivos como .env o appsettings.json permiten mantener las credenciales fuera del código fuente. Al incluir estos archivos en el .gitignore, se evita que lleguen al repositorio [06:10].
Rotar llaves de acceso o cadenas de conexión después de una filtración es un proceso complejo, especialmente cuando múltiples productos o servicios dependen de las mismas credenciales [06:30].
Las mejores prácticas se resumen en:
- Usar archivos de variables de ambiente para toda información sensible.
- Configurar
.gitignore antes del primer commit del proyecto.
- Activar Code Scanning y Secret Scanning como red de seguridad adicional.
- Nunca confiar exclusivamente en las herramientas automatizadas.
Si adoptas estas prácticas desde el inicio, lo ideal es que las alertas de seguridad de GitHub permanezcan siempre en cero. ¿Has tenido alguna experiencia con filtraciones de credenciales en tus repositorios? Comparte cómo lo resolviste.
