Auditoría de código: qué revisar en una base de código heredada

Una auditoría de código es una revisión estructurada de una base de código que te dice qué tienes realmente: qué funciona, qué es riesgoso y qué te va a costar dinero más adelante. Cuando heredas software de una agencia o de un desarrollador que se fue, la auditoría es la primera información concreta que recibes.

El orden importa más que las herramientas. El orden que sigo en los primeros 30 días de una transición es: primero los accesos, luego el build, luego los flujos de dinero y luego los riesgos. Este artículo sigue ese orden, para que puedas hacer la auditoría tú mismo o comprobar si alguien la hizo bien.

¿Qué es una auditoría de código y cuándo la necesitas?

Una auditoría de código revisa el código fuente, la infraestructura y la operación para responder preguntas prácticas. ¿Podemos cambiar esto de forma segura? ¿Puede perder dinero o datos? ¿Qué se rompe si se va la única persona que lo entiende? No es una propuesta de reescritura ni un juicio sobre el talento de los desarrolladores anteriores. Muchos problemas vienen de plazos ajustados y falta de presupuesto, no de malos ingenieros.

Situaciones comunes que la motivan

• Estás dejando una agencia, o una agencia te está dejando a ti.
• El único desarrollador renunció, fue despedido o dejó de responder mensajes.
• La app se generó con herramientas de IA y está a punto de recibir usuarios reales.
• Estás planeando una migración y necesitas saber qué hay realmente en el sistema.
• Vas a comprar una empresa o a levantar capital y alguien hará preguntas difíciles. Ese es un ejercicio relacionado, llamado due diligence técnica.

Si todo funciona, el equipo es estable y entiendes el sistema, quizá no necesites una auditoría completa. Aun así, una revisión ligera de accesos y backups es un seguro barato.

¿Tienes acceso a todo: repositorios, hosting, dominios, secretos?

Empieza aquí, porque todo lo demás depende de esto. Un patrón que busco en cada transición es código que está bien mientras un activo crítico, como el dominio, está registrado con el correo personal de un excontratista. Eso es un riesgo de negocio, no técnico, y puede permanecer oculto hasta el día en que falla una renovación.

Haz un inventario y confirma que tú, como empresa, tienes acceso de propietario a cada elemento:

Una vez que tengas acceso, rota las credenciales que conocía el equipo anterior. Eso incluye claves de API, contraseñas de base de datos y logins compartidos. Es práctica estándar después de cualquier cambio de equipo.

¿El proyecto se compila y se despliega desde cero?

Es lo primero que pruebo en cualquier transición, y dice mucho: en una máquina limpia, ¿alguien puede seguir el README, ejecutar el proyecto en local y hacer un despliegue? Si la respuesta es no, encontraste un problema serio. Un sistema que solo una laptop o una persona puede desplegar es frágil.

Revisa estos puntos:

1. Clonar e instalar. ¿Se instala con comandos documentados? ¿Las versiones del runtime están fijadas?
2. Ejecución local. ¿Necesita datos de producción o secretos que nadie encuentra? ¿Hay un seed o una base de datos de prueba?
3. Pruebas. ¿Existen y pasan? Una suite de pruebas pequeña y confiable vale más que una grande y rota.
4. Despliegue. ¿Está automatizado mediante un pipeline o depende de pasos manuales que alguien hacía de memoria?
5. Entornos. ¿Hay un entorno de staging parecido a producción, o cada cambio va directo al sistema en vivo?
6. Rollback. Si una versión falla, ¿cómo vuelves a la anterior?

Anota cada brecha que encuentres. Anota también las dependencias abandonadas, fijadas en versiones muy antiguas o que requieren runtimes al final de su vida útil. Ellas determinan el costo de cada cambio futuro.

¿Son seguros los flujos de dinero (pagos, autenticación, facturación)?

Después del build, revisa todo lo que toca ingresos o identidad. A esto lo llamo los flujos de dinero: pagos, checkout, suscripciones, facturación, login, restablecimiento de contraseña y permisos. Un bug en una página de configuración es una molestia. Un bug aquí cuesta dinero o expone cuentas.

Trabajé en el equipo de carrito y checkout de Total Wine & More, un minorista estadounidense con 190 millones de visitas al año en su sitio. Con ese nivel de tráfico, fallas que parecen casos extremos poco frecuentes pueden aparecer mucho más seguido de lo que esperarías. La lección que saqué aplica a cualquier tamaño: los flujos de dinero merecen más escrutinio que el resto del código, por pequeño que sea el producto.

Qué revisar en pagos y facturación

