Auditoría de código: lista de comprobación para revisar software ajeno

Una auditoría de código es la revisión sistemática de una base de código por parte de alguien que no la ha construido. Responde a tres preguntas: si el software es lo bastante seguro para su finalidad, si se puede seguir desarrollando con un esfuerzo razonable y qué riesgos asume usted con él, en el plano técnico, de licencias y regulatorio.

¿Cuándo necesito una auditoría de código?

Siempre que asuma la responsabilidad de un código que no ha escrito. Cinco motivos típicos:

• Traspaso desde un proveedor de servicios. El caso más frecuente y el que más sorpresas puede deparar.
• Antes de una compra o una participación. Due diligence técnica: aquí el resultado decide el precio.
• Antes de poner en producción un prototipo. Especialmente relevante si se creó con herramientas de IA, véase Del prototipo a producción.
• Tras un incidente de seguridad. No solo la vulnerabilidad explotada, sino la pregunta de si el mismo patrón existe también en otro lugar.
• Antes de una inversión mayor. Antes de invertir un año de desarrollo en una base cuya solidez nadie ha comprobado.

La lista de comprobación: seis áreas que una auditoría debe revisar

Una auditoría que solo revisa la primera área es un escaneo de seguridad. Puede contrastar estos seis puntos con una oferta como lista de comprobación: si falta alguno, pregunte.

• Seguridad. Patrones de vulnerabilidad conocidos según el OWASP Top 10:2025, gestión de credenciales, autenticación y permisos, tratamiento de las entradas.
• Mantenibilidad. Estructura, duplicados, complejidad, cobertura de pruebas, comprensibilidad para alguien que se incorpora.
• Dependencias. Qué paquetes, qué versiones, qué vulnerabilidades conocidas, con qué actividad de mantenimiento, qué profundidad tiene la cadena. Desde 2025, los fallos de la cadena de suministro son una categoría OWASP propia (A03).
• Licencias. Qué licencias hay en lo existente y si son compatibles con su modelo de negocio. Una licencia copyleft en un producto cerrado es un hallazgo que eclipsa todo lo demás.
• Operación. ¿Se puede desplegar, monitorizar y revertir? ¿Existe un entorno reproducible o solo funciona en un equipo concreto?
• Derecho y regulación. Qué datos personales se tratan y con qué base. ¿Entra el producto en el Cyber Resilience Act, cuyas obligaciones de notificación se aplican a partir del 11 de septiembre de 2026?

¿Cómo transcurre una auditoría de código?

En cinco pasos, y el primero decide la calidad de todo el resultado.

• 1. Aclarar la finalidad. Una auditoría previa a una compra busca cosas distintas que una posterior a un incidente. Sin esta definición se obtiene un informe que lo menciona todo y no decide nada.
• 2. Recopilar automáticamente. Análisis estático, revisión de dependencias y licencias, duplicados, complejidad, cobertura de pruebas, frecuencia de cambio a partir del historial de versiones. Es la base, no el resultado.
• 3. Leer de forma selectiva. Una persona lee las áreas que destacan en el paso 2, y siempre además: autenticación, permisos, pagos, acceso a datos. Una lectura completa no es asumible económicamente con un tamaño realista y tampoco es necesaria.
• 4. Documentar. Cada hallazgo con su ubicación y un escenario concreto de cómo repercute. Un hallazgo sin repercusión es una opinión.
• 5. Priorizar. Por daño multiplicado por probabilidad de ocurrencia, con estimación de esfuerzo. Una lista de 200 puntos del mismo rango no ayuda a nadie.

¿Cómo reconozco una auditoría superficial?

Por cuatro rasgos que desembocan todos en lo mismo: se ejecutó una herramienta y se exportó el informe.

• Consiste sobre todo en salidas de herramientas. Sin valorar qué hallazgo cuenta realmente en este proyecto.
• Falta la lógica de negocio. Ninguna herramienta juzga si las reglas de permisos encajan con el modelo de negocio. Justo ese es el hallazgo más caro.
• Sin priorización. Todo es «medio».
• Sin indicación del alcance. Una auditoría seria indica qué no se revisó. La ausencia de límites es en sí misma una señal de alarma.

¿Cuánto cuesta una auditoría de código?

La respuesta honesta: depende casi por completo del alcance y de la finalidad, y los importes globales de las guías son observación de mercado, no valores fiables.

Lo que se puede decir con seriedad: el esfuerzo no escala con el número de líneas, sino con el número de componentes independientes y la profundidad del juicio deseado. Una auditoría que solo recoge y valora las seis áreas anteriores con herramientas automáticas es una fracción de una auditoría que penetra en la lógica de negocio de los permisos.

Por eso no pida una oferta a tanto alzado, sino una estimación de esfuerzo por área: así podrá decidir dónde hace falta profundidad. Si desea encargar una revisión de este tipo, nuestro desarrollo de software y SaaS es la puerta de entrada.

Preguntas frecuentes sobre la auditoría de código

¿Puede una IA realizar una auditoría de código?

Puede acelerar considerablemente el paso 2 y partes del paso 3: encontrar patrones, explicar relaciones, preclasificar hallazgos. No puede hacer los pasos 1 y 5: definir la finalidad y priorizar según el riesgo empresarial presupone conocer la empresa.

¿Cuánto dura una auditoría?

Para un proyecto de tamaño medio, el marco habitual va de unos pocos días a pocas semanas. El rango es tan amplio porque el paso 3 depende del resultado del paso 2: antes no se puede fijar con seriedad.

¿Debería el propio proveedor auditar su propia obra?

Para un inventario es útil. Para un juicio que vaya a ser la base de una decisión de compra o de una negociación contractual, la independencia de quien revisa forma parte del valor.

¿Qué hago con el resultado?

Los hallazgos críticos, de inmediato; los caros, a la planificación; el resto, a una lista que se resuelve la próxima vez que se toque el área correspondiente. Una auditoría cuyo resultado debiera resolverse por completo en un proyecto aparte rara vez se financia.

Una auditoría es una instantánea; el hallazgo más caro es el que vuelve a aparecer medio año después. Code Guardian hace que las comprobaciones que una auditoría realiza una sola vez se ejecuten con cada cambio.

Fuentes

• OWASP Top 10:2025 (marco de revisión para la parte de seguridad), versión final de enero de 2026.
• Reglamento (UE) 2024/2847 (Cyber Resilience Act), obligaciones de notificación a partir del 11 de septiembre de 2026, obligaciones principales a partir del 11 de diciembre de 2027.
• ISO/IEC 25010:2023 (marco de referencia para la parte de mantenibilidad).

Fecha: 27 de julio de 2026. Valoración técnica general, sin asesoramiento jurídico ni compromiso de precio; los esfuerzos deben estimarse en cada caso.