Un desarrollador hizo commit en GitHub, el archivo de config que incluyó tiene la password de la base de datos. Se ve en un repo público. ¿Qué hago ya?
Cambié la contraseña en la base de datos, pero en el historial de GitHub todavía se ve. ¿Borro el historial de commits?
¿Se puede hacer detección de secretos con herramientas automatizadas? ¿Puedo pillarlo antes?
Respuesta a incidente de filtración de secretos (Secret Leak): La respuesta rápida es crítica. Pasos: 1) INMEDIATO (1-5 min): a) Cambiar contraseña de la BD, b) Revocar acceso al repo de GitHub (revisar colaboradores), c) Activar alertas de secret scanning si existen (Settings → Security → Secret scanning), 2) CORTO PLAZO (5-30 min): a) Limpiar historial de Git (BFG Repo-Cleaner: bfg --delete-files 'config.yml' — reescribe el historial), b) Force push (git push --force-with-lease) — OJO: Requiere coordinación con el equipo, c) Revisar otros repos (grep -r password *.git), 3) REVISIÓN (30-60 min): a) Revisar git log (quién hizo push, cuándo), b) Logs de acceso (BD): ¿hay intentos de acceso sospechosos?, c) Revisar AWS CloudTrail, GCP Cloud Audit Logs, 4) NOTIFICACIÓN: a) Informar al equipo (aviso de reescritura de git, se requiere rebase), b) Equipo de BD (rotación de contraseñas). Herramientas de prevención: 1) .gitignore (excluir archivos de config), 2) Variables de entorno (.env, ignoradas por git), 3) GitHub secret scanning (interno + terceros: TruffleHog, GitGuardian), 4) Hooks de commit (framework pre-commit: detectar secretos antes del commit), 5) Escaneo automático (CI/CD: escanear commits por patrones). Mitigación de riesgos: Logs de acceso a BD (IPs sospechosas, patrones de consulta), API rate limiting (prevención de fuerza bruta), MFA en la BD (si está soportado).
cambien la contraseña ya en la db. para borrar el historial en github usen bfg-repo-cleaner o git-filter-branch. avisen al equipo que tienen que hacer git rebase. bueno activen el secret scanning en github bfg lo hace automático en el historial.....
Remediación de secretos: 1) BFG Repo-Cleaner (bfg --replace-text passwords.txt --no-blob-protection repo.git), 2) git-filter-branch (legacy, más lento pero preciso), 3) GitHub secret scanning + revocación automática (si es token, auto-revoke), 4) Auditoría: git log -S 'password' --all (buscar commits), 5) Notificar: verificar si los atacantes accedieron a la base de datos (query logs, intentos de login fallidos, geolocalización de IP). Implementación de prevención: pre-commit hook (framework pre-commit + plugins: detect-secrets, truffleHog), escaneo en CI/CD (GitHub Actions: Trivy, GitGuardian), plantilla .gitignore (.env, *.key, config.local.yml). Comunicación con el equipo: reescribir el historial de git requiere que todos los usuarios hagan force-pull + rebase (sobrecarga de coordinación).
Doki · Aplicación móvil · 2026
cambien la contraseña ya usen BFG para borrar el historial. avisen al equipo que necesitan hacer git rebase... activen el secret scanning en GitHub. instalen un pre-commit hook (truffleHog, detect-secrets) para detectar esto en el futuro. agreguen escaneo en CI/CD...
Automatización de detección de secretos: 1) Pre-commit local (framework pre-commit + plugin detect-secrets), 2) Pipeline CI/CD (GitHub Actions, GitLab CI: TruffleHog, GitGuardian), 3) Escaneo de repositorio (GitHub native secret scanning, GitLab security scanning), 4) Auditoría de historial de Git (git-secrets git-dumper). Automatización de respuesta: GitHub secret scanning → auto-revoke (para tokens de GitHub), alertar al equipo, crear incidente. Buenas prácticas: plantilla .gitignore (excluir *.key, *.pem, .env config/*local*) estrategia de variables de entorno (todos los secretos desde vars de entorno de CI/CD, nunca en código), servicio de gestión de secretos (HashiCorp Vault, AWS Secrets Manager).
Soy una pequeña empresa, os lo cuento desde mi lado. Lo importante no es la cifra, sino en qué se basa esa cifra.
Comprobado por experiencia.
Gracias, me ha servido de mucha ayuda. Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.
Eso es todo, disculpa si me he extendido demasiado.
Separemos los conceptos, se están confundiendo. Si regañas las falsas alarmas, nadie volverá a reportar.
Corrijanme si me equivoco.
Doki · Identidad de marca · 2026
Os cuento lo que me pasó a mí, a ver si os sirve de ayuda. El error cometido por contraseña olvidada en el código fuente suele ser reversible, pero caro.
Empezad con una pequeña prueba, no lo integréis todo de golpe. Eso es todo, disculpa si me he extendido demasiado.
Creo que este consejo no sirve para todos. La mayoría de los incidentes no empiezan por una vulnerabilidad, sino por una contraseña filtrada.
Aquí hay que hacer una distinción. Si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde.
Yo seguiría por ese camino.
Soy una pequeña empresa, os lo cuento desde mi lado. Los cambios en los datos de pago nunca se verifican por el mismo canal por el que llegan.
Os cuento lo que me pasó a mí, a ver si os sirve de ayuda. Todo lo que no está por escrito, ambas partes lo recordarán de forma distinta en el futuro.
La gente no defiende el proceso, defiende la costumbre. La resistencia viene de ahí. Esta es mi opinión, no lo escribo como una verdad absoluta.
Si lo ves como un proceso, el panorama cambia. La seguridad no es absoluta; significa hacer que el ataque no merezca la pena.
Por supuesto, cambia si tu situación es diferente.