Auditoría de Código: Qué Revisamos, Cómo Trabajamos y Qué Entregamos

Heredar un codebase es como comprar un piso de segunda mano: las fotos tienen buena pinta, pero lo importante está dentro de las paredes. Instalación eléctrica, tuberías, humedades… En software, las «humedades» son deuda técnica, vulnerabilidades y decisiones de arquitectura que nadie documentó. Y se descubren igual: abriendo la pared.

Una auditoría de código es exactamente eso: abrir la pared antes de firmar. Ya sea porque valoras refactorizar o reescribir, porque vas a comprar una empresa por su producto, o porque el equipo que lo construyó ya no está. Esta guía explica qué revisamos en una auditoría seria, cómo es el proceso y — lo más importante — qué te llevas al final: no un PDF para el cajón, sino un plan accionable.

El Problema: Decisiones Grandes con Información Pequeña

Las decisiones más caras sobre un producto software se toman con la peor información disponible:

• «¿Refactorizamos o reescribimos?» — respondida en una reunión, de memoria, con la opinión del que habla más alto.
• «¿Cuánto vale el software de esta empresa que queremos comprar?» — respondida con una demo bonita y la facturación.
• «¿Por qué cada feature tarda el doble que hace dos años?» — respondida con «es que el código es muy malo», que no es una respuesta accionable.

En los tres casos falta lo mismo: evidencia objetiva sobre el estado real del código. Y las corazonadas en estas decisiones se pagan en trimestres.

Qué Es una Auditoría de Código (y Qué No Es)

Una auditoría de código es una revisión sistemática e independiente del estado de una base de código, orientada a responder preguntas de negocio: ¿qué riesgos tiene?, ¿qué cuesta mantenerla?, ¿aguanta el crecimiento previsto?, ¿qué hay que arreglar primero?

Y es igual de importante lo que no es:

• No es un linter glorificado. Las herramientas automáticas (análisis estático, métricas de complejidad, escáneres de dependencias) son la materia prima — el 20% del trabajo. El 80% restante es criterio: leer la arquitectura, entender por qué se tomaron las decisiones y valorar su impacto real.
• No es un juicio al equipo. Todo código es hijo de su contexto: plazos, pivotes de negocio, equipos que rotan. La auditoría evalúa el código, no a las personas — y un informe que se usa para señalar culpables es un informe fallido.
• No es un informe para archivar. Si no termina en un backlog priorizado con quick wins y un roadmap, no es una auditoría: es un funeral.

Las Seis Dimensiones que Revisamos

Ninguna dimensión aislada cuenta la verdad. Una app puede tener tests estupendos sobre una arquitectura que no escala, o un código limpio desplegado sobre una infraestructura frágil. Por eso la revisión es siempre multidimensional:

1. Arquitectura: ¿el diseño aguanta los próximos dos años de producto? Acoplamiento, límites entre módulos, escalabilidad real, puntos únicos de fallo. Es la dimensión que más cuesta cambiar después.
2. Calidad del código: legibilidad, duplicación, complejidad ciclomática, convenciones. No por estética: porque la calidad del código es el predictor más fiable de la velocidad futura del equipo.
3. Seguridad: el OWASP Top 10 como punto de partida — control de acceso, inyección, secretos en el repo, dependencias vulnerables, exposición de datos. Lo detallamos en nuestra guía de OWASP.
4. Testing: cobertura sí, pero sobre todo valor: ¿los tests detectan regresiones reales o solo dan sensación de seguridad? ¿La suite corre en minutos o en horas? ¿Hay tests en las capas correctas?
5. Infraestructura y despliegue: CI/CD, entornos reproducibles, monitorización, backups probados (no «configurados»: probados), y cuánto del despliegue depende de una persona concreta.
6. Documentación y conocimiento: ¿puede un desarrollador nuevo ser productivo en una semana? Decisiones de arquitectura registradas (ADRs), runbooks, y el índice de «bus factor»: qué pasa si mañana falta la persona clave.

El Proceso, Semana a Semana

Una auditoría típica dura entre dos y cuatro semanas según el tamaño del sistema, y convive con el equipo sin frenarlo:

