En resumen
Una auditoría de código lee la aplicación como un atacante: revisa accesos, sesiones, datos, dependencias y configuración con herramientas y revisión humana, y entrega cada hallazgo con su riesgo y su corrección. Conviene antes de lanzar, tras cambios grandes o si la app se hizo con IA.
Una auditoría de código es una revisión del código fuente de una aplicación para encontrar fallas de seguridad antes de que alguien las aproveche. Revisa quién puede ver y cambiar cada dato, cómo se manejan las sesiones, qué dependencias usa la aplicación y cómo llega el código a producción. En este artículo explicamos qué cubre, cómo se hace paso a paso, qué deberías recibir al final y en qué momentos conviene hacerla.
Qué es una auditoría de código
El NIST, el instituto de estándares de Estados Unidos, distingue dos formas de revisar el código en su marco de desarrollo seguro (SSDF, SP 800-218): la revisión de código, en la que una persona mira directamente el código para encontrar problemas, y el análisis de código, en el que se usan herramientas, solas o con una persona, para el mismo fin. Una auditoría seria usa las dos.
La diferencia con una prueba de penetración está en el punto de partida. La prueba de penetración ataca la aplicación desde afuera, sin ver el código. La auditoría lee el código, así que encuentra fallas que desde afuera no se ven, como una regla de permisos mal escrita que solo se activa en un caso raro.
Qué revisa una auditoría de código
La referencia más usada es el OWASP Top 10, la lista de los riesgos más importantes en aplicaciones web que publica la fundación OWASP. Su edición 2025 tiene estas diez categorías:
- A01:2025 Broken Access Control
- A02:2025 Security Misconfiguration
- A03:2025 Software Supply Chain Failures
- A04:2025 Cryptographic Failures
- A05:2025 Injection
- A06:2025 Insecure Design
- A07:2025 Authentication Failures
- A08:2025 Software or Data Integrity Failures
- A09:2025 Security Logging and Alerting Failures
- A10:2025 Mishandling of Exceptional Conditions
En la práctica, esa lista se traduce en seis áreas que revisamos en cada proyecto:
- Accesos y permisosQuién puede ver, crear o cambiar cada dato, y si un usuario puede darse más permisos que los suyos.
- Autenticación y sesionesContraseñas, códigos de acceso, límites de intentos y cierre de sesiones de usuarios desactivados.
- Datos y criptografíaQué se guarda cifrado, qué queda en texto plano y qué datos personales quedan en el navegador.
- Entradas e inyecciónFormularios, archivos subidos y parámetros que podrían ejecutar código o consultas no previstas.
- DependenciasLibrerías con vulnerabilidades conocidas y paquetes que no se actualizan.
- Configuración y despliegueSecretos, cabeceras de seguridad, registros y cómo llega cada cambio a producción.
Cómo se hace, paso a paso
Una auditoría no es correr un programa y entregar el reporte que genera. Este es el proceso que seguimos:
- 1Alcance y autorizaciónSe define qué aplicaciones, repositorios y servidores entran, y se firma la autorización antes de empezar.
- 2Análisis automáticoHerramientas de análisis estático y de dependencias recorren todo el código y marcan patrones conocidos.
- 3Revisión manualUna persona lee los flujos críticos: accesos, sesiones, pagos, archivos y datos personales.
- 4ValidaciónCada hallazgo se confirma en un entorno de prueba para descartar falsos positivos.
- 5InformeCada hallazgo se documenta con su riesgo, su ubicación, cómo reproducirlo y cómo corregirlo.
- 6VerificaciónDespués de corregir, se revisa de nuevo y cada corrección queda cubierta por una prueba.
El NIST pide lo mismo en su marco: registrar y priorizar cada problema encontrado, junto con la corrección recomendada, dentro del flujo de trabajo del equipo, e identificar la causa raíz de cada uno.
Herramientas automáticas y revisión humana
Las herramientas de análisis estático (SAST) son útiles y escalan bien: se pueden correr sobre todo el código en cada cambio y señalan el archivo y la línea exacta de patrones conocidos, como la inyección SQL. Pero la propia OWASP enumera sus límites:
Herramienta automática
- Escala a todo el código y se repite en cada cambio
- Detecta fallas conocidas como la inyección SQL
- Señala archivo, línea y fragmento afectado
- Genera muchos falsos positivos
Revisión humana
- Encuentra problemas de autenticación y control de acceso
- Detecta usos inseguros de la criptografía
- Revisa la configuración, que no siempre está en el código
- Confirma qué hallazgos son vulnerabilidades reales
Según OWASP, las herramientas actuales identifican solo un porcentaje relativamente pequeño de las fallas de seguridad de una aplicación. Por eso los errores más caros, como que un usuario vea los datos de otro, casi siempre los encuentra una persona.
Qué deberías recibir al final
Un buen informe no es una lista de alertas copiadas de una herramienta. Cada hallazgo debería traer:
- Nivel de riesgo: crítico, alto o medio, para saber qué atender primero.
- Ubicación: el archivo y la parte del código donde está la falla.
- Cómo reproducirlo: los pasos para comprobar que el problema existe.
- Cómo corregirlo: la solución concreta, no solo la descripción del riesgo.
Si tu equipo quiere un estándar para exigir en un contrato, OWASP mantiene el ASVS (Application Security Verification Standard), cuya versión 5.0.0 se publicó el 30 de mayo de 2025. Sirve como lista de requisitos de seguridad para medir una aplicación y para especificarlos en una contratación.
Cuándo conviene hacer una auditoría de código
Estos son los momentos en que una auditoría evita más problemas de los que cuesta:
- Antes de lanzar una aplicación que va a guardar datos personales, de clientes o de pagos.
- Si la aplicación se hizo con IA y nadie leyó el código completo. Veracode encontró que el 45 % del código generado por más de 100 modelos de IA introdujo vulnerabilidades del OWASP Top 10. Lo explicamos en cómo auditar una app hecha con vibe coding.
- Después de una migración o una reescritura. Cambiar de tecnología no deja la aplicación segura por sí solo.
- Al heredar código de otro proveedor o de un desarrollador que ya no está.
- Cuando aparece una vulnerabilidad grave en una tecnología que usas, como pasó con las fallas de PHP que contamos en Octubre negro.
Un caso real: 34 hallazgos en una plataforma que ya funcionaba
En una plataforma de gestión que acababa de reconstruirse, la primera auditoría encontró 34 hallazgos y una segunda pasada sumó 29 más. Entre ellos: un administrador podía darse más permisos que los suyos, los usuarios desactivados conservaban la sesión y las dependencias tenían 3 vulnerabilidades críticas y 22 altas conocidas. Cada corrección quedó cubierta por una prueba, y la suite pasó de 729 a más de 3.000 pruebas.
Cuánto tarda y de qué depende el costo
No hay un precio único, porque el esfuerzo depende del tamaño del código, del número de roles y flujos críticos, de cuántas integraciones tiene la aplicación y de si incluye la revisión del servidor. Una aplicación pequeña con un solo rol no se revisa igual que una plataforma con pagos, varios tipos de usuario y una API pública.
Por eso empezamos con una llamada para entender la aplicación y luego enviamos una propuesta con el alcance y el tiempo estimado. Si además tu servidor necesita revisión, te sirve nuestro checklist de seguridad para servidores y dependencias.
Fuentes
- OWASP Top 10:2025, OWASP Foundation
- Source Code Analysis Tools, OWASP Foundation
- Application Security Verification Standard (ASVS), OWASP Foundation
- SP 800-218, Secure Software Development Framework (SSDF) Version 1.1, NIST
- We Asked 100+ AI Models to Write Code. Here's How Many Failed Security Tests, Veracode
Preguntas frecuentes
¿Qué es una auditoría de código?
Es una revisión del código fuente de una aplicación para encontrar fallas de seguridad antes de que alguien las aproveche. Combina herramientas automáticas que recorren todo el código con una revisión humana de los flujos críticos, como accesos, sesiones y datos personales.
¿En qué se diferencia de una prueba de penetración?
La prueba de penetración ataca la aplicación desde afuera, sin ver el código. La auditoría lee el código, así que encuentra fallas que desde afuera no se ven, como una regla de permisos mal escrita que solo se activa en un caso raro.
¿Basta con una herramienta automática de análisis de código?
No. OWASP señala que estas herramientas identifican solo un porcentaje relativamente pequeño de las fallas, generan muchos falsos positivos y tienen dificultad para encontrar problemas de autenticación, control de acceso y criptografía. Esos los encuentra una persona.
¿Qué debe incluir el informe de una auditoría de código?
Cada hallazgo debe traer su nivel de riesgo, el lugar del código donde está, los pasos para reproducirlo y la corrección concreta. Así el equipo sabe qué atender primero y cómo comprobar que quedó resuelto.
¿Cuándo conviene auditar el código de una aplicación?
Antes de lanzar una aplicación que guarde datos personales o de pagos, si se hizo con IA y nadie leyó el código completo, después de una migración, al heredar código de otro proveedor o cuando aparece una vulnerabilidad grave en una tecnología que usas.
¿Quieres aplicarlo en tu negocio?
Cuéntanos tu caso y te decimos cómo lo resolveríamos.
Cotiza tu proyecto
Escrito por
Fundador y AI Solutions Engineer
Lidera el diseño y el desarrollo de cada proyecto, con código propio, SEO técnico y foco en resultados medibles. Como AI Solutions Engineer y Full Stack, diseña agentes de IA, automatizaciones e integraciones con MCP y APIs de modelos de lenguaje que resuelven procesos reales del negocio, y fundó Lookitry.