La revisión manual de código es la inspección línea por línea del código fuente hecha por una persona, para encontrar fallas de seguridad que dependen del contexto: quién puede llamar una función, qué permiten las reglas del negocio y si un control que parece estar presente de verdad se sostiene. El análisis automatizado trabaja con patrones. La revisión manual de código trabaja razonando sobre la intención.
La brecha entre las dos se puede medir. En el benchmark de Fluid Attacks de 36 herramientas AppSec de terceros contra una aplicación web con 1.201 vulnerabilidades en 105 categorías CWE, un pentester encontró 743 fallas que ninguna herramienta reportó: el 61,9 % del total, con el 86,8 % de la exposición al riesgo de la aplicación. El benchmark mide las pruebas manuales de un pentester, no solo la revisión de código seguro, y esta página lo usa para mostrar lo que el análisis manual agrega a las herramientas automatizadas.
Esta página cubre qué es la revisión manual de código, cómo elegir qué se revisa primero, qué comprueba un revisor, en qué cambia la revisión de código generado por IA y cómo saber si la revisión de verdad redujo el riesgo. Para la metodología completa del servicio en cuatro etapas, consulta Revisión de Código Seguro.
¿Qué es la revisión manual de código?
La revisión manual de código es la inspección sistemática del código fuente por parte de revisores humanos para encontrar fallas de seguridad y confirmar que el código cumple los estándares de seguridad. La documentación de Fluid Attacks la define en esos términos y añade que este análisis experto “frequently finds severe and complex vulnerabilities that automated tools alone cannot find”.
Antes de seguir, dos distinciones. La revisión manual de código no es lo mismo que una revisión entre pares estándar: la revisión entre pares pregunta si el código funciona y se lee bien, mientras que la revisión manual de código pregunta si un atacante puede abusar de él. Las dos usan listas de verificación distintas y, por lo general, personas distintas. Tampoco es lo opuesto al análisis automatizado. En el proceso de Fluid Attacks, SAST y SCA corren primero, y sus hallazgos se usan para filtrar falsos positivos y guiar la investigación manual más profunda.
Por qué la revisión manual de código sigue importando
Los escáneres reconocen patrones conocidos; la revisión manual de código resuelve el significado. La OWASP DevSecOps Guideline, en su actualización de octubre de 2026, plantea la división sin rodeos: “Automated scanners find known patterns; human review finds the flaws that need context”, y señala que “Scanners rarely detect broken access control or business-logic flaws”.
Dos estándares ponen la revisión de código dentro del proceso formal de desarrollo. Ninguno exige la revisión manual de código como tal: NIST deja a la organización la elección entre revisión humana y análisis con herramientas, y PCI DSS acepta revisión manual, automatizada o combinada.
NIST SP 800-218 (SSDF 1.1, febrero de 2022) dedica la práctica PW.7 a revisar código legible por humanos. La tarea PW.7.1 le pide a la organización decidir “whether code review (a person looks directly at the code to find issues) and/or code analysis” aplica; PW.7.2 pide que la revisión se haga contra estándares de codificación segura y que los hallazgos se registren y prioricen en el flujo de trabajo del equipo de desarrollo.
PCI DSS v4.0.1: el requisito 6.2.3 establece que “Bespoke and custom software is reviewed prior to being released into production” y permite que la revisión se haga “using either manual or automated processes, or a combination of both”. El requisito 6.2.3.1 regula específicamente el caso manual: el revisor debe ser alguien distinto del autor del código, debe tener competencia en técnicas de revisión y codificación segura, y la gerencia debe aprobar el resultado antes del despliegue.
Fluid Attacks mapea la práctica PW.5.1 del NIST SSDF, prácticas de codificación segura, a siete requisitos de seguridad que un revisor puede comprobar.
Ninguno de los dos estándares trata la revisión de código como un trámite. NIST pide que los problemas y las remediaciones recomendadas se registren y prioricen en el flujo de trabajo del equipo de desarrollo, y PCI DSS pide correcciones antes del despliegue.
La revisión manual de código en Fluid Attacks
Fluid Attacks ejecuta la revisión manual de código como Secure Code Review, un servicio del plan Advanced en el que los analistas inspeccionan el código fuente junto con las pruebas automatizadas que corren sobre el mismo repositorio.
Qué revisamos y en qué orden
Nadie lee un millón de líneas a mano, así que el orden es el método. Fluid Attacks usa IA para predecir los archivos de alto riesgo y revisarlos primero, y modelos estadísticos “identify the systems and components that require the most attention”. El esfuerzo de prueba sigue al riesgo, no a una cobertura uniforme de archivos.
Cómo se ve un hallazgo
Un hallazgo de la revisión manual de código solo sirve si un desarrollador puede actuar sobre él. Cada uno llega a la plataforma con el archivo y la línea afectados, una puntuación de severidad CVSS v4.0, su estado de remediación y la debilidad con la que se corresponde en la base de datos pública de Fluid Attacks. Ese enlace hace que un hallazgo de la revisión manual de código se pueda comprobar: cualquiera puede abrir la entrada y leer el impacto, la recomendación y el requisito de seguridad vinculado.
Contra qué compara un revisor: la debilidad 013 y el requisito de seguridad al que está vinculada.
Revisión manual de código frente a análisis automatizado, con cifras propias
Evaluador | Precisión | Recall (vulnerabilidades) | Recall (exposición al riesgo) |
|---|---|---|---|
Pentester de Fluid Attacks | 100 % | 89,6 % | 98,9 % |
Escáner de Fluid Attacks | 99 % | 22,7 % | 8,8 % |
Herramienta de terceros con más verdaderos positivos | 72 % | 21,6 % | 4,0 % |
Promedio de las demás herramientas de terceros | — | 1,7 % | — |
Resultados del benchmark de Fluid Attacks contra una aplicación web con 1.201 vulnerabilidades; la fila del pentester corresponde a pruebas manuales. Diecisiete herramientas no lograron identificar ni diez.
El límite de nuestras propias cifras: más hallazgos no es más riesgo cubierto
Si se lee la tabla por columnas, dice algo que las cifras principales esconden. El escáner propio de Fluid Attacks alcanza 22,7 % de recall en número de vulnerabilidades, pero solo 8,8 % de la exposición al riesgo: encuentra una parte respetable de las fallas y una parte pequeña del peligro. Las vulnerabilidades que pesan son las que necesitan contexto, y ese es el argumento completo a favor de la revisión manual de código expresado como una proporción.
Una salvedad más sobre el alcance. El análisis de Fluid Attacks sobre pruebas de seguridad de 2023 en sistemas de clientes encontró que el 71,4 % de la exposición al riesgo fue reportado solo por métodos manuales. Esa cifra describe los métodos manuales en conjunto, no la revisión manual de código por sí sola.
Dónde termina la revisión: el reattack
Una revisión manual de código que se detiene en el reporte deja abierta la pregunta más importante. Cuando un desarrollador corrige un hallazgo, el cliente solicita un reattack en la plataforma y, en los hallazgos manuales, un pentester hace la verificación (Platform FAQ). Sobre las funciones privilegiadas, Juan Restrepo, Certified DevSecOps Professional, escribe en el análisis de Fluid Attacks sobre el hackeo a Binance:
“In our Secure Code Review, analysts trace who can call each of these functions and with which identity”.
(En nuestra Revisión de Código Seguro, los analistas rastrean quién puede llamar a cada una de estas funciones y con qué identidad).
Cómo decidir qué revisar primero
Una revisión de código basada en riesgo es lo que hace viable la revisión manual de código a escala. En vez de repartir la atención por igual, concentra las horas de revisión donde un error cambia en quién se confía. La OWASP DevSecOps Guideline lista los tipos de cambio que justifican una mirada más profunda:
Código sensible para la seguridad: autenticación, manejo de sesiones, autorización, criptografía, procesamiento de entradas, deserialización y carga de archivos.
Cambios en los límites de confianza: nuevos endpoints públicos, integraciones con terceros, nuevos almacenes de datos y cambios en CORS o en la exposición de red.
Cambios en construcción y entrega: flujos de CI, Dockerfiles, manifiestos de infraestructura y scripts de despliegue, revisados como código de producción.
Cambios en dependencias: paquetes nuevos o actualizados y diferencias en los lockfiles, con revisión de procedencia, mantenedores y scripts de instalación.
Cambios grandes o inusuales: diffs muy grandes, código generado y cambios de colaboradores nuevos, que conviene dividir o asignar a un segundo revisor.
Todo lo que está en esa lista comparte una propiedad: el daño no se queda en la línea. Un nuevo endpoint público o una integración vuelve a trazar los límites de confianza del sistema, y OWASP pide revisar esos cambios contra el modelo de amenazas, algo que exige un contexto que un escáner rara vez tiene. Una revisión manual de código basada en riesgo justifica su costo ahí, no en cambios que alteran lo que muestra una pantalla.
Una lista de verificación para la revisión manual de código mantiene ese foco de forma repetible. Validación de entradas, autenticación y gestión de contraseñas, control de acceso y gestión de sesiones, criptografía y protección de datos, manejo de errores y logging, y configuración del sistema son los encabezados recurrentes, cada uno atado a un requisito de seguridad que el revisor puede comprobar en vez de dejarlo a criterio.
Revisión integral frente a revisión de cambios
La revisión manual de código tiene dos formas. El Secure Code Review Cheat Sheet de OWASP las separa: las revisiones integrales (baseline) “examine the entire codebase comprehensively”, mientras que las revisiones de cambios (diff-based) “focus on code changes only”.
Revisión manual de código integral | Revisión manual de código de cambios | |
|---|---|---|
Alcance | Toda la base de código | Solo las líneas que un cambio agrega o altera |
Cuándo hacerla | Aplicaciones nuevas, versiones mayores, incorporación de sistemas heredados, cumplimiento, análisis posterior a incidentes | Pull requests, commits, desarrollo diario, validación continua |
Qué responde | Qué riesgo ya está en producción | Qué riesgo introduce este cambio |
Frecuencia | En hitos y eventos que la detonan | Con cada cambio |
Las dos funcionan juntas. El enfoque híbrido de OWASP combina revisiones integrales para los componentes de alto riesgo con revisiones de cambios para los cambios rutinarios, y escala de la revisión de cambios a la integral cuando aparecen preocupaciones de seguridad importantes. Un equipo que hace revisión manual de código solo sobre los pull requests nunca examina el código que heredó.
Qué encuentra la revisión manual de código que los escáneres no ven
Las fallas reservadas para la revisión manual de código comparten un rasgo: el código es sintácticamente correcto y aun así está mal. El control de acceso roto es la familia más clara: OWASP señala que los escáneres, incluidas las Pruebas Estáticas de Seguridad de Aplicaciones (SAST), rara vez lo detectan, porque una verificación de permisos puede existir en el código y aun así verificar lo equivocado para el usuario equivocado. Estas entradas de la base de datos de Fluid Attacks muestran qué busca en realidad una revisión manual de código.
Qué revisa el analista | Debilidad de la base de datos | Qué comprueba |
|---|---|---|
Autorización y roles | Que una cuenta estándar no pueda obtener privilegios de administrador. Requisito vinculado: 035, gestionar las modificaciones de privilegios. | |
Gestión de secretos | Que no haya credenciales en el repositorio ni en su historial de git. Requisito vinculado: 156. | |
Control de acceso a objetos | Que un usuario no pueda llegar a los datos de otro cambiando un valor de clave. Requisito vinculado: 176. | |
Concurrencia | Que la verificación y el uso de una entrada ocurran de forma atómica. Requisito vinculado: 337. |
Las fallas de lógica de negocio entran en la misma lista. Si una transferencia de dinero acepta un monto negativo, todas las verificaciones de tipo pasan y el retiro se convierte en un depósito. Ningún archivo de reglas describe esa falla, porque la regla que rompe solo existe en el negocio, y por eso los escáneres rara vez detectan estas fallas. Una condición de carrera se comporta igual: cada línea es válida y solo el orden de llegada expone el problema.
El fallo goto fail de Apple en 2014 (CVE-2014-1266) muestra el mismo rasgo en una sola línea. Una línea goto fail; duplicada dentro de SSLVerifySignedServerKeyExchange, sin llaves alrededor del condicional, dejó inalcanzables las verificaciones de certificado restantes e hizo que la función devolviera éxito, lo que permitió a atacantes de intermediario (man-in-the-middle) suplantar servidores SSL. El análisis del fallo del investigador de seguridad David A. Wheeler concluye: “Just about any manual review is very likely to have found this”. También lista otros controles que lo habrían detectado, entre ellos la detección de código inalcanzable, el uso obligatorio de llaves y el análisis de cobertura de pruebas, así que la revisión manual de código funciona mejor como un control entre varios.
Revisar código generado por IA
La revisión manual de código generado por IA es hoy el caso de mayor volumen, y el modo de falla cambió con ella. El código compila, se lee limpio y omite controles que nadie pidió. El Secure Coding with AI Cheat Sheet de OWASP traza la línea de la responsabilidad: “AI-generated code must have a human owner”, porque “AI tools do not accept responsibility for the code they generate. The developer who accepts and commits the code does”.
Tres cosas que una revisión manual de código tiene que comprobar aquí y que los hábitos generales de revisión no cubren:
Dependencias que no existen. OWASP señala que los asistentes “frequently suggest package names that do not exist on public registries”, una puerta para un atacante que registre el nombre inventado.
Controles omitidos por silencio. La DevSecOps Guideline apunta a “Missing authorization and input validation, which models omit when the prompt does not mention them”.
Comprensión por parte del autor. La misma guía fija un filtro útil: “If the author cannot describe how it works, it is not ready to merge”. También sostiene que el código generado “needs at least the same scrutiny as code from an unknown contributor”.
Un revisor automatizado que comenta el cambio no reemplaza aquí a una revisión manual de código. OWASP es explícito en que los comentarios de revisión generados por IA no sustituyen la revisión humana, y en que “a human with accountability must still approve security-relevant changes”. El análisis de Fluid Attacks sobre cómo el desarrollo con agentes desplaza la responsabilidad llega a la misma conclusión: la ejecución escala, el criterio no.
Cómo medir si la revisión funcionó
En la revisión manual de código, encontrar una falla no es el resultado. Un estudio empírico de 135.560 comentarios de revisión de código en OpenSSL y PHP, de investigadores de la Universidad de Melbourne y la Singapore Management University (2023), encontró que los revisores plantearon preocupaciones de seguridad en 35 de 40 categorías de debilidades de codificación, y que entre el 30 % y el 36 % de esas preocupaciones solo se reconocieron, sin corregirse, mientras que entre el 18 % y el 20 % quedaron sin resolver porque revisores y desarrolladores no se pusieron de acuerdo en la solución.
Ese es el número que hay que gestionar. Un programa de revisión manual de código que reporta hallazgos y nunca comprueba su cierre está midiendo actividad, no riesgo. Tres métricas describen el resultado: la proporción de hallazgos remediados, el tiempo desde el reporte hasta la corrección verificada y la proporción de reattacks que pasan en el primer intento. La precisión y el recall describen qué tan bien detecta la revisión manual de código; estas tres describen si sirvió de algo.
Heartbleed muestra por qué muchos lectores no equivalen a una revisión que funcionó. El código defectuoso del heartbeat de OpenSSL se introdujo en diciembre de 2011 y salió en OpenSSL 1.0.1 el 14 de marzo de 2012; la corrección llegó en 1.0.1g el 7 de abril de 2014 (heartbleed.com). El relato de CSO señala que cualquiera podía leer el código y “presumably hundreds did”, y que la falla “lurked undetected for two years” hasta que Neel Mehta, de Google, decidió hacer una auditoría línea por línea del código de OpenSSL. Al momento de la divulgación, Netcraft encontró la extensión heartbeat habilitada en el 17,5 % de los sitios SSL, alrededor de medio millón de certificados emitidos por autoridades de certificación de confianza. Por eso las tres métricas anteriores miden resultados, no actividad.
Revisión manual de código frente a revisión automatizada de pull requests
Son trabajos distintos, y confundirlos genera una falsa sensación de seguridad. Un revisor automatizado de pull requests analiza las líneas que agrega un cambio; una revisión manual de código analiza qué significa ese cambio para el sistema.
El Peer Reviewer Assistant de Fluid Attacks ilustra con precisión la mitad automatizada. Reporta “the vulnerabilities that the change introduces”, compara contra la base del merge y solo reporta sobre las líneas agregadas, con SAST, SCA y escaneo de secretos. Publica un comentario de resumen por cambio, hace fallar su verificación de estado cuando una puntuación CVSS 4.0 supera el umbral “Minimum to break the build” y, algo importante, no bloquea los merges por sí solo a menos que el equipo haga obligatoria la verificación.
Lo que no puede hacer es decidir si un cambio de autorización bien escrito es el cambio de autorización correcto. Esa sigue siendo una pregunta de la revisión manual de código y, junto con las pruebas de penetración manuales, es la razón por la que las técnicas humanas corren junto con las automatizadas en vez de que una reemplace a la otra.
▶️ Video: mostramos cómo nuestra herramienta basada en IA hace revisión de seguridad automática y contextual en los pull requests, y dónde sigue siendo necesario el criterio humano.
Conclusiones
La revisión manual de código lee el código según lo que se supone que debe hacer, y ahí es donde los escáneres rara vez miran. El benchmark de Fluid Attacks muestra qué tan grande puede ser la brecha para las pruebas manuales en general: el 86,8 % de la exposición al riesgo de la aplicación estaba en fallas que ninguna herramienta automatizada reportó. Los estándares apuntan en la misma dirección (PCI DSS v4.0.1 exige revisión de código antes del despliegue y el SSDF de NIST la nombra como práctica), pero el cumplimiento es el piso, no la razón.
La versión práctica de la revisión manual de código es más acotada que “revisarlo todo”. Haz una revisión de código basada en riesgo para elegir los objetivos, separa la pasada integral de la pasada por cambio, aplica más escrutinio al código que escribió un modelo y verifica que cada hallazgo de verdad se cerró. Las prácticas de codificación segura le dan al revisor el estándar contra el cual comparar; el reattack le da a la organización la prueba. Una revisión manual de código que termina en el reporte hizo la parte cara del trabajo y se saltó la parte que reduce el riesgo.
Preguntas frecuentes
¿Cuál es la diferencia entre revisión de código y revisión manual de código?
La revisión de código es la práctica general de evaluar el código fuente contra estándares, y la pueden hacer herramientas o personas. La revisión manual de código es específicamente la mitad humana: un revisor que lee el código para encontrar fallas de seguridad que dependen del contexto, como la lógica de autorización, las reglas de negocio y los límites de confianza. El análisis automatizado comprueba los patrones para los que fue configurado.
¿Las herramientas automatizadas pueden reemplazar la revisión manual de código?
No. En el benchmark de Fluid Attacks de 36 herramientas AppSec de terceros contra una aplicación web con 1.201 vulnerabilidades, la herramienta de terceros con más verdaderos positivos alcanzó 21,6 % de recall y 4,0 % de la exposición total al riesgo, mientras que un pentester haciendo pruebas manuales alcanzó 89,6 % de recall con 100 % de precisión. Las herramientas cubren amplitud a bajo costo; el análisis manual cubre más de las fallas que cargan el riesgo.
¿PCI DSS exige revisión manual de código?
No específicamente. El requisito 6.2.3 de PCI DSS v4.0.1 exige que el software a medida y personalizado se revise antes de pasar a producción, y acepta procesos manuales, automatizados o ambos. Si la organización elige la revisión manual, el requisito 6.2.3.1 agrega condiciones: el revisor no puede ser el autor del código, debe tener competencia en codificación segura y técnicas de revisión, y la gerencia debe aprobar el resultado.
¿Cómo se debe revisar el código generado por IA?
Con el mismo escrutinio que se aplica a un cambio de un colaborador desconocido. OWASP exige que ese código tenga un responsable humano que lo haya revisado y entendido, y señala tres problemas recurrentes: paquetes sugeridos por el modelo que no existen, autorización y validación de entradas omitidas porque el prompt no las mencionaba, y autores que no pueden explicar cómo funciona el código.
¿Fluid Attacks hace revisión manual de código?
Sí. Su revisión manual de código es el servicio Secure Code Review del plan Advanced, en el que analistas de seguridad inspeccionan el código fuente en paralelo con las pruebas automatizadas. La IA predice los archivos de alto riesgo para que los revisores empiecen por ahí, los hallazgos llegan con su archivo, línea, severidad CVSS v4.0 y un enlace a la entrada de la debilidad, y un pentester verifica las correcciones de los hallazgos manuales cuando se solicita un reattack.
Revisa el código antes que un atacante
Nuestros analistas hacen revisión manual de código sobre tu código fuente desde el primer commit, junto con los escáneres, para que las fallas sobre las que una herramienta no puede razonar se encuentren mientras todavía son baratas de corregir. Prueba gratuita · Contáctanos.
Empieza ya con la solución de seguridad de aplicaciones de Fluid Attacks
