La auditoría de repos: ese momento incómodo, pero necesario (como el chequeo anual)

Me estaba sirviendo una cerveza —porque me la merecía después de pelear con un merge conflict eterno— cuando me pregunté: “¿Y cuándo fue la última vez que alguien auditó este repo? ¿O estamos navegando en un basural elegante?” Y ahí mismo, mientras caía la espumita, me di cuenta: la auditoría de repositorios es como ir al médico… nadie quiere, pero si no vas, después es peor.

Les cuento una cosa: se han fijado que los repos envejecen como la leche, no como el vino, si nadie los revisa. Archivos olvidados, ramas que nadie usa, secretos expuestos, dependencias obsoletas… todo eso se acumula hasta que explota en el peor momento. Por eso la auditoría no es solo para empresas grandes: cualquier repo que viva más de un mes ya necesita una miradita crítica.

🔥 ¿Cuándo hacer una auditoría de repos?

✔️ Antes de un release importante o migración: para asegurar que solo subes lo necesario y nada comprometedor.
✔️ Cada cierto tiempo (trimestral, semestral), como limpieza de primavera digital.
✔️ Cuando heredas un repo viejo y nadie sabe qué hay adentro.
✔️ Después de un incidente de seguridad o leak (¡obvio!).

➜ ¿Qué se hace en una auditoría?

✔️ Revisar el historial de commits
– ¿Hay commits sospechosos? (“subiendo passwords”, “arreglando rápido pa’ pasar”).
– ¿Commits que subieron archivos sensibles y fueron borrados, pero quedaron en el historial?

✔️ Verificar el .gitignore
– ¿Están bien ignorados los binarios, dependencias, archivos locales?
– ¿Alguien metió carpetas de IDE, node_modules, .env?

✔️ Escaneo de secretos expuestos
– Usar herramientas como git-secrets, truffleHog, gitleaks para buscar API keys, tokens, contraseñas en TODO el historial, no solo en el HEAD.

✔️ Auditoría de dependencias
– Revisar npm audit, pip-audit, yarn audit, snyk, o el que toque según tu stack.
– Actualizar librerías vulnerables.

✔️ Revisión de ramas
– Eliminar ramas muertas, fusionadas o que quedaron colgando.
– Nombrar consistentemente las ramas vivas.

✔️ Permisos y accesos
– ¿Quién tiene acceso al repo? ¿Hay ex-empleados o gente que ya no debería tener permisos?
– Revisar llaves de deploy, accesos SSH, tokens de CI/CD.

✔️ Verificar configuración de hooks, CI/CD
– ¿Hay scripts raros en hooks o pipelines que nadie sabe qué hacen?
– ¿El pipeline está versionado y bien documentado?

➜ ¿Qué hacer después de auditar?

✔️ Documentar lo encontrado.
✔️ Corregir lo urgente (claves expuestas, ramas públicas con datos sensibles).
✔️ Planificar mejoras (actualización de dependencias, cleanup).
✔️ Comunicar al equipo las nuevas buenas prácticas.

Se han fijado que una auditoría es como destapar el closet de la abuela… siempre sale algo inesperado. Pero mejor sacarlo tú que esperar a que caiga en la cabeza de alguien más.

Bueno, eso sería… mi cerveza ya se calentó porque me embalé escribiendo, pero valió la pena. ¡Pórtense mal, pero auditen bien antes que su repo sea el meme del caos! 🦡🔍✨