Auditoría Técnica de Código Antes de Heredar un Software

Una auditoría técnica de código es la revisión independiente de un software antes de heredarlo de otro proveedor o de comprarlo. Analiza arquitectura, seguridad, dependencias y licencias, calidad, tests, despliegue, documentación y quién controla el código y los accesos. Termina en un informe con riesgos priorizados y el esfuerzo de corregirlos. La hacemos antes de asumir cualquier proyecto de desarrollo web o software heredado.

Comprar o heredar un software sin auditarlo es firmar sin leer la letra pequeña. Los problemas aparecen después: el primer cambio cuesta mucho más de lo previsto o el antiguo proveedor no entrega las credenciales de la nube. Revisar la tecnología antes de firmar es una de las primeras tareas de un CTO externo que defiende los intereses técnicos de tu empresa.

Al terminar sabrás qué exigir en la auditoría y qué hallazgos justifican renegociar, además de cómo convertir el resultado en un plan para reducir la deuda técnica acumulada.

Qué es una auditoría técnica de código

Una auditoría técnica de código es un análisis del código fuente y de la infraestructura de un software que mide su calidad y lo que costará mantenerlo. La realiza alguien sin interés en el resultado, con acceso completo al repositorio, y responde a una pregunta de negocio: si la operación sigue adelante y en qué condiciones.

Como marco de referencia sirve la norma ISO/IEC 25010:2023 de calidad de producto, el modelo de ISO publicado en noviembre de 2023 que sustituye a la edición de 2011. Entre sus características están la mantenibilidad y la seguridad, que son las que más pesan cuando vas a hacerte cargo de un sistema.

Lupa holográfica verde suspendida sobre un árbol de carpetas en wireframe, con nodos que se iluminan al pasar — Una auditoría mira dentro del repositorio, no la demo que te enseñaron

Qué se revisa en una auditoría técnica de código

Una auditoría técnica de código revisa ocho áreas, y en cada una busca evidencias dentro del repositorio, no explicaciones del equipo anterior:

Arquitectura: cómo se reparten las responsabilidades y si el diseño aguanta el crecimiento previsto.
Seguridad: secretos en el código y control de accesos. La lista OWASP Top 10:2025 que usamos al auditar código sitúa el control de acceso roto en primera posición e incluye como A03:2025 los fallos en la cadena de suministro de software.
Dependencias y licencias: versiones sin soporte, vulnerabilidades conocidas y licencias copyleft que pueden obligarte a publicar tu código al distribuir el producto.
Calidad: complejidad y duplicación. El historial de revisiones mediante pull request muestra si alguien revisaba antes de fusionar.
Tests: si existen y qué cubren de verdad.
Despliegue: si se puede levantar el sistema desde cero con lo que hay en el repositorio.
Documentación: cómo se arranca el sistema y por qué se tomaron las decisiones de diseño.
Propiedad y accesos: a nombre de quién están el repositorio, el dominio, la nube y las cuentas de las tiendas de apps. Lo explicamos en detalle en quién es el dueño del código de una app.

Señales de alarma antes de heredar o comprar

Las señales de alarma de una auditoría son los hallazgos que cambian el precio o el calendario de la operación. Estas son las más habituales y lo que suelen justificar:

Código solo en la cuenta del proveedor: no firmes hasta tener el repositorio completo, con historial.
Secretos en el historial de Git: borrarlos del último commit no basta; hay que rotar cada credencial expuesta.
Sin tests ni despliegue reproducible: cada cambio será lento y arriesgado; descuéntalo del precio o pide un plan de estabilización.
Dependencias sin soporte de seguridad: presupuesta la actualización antes de añadir funcionalidades.
Licencias copyleft en un producto que distribuyes: consulta con un abogado antes de seguir.
Un único desarrollador conoce el sistema: exige documentación y un periodo de traspaso pagado.

Panel holográfico de cristal verde con varios nodos encendidos en rojo de alerta, rodeado de fragmentos flotantes — Algunas señales se arreglan con dinero; otras justifican parar la operación

Qué entregable debe darte la auditoría

El entregable de una auditoría técnica es un informe con hallazgos clasificados por gravedad, el esfuerzo estimado de cada corrección y una recomendación clara sobre si seguir adelante con la operación.

Ese informe alimenta dos decisiones posteriores. La primera es el presupuesto anual de mantenimiento del software auditado. La segunda, si hay que reconstruir, es el traspaso de información, que conviene planificar con un plan de migración de datos al nuevo software. Si después comparas proveedores, la comparativa técnica de desarrollo de software a medida en Madrid te ayuda a leer las ofertas.

Haz de luz holográfico verde que barre en horizontal un bloque de código en wireframe y deja estelas brillantes — El primer barrido automático decide dónde mirar con lupa

CodeZone Pro Tip: este script en bash hace el primer barrido de un repositorio heredado: tamaño, lenguajes, dependencias, posibles secretos expuestos y ausencia de tests.

#!/usr/bin/env bash
# Primer barrido de un repositorio heredado. Uso: ./barrido.sh /ruta/al/repo
set -uo pipefail
cd "${1:-.}" || exit 1
# Fuera carpetas generadas: inflan el tamaño y llenan el informe de falsos positivos
EXCL=(--exclude-dir=.git --exclude-dir=node_modules --exclude-dir=vendor --exclude-dir=dist)

echo "== Tamaño e historial =="
du -sh --exclude=.git --exclude=node_modules .
git rev-list --count HEAD 2>/dev/null || echo "ALERTA: sin historial Git, pide el repositorio completo"

echo "== Lenguajes (ficheros por extensión) =="
find . -type f -name '*.*' -not -path './.git/*' -not -path '*/node_modules/*' \
  | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -10

echo "== Manifiestos de dependencias =="
find . -maxdepth 3 -not -path '*/node_modules/*' \( -name package.json -o -name requirements.txt \
  -o -name pyproject.toml -o -name composer.json -o -name pom.xml -o -name go.mod \)

echo "== Posibles secretos (revisar a mano, nunca copiar el valor a un informe) =="
# AKIA: prefijo de claves de acceso de AWS; también claves privadas y asignaciones sospechosas
grep -rInE "${EXCL[@]}" "AKIA[0-9A-Z]{16}|-----BEGIN [A-Z ]*PRIVATE KEY-----|(password|secret|api_key|token)[[:space:]]*[:=][[:space:]]*['\"][^'\"]{8,}" . \
  | cut -d: -f1,2 | head -20
find . -name '.env*' -not -name '.env.example' -not -path './.git/*' | sed 's/^/Fichero de entorno en el repositorio: /'

echo "== Tests =="
# Sin tests, cada cambio se valida en producción
N=$(find . -type f -not -path '*/node_modules/*' \( -path '*test*' -o -name '*.spec.*' \) | wc -l)
if [ "$N" -eq 0 ]; then echo "ALERTA: no hay tests"; else echo "$N ficheros de test"; fi

En unos segundos sabes si merece la pena pagar una auditoría completa o si hay motivos para pedir explicaciones antes. El script solo mira la versión actual de los ficheros; para buscar secretos en todo el historial se usan herramientas específicas como Gitleaks. Cada alerta que salga aquí es una pregunta concreta para el vendedor o el proveedor saliente.

El Coste de Heredar Código Sin Haberlo Visto

Un software heredado sin auditar traslada al comprador los riesgos que el vendedor conocía y no contó. La auditoría te da argumentos para negociar el precio y planificar el traspaso, y te dice desde el primer día cuánto costará mantenerlo.