El proveedor anterior se fue en marzo. Dejó un repositorio, un servidor que nadie se atreve a reiniciar y un documento de tres páginas que dice "ver código". Ahora el gerente de operaciones tiene que decidir si sigue invirtiendo en ese sistema o lo reemplaza, y no tiene cómo saber qué hay adentro.
Es el caso más común en que una empresa busca consultoría en desarrollo de software. No necesita construir nada todavía: necesita que alguien externo abra el sistema que ya tiene y diga, con evidencia, en qué estado está. A eso se le llama auditoría de código o diagnóstico técnico de software. Bien hecho, te entrega un mapa de riesgos con prioridades y costos aproximados. Mal hecho, es un PDF largo con mil alertas de una herramienta automática que nadie sabe cómo leer.
Este artículo explica qué revisa un diagnóstico serio, qué deberías recibir al final y en qué momentos conviene pedirlo. Si lo que buscas es modernizar un sistema antiguo con apoyo de IA, eso lo tratamos aparte en consultoría para modernizar sistemas legados; el diagnóstico suele ser el paso previo.
Cuándo pedir un diagnóstico técnico de software
Hay cuatro momentos en que la auditoría paga su costo con holgura:
- Antes de comprar o heredar un sistema. Si vas a adquirir una empresa, un producto o una licencia de código fuente, el diagnóstico te dice cuánta deuda técnica viene incluida en el precio.
- Al cambiar de proveedor. El nuevo equipo necesita saber con qué se encuentra, y tú necesitas una línea base para no pagar después por problemas que ya existían.
- Antes de escalar. Si el sistema va a pasar de 50 a 500 usuarios, o se va a abrir a clientes externos, conviene saber dónde se va a quebrar primero.
- Cuando algo ya está fallando. Caídas recurrentes, cambios simples que tardan semanas o un incidente de seguridad son síntomas, y el diagnóstico busca la causa.
También hay un motivo regulatorio. La Ley 21.719 obliga al responsable de datos personales a adoptar medidas de seguridad acordes al estado de la técnica, los costos y el riesgo del tratamiento (artículo 14 quinquies). Hoy su entrada en vigencia está fijada para el 1 de diciembre de 2026, y hay un proyecto en el Congreso que propone postergarla hasta el 15 de octubre de 2027, aún sin aprobación definitiva según el seguimiento de Eguiguren Abogados al 6 de noviembre. Con o sin prórroga, es difícil demostrar que un sistema está protegido si nadie lo ha revisado.
Qué revisa una auditoría de código
Una auditoría útil mira el sistema completo, y el código es solo una parte. Estas son las áreas que deberían aparecer en el informe:
| Área | Qué se revisa | Señal de alerta típica |
|---|---|---|
| Arquitectura | Cómo se reparten las responsabilidades entre módulos, servicios y base de datos; dónde están los puntos únicos de falla | Toda la lógica de negocio en procedimientos almacenados o en un solo archivo de miles de líneas |
| Calidad del código | Duplicación, complejidad, convenciones, manejo de errores | El mismo cálculo copiado en cinco lugares, cada uno con una variación |
| Dependencias | Librerías y frameworks usados, sus versiones y si tienen vulnerabilidades conocidas o ya no reciben soporte | Un framework sin actualizaciones de seguridad hace años |
| Seguridad | Control de acceso, autenticación, manejo de secretos, inyección, configuración | Contraseñas o llaves de API escritas en el código |
| Pruebas | Si existen pruebas automatizadas, qué cubren y si se ejecutan | "Las pruebas las hace el usuario en producción" |
| Despliegue y operación | Cómo se pasa un cambio a producción, respaldos, registros, monitoreo | Despliegues manuales que solo sabe hacer una persona |
| Documentación | Si alguien nuevo puede entender, instalar y modificar el sistema | El único manual es la memoria del desarrollador que se fue |
Para la parte de seguridad, una buena referencia es el OWASP Top 10:2025, la lista de los riesgos más críticos en aplicaciones web. La edición 2025 pone en primer lugar el control de acceso roto y agrega una categoría nueva sobre fallas en la cadena de suministro de software, que es justamente lo que se revisa en el inventario de dependencias. Si necesitas un nivel de detalle mayor, el OWASP ASVS define requisitos verificables por nivel de exigencia.
En calidad general, la norma ISO/IEC 25010:2023 describe un modelo de calidad de producto que incluye, entre otras, la mantenibilidad y la seguridad. No hace falta certificarse en nada, pero usar un modelo conocido evita que el informe dependa solo del gusto del auditor.
Herramientas automáticas y revisión humana
Las herramientas de análisis estático y de composición de software (las que revisan dependencias) son rápidas y baratas. Recorren el repositorio y encuentran patrones conocidos, como una consulta SQL armada concatenando texto o una librería con una vulnerabilidad publicada.
El problema es que generan mucho ruido. Una sola pasada puede devolver cientos de hallazgos, varios falsos positivos y casi ninguno ordenado según lo que importa para tu negocio. Hay cosas que una herramienta no ve: que la regla de cálculo de comisiones está mal implementada, que un usuario de bodega puede aprobar notas de crédito, o que el sistema completo depende de una tarea programada en un servidor que nadie documentó.
Por eso un diagnóstico serio combina las dos cosas. La herramienta hace el barrido; una persona con experiencia filtra, confirma, entrevista al equipo que usa el sistema y traduce los hallazgos a riesgo concreto. Si alguien te ofrece una auditoría que es solo un reporte automático con logo, estás pagando por algo que podrías correr tú.
Qué entregables deberías recibir
Al final del diagnóstico deberías tener, como mínimo:
- Un resumen ejecutivo de una o dos páginas, escrito para quien decide y no para quien programa: estado general, tres a cinco riesgos principales y una recomendación (mantener, refactorizar por partes, reemplazar).
- Una lista priorizada de hallazgos, cada uno con evidencia (archivo, línea, captura o prueba), impacto, probabilidad y esfuerzo estimado para corregirlo.
- Un inventario de dependencias con versiones, estado de soporte y vulnerabilidades conocidas. Algunos proveedores lo entregan en formato SBOM (lista de materiales de software), útil si después quieres monitorearlo de forma continua.
- Un diagrama de la arquitectura actual, aunque sea simple.
- Una hoja de ruta con lo urgente (semanas), lo importante (meses) y lo que puede esperar.
Pide que el informe distinga hechos de opiniones. "Esta librería tiene una vulnerabilidad publicada" es un hecho; "la arquitectura no va a escalar" es una opinión que debería venir con el razonamiento detrás.
Cómo prepararte y cuánto se demora
El tiempo depende del tamaño y del acceso. Un sistema web mediano con un repositorio ordenado se puede diagnosticar en un par de semanas; un sistema con varios componentes, integraciones con un ERP y sin documentación tomará más. En la práctica, lo que más alarga una auditoría son los permisos: esperar días por acceso al repositorio, a una copia de la base de datos o a alguien que explique el negocio.
Para que avance rápido, ten listo:
- Acceso de solo lectura al repositorio completo, incluido el historial.
- Una copia del ambiente o, si no existe, acceso supervisado al de pruebas. Ojo con usar datos reales de clientes en ese ambiente; revisa qué dice la Ley 21.719 sobre datos de producción en pruebas.
- Un acuerdo de confidencialidad firmado antes de entregar nada.
- Una o dos personas del negocio que puedan explicar los procesos críticos.
- Los contratos con el proveedor anterior, para saber de quién es el código.
Y define desde el inicio qué decisión quieres tomar con el resultado. Auditar para negociar una compra pide otro foco que auditar para planificar el próximo año de mantenimiento, y el informe debería reflejarlo.
Preguntas frecuentes
¿Una auditoría de código reemplaza a un pentest?
No. Una prueba de penetración ataca el sistema en funcionamiento desde afuera; la auditoría lo revisa desde adentro. Se complementan: la auditoría encuentra causas y el pentest confirma qué es explotable.
¿Quién debería hacer el diagnóstico técnico de software?
Alguien que no haya construido el sistema. El equipo que lo desarrolló conoce bien el código, pero tiene sesgos naturales al evaluar su propio trabajo. Un tercero independiente da una opinión más útil, sobre todo si vas a usarla para negociar o cambiar de proveedor.
¿Qué pasa si el resultado es "hay que reemplazarlo"?
Rara vez el informe concluye que todo está perdido. Lo normal es que haya partes que se pueden conservar, como el modelo de datos o ciertas integraciones, y otras que conviene rehacer. Con la lista priorizada puedes reemplazar por etapas en vez de apostar todo a un proyecto grande.
Conversemos sobre tu sistema
En Disrupsoft desarrollamos software a medida con Azure, Power Platform, Angular y Node.js, y antes de proponer cambios sobre un sistema existente nos gusta entender bien qué hay adentro. Si estás por cambiar de proveedor, comprar un sistema o escalar uno que ya no da más, cuéntanos tu caso y vemos juntos por dónde empezar.
