Auditoría de software: qué revisar antes de corregir, comprar o reescribir

1. Empieza por la decisión, el alcance y las fuentes de evidencia

Define qué debe decidir la organización: aceptar una entrega, invertir, renovar proveedor, explicar lentitud, reducir fallas, preparar una migración o mejorar seguridad. La misma aplicación requiere muestras y profundidad distintas según la pregunta. Acordar “revisar el código” no identifica usuarios, riesgos, módulos ni criterio de cierre.

Enumera repositorios, ramas, artefactos, ambientes, bases, servicios, integraciones, documentación, tickets, métricas, incidentes y personas disponibles. Registra fechas, versiones, acceso y limitaciones. Triangula lo que dicen los documentos y entrevistas con lo que muestran los artefactos y el comportamiento; ninguna fuente es una verdad completa por sí sola.

• Decisión, responsable, fecha y consecuencias de actuar o no actuar.
• Usuarios, flujos y datos con mayor impacto o incertidumbre.
• Componentes, repositorios, versiones y ambientes incluidos.
• Período de métricas, incidentes, cambios y actividad revisado.
• Muestras, exclusiones y limitaciones de acceso o evidencia.

Prometer revisar “todo el código” oculta una pregunta más importante: qué evidencia hace falta para tomar la decisión.

2. Modela el producto, la arquitectura y sus dependencias reales

Empieza por los resultados que el usuario necesita y sigue el recorrido a través de interfaz, servicios, datos, colas, archivos, terceros e infraestructura. Documenta componentes, límites, contratos, propietarios y decisiones importantes. Contrasta diagramas con despliegues, configuración, tráfico y repositorios para detectar arquitectura aspiracional.

ISO/IEC 25010:2023 ofrece un modelo de calidad con características que pueden ayudar a formular objetivos de evaluación; no sustituye requisitos específicos. Selecciona atributos relevantes —por ejemplo adecuación funcional, confiabilidad, seguridad, eficiencia y mantenibilidad— y define cómo se observarán en el contexto del producto.

• Propuesta de valor, usuarios, flujos y resultados críticos.
• Componentes, límites de confianza, datos y contratos de integración.
• Dependencias internas, externas, operativas y humanas.
• Decisiones arquitectónicas conocidas y restricciones heredadas.
• Atributos de calidad y evidencia esperada para cada uno.

Un diagrama vigente es una hipótesis comprobable, no un sustituto del sistema desplegado.

3. Reproduce síntomas y separa señales de producción

Define ejemplos concretos: flujo, usuario, volumen, dato, hora, ambiente, resultado esperado y observado. Evita atribuir lentitud al lenguaje o a la base sin medición. Descompón latencia, errores y carga entre cliente, red, aplicación, consultas, almacenamiento, colas e integraciones. Usa trazas o perfiles sólo dentro de límites seguros.

El capítulo de monitoreo del libro SRE de Google distingue síntomas y causas, y monitoreo de caja negra y caja blanca. Revisa si las señales muestran experiencia del usuario y estado interno, si las alertas requieren acción humana y si los cambios pueden relacionarse con variaciones. Un promedio puede ocultar colas largas y fallos de un segmento.

• Escenario reproducible, entrada, carga, estado y resultado esperado.
• Latencia por percentiles, tasa de errores, volumen y saturación.
• Consultas, dependencias, reintentos, bloqueos y tareas en segundo plano.
• Correlación entre versión, despliegue, incidente y cambio de comportamiento.
• Limitaciones del ambiente o de los datos usados para medir.

4. Evalúa código y pruebas como capacidad de cambiar con seguridad

Muestrea componentes según criticidad, frecuencia de cambio, incidentes y acoplamiento. Revisa estructura, responsabilidades, duplicación, complejidad, manejo de errores, concurrencia, convenciones y coherencia con la arquitectura. Las métricas orientan preguntas; un umbral genérico no demuestra por sí solo deuda o calidad.

Relaciona pruebas con riesgos y comportamiento. Distingue pruebas unitarias, integración, contrato, sistema, regresión, migración y rendimiento. Comprueba estabilidad, datos, aislamiento, tiempos, falsos resultados y uso en el pipeline. Una cobertura porcentual alta puede ejecutar líneas sin verificar decisiones importantes.

• Criterio para seleccionar repositorios, módulos, clases o cambios.
• Responsabilidades, acoplamiento, duplicación y manejo de excepciones.
• Defectos recurrentes y áreas donde corregir introduce nuevos fallos.
• Pruebas relacionadas con flujos, riesgos y contratos críticos.
• Facilidad para comprender, modificar, desplegar y revertir.

