Clave API expuesta en Git: cómo responder sin limitarse a borrar el commit
Por Carlos Isidoro De Ayala Diaz ·
Clave API expuesta en Git: cómo revocar, rotar, investigar su uso, limpiar el repositorio y evitar que el secreto reaparezca en código o pipelines de CI.
Trata la exposición como una credencial comprometida
Encontrar una clave API en Git no es un problema que se resuelva borrando una línea y creando otro commit. La credencial pudo quedar en el historial, en una rama, una solicitud de cambios, un fork, un clon local, una caché o el registro de un pipeline. Aunque el repositorio sea privado, cualquier persona, integración o copia con acceso durante el intervalo de exposición debe formar parte del análisis. La primera decisión consiste en tratar la clave como potencialmente comprometida hasta demostrar y documentar lo contrario.
El aviso necesita un registro mínimo antes de que cambie el contexto: proveedor que emitió la clave, sistema al que da acceso, repositorio, ruta y commit donde apareció, fecha aproximada de introducción, ramas afectadas, permisos, entornos y aplicaciones que la consumen. La clave completa no se copia en un ticket, un chat ni una captura. Basta con un identificador seguro o sus últimos caracteres cuando el proveedor permite reconocerla sin volver a exponerla.
Contener y conservar evidencia pueden avanzar en paralelo. Si la clave permite modificar datos, administrar infraestructura, enviar correo o generar costes, no se retrasa la revocación para completar una investigación perfecta. Antes de modificar el repositorio se guardan referencias, horas y registros disponibles sin duplicar el secreto. Después se delimita desde cuándo pudo usarse, quién tenía acceso al repositorio y qué actividad aparece en la cuenta del proveedor durante ese periodo.
El impacto no depende solo de que alguien haya visto el valor. Importan los permisos asociados, restricciones de red, fecha de caducidad, entorno y capacidad de crear otras credenciales. Una clave de solo lectura para un conjunto limitado no equivale a una credencial administrativa compartida por producción y pruebas. La respuesta documenta ese alcance y comprueba si el mismo valor se reutilizó en otras aplicaciones, variables, imágenes de contenedor, paquetes, archivos de ejemplo o copias de seguridad.
Revoca o rota en el proveedor antes de reescribir el historial
GitHub recomienda revocar o rotar primero los secretos expuestos. El objetivo inmediato es que el valor publicado deje de servir, incluso si permanece en una copia que la empresa no controla. Según el servicio, se puede revocar de inmediato o crear una credencial nueva, actualizar consumidores autorizados, comprobarlos y retirar la anterior. Una transición breve puede evitar una interrupción, pero mantener activa una clave que se sospecha comprometida conserva el riesgo durante todo el solapamiento.
La sustitución se prepara con un inventario de consumidores. Aplicaciones, funciones, procesos programados, herramientas de integración y entornos pueden leer la misma variable. Cada uno recibe la nueva credencial mediante el mecanismo aprobado y se prueba una operación representativa. Reiniciar una aplicación no revoca el valor antiguo. La revocación se confirma en el proveedor y, cuando exista esa capacidad, se intenta una llamada controlada con el identificador retirado para verificar que ya no autoriza.
La credencial nueva no debe heredar permisos por comodidad. La rotación es una oportunidad para reducir alcance, separar desarrollo y producción y asignar propietario. OWASP recomienda aplicar mínimo privilegio, limitar la intervención humana y usar secretos dinámicos o de vida corta cuando la plataforma lo permita. En pipelines puede evaluarse una identidad federada que obtenga tokens temporales, evitando guardar una clave estática de larga duración como variable permanente.
Los registros del proveedor ayudan a investigar el uso. Se revisan llamadas, IP, identidad, fecha, recurso y resultado dentro del periodo relevante, teniendo en cuenta la retención disponible. Una ausencia de eventos no demuestra por sí sola que nadie utilizó la clave si el servicio no registraba todas las operaciones. Si la credencial podía emitir tokens, crear usuarios o cambiar permisos, también se buscan efectos secundarios y se retiran accesos derivados que no queden anulados al revocar el valor original.
Limpia el repositorio y los canales por los que pasó el secreto
Con la credencial invalidada se decide si hace falta reescribir el historial. GitHub explica que esta operación cambia identificadores de commits, puede afectar firmas, ramas y solicitudes de cambios y exige coordinar a quienes mantienen clones. Un force push aislado no garantiza la eliminación: una persona puede volver a introducir el historial antiguo al mezclar y publicar su copia. Por eso se detienen temporalmente cambios sobre las referencias afectadas, se identifica a los colaboradores y se define cómo deben volver a clonar o limpiar sus repositorios.
La búsqueda incluye todas las ramas, etiquetas y rutas anteriores del archivo, además de forks, artefactos, versiones publicadas, paquetes y cachés que puedan conservar el valor. También se inspeccionan registros de CI, salidas de depuración y adjuntos de incidencias. Cuando GitHub mantiene referencias en solicitudes de cambios o vistas almacenadas, la documentación indica que puede ser necesaria la coordinación adicional con soporte. No se afirma que una reescritura local borre una copia que ya salió de la organización.
La limpieza debe evitar la recontaminación. Antes de publicar el historial nuevo se actualizan las plantillas de configuración, documentación y pruebas para que usen nombres de variables o valores sintéticos. Los colaboradores no deben fusionar ramas basadas en el historial antiguo; siguen el procedimiento acordado y comprueban que la cadena sensible ya no aparece. La comparación se realiza con herramientas de detección y con búsquedas que no impriman el secreto completo en nuevos logs.
El cierre técnico relaciona cada ubicación con una acción: clave revocada, consumidor migrado, commit tratado, clon sustituido, artefacto retirado o limitación registrada. Si un fork externo o una copia ajena no puede eliminarse, esa limitación permanece visible, pero la revocación reduce su capacidad de acceso. Borrar el historial protege frente a exposiciones futuras y evita que el valor siga apareciendo; no reemplaza la investigación de lo ocurrido mientras estuvo activo.
Previene la repetición con controles que el equipo pueda operar
La prevención comienza sacando secretos del código. Las aplicaciones reciben credenciales en tiempo de ejecución desde un gestor de secretos, una identidad de carga o una variable protegida administrada por el entorno. Los valores no se incorporan a imágenes, archivos generados ni paquetes de frontend. Cada secreto tiene propietario, finalidad, consumidores, permisos, entorno, fecha de revisión y un procedimiento de rotación. Si nadie sabe qué se rompe al cambiarlo, la organización tenderá a mantenerlo indefinidamente.
La detección se coloca antes y después del commit. Una comprobación local puede avisar durante el desarrollo; el escaneo del repositorio localiza patrones ya almacenados; y la protección de inserción de GitHub bloquea secretos compatibles antes de que lleguen al repositorio. Los bypass necesitan motivo y revisión porque una excepción sin seguimiento convierte el control en una advertencia decorativa. También se definen reglas propias para formatos internos que una plataforma pública no pueda reconocer.
Los ejemplos, documentación y pruebas usan valores falsos claramente identificados. Los entornos se separan para que una credencial de desarrollo no acceda a producción, y los pipelines filtran la salida antes de conservar logs. Las aplicaciones no devuelven claves en mensajes de error y los sistemas de observabilidad las enmascaran. NIST SSDF plantea integrar prácticas seguras en el ciclo de desarrollo y corregir causas para evitar recurrencias; la respuesta no termina al cerrar el incidente.
Élite Solutions Tech puede revisar desde Murcia cómo una empresa almacena, entrega y rota claves API en desarrollos regionales o nacionales. La propuesta concreta repositorios, pipelines, proveedores, entornos, permisos y evidencias incluidos, y diferencia contención, limpieza de historial, mejora del proceso y comprobación posterior. No promete eliminar copias fuera del control de la empresa. Para una primera valoración puedes indicar el tipo de credencial, el repositorio y el entorno afectado mediante el formulario de contacto, sin enviar la clave ni otros secretos.