• ¿El monto del pago se calcula en el servidor, o el cliente puede enviar un precio?
• ¿Los webhooks del proveedor de pagos se verifican con una firma y se manejan de forma segura si llegan duplicados o fuera de orden?
• ¿Almacenas datos de tarjetas? Por lo general no deberías; el proveedor debe guardarlos.
• ¿Los estados de suscripción en tu base de datos coinciden con los del proveedor de pagos?
• ¿Qué pasa cuando un pago falla a mitad de un pedido?

Qué revisar en autenticación

• ¿Cómo se almacenan y restablecen las contraseñas? ¿Los enlaces de restablecimiento son de un solo uso y de corta duración?
• ¿Las sesiones o los tokens expiran y se pueden revocar?
• ¿Cada endpoint verifica no solo quién es el usuario, sino también si puede acceder a ese registro específico?
• ¿Hay una forma de encontrar y desactivar las cuentas de administrador?

Luego rastrea una transacción real de punta a punta, desde el clic en el botón hasta la fila en la base de datos y el panel del proveedor. Te enseña más que leer archivos de forma aislada.

¿Qué problemas de seguridad aparecen con más frecuencia?

En proyectos heredados, los hallazgos rara vez son exóticos. Estos son los que reviso primero:

• Secretos en el repositorio. Claves de API y contraseñas subidas al código o al historial de git. La solución es rotarlas; borrar el archivo no basta.
• Verificaciones de autorización ausentes. Un usuario con sesión iniciada puede leer o editar los datos de otro usuario cambiando un ID en la solicitud.
• Reglas de acceso a la base de datos abiertas. Esto es especialmente común en apps construidas a toda prisa sobre backends gestionados como Supabase, donde las políticas de row level security deben activarse y escribirse de forma deliberada. La herramienta está bien; lo que auditas es la configuración.
• Webhooks sin firmar o sin verificar. Cualquiera que encuentre la URL puede falsificar un evento de pago.
• Dependencias desactualizadas. Vulnerabilidades conocidas en paquetes que nadie ha actualizado. Ejecuta el comando de auditoría de tu ecosistema y lee los resultados por severidad.
• Permisos demasiado amplios. Logins de administrador compartidos, roles en la nube con acceso total, buckets de almacenamiento públicos.
• Manejo débil de entradas. Entradas sin validar que llegan a consultas, cargas de archivos o páginas renderizadas.
• Sin backups, o con backups nunca probados. Un backup que nunca has restaurado es una esperanza, no un backup.
• Logs y monitoreo deficientes. Datos sensibles en los logs y ninguna alerta cuando se disparan los errores.

Este es un checklist práctico, no una prueba de penetración formal. Si manejas datos regulados, como información de salud o de tarjetas de pago, consulta a una firma de seguridad calificada y a tu abogado sobre tus obligaciones. Este artículo no es asesoría legal.

¿Qué debe contener el informe de auditoría?

Un informe que solo enumera problemas es difícil de llevar a la acción. La versión útil ayuda a un fundador no técnico a decidir qué hacer después. Yo esperaría estas partes:

1. Resumen. Una página: estado general, los principales riesgos y una recomendación clara.
2. Inventario de accesos y propiedad. Qué tienes, qué falta y quién debe entregarlo.
3. Hallazgos de build y despliegue. Si el proyecto funciona desde cero y los pasos necesarios para cerrar las brechas.
4. Revisión de los flujos de dinero. Qué se rastreó, qué se encontró y qué requiere acción urgente.
5. Hallazgos de seguridad. Cada uno con severidad, evidencia y una corrección sugerida.
6. Notas de mantenibilidad. Cobertura de pruebas, antigüedad de las dependencias, estructura del código, documentación y la deuda técnica que frenará el trabajo futuro.
7. Plan priorizado. Qué hacer esta semana, este mes y más adelante, con un esfuerzo aproximado en términos relativos como pequeño, mediano y grande.

Desconfía de los informes que prometen plazos exactos antes de que el build funcione, o que concluyen que hay que reescribir el código sin mostrar evidencia. En mi experiencia, un camino incremental que mantiene el producto funcionando suele ser más seguro que una reescritura completa, que además tiende a costar más porque el sistema antiguo debe seguir funcionando en paralelo. Cuando lideré la migración de una plataforma de postulación a empleos en producción en avanzzada, trasladamos toda la arquitectura a una nueva stack mientras la gente seguía usándola todos los días, y hacerlo pieza por pieza fue lo que lo hizo posible. Aun así, es una regla general, y la auditoría es donde la pones a prueba frente a tu sistema real.

¿Quieres una segunda opinión sobre tu base de código heredada?

Si estás tomando el control de una base de código y quieres la opinión de un colega, escríbeme a me@filipeeduardo.dev con una breve descripción de la situación. Con gusto le echo un vistazo y te digo qué revisaría primero.