Nos llaman para auditar por tres motivos, casi siempre: alguien está por comprar una empresa y quiere saber qué se lleva, alguien va a reemplazar al proveedor que tiene y necesita saber en qué estado recibe el sistema, o el sistema se cae seguido y adentro ya nadie puede explicar por qué.
Los tres casos necesitan lo mismo: una foto honesta del estado real, con evidencia y con costos estimados. Lo que no necesita nadie es un documento de cuarenta páginas con recomendaciones generales sobre buenas prácticas.
Primero: ¿se puede levantar el proyecto?
Parece básico y es el filtro más informativo de todos. Tomamos el repositorio, lo clonamos en una máquina limpia y seguimos las instrucciones que existan. El tiempo que tarda en levantar y la cantidad de pasos no documentados que hicieron falta dicen más sobre la salud del proyecto que cualquier métrica.
Cuando levantar el sistema requiere que un desarrollador específico pase un archivo por mensaje privado, el problema no es de configuración: es que el proyecto no está entero en ningún lado. Eso, en una compra, es materia de negociación.
Dependencias: qué versiones, qué soporte, qué agujeros
Se releva todo lo que el sistema usa y no escribió: librerías, frameworks, versión del lenguaje, motor de base de datos, imágenes base. De cada cosa interesan tres datos: qué versión corre, si esa versión todavía recibe parches de seguridad, y qué distancia hay hasta la versión soportada más cercana.
Esa última parte es la que convierte el relevamiento en algo accionable. «Estás cuatro versiones mayores atrás» no dice nada. «Estás cuatro versiones atrás, el salto tiene dos cambios que rompen y lo estimamos en tres semanas» sí.
Seguridad: dónde está el 90 % de lo que encontramos
Las auditorías de aplicaciones de gestión se repiten bastante. Los hallazgos serios se concentran en cuatro lugares:
- Autorización. Que el sistema pregunte quién sos al entrar y después no vuelva a preguntar nada. Cambiar un número en la URL y ver el registro de otro cliente sigue siendo el hallazgo más frecuente de todos.
- Consultas armadas con texto. Concatenar lo que escribe el usuario dentro de una consulta a la base. Se sabe desde hace veinte años y se sigue encontrando.
- Secretos en el repositorio. Claves de producción, tokens de pasarelas de pago y credenciales de base versionadas en el código. Aunque se borren después, quedan en el historial.
- Archivos que sube el usuario. Guardados sin validar el tipo real y servidos desde un lugar donde el servidor los puede llegar a ejecutar.
Cada hallazgo va al informe con la ruta del archivo, la línea, y una explicación de qué pasaría si alguien lo aprovecha. Sin eso es una advertencia genérica y no se puede priorizar.
La base de datos, que casi nunca se mira
Buena parte de los sistemas «lentos» no tienen un problema de código sino de esquema. Se revisan índices que faltan sobre columnas que se filtran todo el tiempo, integridad referencial declarada o solamente prometida, tipos de dato elegidos por comodidad —importes en punto flotante, fechas guardadas como texto— y consultas que traen mil registros para contar cuántos hay.
Cuando hay acceso a un entorno parecido al de producción, se toman las veinte consultas más lentas y se explica cada una. Suele ser la sección del informe que más rápido se convierte en plata: dos o tres índices bien puestos cambian la percepción de velocidad de un sistema entero.
Pruebas: no cuántas, cuáles
El porcentaje de cobertura es un número que se puede inflar sin esfuerzo. Lo que miramos es otra cosa: si los caminos donde está el dinero —facturar, cobrar, liquidar, descontar stock— tienen pruebas que verifiquen resultados, o si lo único cubierto son funciones utilitarias que nunca fallaron.
También miramos si las pruebas corren solas en cada cambio o si hay que acordarse de ejecutarlas. Una prueba que nadie corre es documentación desactualizada.
Qué tiene que tener el informe para que te sirva
El informe se entrega en tres partes y cada una tiene un lector distinto:
- Dos páginas para quien decide. Estado general, los cinco riesgos que importan, qué cuesta ordenarlo y qué pasa si no se hace nada. Sin vocabulario técnico.
- El detalle para el equipo. Cada hallazgo con archivo, línea, severidad, reproducción y corrección sugerida. Esto se trabaja, no se lee.
- Un plan con orden y horas. Qué se toca primero, qué se puede hacer sin frenar nada y qué necesita una ventana. Con estimaciones, aunque incomoden.
Y un criterio que aplicamos siempre: si un hallazgo no viene con evidencia de dónde está, no entra al informe. Una auditoría que no se puede verificar no es una auditoría, es una opinión cara.
Cuánto tarda
Un sistema de gestión mediano lleva entre una y dos semanas, según el tamaño del repositorio y de si hay acceso a un entorno para probar. No hace falta frenar al equipo que lo mantiene: la auditoría se hace sobre una copia y no toca producción en ningún momento.