Pocas decisiones técnicas generan tanta incertidumbre como heredar una base de código que nadie del equipo actual ha escrito. Puede llegar por una adquisición, por un cambio de proveedor, por la salida del desarrollador que «lo sabía todo» o simplemente porque el producto ha crecido más rápido que su documentación. En todos esos escenarios la pregunta de fondo es la misma: ¿en qué estado está realmente este código y cuánto me va a costar mantenerlo, evolucionarlo o asegurarlo?
Una auditoría de código profesional existe para responder a esa pregunta con evidencia, no con opiniones. No se trata de que un tercero mire el repositorio y diga «está bien» o «está mal»: se trata de un proceso sistemático que combina análisis automático, revisión manual experta y un informe priorizado que dirección pueda usar para tomar decisiones de inversión, contratación o renegociación con un proveedor.
En Keliam llevamos años auditando plataformas de todo tipo: ecommerce con picos de tráfico, ERPs a medida, APIs que sostienen aplicaciones móviles, y proyectos heredados con una década de parches encima. Este artículo recoge cómo trabajamos y qué debería exigir cualquier CTO, IT manager o founder al contratar una auditoría de código: el proceso completo, las herramientas que separan una auditoría seria de una superficial, y los entregables concretos que justifican la inversión. Si estás valorando comprar un software, asumir el mantenimiento de un proyecto ajeno o simplemente saber cuánta deuda acumula tu plataforma, aquí tienes la guía completa.
1. Qué es una auditoría de código (y qué no es)
Una auditoría de código es un examen sistemático e independiente del código fuente de una aplicación para evaluar su calidad, seguridad, mantenibilidad y adecuación a buenas prácticas. La palabra clave es independiente: la realiza alguien que no participó en el desarrollo, sin conflicto de interés con el resultado.
Conviene distinguirla de prácticas cercanas con las que suele confundirse:
1.1 Auditoría de código vs code review
El code review es una práctica continua dentro del equipo: cada pull request pasa por los ojos de un compañero antes de integrarse. Es imprescindible, pero revisa cambios incrementales, no el sistema completo. Una auditoría mira la fotografía entera: arquitectura, dependencias, patrones repetidos, zonas muertas. Si lo que necesitas es una segunda opinión puntual sobre trabajo reciente, quizá te encaje mejor un code review externo; si necesitas conocer el estado global del proyecto, necesitas una auditoría.
1.2 Auditoría de código vs auditoría técnica global
La auditoría de código es una parte —central, pero una parte— de una auditoría técnica de software completa, que además evalúa infraestructura, procesos de despliegue, documentación, equipo y costes operativos. Cuando el objetivo es una decisión de compra o inversión, lo habitual es encargar la auditoría técnica completa; cuando la duda está específicamente en el código y su mantenibilidad, la auditoría de código es el instrumento adecuado.
1.3 Qué no debes esperar de ella
Una auditoría no reescribe el código, no corrige los problemas que encuentra (eso es la fase de remediación, posterior y separada) y no sustituye a un pentest: el análisis de seguridad sobre código estático detecta vulnerabilidades en el fuente, pero no explota el sistema en ejecución como haría una prueba de intrusión.
2. Cuándo encargar una auditoría de código: seis señales claras
Estos son los escenarios que, en nuestra experiencia, justifican el coste de una auditoría con mayor retorno:
Cambio de proveedor o internalización. Vas a asumir un código que otro equipo ha escrito. Auditarlo antes de firmar el traspaso te da poder de negociación y un inventario real de lo que recibes.
Compra o inversión. En una due diligence, el código es un activo más: su estado condiciona la valoración. Un informe independiente evita sorpresas post-adquisición.
Velocidad de desarrollo en caída libre. Si cada feature tarda el doble que hace un año y los bugs se multiplican, probablemente acumulas deuda técnica sin medir. La auditoría la cuantifica y la convierte en un plan de pago priorizado.
Incidentes de seguridad o requisitos de cumplimiento. Tras un incidente, o ante la exigencia de un cliente o certificación, necesitas evidencia del estado del código y de sus vulnerabilidades.
Escalado inminente. Antes de multiplicar tráfico, usuarios o equipo, conviene saber qué partes del sistema aguantarán y cuáles no. Muchas startups descubren tarde que su MVP arrastra errores técnicos que frenan el crecimiento.
Dependencia de una sola persona. Si solo un desarrollador entiende el sistema, una auditoría documenta el conocimiento crítico y reduce el riesgo de bus factor.
3. El proceso de auditoría paso a paso
Una auditoría seria sigue un proceso estructurado. Así lo ejecutamos en Keliam:
3.1 Definición de alcance y acceso
Se acuerda qué repositorios, ramas y módulos entran en la auditoría, con qué objetivo (mantenibilidad, seguridad, decisión de compra, escalabilidad) y bajo qué acuerdo de confidencialidad. El acceso ideal es de solo lectura al repositorio completo con su historial: el historial de commits cuenta tanto como el código (frecuencia de cambios, hotspots, autoría concentrada).
3.2 Análisis automático
Se ejecuta una batería de herramientas de análisis estático, análisis de dependencias y métricas de calidad (las vemos en detalle en la sección 4). Esta fase produce el mapa de calor inicial: dónde hay complejidad excesiva, duplicación, código muerto, vulnerabilidades conocidas en dependencias y violaciones de estándares.
3.3 Revisión manual experta
Es la fase que distingue una auditoría profesional de un simple informe de herramienta. Un auditor con experiencia en el stack revisa la arquitectura (separación de capas, acoplamiento, patrones), los puntos críticos de negocio (pagos, autenticación, gestión de datos personales), el manejo de errores, la estrategia de tests y la calidad real de las zonas que el análisis automático señaló. También evalúa lo que las herramientas no ven: decisiones de diseño incoherentes, abstracciones incorrectas, lógica de negocio dispersa.
3.4 Priorización de hallazgos
Cada hallazgo se clasifica por severidad (crítico, alto, medio, bajo) cruzada con su impacto en el negocio y el esfuerzo estimado de corrección. Un fallo de inyección SQL en el checkout no pesa lo mismo que una función con complejidad ciclomática alta en un módulo interno. Esta matriz severidad-esfuerzo es la base del plan de remediación.
3.5 Informe y sesión de entrega
El resultado se materializa en los entregables de la sección 6 y se presenta en una sesión de trabajo con el equipo técnico y, cuando procede, con dirección. La sesión importa: un informe sin conversación se archiva; un informe defendido y discutido se convierte en backlog.
4. Herramientas: el arsenal del análisis de código
Ninguna herramienta sustituye al auditor, pero un auditor sin herramientas no escala. Las que usamos habitualmente, por categoría:
4.1 Análisis estático de calidad
SonarQube es la referencia transversal: mide complejidad, duplicación, code smells, cobertura y deuda técnica estimada en horas. En PHP, PHPStan y Psalm detectan errores de tipos y contratos rotos sin ejecutar el código; en JavaScript/TypeScript, ESLint con reglas estrictas y el propio compilador de TypeScript; en Python, ruff y mypy. El valor no está en pasar las herramientas, sino en configurarlas con niveles exigentes y leer los resultados con criterio: un proyecto puede estar «verde» en SonarQube y ser inmantenible.
4.2 Seguridad en el código
Semgrep permite buscar patrones de vulnerabilidad específicos del stack (inyección, deserialización insegura, secretos hardcodeados) con reglas ajustadas al proyecto. Los hallazgos se contrastan contra el OWASP Top 10, que sigue siendo el marco de referencia para clasificar vulnerabilidades web. Para secretos filtrados en el historial de git, gitleaks o trufflehog.
4.3 Dependencias y supply chain
composer audit, npm audit y OWASP Dependency-Check cruzan las dependencias del proyecto contra bases de vulnerabilidades conocidas (CVE). En proyectos maduros generamos además un SBOM (inventario de componentes software) que documenta exactamente qué terceros ejecuta la aplicación y con qué licencias, un requisito cada vez más habitual en contratos con grandes clientes.
4.4 Historial y hotspots
Herramientas como CodeScene o el análisis directo del historial de git identifican hotspots: ficheros que cambian constantemente y concentran defectos. La combinación «alta complejidad + alta frecuencia de cambio + un solo autor» señala el riesgo real mejor que cualquier métrica aislada.
5. Qué se evalúa: las seis dimensiones de la calidad
Un informe de auditoría completo cubre estas dimensiones, cada una con sus criterios objetivos:
Arquitectura y diseño. Separación de responsabilidades, acoplamiento entre módulos, coherencia de patrones, facilidad para añadir funcionalidad sin tocar media aplicación.
Mantenibilidad. Complejidad ciclomática, duplicación, tamaño de funciones y clases, legibilidad, consistencia de estilo, código muerto.
Seguridad. Validación de entradas, gestión de autenticación y sesiones, exposición de datos sensibles, uso de criptografía, dependencias vulnerables, secretos en el código.
Rendimiento. Consultas N+1, ausencia de índices, operaciones bloqueantes, uso de caché, consumo de memoria en los flujos principales.
Testing. Cobertura real (no solo el porcentaje: qué cubre y qué no), calidad de los tests, existencia de tests de integración en los flujos críticos, automatización en CI.
Documentación y conocimiento. READMEs útiles, decisiones de arquitectura documentadas, onboarding posible sin depender de una persona concreta.
6. Entregables: qué debes exigir al contratar una auditoría
El valor de una auditoría está en sus entregables. Si un proveedor no puede enseñarte un índice de ejemplo antes de contratar, desconfía. Los cuatro imprescindibles:
Informe ejecutivo (3-5 páginas). Para dirección: nivel de riesgo global, los 5-10 hallazgos que condicionan decisiones, estimación agregada del esfuerzo de remediación y recomendación clara (mantener, refactorizar por fases, replantear). Sin jerga innecesaria.
Informe técnico de hallazgos. Cada hallazgo con: descripción, evidencia (fichero y línea, no generalidades), severidad justificada, impacto y recomendación concreta de corrección. Ordenado por la matriz severidad-esfuerzo.
Plan de remediación. Los hallazgos convertidos en hoja de ruta: quick wins (alto impacto, bajo esfuerzo) para las primeras semanas, bloques de refactorización por fases y qué puede esperar. Con estimaciones de esfuerzo por bloque.
Métricas de referencia. La foto cuantitativa del día de la auditoría: cobertura, complejidad media, duplicación, número de vulnerabilidades por severidad, deuda estimada. Sirve de línea base para medir el progreso en la re-auditoría o en revisiones trimestrales.
7. Auditoría de código y cumplimiento: ISO 27001, ENS y contratos
La auditoría de código ha dejado de ser una práctica voluntarista para convertirse en pieza de cumplimiento. La ISO 27001:2022 incluye controles específicos de desarrollo seguro (8.25 a 8.31) que exigen revisar el código ante cambios y establecer principios de ingeniería segura; los controles técnicos del Anexo A piden evidencias, y un informe de auditoría independiente es exactamente eso. En el ENS, el marco operacional exige control sobre los servicios externos de desarrollo: si desarrollas para la administración o para un contratista suyo, te pedirán demostrar la calidad y seguridad de tu código.
Más allá de las certificaciones, cada vez más contratos B2B incluyen cláusulas de auditabilidad del software entregado. Llegar con una auditoría reciente bajo el brazo acelera esas negociaciones y transmite madurez técnica.
8. Costes y plazos orientativos
El coste depende del tamaño del código, del stack y de la profundidad. Como referencia de mercado en España: una auditoría de un proyecto pequeño-mediano (una aplicación web con backend y frontend, hasta 100-150k líneas) suele moverse entre 3.000 y 8.000 euros y de una a tres semanas de calendario. Proyectos grandes o multi-repositorio, con análisis de seguridad en profundidad, pueden superar los 15.000 euros y las cuatro semanas. Una re-auditoría de seguimiento sobre la misma base cuesta una fracción, porque el alcance y las herramientas ya están configurados.
La pregunta correcta no es cuánto cuesta la auditoría, sino cuánto cuesta no hacerla: asumir un mantenimiento sin inventario, comprar un software sobrevalorado o descubrir en producción una vulnerabilidad que un análisis estático habría detectado en horas.
9. Errores comunes al contratar (o interpretar) una auditoría
Contratar al mismo proveedor que desarrolló el código. Por bien intencionado que sea, nadie audita con dureza su propio trabajo. La independencia no es un matiz: es la condición que da valor al informe. Si tu proveedor habitual te ofrece «auditarse», agradece el gesto y busca un tercero.
Aceptar un informe que es solo la salida de una herramienta. Un PDF con 4.000 issues exportados de SonarQube sin filtrar, contextualizar ni priorizar no es una auditoría: es ruido. El criterio experto está precisamente en decidir cuáles de esos hallazgos importan para tu negocio y cuáles son irrelevantes.
Leer solo el número de hallazgos. Doscientos hallazgos leves en un proyecto grande pueden ser un estado razonable; tres críticos en el flujo de pago son una emergencia. La severidad cruzada con el impacto de negocio manda sobre cualquier recuento.
Auditar y no actuar. El error más caro. Si no hay presupuesto ni intención de ejecutar al menos los quick wins, la auditoría solo habrá servido para documentar un riesgo que ya intuías. Reserva desde el principio una partida para la remediación inicial.
Usar el informe como arma interna. El objetivo es mejorar el sistema, no señalar culpables. Los equipos que reciben una auditoría como ataque se ponen a la defensiva y el plan de remediación muere. Presentarla como inversión en el producto —y no como examen al equipo— multiplica su efectividad.
10. Después del informe: ejecutar la remediación sin parar el negocio
El informe no es el final del proceso, es el principio del retorno. La remediación eficaz sigue tres principios:
Quick wins primero. Las primeras dos semanas se dedican a los hallazgos de alto impacto y bajo esfuerzo: actualizar dependencias vulnerables, eliminar secretos del repositorio, añadir validación en los puntos de entrada críticos. Genera confianza y reduce riesgo real de inmediato.
Refactorización incremental ligada a roadmap. Los bloques grandes (reordenar arquitectura, subir cobertura de tests, desacoplar módulos) se ejecutan por fases dentro del trabajo normal de producto, priorizando las zonas que el roadmap va a tocar de todos modos. Refactorizar un módulo que nadie va a modificar en un año rara vez es la mejor inversión.
Blindar lo ganado en CI. Cada mejora se consolida incorporando las herramientas de la auditoría al pipeline: análisis estático con umbrales que impiden retroceder, auditoría de dependencias automática, cobertura mínima por módulo. Así la siguiente auditoría no vuelve a encontrar los mismos problemas, y el coste de mantener la calidad se reparte en el día a día en lugar de acumularse en crisis periódicas.
Este acompañamiento posterior es, de hecho, donde un buen socio técnico marca la diferencia: no solo decirte qué está mal, sino ayudarte a corregirlo con un mantenimiento de software continuo que integre la calidad en el ciclo de desarrollo.
¿Necesitas saber en qué estado está realmente tu código?
En Keliam auditamos plataformas web, ecommerce y software a medida: análisis estático, revisión experta y un plan de remediación priorizado que tu equipo puede ejecutar desde la primera semana.
Conclusión: evidencia antes que opiniones
Una auditoría de código profesional convierte una sensación difusa —»creo que este código no está bien»— en un diagnóstico con evidencia, prioridades y coste estimado. Para un CTO es una herramienta de gestión de riesgo; para un founder, un seguro antes de comprar o escalar; para un equipo, la oportunidad de convertir la deuda invisible en un backlog ordenado. El proceso importa tanto como el resultado: exige análisis automático más revisión manual, hallazgos con evidencia concreta y un plan de remediación accionable. Todo lo demás es un PDF que acabará en un cajón.
Preguntas frecuentes sobre la auditoría de código
¿Cuánto dura una auditoría de código?
Entre una y cuatro semanas según el tamaño del proyecto y la profundidad del análisis. El grueso del calendario lo marca la revisión manual: el análisis automático se completa en días.
¿Necesito dar acceso a todo mi repositorio?
Idealmente sí, en modo solo lectura y bajo NDA. El historial de commits aporta información valiosa (hotspots, autoría, evolución). Si hay módulos sensibles, pueden excluirse del alcance de forma explícita.
¿Una auditoría de código incluye pentesting?
No. La auditoría analiza el código fuente en estático; el pentesting ataca el sistema en ejecución. Son complementarios: la primera encuentra vulnerabilidades en el fuente y el segundo demuestra cuáles son explotables. Muchos clientes contratan ambos como paquete.
¿Cada cuánto conviene repetirla?
Tras la remediación inicial, una revisión anual o tras hitos importantes (migración de framework, cambio de equipo, crecimiento fuerte) es suficiente si el equipo mantiene análisis estático en CI de forma continua.
