Un desarrollador subió por accidente una clave de acceso de AWS a un repositorio PÚBLICO de GitHub. ¿Cuál es el orden de respuesta correcto?

Una filtración de credenciales en la nube es un incidente con el reloj corriendo. Bots automatizados rastrean continuamente los eventos públicos de GitHub, y las claves de AWS expuestas se usan habitualmente para desplegar flotas de minería de criptomonedas en cuestión de minutos tras la subida. El instinto del candidato debe ser la contención antes que la limpieza.

Por qué revocar y rotar primero

En cuanto un secreto llega a un commit público, hay que asumir que está comprometido — no hay forma de demostrar que un bot no lo capturó. Revocar (desactivar/eliminar) y rotar la clave de acceso corta de raíz a cualquier atacante que ya la tenga. Solo una vez muerta la clave activa se investiga: extraer CloudTrail para ver qué hizo la clave, buscar llamadas a la API inesperadas, nuevos usuarios IAM, instancias lanzadas o accesos a datos, y luego purgar el secreto del historial de git (por ejemplo con git filter-repo) y avisar a quien haya bifurcado el repositorio.

Por qué los distractores son incorrectos

• Borrar el commit. Es la respuesta débil clásica. Una vez subido a un repo público, el commit probablemente ya fue clonado, bifurcado, indexado por escáneres y cacheado por la propia API de eventos de GitHub. Reescribir el historial no des-filtra el secreto — y da una falsa sensación de seguridad mientras una clave activa sigue siendo válida.
• Hacer el repo privado y seguir usando la clave. La clave ya era pública; cambiar la visibilidad del repo no hace nada contra las copias ya tomadas. Seguir usando una clave filtrada es dejar la puerta principal abierta.
• Añadir el archivo de la clave al .gitignore. .gitignore solo impide que archivos futuros y no rastreados se preparen. No tiene efecto alguno sobre un secreto ya commiteado y subido.

Qué está sondeando el entrevistador

Quiere ver que ordenas tus acciones por reducción del radio de impacto: matar la credencial, luego investigar, luego limpiar. También quiere la conciencia situacional de que la exposición pública es irreversible, así que la única suposición segura es el compromiso total. Puntos extra por mencionar controles compensatorios — escaneo de secretos en pre-commit, credenciales efímeras mediante roles IAM u OIDC, y la protección de subidas de GitHub — para que esto no vuelva a ocurrir.