La mantenibilidad se observa en cambios reales: tiempo, dependencia, defectos, pruebas y capacidad de reversión.

5. Revisa datos, integraciones y migraciones como parte del producto

Mapea entidades, claves, restricciones, índices, consultas críticas, crecimiento, retención y acceso. Busca reglas de negocio duplicadas entre código y base, estados imposibles, conciliaciones manuales y errores silenciosos. Verifica cómo se detecta y corrige una inconsistencia sin editar producción de forma improvisada.

Para cada API, archivo, cola o proveedor, documenta contrato, autenticación, límites, tiempo de espera, reintento, idempotencia, orden, duplicado y observabilidad. Revisa migraciones hacia adelante y reversión, respaldo, compatibilidad y validación. Una integración “estable” puede depender de una persona que reprocesa fallos.

• Propiedad, clasificación, origen, destino y ciclo de vida del dato.
• Restricciones e invariantes que código y almacenamiento deben conservar.
• Consultas críticas, índices, volumen, archivado y ventanas operativas.
• Contratos, errores, reintentos, idempotencia y conciliación de integraciones.
• Migración, reversión, respaldo y verificación de integridad.

6. Evalúa seguridad y cadena de suministro según el riesgo

NIST SSDF organiza prácticas de desarrollo seguro que pueden integrarse al ciclo existente; OWASP SAMM ayuda a evaluar y mejorar actividades de aseguramiento. Examina cómo se definen requisitos, se protege el software, se producen versiones y se responde a vulnerabilidades. No conviertas madurez en un concurso por alcanzar el nivel máximo en todo.

Para aplicaciones web, OWASP ASVS puede aportar requisitos verificables; OWASP SCVS aporta criterios para componentes. Relaciona identidad, autorización, entradas, secretos, registros, dependencias, builds y procedencia con arquitectura y amenazas. Un escáner no conoce lógica de negocio, datos, controles compensatorios ni facilidad real de explotación.

• Requisitos y amenazas relevantes para funciones, roles y datos.
• Autenticación, autorización, sesión, entradas, secretos y registros.
• Inventario de componentes, versiones, procedencia y actualización.
• Protección de repositorios, pipelines, artefactos y ambientes.
• Recepción, priorización, corrección y aprendizaje de vulnerabilidades.

Una dependencia con alerta no equivale automáticamente a riesgo urgente; primero confirma versión, uso, exposición e impacto.

7. Comprueba entrega, operación, observabilidad y recuperación

Sigue un cambio desde requisito y commit hasta build, prueba, artefacto, aprobación, despliegue y verificación. Revisa separación de ambientes, configuración, secretos, migraciones, feature flags y reversión. Identifica pasos manuales, personas indispensables y variación entre lo versionado y lo que corre.

Conecta métricas, logs, trazas, alertas, runbooks, incidentes, respaldo y restauración con los flujos críticos. Comprueba quién responde, qué información recibe y cómo se aprende. La confiabilidad no se demuestra porque el sistema estuvo disponible ayer; necesita objetivos, medición, capacidad, recuperación y disciplina de cambio.

• Build reproducible, artefacto identificable y procedencia de la versión.
• Pruebas, aprobaciones, despliegue gradual, verificación y reversión.
• Configuración y secretos separados del código y entre ambientes.
• Señales orientadas al usuario, alertas accionables y diagnóstico.
• Respaldo, restauración, continuidad e historial de incidentes.

8. Agrupa causas y compara opciones antes de construir la hoja de ruta

Evita un listado de cientos de observaciones aisladas. Agrupa síntomas que comparten una causa: límites confusos, modelo de datos débil, falta de contratos, proceso manual o conocimiento concentrado. Para cada hallazgo, documenta evidencia, alcance, impacto, confianza, dependencia y limitación. Separa deuda deliberada de decisiones que ya no encajan.

El SEI describe la deuda técnica como una preocupación arquitectónica y de gestión, no sólo limpieza de código. Compara no cambiar, contener, documentar, monitorear, refactorizar, encapsular, reemplazar gradualmente, migrar o reescribir. Prioriza por valor y reducción de riesgo, asigna propietario y define la prueba que demostrará mejora.

• Causa agrupadora, evidencia, componentes y efectos observados.
• Confianza, incertidumbre, limitación y evidencia adicional necesaria.
• Opciones con costo relativo, dependencia, riesgo y reversibilidad.
• Acciones inmediatas, estabilización, modernización y mejora sostenida.
• Propietario, fecha, indicador y criterio verificable de cierre.

Reescribir cambia el tipo de riesgo; no lo elimina. También exige recuperar reglas, datos, integraciones y conocimiento.