1. Kickoff (día 1): acotar la pregunta de negocio. No es lo mismo auditar para una adquisición que para decidir un refactor. La pregunta define la profundidad de cada dimensión.
2. Acceso y análisis automático (semana 1): acceso de solo lectura al repo, CI y métricas. Pasamos la batería automática: análisis estático, dependencias, cobertura, historial de git (los ficheros que más cambian y menos tests tienen son oro).
3. Revisión manual (semanas 1-2): lectura dirigida por lo anterior: los módulos calientes, los bordes del sistema, los flujos críticos de negocio. Aquí es donde aparece lo que ninguna herramienta ve.
4. Entrevistas (semana 2): dos o tres conversaciones cortas con el equipo. «¿Qué te da miedo tocar?» es la pregunta más rentable de toda la auditoría.
5. Informe y presentación (semana 3-4): entrega escrita y sesión de una hora con negocio y con el equipo técnico, por separado: cada uno necesita un nivel de detalle distinto.

Cómo Es un Hallazgo Real

El corazón del informe son los hallazgos, y cada uno sigue siempre el mismo formato — sin esto, los hallazgos son opiniones:

SEV-1 | Seguridad | IDOR en /api/invoices/{id}
  Evidencia:    GET /api/invoices/1042 con el token de otro
                cliente devuelve la factura (falta ownership check)
  Impacto:      exposición de datos de clientes (RGPD)
  Esfuerzo:     1 día (policy en el controller + tests)
  Acción:       quick win — semana 1

SEV-2 | Arquitectura | Acoplamiento dominio-framework
  Evidencia:    214 clases de dominio referencian el ORM
  Impacto:      imposible testear el núcleo sin BD; cada
                migración del framework es un proyecto
  Esfuerzo:     4-6 semanas (extracción gradual por módulos)
  Acción:       estructural — planificar Q1

Severidad, evidencia concreta (reproducible), impacto en negocio, esfuerzo estimado y recomendación accionable. Si un hallazgo no tiene los cinco, no entra en el informe.

Qué Te Llevas: El Entregable

El informe tiene tres capas, pensadas para tres lectores distintos:

• Resumen ejecutivo (2 páginas): salud general por dimensión, los 3-5 riesgos que importan y la recomendación estratégica. Para dirección y para responder la pregunta original: refactor o reescritura, comprar o no comprar.
• Informe técnico completo: todos los hallazgos con su evidencia, para el equipo que ejecutará los arreglos.
• Backlog priorizado: cada hallazgo en la matriz impacto/esfuerzo — quick wins (alto impacto, bajo esfuerzo) la primera semana, proyectos estructurales planificados, y lo que honestemente no compensa tocar.

La matriz es deliberadamente cruel: si todo es prioridad, nada lo es. Una buena auditoría dice también qué no hacer.

Cuándo No Hace Falta

• Proyecto joven con equipo estable. Si el código tiene un año, el equipo lo conoce entero y la velocidad no decae, la auditoría te dirá lo que ya sabes.
• Ya tienes la evidencia. Si mides calidad, cobertura, vulnerabilidades y deuda de forma continua (y actúas sobre ello), la auditoría puntual aporta poco: ya vives en ella.
• Como arma arrojadiza. Si el objetivo real es justificar deshacerse del equipo o del proveedor, el informe nacerá contaminado — y el equipo lo notará desde la primera entrevista.

Errores Comunes

1. Auditar solo con herramientas automáticas. Un PDF de SonarQube no es una auditoría: es materia prima sin criterio ni contexto de negocio.
2. No acotar la pregunta. «Revisa todo» produce informes de 80 páginas que no responden nada. La pregunta de negocio es el filtro de todo lo demás.
3. Excluir al equipo. La auditoría a espaldas del equipo genera resistencia y, peor, pierde la mejor fuente de información disponible.
4. Priorizar por lo técnico y no por el riesgo. El código más feo no siempre es el más peligroso: importa lo que rompe negocio si falla, no lo que duele a la vista.
5. Archivar el informe. La auditoría más cara es la que no cambia ninguna decisión. Si a los tres meses nadie ha ejecutado ni un quick win, el problema no era el código.

En Resumen

Una auditoría de código convierte corazonadas en evidencia: seis dimensiones revisadas con método, hallazgos con severidad e impacto en negocio, y un entregable que acaba en decisiones — ejecutivo para dirección, técnico para el equipo, y un backlog priorizado donde los quick wins van primero. Las decisiones grandes sobre software son demasiado caras para tomarlas de memoria.

Si estás ante una decisión de refactor, una adquisición o un equipo que ha perdido velocidad sin explicación clara, es exactamente el trabajo que hacemos: dos a cuatro semanas, sin frenar al equipo, y con un plan accionable al final. Hablemos de tu caso →

Sigue leyendo: OWASP Top 10: las 10 vulnerabilidades críticas explicadas con ejemplos reales.